Pep 3105: the end of print?
Edward K Ream
discussed at:
http://mail.python.org/pipermail/python-dev/2005-September/056154.html
Alas, it appears that the effect of this pep would be to make it impossible
to use the name 'print' in a backward compatible manner. Indeed, if a
program is to compile in both Python 2.x and Python 3.x, the print function
(or the print statement with parentheses) can not use the 'sep', 'end' and
'file' keywords. This in turn makes it impossible to support the effect of
print with trailing comma in Python 2.x programs while retaining the name
'print'.
The only workaround would be to define yet another function, with a name
*other* than 'print'. This function, say print2, can support whatever
features the implementer wants because it does not collide with the Python
2.x print statement.
In short, pep 3105 will *discourage* rather than encourage the use of the
name 'print'. Rather than invalidating most Python 2.x programs, it would
seem more graceful for Python 3.x to define a [your name here] function that
can be used in addition to, rather than to the exclusion of, print.
Edward
P.S. The existence of an automated translation script does not change the
situation described above in any way. At best, such a script could change
print statements to [your name here] functions, but the effect would still
be the elimination of the name 'print' in all programs that aim to support
Python 2.x and Python 3.x.
EKR
--------------------------------------------------------------------
Edward K. Ream email: edre...@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Steven Bethard
> The pros and cons of making 'print' a function in Python 3.x are well
> discussed at:
>
> http://mail.python.org/pipermail/python-dev/2005-September/056154.html
>
> Alas, it appears that the effect of this pep would be to make it impossible
> to use the name 'print' in a backward compatible manner.
You could offer up a patch for Python 2.6 so that you can do::
from __future__ import print_function
and have the 'print' statement replaced by the 'print' function.
That said, why can't you use ``file.write()`` instead of ``print``?
While I use print quite frequently in interactive use, it's pretty much
nonexistent in all my real code.
STeVe
Edward K Ream
> from __future__ import print_function
This would only work for Python 2.6. Developers might want to support Python
2.3 through 2.5 for awhile longer :-)
> why can't you use ``file.write()`` instead of ``print``?
Precisely my point: pep 3105 will force the elimination of the name 'print'.
Edward
massimo s.
*can* be not backwards-compatible with previous releases?
m.
Edward K Ream
> be not backwards-compatible with previous releases?
Not at all. Backwards compatibility means that one can still run old code
provided the code eschews new features. Python releases have generally
been backwards compatible with previous releases, with a few minor
exceptions. For example, my app runs fine on Python 2.2.2 through Python
2.5, and little work was required to make this happen. In fact, my app
should run find on Python 3.x, but that's because it doesn't use print :-)
In other words, the consequence of pep 3105 will be that *nobody* who wants
their app to be portable will be able to use print until *everybody* has
converted to Python 3.x. I doubt that is what Guido had in mind, but I may
be mistaken :-)
Gabriel Genellina
escribió:
> In other words, the consequence of pep 3105 will be that *nobody* who
> wants
> their app to be portable will be able to use print until *everybody* has
> converted to Python 3.x. I doubt that is what Guido had in mind, but I
> may
> be mistaken :-)
print is nice, and has a few advantages (like its own opcode!), and I use
it a lot on the interactive interpreter, but I almost never use it in
production code.
--
Gabriel Genellina
Ben Finney
> > Isn't the very concept of major releases (1.x, 2.x, 3.x) that they
> > *can* be not backwards-compatible with previous releases?
>
> Not at all.
In the context of the question, this answer seems to say that a major
release *must* be backwards-compatible (i.e. "can [may] not be not
backwards-compatible").
Is that what you intend to say?
If so, I disagree strongly. I assert that a major release *may* be
backwards-incompatible, in well-defined ways. That's the only way to
get rid of some kinds of cruft.
So long as it's done in a well-documented way, with a change in major
version number, it's a reasonable way (probably the *only* reasonable
way) to remove particular kinds of cruft from any application -- even
if that application is a programming language.
--
\ "To stay young requires unceasing cultivation of the ability to |
`\ unlearn old falsehoods." -- Robert Anson Heinlein |
_o__) |
Ben Finney
Steven Bethard
>> You could offer up a patch for Python 2.6 so that you can do::
>> from __future__ import print_function
>
> This would only work for Python 2.6. Developers might want to support Python
> 2.3 through 2.5 for awhile longer :-)
Python 3.0 is determined not to be hampered by backwards incompatibility
concerns. It's not even clear yet that your average 2.6 code will work
on 3.0 -- though there's a pretty large contingent trying to make this true.
In short, if you need to support 2.3, you're not ready to be looking at 3.0.
STeVe
Steven D'Aprano
>> Isn't the very concept of major releases (1.x, 2.x, 3.x) that they *can*
>> be not backwards-compatible with previous releases?
>
> Not at all. Backwards compatibility means that one can still run old code
> provided the code eschews new features. Python releases have generally
> been backwards compatible with previous releases, with a few minor
> exceptions.
That's fine, but Python 3 has been explicitly stated to be where Python
will have backwards _in_compatible changes made.
That's not to say that all Python 2.x programs will break under Python 3,
but some surely will.
> For example, my app runs fine on Python 2.2.2 through Python
> 2.5, and little work was required to make this happen. In fact, my app
> should run find on Python 3.x, but that's because it doesn't use print :-)
It's too early to say for sure what will run under Python 3, because it
hasn't been decided fully yet, but it is quite probable that it will still
compile and/or run and possibly even do what you intended.
> In other words, the consequence of pep 3105 will be that *nobody* who wants
> their app to be portable will be able to use print until *everybody* has
> converted to Python 3.x. I doubt that is what Guido had in mind, but I may
> be mistaken :-)
I'm pretty sure you're mistaken. Python 3 will be the release that breaks
code. Hopefully very little, but there almost certainly will be some.
--
Steven.
Eduardo "EdCrypt" O. Padoan
> > Isn't the very concept of major releases (1.x, 2.x, 3.x) that they *can*
> > be not backwards-compatible with previous releases?
>
It is the only intent of Python 3.0: be free of backward compatibity
constraints.
There are a tool called "2to3" that translates things like "print foo"
to print(foo).
--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
Edward K Ream
> 3.0.
I hope this turns out not to be true. As a developer, I have no way to
force people to 3.0, and no reason to want to. For me, maintaining two
incompatible code bases is out of the question.
It will be interesting to see how this plays out. Users, not developers,
will determine when Python 2.x becomes extinct.
Edward K Ream
> print(foo).
The point of my original post was that if I want to maintain a common code
base the tool must translate 'print foo' to 'print2(foo)'.
Edward K Ream
> code. Hopefully very little, but there almost certainly will be some.
Pep 3105 breaks a *lot* of code, despite the bland assertion that most
production programs don't use print.
Presumably, Guido wanted to improve print in such a way that *more* people
would use it. But the effect of the pep is that *less* people will be able
to use print, *regardless* of how backward compatible Python 3.x is
'allowed' to be.
Edward K Ream
I intended to say what I did say: "Python releases have generally been
backwards compatible with previous releases, with a few
minor exceptions." Imo, this is compatible with what you are saying.
> So long as it's done in a well-documented way, with a change in major
> version number, it's a reasonable way (probably the *only* reasonable way)
> to remove particular kinds of cruft from any application.
Agreed.
Fuzzyman
> > In short, if you need to support 2.3, you're not ready to be looking at
> > 3.0.
>
> I hope this turns out not to be true. As a developer, I have no way to
> force people to 3.0, and no reason to want to. For me, maintaining two
> incompatible code bases is out of the question.
>
> It will be interesting to see how this plays out. Users, not developers,
> will determine when Python 2.x becomes extinct.
>
As has been mentioned 3.0 will deliberately break backwards
compatibilit in a few ways in order to remove cruft and make changes
that *can't* be done any other way.
That said, the changing of print feels to me like gratutitous breakage
- but then I've never had the need to go through old code replacing
print with logging code (the need that Guido cites as the reasn for
the change).
There are various of the 3.0 changes being discussed for inclusion (or
at least support) in Python 2.6 so it might be possible to write code
that will run unchanged on Python 2.6 and 3.0. (That is *some* code -
nt arbitrary code.)
There is also the 2to3 converter. The aim is that this will be
effective enough that coders should be able to maintain a 2.X (2.6 ?)
codebase, run it through 2to3 and have the result run unchanged on
Python 3. That way there will be no need to maintain two code bases.
Also bear in mind that people using Python 3.0 will be aware that most
existing libraries won't work - and it will be a long time (2 to 3
yearsafter the release of 3.0 final ?) before the majority of Python
users have switched. This will provide plenty of time for migration
patterns and tools to be established.
Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml
> Edward
> --------------------------------------------------------------------
> Edward K. Ream email: edream...@charter.net
> Leo:http://webpages.charter.net/edreamleo/front.html
> --------------------------------------------------------------------
Edward K Ream
effective enough that coders should be able to maintain a 2.X (2.6 ?)
codebase, run it through 2to3 and have the result run unchanged on
Python 3. That way there will be no need to maintain two code bases.
I have offered a proof that the converter must change print to print2 (or
some other name) in order to maintain a common code base. How much clearer
can I be? If a common code base is desired, it *is* the end of print
Edward
--------------------------------------------------------------------
Peter Otten
>> There is also the 2to3 converter. The aim is that this will be
> effective enough that coders should be able to maintain a 2.X (2.6 ?)
> codebase, run it through 2to3 and have the result run unchanged on
> Python 3. That way there will be no need to maintain two code bases.
>
> I have offered a proof that the converter must change print to print2 (or
> some other name) in order to maintain a common code base. How much
> clearer
> can I be? If a common code base is desired, it *is* the end of print
There could be something like
from __future__ import print_function
to remove the print keyword in 2.x.
Peter
Edward K Ream
To repeat: this would be compatible only with Python 2.6.
Peter Otten
>> There could be something like from __future__ import print_function
>
> To repeat: this would be compatible only with Python 2.6.
Indeed. Don't lose your nerves over that bunch of casual readers of your
thread :-)
Peter
Fuzzyman
> > There is also the 2to3 converter. The aim is that this will be
>
> effective enough that coders should be able to maintain a 2.X (2.6 ?)
> codebase, run it through 2to3 and have the result run unchanged on
> Python 3. That way there will be no need to maintain two code bases.
>
> I have offered a proof that the converter must change print to print2 (or
> some other name) in order to maintain a common code base. How much clearer
> can I be? If a common code base is desired, it *is* the end of print
>
Why won't it be possible to make 'print' in Python 3 that supports all
the functionality of the current print statement, and then translate
to that ?
I saw an assertion to the effect that it wasn't possible - but no
proof.
It sounds relatively straightforward for me...
Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml
> Edward
> --------------------------------------------------------------------
Edward K Ream
> the functionality of the current print statement, and then translate to
> that ?
> I saw an assertion to the effect that it wasn't possible - but no proof.
As discussed in the original post, the problem is the reverse: the Python
2.x print statement does not support the keyword args required by the pep,
so that print(foo) **in Python 2.x** can not simulate the effect of the
print statement with a trailing comma. Here is the theorum carefully stated
and proved.
Theorem: is not possible to define a function called print in Python 3.x
such that
A) print (whatever) is syntaxtically valid in Python 2.x and
B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for
all values of 'whatever'.
Proof:
It is impossible for the print function to simulate the effect of the print
statement with a trailing comma. Indeed, print ('line'), and print
('line',) (note the position of the commas) are valid in Python 2.x, but
neither does what is wanted. And print('line',end='') is invalid in Python
2.x. Let's look at some examples:
1. The following works (prints 'line after\n') in Python 2.x, but will not
suppress the newline in Python 3.x:
print('line'),
print('after')
2. The following doesn't work in Python 2.x. (It prints
"('line',)\nafter").
print ('line',)
print ('after')
3. print ('line',end='') produces a syntax error in Python 2.x:
print ('line',end='')
^
SyntaxError: invalid syntax
That's the proof. Can you find a flaw in it?
Edward
--------------------------------------------------------------------
Roel Schroeven
>> I'm pretty sure you're mistaken. Python 3 will be the release that breaks
>> code. Hopefully very little, but there almost certainly will be some.
>
> Pep 3105 breaks a *lot* of code, despite the bland assertion that most
> production programs don't use print.
>
> Presumably, Guido wanted to improve print in such a way that *more* people
> would use it. But the effect of the pep is that *less* people will be able
> to use print, *regardless* of how backward compatible Python 3.x is
> 'allowed' to be.
AFAIK the intention is not primarily to get more people to use print.
Instead Guido has felt for some time that the print statement is a wart
in the language (see the references in PEP 3105 for his arguments), and
Python 3000 seems like a good opportunity to fix it once and for all.
Precisely because AFAIK the point of Python 3000 is to fix a number of
long-standing shortcomings, even if that means giving up a degree of
backward compatibility.
--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton
Roel Schroeven
Roel Schroeven
>> There are a tool called "2to3" that translates things like "print foo" to
>> print(foo).
>
> The point of my original post was that if I want to maintain a common code
> base the tool must translate 'print foo' to 'print2(foo)'.
At first sight it seems to me that it's pretty straightforward to
translate print(foo) to print2(foo) once "2to3" has done its job.
It looks your main issue is that you're complaining that Python 3000 is
going to break things in a non-backward compatible way. If you want to
change that, you're going to be fighting an uphill battle, as this quote
from PEP 3000 illustrates:
"We need a meta-PEP to describe the compatibility requirements. Python
3000 will break backwards compatibility. There is no requirement that
Python 2.9 code will run unmodified on Python 3.0.
I'm not sure whether it is reasonable to require that Python 2.x code
can be mechanically translated to equivalent Python 3.0 code; Python's
dynamic typing combined with the plans to change the semantics of
certain methods of dictionaries, for example, would make this task
really hard. However, it would be great if there was some tool that did
at least an 80% job of translation, pointing out areas where it wasn't
sure using comments or warnings. Perhaps such a tool could be based on
something like Pychecker."
Steven D'Aprano
>> I'm pretty sure you're mistaken. Python 3 will be the release that breaks
>> code. Hopefully very little, but there almost certainly will be some.
>
> Pep 3105 breaks a *lot* of code, despite the bland assertion that most
> production programs don't use print.
>
> Presumably, Guido wanted to improve print in such a way that *more* people
> would use it.
I don't think Guido cares about _how many_ people use print. I think he
cares about making print better. If that leads to more people using it,
that's a bonus. But your and my guesses about what Guido cares about
aren't terribly important.
> But the effect of the pep is that *less* people will be able
> to use print, *regardless* of how backward compatible Python 3.x is
> 'allowed' to be.
I don't think that follows at all. print is only a problem if you expect
your code to work under both Python 2.x and 3.x. I wouldn't imagine
that many people are going to expect that: I know I don't. There are
likely to be a whole lot of things which change, sometimes radically, from
one to the other. They'll support one or the other, or fork the code, or
in extreme cases take over maintenance of Python 2.x (it is open source,
you can do that).
If you want to "future-proof" your Python code, well, you can't fully
because nobody yet knows all the things which will change. But you can
start by not calling print directly. There are a number of alternatives,
depending on what you're doing. Here's a simple function that does very
close to what print currently does:
def print_(*args, where=None, newline=True):
if where is None:
where = sys.stdout
args = [str(arg) for arg in args]
where.write(' '.join(args))
if newline:
where.write('\n')
--
Steven.
Fuzzyman
I mentioned the 2to3 translator- the goal of which is *precisely* to
allow you to write code that will run on Python 2.X and when
translated run under Python 3.0.
You then repeated the problem with the 'print' statement.
It may be true that you won't be able to write code that runs
untranslated on 2 and 3. That doesn't stop you writing code for Python
2.X, then translating a version for Python 3. (Uhm... indeed that's
the point of 2to3.)
So you only have one codebase to maintain and you can still use
print...
Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml
> Edward
> --------------------------------------------------------------------
Edward K Ream
> 2.x and 3.x.
Exactly.
Stefan Rank
>> There are a tool called "2to3" that translates things like "print foo" to
>> print(foo).
>
> The point of my original post was that if I want to maintain a common code
> base the tool must translate 'print foo' to 'print2(foo)'.
I think you are misunderstanding the purpose of the 2to3 tool.
It is supposed to create a new version of the code that runs on py3,
while you can still run your *"old"* code on py2.x
There won't be a common code base for all python versions.
You will have to decide at what point you want to switch from developing
the 2.x code (and using the 2to3 tool to support py3) to developing the
py3 code.
(You might then develop a 3to2 tool, but I think this discussion is
getting way ahead of its time. ;-)
Edward K Ream
going to break things in a non-backward compatible way.
No. My complaint is *only* that changing the meaning of 'print' is needless
pain.
Jean-Paul Calderone
> [snip]
>
>I don't think that follows at all. print is only a problem if you expect
>your code to work under both Python 2.x and 3.x. I wouldn't imagine
>that many people are going to expect that: I know I don't.
I think some people are confused that the language "Python 3.x" has "Python"
in its name, since there is already a language with "Python" in its name,
with which it is not compatible.
Jean-Paul
Steven D'Aprano
>> Why won't it be possible to make 'print' in Python 3 that supports all
>> the functionality of the current print statement, and then translate to
>> that ?
>> I saw an assertion to the effect that it wasn't possible - but no proof.
>
> As discussed in the original post, the problem is the reverse: the Python
> 2.x print statement does not support the keyword args required by the pep,
> so that print(foo) **in Python 2.x** can not simulate the effect of the
> print statement with a trailing comma. Here is the theorum carefully stated
> and proved.
>
> Theorem: is not possible to define a function called print in Python 3.x
> such that
>
> A) print (whatever) is syntaxtically valid in Python 2.x and
>
> B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for
> all values of 'whatever'.
[snip]
> That's the proof. Can you find a flaw in it?
No, but it doesn't matter. There's no particular reason why you have to
write "print (whatever)" in your code. What you need is *some function*
that is capable of duplicating the functionality of print, which can be
used under Python 2.x and 3. It isn't hard to write a function that will
duplicate print's functionality, so long as you give up the requirement
that it is called just like print.
The problem you describe with the print syntax only is a problem if you
insist on supporting Python 2.x and 3 from the same codebase. I don't
expect many people will try to do that. For those who do, don't use the
print syntax. As for the rest of us, we'll just continue to use print
using whichever syntax is appropriate.
--
Steven.
Steven D'Aprano
> I mentioned the 2to3 translator- the goal of which is *precisely* to
> allow you to write code that will run on Python 2.X and when
> translated run under Python 3.0.
Unfortunately, that is not a realistic goal for the 2to3 translator. The
goal is to accurately translate 80% of Python code that needs changing,
and issue warnings for the other 20%.
> You then repeated the problem with the 'print' statement.
>
> It may be true that you won't be able to write code that runs
> untranslated on 2 and 3. That doesn't stop you writing code for Python
> 2.X, then translating a version for Python 3. (Uhm... indeed that's
> the point of 2to3.)
>
> So you only have one codebase to maintain and you can still use
> print...
No, you have TWO sets of code. You have the code you write, and the code
you have run through 2to3. Even if 2to3 gives you 100% coverage, which it
won't, you still have two codebases.
--
Steven.
Edward K Ream
Not if the theorum is correct.
> It may be true that you won't be able to write code that runs
> untranslated on 2 and 3.
That's my definition of a common code base. That is the content of the
theorum.
> That doesn't stop you writing code for Python
> 2.X, then translating a version for Python 3. (Uhm... indeed that's the
> point of 2to3.)
That is not what I would call a common code base. The developer would have
to run the translater every time the code changed. And if the Python 3.0
code were considered the 'master' code, the developer would need a 3to2
translater.
Either disprove the theorum or give up the notion of having a common code
base that uses print.
Edward
--------------------------------------------------------------------
Edward K Ream
> No, but it doesn't matter. There's no particular reason why you have to
> write "print (whatever)" in your code. What you need is *some function*
> that is capable of duplicating the functionality of print,
Precisely wrong. The title of this thread is 'the end of print', and the
whole point of my comments is that spelling matters.
I would have absolutely no objection to the pep if it specified some other
name for an 'official' print function. Pick any name, preferably longer
than two characters, that does not conflict with either an existing global
function or module.
Steven D'Aprano
There is no language "Python 3" -- yet. We're still all guessing just
how compatible it will be with Python 2.
To be precise, there is an experimental Python 3, but the specifications
of the language are not fixed yet.
As for the name... big deal. C and C++ and Objective C are completely
different languages. Fortran 77 and Fortran 90 aren't exactly the same;
nobody expects the same code to run unmodified on Forth 77 and FigForth,
or any of another three dozen varieties of Forth.
And dare I mention Java and Javascript?
Even in the Python world, nobody expects to run the same code base under
C Python and Jython and IronPython and PyPy.
--
Steven.
Fuzzyman
<s...@REMOVE.THIS.cybersource.com.au> wrote:
> On Fri, 16 Feb 2007 06:42:55 -0800, Fuzzyman wrote:
> > I mentioned the 2to3 translator- the goal of which is *precisely* to
> > allow you to write code that will run on Python 2.X and when
> > translated run under Python 3.0.
>
> Unfortunately, that is not a realistic goal for the 2to3 translator. The
> goal is to accurately translate 80% of Python code that needs changing,
> and issue warnings for the other 20%.
>
Right, but it *was* a stated aim of the translator when discussed on
Python-dev recently.
> > You then repeated the problem with the 'print' statement.
>
> > It may be true that you won't be able to write code that runs
> > untranslated on 2 and 3. That doesn't stop you writing code for Python
> > 2.X, then translating a version for Python 3. (Uhm... indeed that's
> > the point of 2to3.)
>
> > So you only have one codebase to maintain and you can still use
> > print...
>
> No, you have TWO sets of code. You have the code you write, and the code
> you have run through 2to3. Even if 2to3 gives you 100% coverage, which it
> won't, you still have two codebases.
>
Only one of which you maintain - if the translator works 100% (which I
accept may be unrealistic).
Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml
> --
> Steven.
Fuzzyman
> > So you only have one codebase to maintain and you can still use print...
>
> Not if the theorum is correct.
>
> > It may be true that you won't be able to write code that runs
> > untranslated on 2 and 3.
>
> That's my definition of a common code base. That is the content of the
> theorum.
>
Ok - in which case it is very limited.
> > That doesn't stop you writing code for Python
> > 2.X, then translating a version for Python 3. (Uhm... indeed that's the
> > point of 2to3.)
>
> That is not what I would call a common code base.
But it is what I call a common code base. We are at an impasse. :-)
> The developer would have
> to run the translater every time the code changed. And if the Python 3.0
> code were considered the 'master' code, the developer would need a 3to2
> translater.
>
> Either disprove the theorum or give up the notion of having a common code
> base that uses print.
>
Yes the use of print is changing in a backwards incompatible way, no
one is disputing that.
Personally I wish it wasn't, print 'feels like a statement' to me. But
it's not the end of the world and it is *definitely* going to be able
to be handled by 2to3.
It's also not about to change.
Fuzzyman
http://www.voidpsace.org.uk/python/articles.shtml
> Edward
> --------------------------------------------------------------------
Jean-Paul Calderone
>On Fri, 16 Feb 2007 09:49:03 -0500, Jean-Paul Calderone wrote:
>
>> On Sat, 17 Feb 2007 01:32:21 +1100, Steven D'Aprano
>>> [snip]
>>>
>>>I don't think that follows at all. print is only a problem if you expect
>>>your code to work under both Python 2.x and 3.x. I wouldn't imagine
>>>that many people are going to expect that: I know I don't.
>>
>> I think some people are confused that the language "Python 3.x" has "Python"
>> in its name, since there is already a language with "Python" in its name,
>> with which it is not compatible.
>
>There is no language "Python 3" -- yet. We're still all guessing just
>how compatible it will be with Python 2.
>
>To be precise, there is an experimental Python 3, but the specifications
>of the language are not fixed yet.
>
>As for the name... big deal. C and C++ and Objective C are completely
>different languages. Fortran 77 and Fortran 90 aren't exactly the same;
>nobody expects the same code to run unmodified on Forth 77 and FigForth,
>or any of another three dozen varieties of Forth.
>
>And dare I mention Java and Javascript?
>
I was just pointing out that some people might be confused. I didn't make
any judgement about that fact. You seem to be suggesting that because there
are other confusing things, it's okay for Python to be confusing too. I'm
not making any judgements about that, either.
>Even in the Python world, nobody expects to run the same code base under
>C Python and Jython and IronPython and PyPy.
>
I wonder if the fact that Jython and IronPython can't run most Python programs
is one of the reasons they are generally only used in special circumstances?
PyPy isn't finished yet, however, it _is_ an /explicit/ goal of PyPy to be
compatible with CPython, so it doesn't really belong on that list.
Jean-Paul
Edward K Ream
C Python and Jython and IronPython and PyPy.
Leo now runs under CPython with both wxWidgets and Tkinter. The gui code is
confined to plugins, and a similar gui plugin will suffice to run Leo under
IronPython. Indeed, Leo's startup code already runs unchanged under CPython
and IronPython. I expect minimal changes will be needed to run Leo's core
under Jython. And I *am* talking about a single code base: no translator
needed.
Edward
--------------------------------------------------------------------
Steven D'Aprano
>>> That's the proof. Can you find a flaw in it?
>> No, but it doesn't matter. There's no particular reason why you have to
>> write "print (whatever)" in your code. What you need is *some function*
>> that is capable of duplicating the functionality of print,
>
> Precisely wrong.
Are you trying to say that the name "print" is more important to you
than the functionality?
If not, then I have no idea why you say I'm wrong.
> The title of this thread is 'the end of print', and the
> whole point of my comments is that spelling matters.
That might be the point you are trying to make, but you haven't succeeded.
> I would have absolutely no objection to the pep if it specified some other
> name for an 'official' print function. Pick any name, preferably longer
> than two characters, that does not conflict with either an existing global
> function or module.
Huh? Now you're just not making sense. If Python 3 dropped the print
statement and replaced it with official_print_function(), how would that
help you in your goal to have a single code base that will run on both
Python 2.3 and Python 3, while still using print?
In software development there is a common saying: "Good, Fast, Cheap --
Pick any two". The same holds here:
Keep the print name;
Keep the print functionality;
Keep a single code base.
Pick any two.
--
Steven.
Edward K Ream
> Keep the print functionality;
> Keep a single code base.
Retain the print statement and its functionality, and define an
official_print_function to be used in the common code base. I would be
satisfied with this (it's what I do now), and it would cause no needless
problems for anyone. Having an official print function is a *good* idea,
provided it isn't called print :-)
BJörn Lindqvist
> I was just pointing out that some people might be confused. I didn't make
> any judgement about that fact. You seem to be suggesting that because there
> are other confusing things, it's okay for Python to be confusing too. I'm
> not making any judgements about that, either.
Does not change always cause confusion? The confusion in Python land
is pretty minor in comparison to the one caused Java 1.1, 1.2, 1.3,
1.4, 1.5, 1.6, 1, 2, 4, 5, 6 SE/ME/EE.
I think that people are just complaining to much. The python-devvers
are managing the transition extraordinarily well.
> >Even in the Python world, nobody expects to run the same code base under
> >C Python and Jython and IronPython and PyPy.
> >
>
> I wonder if the fact that Jython and IronPython can't run most Python programs
> is one of the reasons they are generally only used in special circumstances?
Or maybe it is because Jython requires Java and IronPython a CLR?
--
mvh Björn
Jean-Paul Calderone
>On 2/16/07, Jean-Paul Calderone <exa...@divmod.com> wrote:
>>I was just pointing out that some people might be confused. I didn't make
>>any judgement about that fact. You seem to be suggesting that because
>>there
>>are other confusing things, it's okay for Python to be confusing too. I'm
>>not making any judgements about that, either.
>
>Does not change always cause confusion? The confusion in Python land
>is pretty minor in comparison to the one caused Java 1.1, 1.2, 1.3,
>1.4, 1.5, 1.6, 1, 2, 4, 5, 6 SE/ME/EE.
You're just repeating the same argument. I don't buy it, but I'm sure you
and other people will continue to repeat it. Fine, whatever, but I'm not
interested, and your not countering the point I made.
>
>I think that people are just complaining to much. The python-devvers
>are managing the transition extraordinarily well.
>> >Even in the Python world, nobody expects to run the same code base under
>> >C Python and Jython and IronPython and PyPy.
>> >
>>
>>I wonder if the fact that Jython and IronPython can't run most Python
>>programs
>>is one of the reasons they are generally only used in special
>>circumstances?
>
>Or maybe it is because Jython requires Java and IronPython a CLR?
>
I have a JVM and I have Mono. I don't use Jython or IronPython. Maybe
because none of my Python programs run on it?
Jean-Paul
Steven D'Aprano
>> Even in the Python world, nobody expects to run the same code base under
> C Python and Jython and IronPython and PyPy.
>
> Leo now runs under CPython with both wxWidgets and Tkinter. The gui code is
> confined to plugins, and a similar gui plugin will suffice to run Leo under
> IronPython. Indeed, Leo's startup code already runs unchanged under CPython
> and IronPython. I expect minimal changes will be needed to run Leo's core
> under Jython. And I *am* talking about a single code base: no translator
> needed.
Good for Leo. I'm not being sarcastic. But that doesn't just happen, it
happens because Leo's developers don't insist on using mutually
incompatible CPython and IronPython features or modules, but instead
worked really hard to *make* Leo work with both. They didn't just expect
IronPython code to work unchanged with CPython (or vice versa).
--
Steven.
Steve Holden
> On Sat, 17 Feb 2007 01:32:21 +1100, Steven D'Aprano
>> [snip]
>>
>> your code to work under both Python 2.x and 3.x. I wouldn't imagine
>> that many people are going to expect that: I know I don't.
>
> in its name, since there is already a language with "Python" in its name,
> with which it is not compatible.
>
"snake oil"? ;-)
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007
Edward K Ream
True, but it didn't happen as you imply. Leo's core defines a
gui-and-platform-independent set of api's which then get instantiated in
plugins. Plugins can, and do, use platform-dependent features. For
example, the wxWidgets plugin uses the scintilla text widget, something that
does not exist by default in Tk/Tkinter.
Leo just started to work with IronPython last night, so the details are
fresh in my mind. Amazingly, IronPython allows you to point sys.path
(IronPython's sys.path, that is) at CPython's Python24\Lib and for the most
part IronPython 'just works' with those libs. So all of Leo's core, being
free of any gui code, just worked. That is, until it started to load the
IronPython plugin :-) At which point I started to have newbie problems with
dbgclr, but that's another story...
Tobias Brox
> Not at all. Backwards compatibility means that one can still run old code
> provided the code eschews new features. Python releases have generally
> been backwards compatible with previous releases, with a few minor
> exceptions. For example, my app runs fine on Python 2.2.2 through Python
> 2.5, and little work was required to make this happen.
2.2 -> 2.5 is a minor step, the 2.2-code should in general work out on
2.5 without problems.
2.6 -> 3.0 will be a major step, and code written for 2.6 or earlier
will in general not run on python 3.0. Hopefully this issue can be
partially solved by automatic code converting.
--
Tobias Brox, 69°42'N, 18°57'E
Klaas
> That's the proof. Can you find a flaw in it?
Casting this in terms of theorem proving only obfuscates the
discussion.
Here is how to maintain a single codebase for this feature:
1. Convert all your print statements to 3.0 print functions, named
something else (say, print2())
2. define a module called compat26 containing:
def print2(*args, **kwargs):
# code to convert the above to print statements (better still,
sys.stdout.write())
3. in your code:
try:
from compat26 import print2
except (ImportError, SyntaxError):
# python 3.0
print2 = print
-Mike
Sam
> 3. in your code:
> try:
> from compat26 import print2
> except (ImportError, SyntaxError):
> # python 3.0
> print2 = print
Python 2.5c1 (r25c1:51305, Aug 17 2006, 10:41:11) [MSC v.1310 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> try:
from compat26 import print2
except (ImportError, SyntaxError):
# python 3.0
print2 = print
SyntaxError: invalid syntax
>>> try:
pass
except (ImportError, SyntaxError):
# python 3.0
print2 = print
SyntaxError: invalid syntax
Any and all aliasing must happen in compat26.py. My suggested solution is this:
#_compat30.py
print2 = print
#compat.py
try:
from _compat30 import print2
except SyntaxErorr, ImportError):
def print2():
....
--Sam
Klaas
> pass
> except (ImportError, SyntaxError):
> # python 3.0
> print2 = print
> SyntaxError: invalid syntax
>
> Any and all aliasing must happen in compat26.py. My suggested solution is this:
Good catch. Point is that it is not impossible.
-mike
Hendrik van Rooyen
> Jean-Paul Calderone wrote:
> >
> > I think some people are confused that the language "Python 3.x" has "Python"
> > in its name, since there is already a language with "Python" in its name,
> > with which it is not compatible.
> >
> Right. Let's call Python 3.0 something different but related. How about
> "snake oil"? ;-)
I kind of like this idea - it means that the initiates can go on caravan tours
of America, selling it as a panacea for all ills, IT related or not...
A whole new industry.
- Hendrik
Peter mayne
> If Python 3 dropped the print
> statement and replaced it with official_print_function(), how would that
> help you in your goal to have a single code base that will run on both
> Python 2.3 and Python 3, while still using print?
Is there any reason why official_print_function isn't sys.stdout.write?
I can't remember the last time I used print in actual code (apart from
short-lived debugging lines), so I'm bewildered as to why print seems to
be so important.
PJDM
Steven D'Aprano
> Steven D'Aprano wrote:
>> If Python 3 dropped the print
>> statement and replaced it with official_print_function(), how would that
>> help you in your goal to have a single code base that will run on both
>> Python 2.3 and Python 3, while still using print?
>
> Is there any reason why official_print_function isn't sys.stdout.write?
Why would you want a convenience function like print to take one import,
three look-ups and 16 characters instead of always available, one look-up
and five characters?
> I can't remember the last time I used print in actual code (apart from
> short-lived debugging lines), so I'm bewildered as to why print seems to
> be so important.
print is important for the convenience, for short-lived debugging, and for
use in the interactive interpreter.
--
Steven.
Jay Tee
On Feb 16, 6:07 am, Steven Bethard <steven.beth...@gmail.com> wrote:
> Python 3.0 is determined not to be hampered by backwards incompatibility
> concerns. It's not even clear yet that your average 2.6 code will work
Then Python is pretty much determined to remove itself from
consideration
from various kinds of international projects like the one I work on.
We're already catching flack from people due to a few things that were
valid
in 2.2 that are not valid in 2.3 (I don't have the details but could
scare them
up). The project we work on contains code from many different people
and has to
run on thousands of computers all over the world. The installed base
at the
moment is a mix of RHEL 3, RHEL 4, and Debian, with a few other
machines thrown in.
The relevant Python versions at this moment IIRC are 2.2.3 and 2.3.4,
because these
are the native versions on those platforms.
We are estimating, due to the speed at which our applications follow
OS releases, that
we can drop RHEL 3 (and hence Python 2.2) support a year from now. Go
figure when you
think we might be ready to require that all programs run on python
3.0. If it's not
backwards compatible, meaning if 2.4 code doesn't run on 3.0, it's
rather likely that
strong pressure will be applied to port *away* from Python into
something less capricious.
Bottom line: practicality and beauty is always a tradeoff. Oberon is
the most beautiful
language I ever saw, but there is almost nobody using it any more.
Too many beauty contests over who had the best proposal for a standard
library.
Beliavsky
<s...@REMOVE.THIS.cybersource.com.au> wrote:
> On Fri, 16 Feb 2007 09:49:03 -0500, Jean-Paul Calderone wrote:
> > On Sat, 17 Feb 2007 01:32:21 +1100, Steven D'Aprano
> >> [snip]
>
> >>I don't think that follows at all. print is only a problem if you expect
> >>your code to work under both Python 2.x and 3.x. I wouldn't imagine
> >>that many people are going to expect that: I know I don't.
>
> > I think some people are confused that the language "Python 3.x" has "Python"
> > in its name, since there is already a language with "Python" in its name,
> > with which it is not compatible.
>
> There is no language "Python 3" -- yet. We're still all guessing just
> how compatible it will be with Python 2.
>
> To be precise, there is an experimental Python 3, but the specifications
> of the language are not fixed yet.
>
> As for the name... big deal. C and C++ and Objective C are completely
> nobody expects the same code to run unmodified on Forth 77 and FigForth,
> or any of another three dozen varieties of Forth.
The attitudes towards backwards compatibility of the Fortran standards
committee and the Python BDFL is very different.
Fortran 90 was a superset of Fortran 77, so standard-conforming
Fortran 77 programs have the same meaning when compiled with an F90
compiler. The committee does not consider changing things like the
meaning of 1/2. Even though WRITE provides a superset of the
functionality of PRINT, the committee would not dream of breaking so
much code by removing PRINT. No feature is deleted without being
declared obsolescent in a previous standard, which makes it easier to
plan ahead. In practice Fortran 95 compilers accept deleted features,
but they are required to a have a switch that identifies non-standard
code.
I think the C and C++ committees also take backwards compatibility
seriously, in part because they know
that working programmers will ignore them if they break too much old
code.
Steven Bethard
> Yo,
>
> On Feb 16, 6:07 am, Steven Bethard <steven.beth...@gmail.com> wrote:
>> Python 3.0 is determined not to be hampered by backwards incompatibility
>> concerns. It's not even clear yet that your average 2.6 code will work
>
> Then Python is pretty much determined to remove itself from
> consideration
> from various kinds of international projects like the one I work on.
You snipped the rest of that comment:
"It's not even clear yet that your average 2.6 code will work on 3.0 --
though there's a pretty large contingent trying to make this true."
If you want to make sure average 2.6 code works on 3.0, please help
contribute to Python. You can find out where best to focus your efforts
by asking on python-dev:
http://mail.python.org/mailman/listinfo/python-dev
> If it's not backwards compatible, meaning if 2.4 code doesn't run on
> 3.0, it's rather likely that strong pressure will be applied to port
> *away* from Python into something less capricious.
Well, Python 2.4 code will work on Python 2.6 and 2.7 so just because
your code isn't yet compatible with Python 3.0 doesn't mean you should
give up on Python.
Python 2.2 was released in early 2003 and you said you'd be dropping
support for 2.2 in early 2008, so I conclude that since Python 2.5 was
released in late 2006, you'll be ready to drop Python 2.5 support (and
have 2.6/3.0 compatible code) by late 2011. Sure, it's a long way off,
but you're writing 2.2 compatible code *now*. Is it really that bad to
wait four years for Python 3.0?
STeVe
Jay Tee
On Feb 20, 8:59 pm, Steven Bethard <steven.beth...@gmail.com> wrote:
> You snipped the rest of that comment:
>
> "It's not even clear yet that your average 2.6 code will work on 3.0 --
> though there's a pretty large contingent trying to make this true."
Thanks for pointing this out. I voted for the comp.lang.python
newsgroup back in the early 90's, my active days of python
'development' are over, it's all i can do to hang on to the code i've
been posting about.
> have 2.6/3.0 compatible code) by late 2011. Sure, it's a long way off,
> but you're writing 2.2 compatible code *now*. Is it really that bad to
> wait four years for Python 3.0?
As long as when python 3.0 shows up, i don't have to do a massive
rewrite. I think I've really only had to change two or three things
over the years .. one was that I used to use words like "dict" and
"list" in my code, which broke in subtle ways when d = dict() became
legal.
I just dug out some code laying around on disk from 1994, and ran it,
unchanged, under python 2.3.5. If I can achieve this (running 2007
code under python3.0 in 2011 with no modifications), that'd be OK.
JT
BJörn Lindqvist
have multiple version of installed. When Python 3.0 is released, all
Linux distros will acquire a symlink at /usr/bin/python2 pointing to
the latest Python 2.x version installed. Or something equivalent.
Rest assured that Linux distributors will not drop Python 2.x support
in the nearest decade. They are not stupid.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
mvh Björn
Paul Boddie
>
> Well, Python 2.4 code will work on Python 2.6 and 2.7 so just because
> your code isn't yet compatible with Python 3.0 doesn't mean you should
> give up on Python.
Perhaps the most important concern in the context of Python 3.0 is
what the term "Python" will come to mean to the different communities
using the language. Some people will be maintaining software that
needs to be compatible with older releases; these people aren't
technologically backwards: they just find that such older releases
provide sufficient capabilities for the implementation of their
solutions. For such people, "Python" will be the language they've
always used, with a gradual accumulation of features, some known
quirks, and some relatively minor incompatibility issues over the
years.
Meanwhile, the risk is that the core developers will only consider
Python 3.0 as "Python" and that people doing anything with older
releases will be on their own. If the gap is too wide between 2.x and
3.x, any lack of maintenance in the 2.x series will be perceived as an
abandonment of "Python" for certain kinds of user, and the result will
probably be a loss of confidence in both variants of the language.
Although I believe that some of the recent attempts to lower the
disruptiveness of Python 3.0 may have helped to maintain "Python" as a
single narrow continuum, I think some people overlook how fortunate
the relationship between Python's evolution and momentum has been, and
how easily such a relationship can be broken.
Paul
Jeff Templon
Bjorn, I am not sure I see why my post is bull crap. I think all you
are doing is agreeing with me. My post was entitled "Python 3.0 unfit
for serious work", you just indicated that the Linux distros will
agree with me, in order to be taken seriously, the distros will have
to include 2.x python for a very long time. If 3.0 and 2.x have any
serious degree of incompatibility, python will be a favorite subject
for religious rants and heated arguments for many people. And if we
don't manage to restrain our developers from using features that force
us prematurely to move to 3.0 ... and don't underestimate what this
means, because this means other things will have to move as well,
which may have dependencies on yet other things like C++ library
versions ... then I would have to, for reasons of maintainability,
argue against continuing to allow python code development in the
project. I love python, but not enough to make 20+ people's lives
difficult.
There are already people making this sort of argument in our project.
JT
Jay Tee
Paul, thanks for this, I didn't realize the scope of the situation. I
agree with your assessment to the extent that I understand what the
whole python 3.0 thing is about.
Let's see if I can scare up something I wrote about ten years ago on a
now-dead language that I really wanted to use (wound up sticking with
python instead because "it was supported" ;-)
=======================
to figure out how to work things. The fact that there are three (or
four depending if you count Linz V4) different Oberon System
implementations, and several different compilers, and even four or
five separate dialects of Oberon with none of them appearing to be
really "official", gives the impression of a fragmented, directionless
development effort, and a probability bordering on 1.0000 that
whatever you try to do will be incompatible with all but a small
subset of what's available (unless you stick to writing small programs
like in the books.) It does not matter if you tell people that this
is not so; something has to clearly stand out as being THE STANDARD
STUFF and all the other stuff as INTERESTING BUT NONTHREATENING SIDE
PROJECTS. The STANDARD STUFF must include a sufficient number of
=========================
Oberon is really really cool, seriously, ... but nobody is using it.
People working on python development are of course free to do what
they want, but so are the users ...
J "actie-reactie is what my ex-brother-in-law would say" T
Steven Bethard
> Let's see if I can scare up something I wrote about ten years ago on a
> now-dead language that I really wanted to use (wound up sticking with
> python instead because "it was supported" ;-)
>
> =======================
> to figure out how to work things. The fact that there are three (or
> four depending if you count Linz V4) different Oberon System
> implementations, and several different compilers, and even four or
> five separate dialects of Oberon with none of them appearing to be
> really "official", gives the impression of a fragmented, directionless
> development effort, and a probability bordering on 1.0000 that
> whatever you try to do will be incompatible with all but a small
> subset of what's available (unless you stick to writing small programs
> like in the books.) It does not matter if you tell people that this
> is not so; something has to clearly stand out as being THE STANDARD
> STUFF and all the other stuff as INTERESTING BUT NONTHREATENING SIDE
> PROJECTS. The STANDARD STUFF must include a sufficient number of
> =========================
Well, the problem of multiple standards shouldn't really apply in the
same way to Python. Right now, Python 2.X is the standard. Python 2.6,
2.7 and any later 2.X versions are intended to be transitional versions
while the standard is migrating to Python 3.X. At some point, the 2.X
line will almost certainly be discontinued.
So as a Python programmer, the path is clear. As soon as possible, you
should make your code compatible with Python 3.0. That will likely mean
taking advantage of some new features in Python 2.6, so "as soon as
possible" may still mean many years for projects that need to support
older versions of Python. Still, once Python 2.6 is installed everywhere
by default, it shouldn't be difficult to start making code compatible
with the new standard, Python 3.0.
STeVe
Paul Boddie
>
> Paul, thanks for this, I didn't realize the scope of the situation. I
> agree with your assessment to the extent that I understand what the
> whole python 3.0 thing is about.
I don't know if I've delimited the scope of any situation, really.
However...
[...]
> The fact that there are three (or
> four depending if you count Linz V4) different Oberon System
> implementations, and several different compilers, and even four or
> five separate dialects of Oberon with none of them appearing to be
> really "official",
[...]
The fortunate thing about different Python implementations and in
contrast to a lot of other languages and their implementations is that
the most actively developed Python implementation, CPython, is very
portable and is present on all major operating systems of consequence
(capable of running it). Other languages have suffered because there'd
be a UNIX version and then a version for Windows or the Mac which
wasn't as well maintained, or perhaps no version at all for one or
more of these platforms. So with Python, even if one implementation is
lagging behind (eg. Jython) there's still likely to be some deployment
solution on one's operating system of choice, given some level of
flexibility.
Where incompatibilities may arise with Python implementations is in
the level of support for recent language developments and additions.
Again, CPython's portability prevents this from becoming an operating
system issue, but we see rifts between implementations targeting
different runtime platforms, and whilst CPython 2.x and CPython 3.x
may continue to cover similar operating systems (although a desire to
drop support for various operating systems was stated), it's the rift
between them that presents the risk to any common notion of what
Python actually is.
Paul
BJörn Lindqvist
> Bjorn, I am not sure I see why my post is bull crap. I think all you
> are doing is agreeing with me. My post was entitled "Python 3.0 unfit
> for serious work", you just indicated that the Linux distros will
> agree with me, in order to be taken seriously, the distros will have
> to include 2.x python for a very long time. If 3.0 and 2.x have any
> serious degree of incompatibility, python will be a favorite subject
> for religious rants and heated arguments for many people. And if we
> don't manage to restrain our developers from using features that force
> us prematurely to move to 3.0 ... and don't underestimate what this
> means, because this means other things will have to move as well,
> which may have dependencies on yet other things like C++ library
> versions ... then I would have to, for reasons of maintainability,
> argue against continuing to allow python code development in the
> project. I love python, but not enough to make 20+ people's lives
> difficult.
>
> There are already people making this sort of argument in our project.
This is why I said that your post was a load of bull crap:
"Then Python is pretty much determined to remove itself from
consideration from various kinds of international projects like the
one I work on [unless py3k is backwards compatible with python 2.x]."
You did not explain why this is so.
"if 2.4 code doesn't run on 3.0, it's rather likely that strong
pressure will be applied to port *away* from Python into something
less capricious."
Who are these people that are applying the strong pressure? How can
you run a international and seemingly very important project without
knowing basic things about how to handle versioning problems?
I mean, they would rather port this big system, deployed on thousands
of computers all over the world, to an entirely different programming
language than to continue using Python 2.x because Python 3.x, when it
is released, MIGHT cause them some problems several YEARS from now?
--
mvh Björn
John Nagle
> So as a Python programmer, the path is clear. As soon as possible, you
> should make your code compatible with Python 3.0.
There's always the possiblity that Python 3 won't happen. Look at
what happened with Perl 6. That's been talked about for
seven years now. The user base just wasn't interested.
Perl 5 was good enough, and users migrated to PHP for the
little stuff and other languages for the bigger stuff.
As Wikipedia says, "As of 2007, Perl 6 was still under development,
with no planned completion date."
John Nagle
Paul Rubin
> There's always the possiblity that Python 3 won't happen. Look at
> what happened with Perl 6. That's been talked about for
> seven years now. The user base just wasn't interested.
> Perl 5 was good enough, and users migrated to PHP for the
> little stuff and other languages for the bigger stuff.
> As Wikipedia says, "As of 2007, Perl 6 was still under development,
> with no planned completion date."
I like to think PyPy will replace CPython as the main Python
implementation. Python 3.0 can then fork the language fairly
radically, like C++ vs C (ok, not so attractive an example) or Scheme
vs Lisp. Both dialects would stay active.
It seems to me that the flavor of Python programming has changed
significantly over the past few releases. That trend will likely
continue and even accelerate.
Steven Bethard
> So as a Python programmer, the path is clear. As soon as possible, you
> should make your code compatible with Python 3.0.
John Nagle wrote:
> There's always the possiblity that Python 3 won't happen.
That's not really a possibility. Unlike Perl 6, Python 3 is not a new
language. And you can see Guido's release plan here:
http://www.python.org/dev/peps/pep-3000/
In brief:
* An alpha in the first half of 2007
* First real release in the first half of 2008
STeVe
John Nagle
> John Nagle <na...@animats.com> writes:
>
>> There's always the possiblity that Python 3 won't happen. Look at
>>what happened with Perl 6. That's been talked about for
>>seven years now. The user base just wasn't interested.
>>Perl 5 was good enough, and users migrated to PHP for the
>>little stuff and other languages for the bigger stuff.
>>As Wikipedia says, "As of 2007, Perl 6 was still under development,
>>with no planned completion date."
>
>
> I like to think PyPy will replace CPython as the main Python
> implementation.
Well, something faster really should take over. It's a bit
embarassing that the main implementation of Python is still a
pure interpreter. Even Javascript has a JIT compiler now.
And it's tiny, under 1MB.
John Nagle
greg
> It's a bit
> embarassing that the main implementation of Python is still a
> pure interpreter. Even Javascript has a JIT compiler now.
Pure interpreted Python has always seemed more responsive
to me than any Java application I've tried to use. So I
can't help feeling that this JIT business is over-hyped.
--
Greg
Jay Tee
[ citing me ]
> "if 2.4 code doesn't run on 3.0, it's rather likely that strong
> pressure will be applied to port *away* from Python into something
> less capricious."
>
> Who are these people that are applying the strong pressure? How can
> you run a international and seemingly very important project without
> knowing basic things about how to handle versioning problems?
This isn't versioning. At least not the way I see it. Versioning has
to do with changes in your own product. Indeed one needs to know how
to handle it. Lately our project has been doing OK on this front, a
couple years ago was a different story.
Underlying technology is a different story. This should be reasonably
stable. Small changes are inevitable but even these are a major pain,
since we have dependency links like the following:
OS release links to
Python release which changes an
Third-party extension module which requires
A third party library whose
Version needs to be upgraded but which
Is used by some other non-python means that
Requires the earlier version.
Or the earlier problem, an OS upgrade comes with a new python version
on which existing code breaks.
The fraction of code in our system that's written in python is
something like 10% -- it's not a big pure-python system.
Now you're talking about major changes in the underlying technology,
forcing, at some point in the future, an extensive rewrite of the
python code. Yes, at that point, some people would make the comment
that a language which changes to that extent by major versions is not
fit for production work, and if one was going to have to rewrite, it
would be better to rewrite in a more stable language.
And finally, remember the original post I replied to said that python
3.0 was determined not to be hampered by backwards compatibility.
This is quite a bit different than what you say here ("MIGHT cause
problems"):
> language than to continue using Python 2.x because Python 3.x, when it
> is released, MIGHT cause them some problems several YEARS from now?
If backwards compatibility is not a consideration, then it would be a
miracle if there were no problems.
JT
Steven D'Aprano
> Well, something faster really should take over. It's a bit
> embarassing that the main implementation of Python is still a
> pure interpreter. Even Javascript has a JIT compiler now.
> And it's tiny, under 1MB.
Python has a compiler, just like Java. That's where the .pyc files come
from.
You might also notice the built-in function "compile", which compiles text
strings into byte-code and puts it into a code object. The dis module may
also be of interest.
--
Steven D'Aprano
Aahz
Jay Tee <jeff.t...@gmail.com> wrote:
>
>If backwards compatibility is not a consideration, then it would be a
>miracle if there were no problems.
Backwards compatibility is a consideration AND there will be problems.
That is, the goal of 3.0 is to lower the priority of backwards
compatibility enough to make some incompatible changes, but not to reduce
the priority of compatibility to zero. Just for example, "foo" will
become a Unicode string.
Note that I believe it will be many years, perhaps even a decade, before
"python" on a Unix system starts up Python 3.0. Python 2.x will have at
least two releases after 3.0 gets released, and I can't imagine that any
OS will have "python" refer to 3.0 while 2.x is still under active
development or even for a while after. I'd expect any OS to provide a
python3.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"I disrespectfully agree." --SJM
ols...@verizon.net
> yo,
>
> Bjorn, I am not sure I see why my post is bull crap. I think all you
> are doing is agreeing with me. My post was entitled "Python 3.0 unfit
> for serious work", you just indicated that the Linux distros will
> agree with me, in order to be taken seriously, the distros will have
> to include 2.x python for a very long time. If 3.0 and 2.x have any
> serious degree of incompatibility, python will be a favorite subject
> for religious rants and heated arguments for many people. And if we
> us prematurely to move to 3.0 ... and don't underestimate what this
> means, because this means other things will have to move as well,
> which may have dependencies on yet other things like C++ library
> versions ... then I would have to, for reasons of maintainability,
> argue against continuing to allow python code development in the
> project. I love python, but not enough to make 20+ people's lives
> difficult.
>
> There are already people making this sort of argument in our project.
>
> JT
I don't know the specifics of your app, but why does everyone insist
that they need to use the 'system' python?
At least one commercial python app I work with installs it's own
completely independant version of python. For many apps where
predictible behaviour is required you can install 'your' python,
under /opt/myapp or /usr/local/myapp or whatever instead of python,
python2.2, python3, etc. The downside is that you'll waste another
15Mb harddrive space, and you'll need to update your internal source
tree 4 or 5 times when maintenance releases come out.
Apologies if this sounds like a rant, I really mean it in a
constructive way.
-Grant
Jay Tee
> I don't know the specifics of your app, but why does everyone insist
> that they need to use the 'system' python?
Hey Grant, don't worry it's not a rant. A completely valid question.
Again it's a problem of dependency management ... one of the things
we've had to deal with is one of the applications : they have a
framework largely built in python, and I think they were indeed at one
point shipping their own python because they used features not present
in the "system" python.
However, they did use the middleware installed on the system, and this
middleware is also partially written in python ... except it was
expecting the system python. So you get into very tricky things
having to sanity check the PYTHONPATH, that the "user" python path is
not getting exported into middleware land, nor is the application's
desired PYTHONPATH being destroyed by middleware. We had just such an
issue here last week, we had solved the problem for bourne shell
users, but csh for some reason had a different behavior, and the user
app could not longer find its python modules.
About the only code for which we don't seem to have these issues is
compiled C. C++ is nasty because the compilers are still catching up
to the standard; the last I heard, a big segment of C++ code was stuck
because it was full of apparently illegal constructs that the previous
compiler (the g++ shipped stock with RHEL3) accepted, but the RHEL-4
native version refused to compile.
A colleague of mine pointed out today that this is an old problem, and
used to be handled by automake at compile time, with code full of
ifdefs ... now we've moved the problem to run time. Which I think is
harder, because sometimes we don't find the problem until our binary
is halfway across the world ...
JT
sjde...@yahoo.com
>
> Note that I believe it will be many years, perhaps even a decade, before
> "python" on a Unix system starts up Python 3.0.
That's a pretty safe bet considering that the factory-installed
"python" on my Linux system is still 1.x and you run "python2" to get
2.x (I haven't done a new OS install in a couple of years, but 2.x had
been out for years when I did the install). And 2.x is much less
likely to break 1.x code than 3.x will be to break 2.x code.
Peter Mayne
> On Tue, 20 Feb 2007 00:44:24 +0000, Peter mayne wrote:
>
>> Steven D'Aprano wrote:
>>> If Python 3 dropped the print
>>> statement and replaced it with official_print_function(), how would that
>>> help you in your goal to have a single code base that will run on both
>>> Python 2.3 and Python 3, while still using print?
>> Is there any reason why official_print_function isn't sys.stdout.write?
>
> Why would you want a convenience function like print to take one import,
> three look-ups and 16 characters instead of always available, one look-up
> and five characters?
Because it's compatible between Python 2.x and Python 3.x? :-)
Because without print as a keyword, I can say "print = sys.stdout.write"
and still have (some) convenience? (Albeit still one import and one
lookup, though given the probable time taken to do the I/O, why worry
about the lookup?) Or, if your editor has an abbreviation facility like
Eclipse, you can type sys.stdout.write with less than 5 keystrokes.
>> I can't remember the last time I used print in actual code (apart from
>> short-lived debugging lines), so I'm bewildered as to why print seems to
>> be so important.
>
> print is important for the convenience, for short-lived debugging, and for
> use in the interactive interpreter.
Why use print in the interactive interpreter? Just type the expression.
Hmm, I was expecting that that wouldn't always work, but:
>>> x=3
>>> if x==3: x
...
3
>>> for i in range(x):
... i
...
0
1
2
PJDM
Steven D'Aprano
> Why use print in the interactive interpreter? Just type the expression.
Many reasons. Here are four:
>>> print None
None
>>> None
>>> print 0.1
0.1
>>> 0.1
0.10000000000000001
>>> print 'null = \0'
null =
>>> 'null = \0'
'null = \x00'
>>> print 1, 2, 3
1 2 3
>>> 1, 2, 3
(1, 2, 3)
I'm sure you can find your own examples.
--
Steven.
I V
> I think the C and C++ committees also take backwards compatibility
> seriously, in part because they know
> that working programmers will ignore them if they break too much old
> code.
While that's true, C++ compiler vendors, for example, take backwards
compatibility significantly less seriously, it seems to me. A year or so
ago, I tried compiling something I'd written for g++ 2, using a
then-recent-ish g++ 3; it failed spectacularly. Likewise with Visual C++ 6
and a Visual C++ 2005. The suggestion that "working programmers"
will reject python if a major version change introduces some backwards
incompatibilities is not borne out by the experience of any other
language I am aware of.
Jay Tee
> While that's true, C++ compiler vendors, for example, take backwards
> compatibility significantly less seriously, it seems to me. A year or so
> ago, I tried compiling something I'd written for g++ 2, using a
> then-recent-ish g++ 3; it failed spectacularly. Likewise with Visual C++ 6
> and a Visual C++ 2005. The suggestion that "working programmers"
> will reject python if a major version change introduces some backwards
> incompatibilities is not borne out by the experience of any other
> language I am aware of.
The experience with C++ in our project is similar to yours. I think
the real reason is that the compiler tries to be more true to the
standard than to past implementations; past implementations accepted
incorrect syntax, newer "improved" compilers broke backwards
compatibility by rejecting the incorrect syntax.
Can't blame 'em, C++ syntax is hard ... don't try this at home,
kids ...
On the other hand, C++ is firmly established as a "serious" language
in our community while python is not. So the programmers tend to be
more forgiving. There is no perception that compiler developers are
*trying* to be difficult by changing the language to break backwards
compatibility. That's the difference I think.
JT
Aahz
Jay Tee <jeff.t...@gmail.com> wrote:
>
>On the other hand, C++ is firmly established as a "serious" language
>in our community while python is not. So the programmers tend to be
>more forgiving. There is no perception that compiler developers are
>*trying* to be difficult by changing the language to break backwards
>compatibility. That's the difference I think.
Consider the difference between "Python 3.0 is designed to break
backward compatibility" and "Python 3.0 cleans up a lot of accumulated
cruft".
sk...@pobox.com
Jeff> My post was entitled "Python 3.0 unfit for serious work", you just
Jeff> indicated that the Linux distros will agree with me, in order to
Jeff> be taken seriously, the distros will have to include 2.x python
Jeff> for a very long time. If 3.0 and 2.x have any serious degree of
Jeff> incompatibility, python will be a favorite subject for religious
Jeff> rants and heated arguments for many people.
The notion that Python 3.0 was going to fix design/implementation issues in
earlier versions of Python and thus cause some breakage has been known for a
long time, at least since Guido's UK Python talk in March 2003. Python 2.x
released will continue to be created for some time after Python 3.0 is
released. From PEP-3000:
I expect that there will be parallel Python 2.x and 3.x releases for
some time; the Python 2.x releases will continue for a longer time than
the traditional 2.x.y bugfix releases. Typically, we stop releasing
bugfix versions for 2.x once version 2.(x+1) has been released. But I
expect there to be at least one or two new 2.x releases even after 3.0
(final) has been released, probably well into 3.1 or 3.2. This will to
some extend depend on community demand for continued 2.x support,
acceptance and stability of 3.0, and volunteer stamina.
The whole intention is to give authors a long period of time to port to
Python 3.x. I believe your fear is just a knee jerk reaction to the notion
that there will be some stated incompatibilities between 2.x and 3.x without
having done any investigation of the transition process. Nobody is forcing
you to do anything right now or completely abandon your code base. Python
2.x still has a long shelf life. Hell, 3.0a1 isn't even out yet. If you
hang on for a few days I'm sure Guido's keynote about Python 3 from the
PyCon just wrapping up in Dallas will be available online. There might be
something in there of interest to you. If you poke around a bit you will
probably find nearly live blogs from the conference as well.
Skip
Neil Cerutti
> On Tue, 20 Feb 2007 10:46:31 -0800, Beliavsky wrote:
>> I think the C and C++ committees also take backwards
>> compatibility seriously, in part because they know that
>> working programmers will ignore them if they break too much
>> old code.
>
> While that's true, C++ compiler vendors, for example, take
> backwards compatibility significantly less seriously, it seems
> to me.
Compiler vendors usually take care of their customers with
compiler switches that enable backwards compatibility.
--
Neil Cerutti
"Martin v. Löwis"
> In other words, the consequence of pep 3105 will be that *nobody* who wants
> their app to be portable will be able to use print until *everybody* has
> converted to Python 3.x. I doubt that is what Guido had in mind, but I may
> be mistaken :-)
That's not true. Many uses of print work just fine whether print is a
function. For example, from the standard library:
quopri.py: print "-t: quote tabs"
can be rewritten as
print("-t: quote tabs")
shlex.py: print 'shlex: reading from %s, line %d' \
% (self.instream, self.lineno)
can be rewritten as
print('shlex: reading from %s, line %d' \
% (self.instream, self.lineno))
So people can rewrite their code so that it uses print, and still works
in both Python 1.5 and 3.0.
Of course, there are many uses that cannot be converted this way, but
it's not true that *nobody* who want there app to be portable will be
able to use print until *everybody* has converted to Python 3.x.
Regards,
Martin
"Martin v. Löwis"
That's a bold statement, after I V already gave two examples
(g++ and MSVC 2005) of compilers that broke backwards compatibility
without providing compiler switches to bring it back. These two
aren't "minor" compilers.
Regards,
Martin
Christophe
In C++ land, people are expected to fix their code and not use broken
compilers in such situations.
They have some kind of moral high ground because they do not break
compatibility just for that but to be more standards compliant. And the
fact that all the C++ code I've written with g++ recently compiled
perfectly on Visual 2005 without a single change ( except fixing new
warnings ) shows that standard compliance in C++ compilers is a good
thing to have. That same code had some major and very annoying breakage
with Visual 6. The fix? Updating that outdated compiler.
Jay Tee
> Python 3.x. I believe your fear is just a knee jerk reaction to the notion
> that there will be some stated incompatibilities between 2.x and 3.x without
> having done any investigation of the transition process. Nobody is forcing
> you to do anything right now or completely abandon your code base. Python
> 2.x still has a long shelf life. Hell, 3.0a1 isn't even out yet. If you
Thanks to the pointer to PyCon, if there is anything relevant maybe
you can send me off a mail (or post here) with some links. About the
above : it isn't fear, I'm just telling you what I suspect might
happen. My own little piece of code in the giant picture will remain
in python, unless i am mandated to move it to something else : I
*like* python.
I threw in my few cents here just because I suspect the python
community does not intend to move itself into the realm of
"interesting but not serious languages" like Oberon did. I could be
wrong, both in the sense that maybe that *is* the intention, or maybe
making a backwards-incompatible "evolution" of the language won't hurt
python or it's users. We now return to your regularly scheduled
program.
J "back to the grind" T