On Thu, Mar 20, 2008 at 8:25 PM, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 3/20/08, Anand Balachandran Pillai <[EMAIL PROTECTED]> wrote:
>
> > There are also many bugs filed for Py3k which are patterned
> > like "deprecated feature should raise a warning in py3k".
> > Are they in any priori
> That would certainly work for me. Could we add some description of this
> separation to the Roundup pages? And/or is there a way that only
> developers or the triage specialists are allowed to change the priority?
I dropped the severity. Changing the priority was already restricted to
people
> 'critical' is fine (or 'immediate'). My problem before was that I
> couldn't do one query that gave me all the critical issues for both
> 2.6 and 3.0. That certainly could have been pebkac though. Neal
> mentioned that that kind of query should be possible, if it's not
> already there.
On Thu, Mar 20, 2008 at 2:13 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> test_getargs2 is failing on Windows x64:
> test test_getargs2 failed -- Traceback (most recent call last):
> File
> "S:\buildbots\python.x64\3.0.nelson-win64\build\lib\test\test_getargs2.py",
> line 190, in test_n
>
"Christian Heimes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Thomas Wouters schrieb:
| The __future__ docs say "No feature description will ever be deleted
| from __future__."
|
| ever is a very strong word and I expect Python 3.x to follow the rule.
I was tempted to suggest
You're right, having at least one example in svn helps tremendously.
This is super deep code written by Tim Peters, and getting all the
details right is tricky...
On Thu, Mar 20, 2008 at 8:07 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Cool, I can live with that. Are a
Guido van Rossum wrote:
> Cool, I can live with that. Are all current __future__ statements
> still valid in 3.0?
Yes, all of them are in __future__.py. But most references to 2 of them
(nested scopes and generators) have been deleted from the C code, in
both 2.6 and 3.0.
I think it is useful
Guido van Rossum wrote:
> Cool, I can live with that. Are all current __future__ statements
> still valid in 3.0?
I believe so, yes. But I'll double check.
>
> On Thu, Mar 20, 2008 at 5:55 PM, Eric Smith
> <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > Really? I though 2to3 was sup
Cool, I can live with that. Are all current __future__ statements
still valid in 3.0?
On Thu, Mar 20, 2008 at 5:55 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Really? I though 2to3 was supposed to remove all __future__ imports?
>
> I was convinced when Christian point
Guido van Rossum wrote:
> Really? I though 2to3 was supposed to remove all __future__ imports?
I was convinced when Christian pointed out the statement in
http://docs.python.org/lib/module-future.html:
"No feature description will ever be deleted from __future__."
Admittedly, I implemented more
Would it help if 2.6 had a __future__ import to treat
all unadorned string literals as unicode?
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/
On Thu, Mar 20, 2008 at 11:49:42PM +0100, Christian Heimes wrote:
> Walter D?rwald schrieb:
> > Isn't the super secret -U option most of what we need?
>
> Yeah, it's really super secret. Neither me nor python --help knows about
> it. :)
Neither "man python". I knew the option, but forgot about
On Thu, Mar 20, 2008 at 11:20 PM, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> A future import would only affect one module though, -U is global.
Yeah, I don't think -U would work because of that. That would again
mean you need to switch all code at the same time.
--
Lennart Regebro: Zope and Pl
Walter Dörwald schrieb:
> Isn't the super secret -U option most of what we need?
Yeah, it's really super secret. Neither me nor python --help knows about
it. :)
Christian
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman
Christian Heimes wrote:
> Barry Warsaw schrieb:
>> I proposed what I think is a better solution. Add
>>
>> from __future__ import unicode_strings
>>
>> to Py2.6. That would let you write Py3k compatible strings (and of
>> course byte literals) in 2.6. It would essential treat 'foo' as
>> u'f
Barry Warsaw schrieb:
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.
Somebody has to fix the subversion related code in Python/sysmodule.c:
[EMAIL PROTECTED]:
On Thu, Mar 20, 2008 at 8:42 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version con
>> For the development cycle, it could remain change-test, if the test
>> runner would do the 2to3 conversion first.
>
> Why/how would it? How would it know what to run 2to3 on?
There could be a 3k copy created by the test suite, which it
updates based on the time stamps of the 2.x sources.
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 20, 2008, at 3:58 PM, Christian Heimes wrote:
> Barry Warsaw schrieb:
>> I'm happy to announce that we now have available for public
>> consumption, the Python source code for 2.5, 2.6 and 3.0 available
>> under the Bazaar distributed ver
Lennart Regebro schrieb:
> On Thu, Mar 20, 2008 at 9:35 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> I think it's an reasonable approach to change *all* literals to be 100%
>> Python 3.0 compatible.
>
> Well, I'm sure not going to complain if that is the case. :)
It's just a proposal. We'
Barry Warsaw schrieb:
> I proposed what I think is a better solution. Add
>
> from __future__ import unicode_strings
>
> to Py2.6. That would let you write Py3k compatible strings (and of
> course byte literals) in 2.6. It would essential treat 'foo' as
> u'foo' in the file with the future
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 20, 2008, at 2:48 AM, Lennart Regebro wrote:
> So, please allow u'' in Python 3.0! With that change, my
> porting/compatibility worried would be gone, and you would be able to
> choose between the three porting strategies dependningon how your
Barry Warsaw schrieb:
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version control system.
Thank you very much to Barry and the rest of team! Great work!
Ubuntu users have to i
On Thu, Mar 20, 2008 at 9:35 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I think it's an reasonable approach to change *all* literals to be 100%
> Python 3.0 compatible.
Well, I'm sure not going to complain if that is the case. :)
> When the user specifies the py3k_literal mode than 1L a
On Thu, Mar 20, 2008 at 9:29 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> In such an environment, you could run 2to3 even at import time,
> as somebody proposed.
That is even less realistic, to be honest. And many of these modules
are not installed, so there there is no install time. That
On Thu, Mar 20, 2008 at 9:15 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> How about "from __future__ import py3k_literals" for Python 2.6? The
> future statement turns several literals into Python 3.0 mode:
>
> * '' creates an unicode object instead of a str object
That would be fantastic
Lennart Regebro schrieb:
>> * b'' creates a str object (aka bytes in Python 3.0)
>
> It already does that, as b'' doesn't clash with any python 2 literal,
> so that's already fixed.
I know, I've implemented the feature myself about two months ago. I
wanted to emphasis on the fact that b'' creat
> The recommended path for porting Python code to Python 3.0 is to use a
> tool called 2to3 to convert the code from Python 2.x code to 3.x code.
Correct.
> If you need to support both 2.x and 3.0, you should maintain the code
> as 2.x code, and convert it to 3.x code and test it before you make
>> It was proposed before, I don't know whether any implementation
>> on that has started.
>
> I don't see anything in the bug tracker. I'd be willing to look at it,
> if this is what we want to do.
Neither could I. I vaguely remember having people mention it, but
could not find anything, eithe
Lennart Regebro schrieb:
> Now, before we all get into doomsday mode, there is good news. First
> of all, 2.6a1 already contains a lot of forwards compatibility. And
> with the "from __future__ import print_function", which adds more such
> compatibility. The horrible complete compatibility break t
On Thu, Mar 20, 2008 at 7:02 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Lennart Regebro schrieb:
>
> > On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> >> It'll do a much better job than try-and-pray. It may not matter in any of
> >> your code, but I really sug
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm happy to announce that we now have available for public
consumption, the Python source code for 2.5, 2.6 and 3.0 available
under the Bazaar distributed version control system.
The current Subversion repository is still the master copy of the
Christian Heimes wrote:
> Thomas Wouters schrieb:
> > This surprises me greatly. The reason this is true in 2.x is for the
> obvious
>> backward compatibility. 3.0 is about not worrying about backward
>> compatibility. Why do we need to keep the future imports?
>>
>
> The __future__ docs say "No
Thomas Wouters schrieb:
> This surprises me greatly. The reason this is true in 2.x is for the
obvious
> backward compatibility. 3.0 is about not worrying about backward
> compatibility. Why do we need to keep the future imports?
>
The __future__ docs say "No feature description will ever be d
Eric Smith schrieb:
> py3k supports future imports. For example, "from __future__ import
> with_statement" works, and I presume it's a no-op. I did not forward
> port print_function, but maybe I should?
Python 3.0 must accept all future imports that are available in the 2.x
series although th
On Thu, Mar 20, 2008 at 12:10 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Eric Smith schrieb:
> > py3k supports future imports. For example, "from __future__ import
> > with_statement" works, and I presume it's a no-op. I did not forward
> > port print_function, but maybe I should?
>
> Pyt
Martin v. Löwis wrote:
>> Will python 2.6 have something like "from future import
>> unicode_string_literals" ?
>
> It was proposed before, I don't know whether any implementation
> on that has started.
I don't see anything in the bug tracker. I'd be willing to look at it,
if this is what we w
Lennart Regebro schrieb:
> On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> It'll do a much better job than try-and-pray. It may not matter in any of
>> your code, but I really suggest not relying on it. Use 2to3.
>
> This is not a case of try and pray, and 2to3 is not
On Thu, Mar 20, 2008 at 5:50 PM, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> It'll do a much better job than try-and-pray. It may not matter in any of
> your code, but I really suggest not relying on it. Use 2to3.
This is not a case of try and pray, and 2to3 is not a realistic option.
--
Lennart
On Thu, Mar 20, 2008 at 9:28 AM, Lennart Regebro <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 20, 2008 at 4:40 PM, Charles Merriam
> <[EMAIL PROTECTED]> wrote:
> > The problem is not the gratuitous removal of the leading 'u', but the
> > subtle problems when
> > the code looks nearly identical. Th
On Thu, Mar 20, 2008 at 5:27 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Will python 2.6 have something like "from future import
> > unicode_string_literals" ?
>
> It was proposed before, I don't know whether any implementation
> on that has started.
>
>
> > This should also solve lenn
On Thu, Mar 20, 2008 at 4:40 PM, Charles Merriam
<[EMAIL PROTECTED]> wrote:
> The problem is not the gratuitous removal of the leading 'u', but the
> subtle problems when
> the code looks nearly identical. The most likely one to cause
> problems is the new semantics
> of the keys operations.
> Will python 2.6 have something like "from future import
> unicode_string_literals" ?
It was proposed before, I don't know whether any implementation
on that has started.
> This should also solve lennart's problem. (But then py3k would need to
> support that future import, which
> is forbidden
On Thu, Mar 20, 2008 at 3:20 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> Will python 2.6 have something like "from future import
> unicode_string_literals" ?
> This should also solve lennart's problem. (But then py3k would need to
> support that future import, which
> is forbidden).
A try/excep
@#$ send in the middle of the email.Sorry.
Short version: Python 3000 breaks other code as well, some subtly.
This could be bad.One long debugging
session over a missing character on a report due to the change in
representation of a Long could make all
the work of trying for an easy "3to2
Hello Lennart,
As you can see by the growing conversation, the matter is a bit old
and, with age, smells
bad. I'd like to convince you that it is a bad idea anyway.
The problem is not the gratuitous removal of the leading 'u', but the
subtle problems when
the code looks nearly identical. The mo
Lennart Regebro
Ralf Schmitt
On 3/20/08, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
> What about using sys.path_hooks to run 2to3 on the fly at import time?
> It would cache its results, of course.
I think even that might be overkill; Lennart (and others) are talking
about trying to use t
I *think* you already fixed this; if not, I agree it should be fixed.
While import * is not great, I think the alternative is worse.
As you point out, an explicit listing is unmaintainable, and the
alternative is a funky dance to first import that module's __all__,
then import based on that -- whi
On 3/20/08, Anand Balachandran Pillai <[EMAIL PROTECTED]> wrote:
> There are also many bugs filed for Py3k which are patterned
> like "deprecated feature should raise a warning in py3k".
> Are they in any priority ?
Do you really mean warn in 3.0? Or do you mean that they're gone (or
should
On Thu, Mar 20, 2008 at 3:09 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > Now, it is quite possible to say that this isn't desirable, and that
> > 2.6 and 3.0 should not be able to run the same code at all, even if
> > that was possible, but I haven't heard that opinion, and hope it isn't
> Now, it is quite possible to say that this isn't desirable, and that
> 2.6 and 3.0 should not be able to run the same code at all, even if
> that was possible, but I haven't heard that opinion, and hope it isn't
> common.
>
> If we need to have this discussion again, I will prepare a longer
> an
> What about using sys.path_hooks to run 2to3 on the fly at import time?
> It would cache its results, of course.
It would have to do so selectively, and it would be fairly slow (atleast
with the current implementation), but yes, that could also work.
The question then is: what __file__ do you pu
Ralf Schmitt wrote:
>
> On Thu, Mar 20, 2008 at 1:30 PM, Lennart Regebro <[EMAIL PROTECTED]> wrote:
> >
> > On Thu, Mar 20, 2008 at 1:16 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
> wrote:
> > > However, it *is* common to install Python code before running it.
> >
> > Not every time you make a chan
On Thu, Mar 20, 2008 at 1:30 PM, Lennart Regebro <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 20, 2008 at 1:16 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
> wrote:
> > However, it *is* common to install Python code before running it.
>
> Not every time you make a change in the code.
>
I also happen to
On Thu, Mar 20, 2008 at 1:16 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> However, it *is* common to install Python code before running it.
Not every time you make a change in the code.
> Lennart, can you please comment whether this (need for compilation)
> was also your concern, or just
> Well, he is basically required to compile his source code before he can
> run it.
> This is quite uncommon for python code...
However, it *is* common to install Python code before running it.
I propose a scheme (which is almost implemented) where you run
2to3 as part of the distutils build st
On Thu, Mar 20, 2008 at 1:00 PM, "Martin v. Löwis" <[EMAIL PROTECTED]>
wrote:
> > So, please allow u'' in Python 3.0! With that change, my
> > porting/compatibility worried would be gone, and you would be able to
> > choose between the three porting strategies dependningon how your code
> > base
> So, please allow u'' in Python 3.0! With that change, my
> porting/compatibility worried would be gone, and you would be able to
> choose between the three porting strategies dependningon how your code
> base and user base looks: 1. Clean break. 2. Syncing with 2to3, 3.
> Supporting both 2.6 and
On Thu, Mar 20, 2008 at 11:28 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 3 is not an option, and isn't going to be an option.
I know the Python 3000 project started with the attitude of not having
any backwards compatibility to be able to start at a blank slate. But
since then the compatibilit
Lennart Regebro wrote:
> So, please allow u'' in Python 3.0! With that change, my
> porting/compatibility worried would be gone, and you would be able to
> choose between the three porting strategies dependningon how your code
> base and user base looks: 1. Clean break. 2. Syncing with 2to3, 3.
>
Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 2:57 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> However, PEP 3100 (the general Py3k TO-DO list) includes a line item to
>> get rid of "from ... import *" at function level because of the merry
>> hell it plays with the local variable optimisa
Hi,
Sorry for the late reply. Looked into the bug list, the following bugs
looked interesting.
http://bugs.python.org/issue2122
http://bugs.python.org/issue2188
http://bugs.python.org/issue2320
http://bugs.python.org/issue2325
http://bugs.python.org/issue2355
http://bugs.python.org/issue2389
T
Hiya all, I've googled for this issue but I couldn't find it so I hope
this hasn't been beaten to death already.
I've been doing some compatibility tests with 3.0a3, 2.6a1 and 2.5, to
see exactly what breaks and how and if you can get around it,
basically to see if it is possible to write code tha
test_getargs2 is failing on Windows x64:
test test_getargs2 failed -- Traceback (most recent call last):
File
"S:\buildbots\python.x64\3.0.nelson-win64\build\lib\test\test_getargs2.py",
line 190, in test_n
self.failUnlessEqual(99, getargs_n(Long()))
TypeError: 'Long' object cannot be interp
Hm. zlib is an odd place to find this API (unless you know way more
about gzip than healthy :-). Though binascii isn't much better. I'd
rather expect this in the vicinity of md5 and sha... Is it possible to
tweak that C code to use the zlib version if present and the old C
code otherwise?
On Tu
65 matches
Mail list logo
