Martin v. Löwis a écrit :
> Neil Cerutti schrieb:
>> On 2007-02-23, I V <[EMAIL PROTECTED]> wrote:
>>> 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 w
Neil Cerutti schrieb:
> On 2007-02-23, I V <[EMAIL PROTECTED]> wrote:
>> 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 e
Edward K Ream schrieb:
> 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
On 2007-02-23, I V <[EMAIL PROTECTED]> wrote:
> 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.
>
> Whi
In article <[EMAIL PROTECTED]>,
Jay Tee <[EMAIL PROTECTED]> 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 diff
On Feb 23, 8:48 am, I V <[EMAIL PROTECTED]> wrote:
> 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
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
On Thu, 22 Feb 2007 16:29:17 +1100, Peter Mayne wrote:
> 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.10001
>>> print 'null = \0'
null =
>>> 'null = \0'
'null = \x00'
>>>
Steven D'Aprano wrote:
> On Tue, 20 Feb 2007 00:44:24 +, 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
>>>
On Feb 16, 10:17 am, Steven D'Aprano
<[EMAIL PROTECTED]> 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 u
On Tue, 20 Feb 2007 00:44:24 +, 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 s
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_func
"Steve Holden" <[EMAIL PROTECTED]> wrote:
> 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 Py
On Feb 16, 2:31 pm, Sam <[EMAIL PROTECTED]> wrote:
>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 impossib
On 16 Feb 2007 13:48:29 -0800, Klaas <[EMAIL PROTECTED]> wrote:
> 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 "copy
On Feb 16, 6:01 am, "Edward K Ream" <[EMAIL PROTECTED]> wrote:
> 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 f
[Edward K Ream]
> 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.
> But that doesn't just happen.
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 widg
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 do
On Fri, 16 Feb 2007 09:32:56 -0600, Edward K Ream wrote:
>> 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
On Fri, 16 Feb 2007 16:49:05 +0100, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
>On 2/16/07, Jean-Paul Calderone <[EMAIL PROTECTED]> 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
>
On 2/16/07, Jean-Paul Calderone <[EMAIL PROTECTED]> 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 m
> Keep the print name;
> 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
prob
On Fri, 16 Feb 2007 09:07:02 -0600, Edward K Ream wrote:
>>> 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 fun
> 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
On Sat, 17 Feb 2007 02:17:23 +1100, Steven D'Aprano <[EMAIL PROTECTED]> 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
On Feb 16, 3:00 pm, "Edward K Ream" <[EMAIL PROTECTED]> wrote:
> > 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
On Feb 16, 2:54 pm, Steven D'Aprano
<[EMAIL PROTECTED]> 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.
>
> Unf
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
>> 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. The title of this thre
> 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.
> That doesn't
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
goa
On Fri, 16 Feb 2007 08:01:11 -0600, Edward K Ream wrote:
>> 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.
>
> A
> It looks your main issue is that you're complaining that Python 3000 is
going to break things in a non-backward compatible way.
No. My complaint is *only* that changing the meaning of 'print' is needless
pain.
Edward
Edward
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 confuse
on 16.02.2007 13:02 Edward K Ream said the following:
>> 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 y
> print is only a problem if you expect your code to work under both Python
> 2.x and 3.x.
Exactly.
Edward
Edward K. Ream email: [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.html
---
On Feb 16, 2:01 pm, "Edward K Ream" <[EMAIL PROTECTED]> wrote:
> > 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 proo
On Fri, 16 Feb 2007 06:07:42 -0600, Edward K Ream wrote:
>> 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 pr
Edward K Ream schreef:
>> 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
Edward K Ream schreef:
>> 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.
>
> Presum
> 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
On Feb 16, 12:47 pm, "Edward K Ream" <[EMAIL PROTECTED]> wrote:
> > 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 ther
Edward K Ream wrote:
>> 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
--
http://mail.python.org/mailman/listinfo/pytho
> There could be something like from __future__ import print_function
To repeat: this would be compatible only with Python 2.6.
Edward
Edward K. Ream email: [EMAIL PROTECTED]
Leo: http://webpages.charter.net/edreamleo/front.
Edward K Ream wrote:
>> 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.
> 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
On Feb 16, 11:54 am, "Edward K Ream" <[EMAIL PROTECTED]> wrote:
> > 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
> Is that what you intend to say?
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
> 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
> 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)'.
Edward
> 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 interesti
On 2/15/07, Edward K Ream <[EMAIL PROTECTED]> wrote:
> > 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. [...]
It is the only intent of Python 3.0: be free of backward compatibity
constraints.
There ar
On Thu, 15 Feb 2007 19:04:34 -0600, Edward K Ream wrote:
>> 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
Edward K Ream wrote:
>> 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
"Edward K Ream" <[EMAIL PROTECTED]> writes:
> > 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-compat
En Thu, 15 Feb 2007 22:04:34 -0300, Edward K Ream <[EMAIL PROTECTED]>
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
> 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 com
Isn't the very concept of major releases (1.x, 2.x, 3.x) that they
*can* be not backwards-compatible with previous releases?
m.
--
http://mail.python.org/mailman/listinfo/python-list
> 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 :-)
> why can't you use ``file.write()`` instead of ``print``?
Precisely my
Edward K Ream wrote:
> 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 ba
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. Indeed, i
62 matches
Mail list logo
