programming with Python 3000 in mind

[beliavsky]

At http://www-03.ibm.com/developerworks/blogs/page/davidmertz David
Mertz writes

"Presumably with 2.7 (and later 2.x versions), there will be a means of
warning developers of constructs that are likely to cause porting
issues [to Python 3000]. In the simplest case, this will include
deprecated functions and syntax constructs. But presumably the warnings
may cover "potential problems" like the above example."

The current beta version of Python is 2.5 . How can a Python programmer
minimize the number of changes that will be needed to run his code in
Python 3000? In general, he should know what is being removed from
Python 3000 and if possible use the "modern" analogs in Python. A
manager of Python programmers might want external evidence of
portability, though (such as an absence of interpreter warnings).

Some basic syntax such as

print "hello world"

is going away to make print look like a function. IMO, fixing what is
not broken because of the aesthetic tastes of the BDFL is a bad idea.
His reasoning is at
http://mail.python.org/pipermail/python-dev/2005-September/056154.html
..

 

[skip]

Since we don't know what Python 3000 will look like yet (it's still in very
early development), that is a question that can't be answered today.

Skip

 

[=?iso-8859-1?q?Luis_M._Gonz=E1lez?=]

(e-mail address removed) ha escrito:

At http://www-03.ibm.com/developerworks/blogs/page/davidmertz David
Mertz writes

"Presumably with 2.7 (and later 2.x versions), there will be a means of
warning developers of constructs that are likely to cause porting
issues [to Python 3000]. In the simplest case, this will include
deprecated functions and syntax constructs. But presumably the warnings
may cover "potential problems" like the above example."

The current beta version of Python is 2.5 . How can a Python programmer
minimize the number of changes that will be needed to run his code in
Python 3000? In general, he should know what is being removed from
Python 3000 and if possible use the "modern" analogs in Python. A
manager of Python programmers might want external evidence of
portability, though (such as an absence of interpreter warnings).

Some basic syntax such as

print "hello world"

is going away to make print look like a function. IMO, fixing what is
not broken because of the aesthetic tastes of the BDFL is a bad idea.
His reasoning is at
http://mail.python.org/pipermail/python-dev/2005-September/056154.html
.

Check this out:
http://video.google.com/videoplay?docid=-6459339159268485356

Additionaly, you can make a simple Google search: "guido python 3000"
There is quite a lot of information.

Hope this helps...
LUIS

 

[=?iso-8859-1?B?QW5kcuk=?=]

The current beta version of Python is 2.5 . How can a Python programmer
minimize the number of changes that will be needed to run his code in
Python 3000? In general, he should know what is being removed from
Python 3000 and if possible use the "modern" analogs in Python. A
manager of Python programmers might want external evidence of
portability, though (such as an absence of interpreter warnings).

You might want to have a look at PEP-3100 which outlines possible
changes. You can also follow the discussion on the python-3000 mailing
list. From my reading of this, it looks like there will be relatively
few changes.

Some basic syntax such as

print "hello world"

is going away to make print look like a function. IMO, fixing what is
not broken because of the aesthetic tastes of the BDFL is a bad idea.
His reasoning is at
http://mail.python.org/pipermail/python-dev/2005-September/056154.html

I don`t see his main reasoning as related to aesthetic taste, but
rather as one of functionality. As it is, if you use print in your
code (very useful for debugging, you're stuck with it. If print
were a function, you could redefine it at will and very easily, on a
module by module basis, perhaps redirecting the output to a file for
logging or other reasons as described by GvR.

When it comes to *teaching/learning* Python, it makes much more sense
to have print() as a function (same with exec) given what it does
-compared with the purpose of the other keywords. [I'm not sure I'd do
away with input() though...]

Finally, even though I disagreed above with the characterisation of
this change being related to the "aesthetic tastes of the BDFL", from
what I read it appears that his taste is most often bang-on with the
consensus from experienced programmers; as just a hobbyist myself, I am
constantly amazed at how easy Python code is to read and decipher,
compared with other languages.

André

 

[Fredrik Lundh]

When it comes to *teaching/learning* Python, it makes much more sense
to have print() as a function (same with exec) given what it does
-compared with the purpose of the other keywords.

that's rubbish, of course, and seems to assume that python students, in
general, are obsessed with hyper-generalization. they're not.

</F>

 

[Fredrik Lundh]

The current beta version of Python is 2.5 . How can a Python programmer
minimize the number of changes that will be needed to run his code in
Python 3000?

by ignoring it, until it exists.

</F>

 

[=?iso-8859-1?B?QW5kcuk=?=]

that's rubbish, of course, and seems to assume that python students, in
general, are obsessed with hyper-generalization. they're not.

</F>

On a scale of 0-10, for Python technical knowledge, you (F.L.) are
probably at 9.5 whereas I might hover around 2 - and I will most likely
always defer to your expertise in this area.

However, I have some experience as a Python student (having learned
about programming in Python on my own over the past two years) and as a
teacher (*mostly* in a very different field) and I respectfully
disagree over this hyper-generalised characterisation of my stated
opinion on this subject as "rubbish".

André

 

[Simon Forman]

Some basic syntax such as

print "hello world"

is going away to make print look like a function. IMO, fixing what is
not broken because of the aesthetic tastes of the BDFL is a bad idea.
His reasoning is at
http://mail.python.org/pipermail/python-dev/2005-September/056154.html
.

When it comes to programming language design, I *trust* Guido.

I think he makes good non-aesthetic-taste-based points in that posting.
Just the other day, someone was wanting to know how to capture the
output from ftplib printing to stdout. IIRC, the least inconvenient
way (without replacing stdout) was rewriting it not to use print
statements...

http://groups.google.ca/group/comp.lang.python/browse_frm/thread/70aca5068c18384f/d19e9119b7ca1af2

Peace,
~Simon

 

[Steven D'Aprano]

The current beta version of Python is 2.5 . How can a Python programmer
minimize the number of changes that will be needed to run his code in
Python 3000? In general, he should know what is being removed from
Python 3000 and if possible use the "modern" analogs in Python.

In general, you can't, as Python 3000 hasn't been nailed down yet.

You shouldn't be asking "How do I write for a language that doesn't exist
yet?" but instead should ask:

(1) How far away is Python 3000?

Years away, although not that many years. Three? Four?

(2) Will there be automated tools for converting source code from Python 2
to Python 3000?

Almost certainly.

(3) Once Python 3000 is released, will Python 2 still be supported and if
so, for how long?

I'm sure there will be a nice long transition period, and if the Python
developers don't want to support Python 2, it will be a wonderful
opportunity for some commercial operation to charge for support.

 

[Kay Schluehr]

by ignoring it, until it exists.

</F>

And why not ignoring it, when it comes to exist?

 

[Terry Reedy]

(1) How far away is Python 3000?
Years away, although not that many years. Three? Four?

Try 1 1/2. Guido hopes to release 3.0a1 next January and 3.0 final a year
after.

(2) Will there be automated tools for converting source code from Python
2
to Python 3000?
Almost certainly.

There will be tools for detecting things that need examination. Complete
auto conversion will probably not be possible.


One way to program for the future is to import the future, in particular,
'integer division'.

Terry Jan Reedy

 

[Steve Holden]

In general, you can't, as Python 3000 hasn't been nailed down yet.

You shouldn't be asking "How do I write for a language that doesn't exist
yet?" but instead should ask:

(1) How far away is Python 3000?

Years away, although not that many years. Three? Four?
Two.

(2) Will there be automated tools for converting source code from Python 2
to Python 3000?

Almost certainly.
Yes.

(3) Once Python 3000 is released, will Python 2 still be supported and if
so, for how long?

I'm sure there will be a nice long transition period, and if the Python
developers don't want to support Python 2, it will be a wonderful
opportunity for some commercial operation to charge for support.

For the answers to questions like these see

http://video.google.com/videoplay?docid=-6459339159268485356

which is Guido's rehearsal for his OSCON presentation on Python 3000.

regards
Steve

 

[Paul Boddie]

And why not ignoring it, when it comes to exist?

The risk of Python 3000 being ignored or marginalised may increase in
direct proportion to the amount of exotic new stuff introduced upon its
release, mostly because people have a large amount of code that may not
work with an extensively modified language, library and runtime
(although the latter is only a remote possibility), and because
newcomers may not see Python 3000 as significantly interesting to adopt
in preference to other languages. This observation, which I'm sure I've
stated before, seems to have influenced (perhaps coincidentally)
various pronouncements about how conservative Python 3000 will be, at
least when compared to the expectations of the python-3000 mailing list
where various participants seem obsessed with reenacting 20th century
Types-SIG mailing list discussions and reproducing works with varying
degrees of similarity to the conclusions of that old activity:

http://www.python.org/community/sigs/retired/types-sig/

Note that links to the Types-SIG archives are broken on python.org, but
the archives are viewable via ASPN:

http://aspn.activestate.com/ASPN/Mail/Browse/Plain/types-sig/

Ultimately, and to the disappointment of a few people, Python 3000's
benefits may very well seem incremental, if only to avoid fracturing
the community.

Paul

 

[John Roth]

Since we don't know what Python 3000 will look like yet (it's still in very
early development), that is a question that can't be answered today.

Skip

It may not be answerable precisely, but it most likely can
be answered in general terms. As far as I can tell, there is
one really major, overwhelmingly large change in 3.0, and
that is making the str class unicode, with the corresponding
elimination of the 8-bit string type in favor of a new bytes type.
That also implies lots of changes in the I/O classes as well.

In comparison, the elimination of the print statement is a
"so-what". It can be handled by a conversion program.

Most of the rest of the changes seem to be either forward
compatable or easily handable by a conversion program.
The change in the raise statement, for example, can
be handled right now.

John Roth

 

[GHUM]

Steven,

you ask good questions!

(2) Will there be automated tools for converting source code from Python 2
to Python 3000?

If you would have been to the EuroPythom 2006, you may have heard the
plans for PyPy 2.0; which may have per-module-switchable syntax
compatibility for Py 2.2-3000. So by trusting the PyPy team, you can
stay very very relaxed concerning Python 3000.

Harald