Misleading wikipedia article on Python 3?

[John J. Lee]

I'm surprised to read this:

http://en.wikipedia.org/wiki/Python_3

"""Note that while there is no explicit requirement that code be able
to run unmodified in both versions, in practice it is quite likely for
most code. As of January 2007, it looks like most reasonable code
should run quite well under either branch."""
I haven't been following Python 3 development recently. Have things
really changed that much? Last time I looked, e.g. dict.items() no
longer returned a list. Seems unlikely that most code will run on 2
and 3, in that case, and IIUC Guido has said all along that not much
code will run on both.

Maybe somebody who's following current Py3k goings-on can fix the
article if needed...
John

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

I'm surprised to read this:

>
http://en.wikipedia.org/wiki/Python_3

"""Note that while there is no explicit requirement that code be able
to run unmodified in both versions, in practice it is quite likely for
most code. As of January 2007, it looks like most reasonable code
should run quite well under either branch."""

It's difficult to predict the future, but I think this statement is
a fair description.

>
I haven't been following Python 3 development recently. Have things
really changed that much? Last time I looked, e.g. dict.items() no
longer returned a list.

Correct.

Seems unlikely that most code will run on 2
and 3, in that case,

Why that? Most reasonable code doesn't care what dict.items returns,
as it reads like

for k,v in dict.items():
do_something_with(k,v)

and IIUC Guido has said all along that not much
code will run on both.

I think you misunderstood. It's not a design goal that code works
without modifications, yet most reasonable code will even without
that being an explicit goal.

Regards,
Martin

[John J. Lee]

"Martin v. Löwis" <ma****@v.loewis.dewrites:

>I'm surprised to read this:

http://en.wikipedia.org/wiki/Python_3

"""Note that while there is no explicit requirement that code be able
to run unmodified in both versions, in practice it is quite likely for
most code. As of January 2007, it looks like most reasonable code
should run quite well under either branch."""

It's difficult to predict the future, but I think this statement is
a fair description.

>>
I haven't been following Python 3 development recently. Have things
really changed that much? Last time I looked, e.g. dict.items() no
longer returned a list.

Correct.

>Seems unlikely that most code will run on 2
and 3, in that case,

Why that? Most reasonable code doesn't care what dict.items returns,
as it reads like

for k,v in dict.items():
do_something_with(k,v)

We could discuss that. However, my example wasn't really intended to
relate strictly to that technical feature. Rather, to the intent of
the Python 3 developers, as suggested by things like that change, and
by what they've said over the last year or so (I think I've seen that
specific change used several times by people explaining that 2.6 / 3.0
compatibility will be impractical, which is why I chose it).

>and IIUC Guido has said all along that not much
code will run on both.

I think you misunderstood. It's not a design goal that code works
without modifications, yet most reasonable code will even without
that being an explicit goal.

I think the design goals have been fairly clear. What hasn't been
clear (to me, at least) is the practical question of the feasibility
of code working unchanged on both 2.6 and 3.0.

http://www.python.org/dev/peps/pep-3000/

"""There is no requirement that Python 2.6 code will run unmodified on
Python 3.0. Not even a subset. (Of course there will be a tiny subset,
but it will be missing major functionality.)"""
Though certainly neither quote is precise enough to pin it down
formally, certainly the tone of the first quote (from the Wikipedia
article) to my ear makes it sound like (at minimum!) it will be
practical for most projects, if they do the work to support both 3.0
and 2.6, to run simultaneously on 2.6 and 3.0 without use of a
translation tool. The second quote makes it sound like that will be
highly impractical. That picture is reinforced by what follows (in
PEP 3000):

"""
The recommended development model for a project that needs to support
Python 2.6 and 3.0 simultaneously is as follows:

0. You should have excellent unit tests with close to full
coverage.

1. Port your project to Python 2.6.

2. Turn on the Py3k warnings mode.

3. Test and edit until no warnings remain.

4. Use the 2to3 tool to convert this source code to 3.0 syntax. Do
not manually edit the output!

5. Test the converted source code under 3.0.

6. If problems are found, make corrections to the 2.6 version of
the source code and go back to step 3.

7. When it's time to release, release separate 2.6 and 3.0 tarballs
(or whatever archive form you use for releases).

It is recommended not to edit the 3.0 source code until you are ready
to reduce 2.6 support to pure maintenance (i.e. the moment when you
would normally move the 2.6 code to a maintenance branch anyway).
"""
So which is it? That is, will it be practical for most projects to
support 2.6 and 3.0 simultaneously, from the same codebase, without
relying on translation tools? I'm assuming the practicalities of this
*are* clear by now to the Python 3 developers -- is that right? It
seems to me that if I don't understand what the Python 3 developers
expect the practicalities to be, most other interested people won't
either ("interested" in the opposite sense to "disinterested" rather
than to "uninterested").
John

[=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=]

>I think you misunderstood. It's not a design goal that code works

>without modifications, yet most reasonable code will even without
that being an explicit goal.

I think the design goals have been fairly clear. What hasn't been
clear (to me, at least) is the practical question of the feasibility
of code working unchanged on both 2.6 and 3.0.

http://www.python.org/dev/peps/pep-3000/

"""There is no requirement that Python 2.6 code will run unmodified on
Python 3.0. Not even a subset. (Of course there will be a tiny subset,
but it will be missing major functionality.)"""

That's a different statement, though: It is likely that code will not
run unmodified on 3k. For example, print is now a statement, and
many many modules use that statement somewhere; they break in 3k.

However, it *is* a design goal to make 2.6 so that transition to
3k becomes simpler. That's not a 3k feature, but a 2.6 one.

Though certainly neither quote is precise enough to pin it down
formally, certainly the tone of the first quote (from the Wikipedia
article) to my ear makes it sound like (at minimum!) it will be
practical for most projects, if they do the work to support both 3.0
and 2.6, to run simultaneously on 2.6 and 3.0 without use of a
translation tool. The second quote makes it sound like that will be
highly impractical. That picture is reinforced by what follows (in
PEP 3000):

"""
The recommended development model for a project that needs to support
Python 2.6 and 3.0 simultaneously is as follows:

That's Guido's recommendation, yes: use the 2to3 tool.

There are certainly projects for which this might be the only reasonable
strategy. However, whether that will be the *common* strategy remains
to be seen. I personally believe that many projects won't need the 2to3
tool, if they are willing to compromise on the notations used in the
source code.

So which is it?

Both.

That is, will it be practical for most projects to
support 2.6 and 3.0 simultaneously, from the same codebase, without
relying on translation tools?

That remains to be seen. I believe it will be, yes. Only when people
start trying we will actually know. Personal preference will vary
across projects; some will use the conversion tool even though they
could have come up with a single-source solution, others will fight
for a single-source solution even though life would have been much
simpler with the conversion tool.

I'm assuming the practicalities of this
*are* clear by now to the Python 3 developers -- is that right?

Not at all (at least now to me). I know what kind of changes *I*
regularly do to make code run in 3k, namely, put parentheses around
into the print statements. I can live with that. Whether it is
practical to run, say, Django unmodified, I don't know - I have
not looked into Django with that much detail, let alone tested
whether it will work.

Note that I'm primarily talking about pure Python here; for
C code, you can get a single-source version only with a lot
of #ifdefs (but again, I believe it is practical to make it
work that way).

It
seems to me that if I don't understand what the Python 3 developers
expect the practicalities to be, most other interested people won't
either ("interested" in the opposite sense to "disinterested" rather
than to "uninterested").

I think comp.lang.python is then the wrong place to find out; the py3k
list likely reaches more of these developers. OTOH, I don't know whether
they all want to participate in a survey of their expectations...

Rather than studying people's opinions, why don't you try to port your
own projects to 3k, and report whether you found it practical to use
a single source (assuming you would prefer such a solution for your
own project)?

Regards,
Martin

[John J. Lee]

"Martin v. Löwis" <ma****@v.loewis.dewrites:
[... snip stuff I don't follow ...]

However, it *is* a design goal to make 2.6 so that transition to
3k becomes simpler. That's not a 3k feature, but a 2.6 one.

Not sure I care about this sort of thing for the purpses of my
question. I just wanted to know: is it easy to make my code so it
runs on 2.6 and 3.0, without funny stuff like a code translator?
Seems wikipedia said "yes" and Guido said "no".
[...]

to be seen. I personally believe that many projects won't need the 2to3
tool, if they are willing to compromise on the notations used in the
source code.

OK, so there's disagreement on this point amongst the Python 3
developers. That's interesting (I don't mean that in a negative way).
[...]

>It
seems to me that if I don't understand what the Python 3 developers
expect the practicalities to be, most other interested people won't
either ("interested" in the opposite sense to "disinterested" rather
than to "uninterested").

I think comp.lang.python is then the wrong place to find out; the py3k
list likely reaches more of these developers. OTOH, I don't know whether
they all want to participate in a survey of their expectations...

I was also hoping to get a quick answer rather than a long discussion,
if any Python 3 developers were around to talk to the broader range of
people that read this list. You have given your answers, I wonder if
anybody else will turn up.

Rather than studying people's opinions, why don't you try to port your
own projects to 3k, and report whether you found it practical to use
a single source (assuming you would prefer such a solution for your
own project)?

Because that might well tell me much less than asking a Python 3
developer, and yet take far more time, and fail to inform everybody
else.
John

[=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=]

John J. Lee schrieb:

"Martin v. Löwis" <ma****@v.loewis.dewrites:
[... snip stuff I don't follow ...]

>However, it *is* a design goal to make 2.6 so that transition to
3k becomes simpler. That's not a 3k feature, but a 2.6 one.

Not sure I care about this sort of thing for the purpses of my
question. I just wanted to know: is it easy to make my code so it
runs on 2.6 and 3.0, without funny stuff like a code translator?
Seems wikipedia said "yes" and Guido said "no".

Neither of these are qualified to make any statements about your
code. Only you can find out yourself. OTOH, neither of these *did*
make any statement about *your* code.

Regards,
Martin

[Carsten Haese]

On Sun, 2007-08-05 at 23:09 +0000, John J. Lee wrote:

I just wanted to know: is it easy to make my code so it
runs on 2.6 and 3.0, without funny stuff like a code translator?

That depends on your definitions of "easy" and "funny stuff." I'm pretty
sure you'll be able to run the same source code on Python 2.6 and Python
3.0 without either one breaking, as long as the code is written
sufficiently carefully. You may have to give up some Python 3.0 features
and/or write compatibility shims depending on what features you'll need.
Whether that's acceptable depends on the features you need and how much
"yak shaving" you find acceptable.

For instance, if you never use print statements in your code, you won't
notice that print is becoming a function. If you do, you'll have to make
appropriate accommodations.

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net

[Paul Rubin]

Carsten Haese <ca*****@uniqsys.comwrites:

For instance, if you never use print statements in your code, you won't
notice that print is becoming a function. If you do, you'll have to make
appropriate accommodations.

Why on earth did they make this change? It just seems gratuitous. Is
the assert statement also being changed? Are they going to update all
the docs that say that the yield statement works like the print statement?

[Neil Cerutti]

On 2007-08-06, Paul Rubin <httpwrote:

Carsten Haese <ca*****@uniqsys.comwrites:

>For instance, if you never use print statements in your code, you won't
notice that print is becoming a function. If you do, you'll have to make
appropriate accommodations.

Why on earth did they make this change? It just seems
gratuitous. Is the assert statement also being changed? Are
they going to update all the docs that say that the yield
statement works like the print statement?

From the footnotes of PEP 3100:

http://mail.python.org/pipermail/pyt...er/056154.html
http://www.python.org/dev/peps/pep-3105

--
Neil Cerutti

[Neil Cerutti]

On 2007-08-06, Neil Cerutti <ho*****@yahoo.comwrote:

On 2007-08-06, Paul Rubin <httpwrote:

>Carsten Haese <ca*****@uniqsys.comwrites:

>>For instance, if you never use print statements in your code,
you won't notice that print is becoming a function. If you
do, you'll have to make appropriate accommodations.

Why on earth did they make this change? It just seems
gratuitous. Is the assert statement also being changed? Are
they going to update all the docs that say that the yield
statement works like the print statement?

From the footnotes of PEP 3100:

http://mail.python.org/pipermail/pyt...er/056154.html
http://www.python.org/dev/peps/pep-3105

Incidentally, from the second link I find it shocking that the
keyword parameter "file" shadows a builtin. It seems to endorse a
bad practice.

--
Neil Cerutti

[Paul Boddie]

On 6 Aug, 12:11, Paul Rubin <http://[e-mail]:

Carsten Haese <[e-mail]:

For instance, if you never use print statements in your code, you won't
notice that print is becoming a function. If you do, you'll have to make
appropriate accommodations.

Why on earth did they make this change? It just seems gratuitous. Is
the assert statement also being changed? Are they going to update all
the docs that say that the yield statement works like the print statement?

Indeed: practicality beats purity [1]. Uh, wait a moment!

Paul

[1] http://www.python.org/dev/culture/

[John J. Lee]

Carsten Haese <ca*****@uniqsys.comwrites:

On Sun, 2007-08-05 at 23:09 +0000, John J. Lee wrote:

>I just wanted to know: is it easy to make my code so it
runs on 2.6 and 3.0, without funny stuff like a code translator?

That depends on your definitions of "easy" and "funny stuff." I'm pretty
sure you'll be able to run the same source code on Python 2.6 and Python
3.0 without either one breaking, as long as the code is written
sufficiently carefully. You may have to give up some Python 3.0 features
and/or write compatibility shims depending on what features you'll need.
Whether that's acceptable depends on the features you need and how much
"yak shaving" you find acceptable.

[...]

If I had wanted to start analysing requirements for some specific
project, I'd have gone and done that!-) I was actually interested in
the general case (all existing projects), as perhaps you'll see if you
read my original post (my followup question you quote above was
deliberately blunt for rhetorical let's-move-this-discussion-along
purposes -- <sighhonestly, these literal-minded programmer types,
what CAN you do with them?-).

Do you *really* think that projects will fall 50-50 into the "yes" and
"no" camps, as you seem to imply -- after all, if you thought that one
case was more common, why wouldn't you mention which it was?

(where "yes" == "feasible to keep a single source code working in both
2.6 and 3.0", and of course it's taken as read that you can do the
generalisation to the -- I hope -- obvious continuum of cases
"between" "yes" and "no" without our needing to tiresomely spell it
out here)

I'll also add that previous comments from Guido have implied (to my
reading, admittedly without studying them like biblical texts) that
the great majority of projects will/should fall pretty squarely, in
his judgement, into the "no" camp -- i.e. NOT practical to keep 2.6
and 3.0 comptibility from a single source code without use of a
translation tool. Does your "pretty sure"-ness stem from 1) a
knowledge of how 3.0 will look when it's done, 2) experience of
playing with the Py3k project as it is right now or 3) other? What
sort of frequencies does your understanding of Py3k predict for the
"yes" and "no" cases? By all means "use your skill and judgement" in
answering, rather than asking for clarification -- since that would
rather defeat the point of the question.
John

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

Do you *really* think that projects will fall 50-50 into the "yes" and

"no" camps, as you seem to imply -- after all, if you thought that one
case was more common, why wouldn't you mention which it was?

I know you didn't ask me this time, but I answer anyway: I don't know.

I *really* think that only experience can tell, and that any kind of
prediction on that matter is futile FUD (as FUD, it might be successful,
of course). I do so using all my skill and judgment. Only when people
actually start to try porting, list specific issues that they actually
ran into (rather than listing issues they anticipate to run into),
only then I can make guesses as to what the common case will be.

Ask this question a year from now again.

Regards,
Martin

[John J. Lee]

"Martin v. Löwis" <ma****@v.loewis.dewrites:

>Do you *really* think that projects will fall 50-50 into the "yes" and
"no" camps, as you seem to imply -- after all, if you thought that one
case was more common, why wouldn't you mention which it was?

I know you didn't ask me this time, but I answer anyway: I don't know.

I *really* think that only experience can tell, and that any kind of
prediction on that matter is futile FUD (as FUD, it might be successful,
of course). I do so using all my skill and judgment. Only when people
actually start to try porting, list specific issues that they actually
ran into (rather than listing issues they anticipate to run into),
only then I can make guesses as to what the common case will be.

[...]

By this criterion, Guido himself is engaging in FUD, as near as I can
tell (of course, I don't believe he is doing that; I also can't
believe that the effective requirements for the project are quite as
decoupled from source compatibility considerations as has sometimes
been implied by some of those working on the project).
John

[Istvan Albert]

On Aug 6, 6:49 am, Neil Cerutti <[e-mail]:

Incidentally, from the second link I find it shocking that the
keyword parameter "file" shadows a builtin. It seems to endorse a
bad practice.

I believe that the "file" builtin has been removed as well so it won't
shadow anything.

i.

[Istvan Albert]

On Aug 6, 6:11 am, Paul Rubin <http://[e-mail]:

Why on earth did they make this change? It just seems gratuitous.

Having print a function (with parameters) makes is very easy to modify
where the output goes.

Say you want to have some prints go to one particular file, today you
cannot easily do it, you have to either do a regex based search/
replace or fiddle with the sys.stdout etc. both have substantial
drawbacks.

A solution would be writing the code with a logging function to begin
with, alas many times that is out of one's hand. I wished print was a
function great many times. I bet Guido has had similar experiences,
note that attempt to keep print in the current form but have it print
to a file ... with that crazy syntax, print >>f, ... alas that did not
solve anything

It is time to fix it for good.

i.

[Paul Boddie]

On 8 Aug, 16:26, Istvan Albert <[e-mail]:

On Aug 6, 6:11 am, Paul Rubin <http://[e-mail]:

Why on earth did they make this change? It just seems gratuitous.

Having print a function (with parameters) makes is very easy to modify
where the output goes.

I'm not arguing with this.

Say you want to have some prints go to one particular file, today you
cannot easily do it, you have to either do a regex based search/
replace or fiddle with the sys.stdout etc. both have substantial
drawbacks.

Well, you could find all print statements reliably using various
parsing solutions provided with Python. It's interesting that for this
reason, migrating from the print statement is not particularly
difficult whereas identifying invocations of the upcoming print built-
in function will not be a trivial task. I'm not passing judgement on
the introduction of the print function here, but I find such
properties of the language very interesting - it's not too far removed
from the static typing debate or people's fascination with making
domain-specific languages.

A solution would be writing the code with a logging function to begin
with, alas many times that is out of one's hand. I wished print was a
function great many times. I bet Guido has had similar experiences,
note that attempt to keep print in the current form but have it print
to a file ... with that crazy syntax, print >>f, ... alas that did not
solve anything

Yes, print >>f is a bit of a hack which I must admit to using
occasionally. However, for every enthusiast of one approach, there
will always be an enthusiast for another (see point #6):

http://mechanicalcat.net/cgi-bin/log...#anti-pitfalls

It is time to fix it for good.

Well, it has always been possible to use a logging function, just not
one called "print" exactly.

Paul

[Istvan Albert]

On Aug 8, 12:08 pm, Paul Boddie <[e-mail]:

However, for every enthusiast of one approach, there
will always be an enthusiast for another (see point #6):

True.

For example I for one also like the way the current print adds a
newline, the vast majority of the time that is exactly what I want. I
don't know if this will be kept when print becomes a function (might
be that some default parameters make it work the same way)

Which reminds me of an experience I had when I originally learned how
to program in Pascal, then moved on to C. At first it felt wrong that
I had to include the "\n" to print a new line at the end, seemed
unreadable (Pascal had separate functions: write and a writeln for
it). Today I'd consider it appallingly bad design to have separate
functions for such a small difference.

i.

[Neil Cerutti]

On 2007-08-08, Istvan Albert <is***********@gmail.comwrote:

On Aug 6, 6:49 am, Neil Cerutti <[e-mail]:

>Incidentally, from the second link I find it shocking that the
keyword parameter "file" shadows a builtin. It seems to
endorse a bad practice.

I believe that the "file" builtin has been removed as well so
it won't shadow anything.

I can't find any evidence of that in the PEPs. Do you have a
reference?

I thought, in fact, that open was on more shaky ground. ;)

--
Neil Cerutti

[Istvan Albert]

On Aug 8, 2:00 pm, Neil Cerutti <[e-mail]:

I thought, in fact, that open was on more shaky ground. ;)

yeah, that too ...

I can't find any evidence of that in the PEPs. Do you have a reference?

here is something:

http://svn.python.org/view/python/br...6685&view=auto

look for :

- Removed these Python builtins:
apply(), callable(), coerce(), file(), reduce(), reload()

i.

[Neil Cerutti]

On 2007-08-08, Istvan Albert <is***********@gmail.comwrote:

On Aug 8, 2:00 pm, Neil Cerutti <[e-mail]:

>I thought, in fact, that open was on more shaky ground. ;)

yeah, that too ...

OK, I had misremembered. The current docs say that open is
preferred, and that file should rather be used as a type name.

>

>I can't find any evidence of that in the PEPs. Do you have a reference?

here is something:

http://svn.python.org/view/python/br...6685&view=auto

look for :

- Removed these Python builtins:
apply(), callable(), coerce(), file(), reduce(), reload()

Thanks very much.

--
Neil Cerutti
Outside of the killings, Washington has one of the lowest crime rates in the
country. --Marion Barry

[Paul Rubin]

Istvan Albert <is***********@gmail.comwrites:

apply(), callable(), coerce(), file(), reduce(), reload()

reduce() is really gone????? Maybe itertools can get an ireduce
function or something like that?

[Neil Cerutti]

On 2007-08-08, Paul Rubin <httpwrote:

Istvan Albert <is***********@gmail.comwrites:

> apply(), callable(), coerce(), file(), reduce(), reload()

reduce() is really gone????? Maybe itertools can get an
ireduce function or something like that?

I don't see how file() can be "removed", actually, unless the
file type itself is getting axed.

--
Neil Cerutti

[=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=]

I don't see how file() can be "removed", actually, unless the

file type itself is getting axed.

Indeed, that's the case. Py3k won't use stdio for file input and
output, but the io module.

Regards,
Martin

[greg]

Istvan Albert wrote:

A solution would be writing the code with a logging function to begin
with, alas many times that is out of one's hand.

If the code has been written with calls to a builtin
print function, the situation isn't much better. You
could monkeypatch the print function, but that's
probably worse than swapping sys.stdout.

(I agree that print should be a function, simply because
there's no strong reason for it *not* to be. But I
don't think it makes a difference to this particular
problem.)

--
Greg

[Evan Klitzke]

On 8/8/07, greg <gr**@cosc.canterbury.ac.nzwrote:

Istvan Albert wrote:

A solution would be writing the code with a logging function to begin
with, alas many times that is out of one's hand.

If the code has been written with calls to a builtin
print function, the situation isn't much better. You
could monkeypatch the print function, but that's
probably worse than swapping sys.stdout.

You can easily modify print in a safe way. Here's an example, that
will work in any recent version of Python:

import sys

def print_(s):
print s

def logger(method):
def wrapper(s):
sys.stderr.write('Logging: %s\n' % s)
method(s)
return wrapper

print_ = logger(print_)

print_('hello')
Running this code will do a regular print of 'hello', as well as
"logging" it to stderr. As a function, you can convert print wholesale
to another logging function, or wrap it transparently like this to
provide additional logging functionality. What do you find wrong with
this sort of "monkeypatching"?

--
Evan Klitzke <ev**@yelp.com>

[=?ISO-8859-1?Q?Ricardo_Ar=E1oz?=]

Evan Klitzke wrote:

On 8/8/07, greg <gr**@cosc.canterbury.ac.nzwrote:

>Istvan Albert wrote:

>>A solution would be writing the code with a logging function to begin
with, alas many times that is out of one's hand.

If the code has been written with calls to a builtin
print function, the situation isn't much better. You
could monkeypatch the print function, but that's
probably worse than swapping sys.stdout.

You can easily modify print in a safe way. Here's an example, that
will work in any recent version of Python:

import sys

def print_(s):
print s

def logger(method):
def wrapper(s):
sys.stderr.write('Logging: %s\n' % s)
method(s)
return wrapper

print_ = logger(print_)

print_('hello')
Running this code will do a regular print of 'hello', as well as
"logging" it to stderr. As a function, you can convert print wholesale
to another logging function, or wrap it transparently like this to
provide additional logging functionality. What do you find wrong with
this sort of "monkeypatching"?

foolish question maybe.
Why wouldn't you do it this way ?

def print_(s):
print s

def logger(m):
sys.stderr.write('Logging: %s\n' % m)
method(m)

print_ = logger(print_)

print_('hello')

[greg]

Evan Klitzke wrote:

You can easily modify print in a safe way.

Yes, but you'd still have to replace the builtin print
function with your own to get it used by non-cooperative
code. That doesn't seem to gain you much over replacing
sys.stdout with something that intercepts and logs
stuff written to it.

What do you find wrong with this sort of "monkeypatching"?

At least sys.stdout was designed somewhat with the
possibility of replacing it in mind. It's not an
entirely unexpected thing to do. Replacing something
in the builtin namespace seems like a more drastic
step, somehow.

--
Greg