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

[Paul Boddie]

On 6 Aug, 12:11, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

Carsten Haese <cars...@uniqsy s.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?

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

Paul

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

[John J. Lee]

Carsten Haese <ca*****@uniqsy s.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.loewi s.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 <horp...@yahoo. comwrote:

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://phr...@NOSPAM.i nvalidwrote:

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 <istvan.alb...@ gmail.comwrote:

On Aug 6, 6:11 am, Paul Rubin <http://phr...@NOSPAM.i nvalidwrote:

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] g.ukwrote:

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 <horp...@yahoo. comwrote:

>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 <horp...@yahoo. comwrote:

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.