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

[Neil Cerutti]

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

On Aug 8, 2:00 pm, Neil Cerutti <horp...@yahoo. comwrote:

>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.cant erbury.ac.nzwro te:

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.writ e('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.co m>

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

Evan Klitzke wrote:

On 8/8/07, greg <gr**@cosc.cant erbury.ac.nzwro te:

>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.writ e('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.writ e('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