> Note that increased 3.x compatibility in the most recent 2.x release
> will always help in two scenarios:
>
> 1. New projects that want to use 2.x only libraries but want to be ready
> for the Py3k transition in their own code (e.g. new 2.7 features like
> set literals, dict and set comprehensio
On Sat, Jan 9, 2010 at 18:29, Benjamin Peterson wrote:
> Please consider trying Python 2.7 with your code and reporting any bugs you
> may
I ran the Mercurial test suite on current trunk, and it worked
alright. There was a small issue with the fact that mimetypes got
fooled by the lack of Import
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
> Tres Seaver wrote:
>> There is an obnoxious deprecation warning out of the distutils:
>>
>> DeprecationWarning: 'compiler' specifies the compiler type in
>> build_ext. If you want to get the compiler object itself, use
>> 'c
Tres Seaver wrote:
> There is an obnoxious deprecation warning out of the distutils:
>
> DeprecationWarning: 'compiler' specifies the compiler type in
> build_ext. If you want to get the compiler object itself, use
> 'compiler_obj'
>
> which is likely a simple one-line fix, if I only knew w
Michael Foord wrote:
> I agree with Martin that the *perception* is that to use Python 2.6 to
> help you port to Python 3 you have to be willing to drop support for
> earlier versions of Python.
Note that increased 3.x compatibility in the most recent 2.x release
will always help in two scenarios:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Karen Tracey wrote:
> On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson wrote:
>
>> On behalf of the Python development team, I'm gleeful to announce the
>> second
>> alpha release of Python 2.7.
>>
>>
> Well yay. Django's test suite (1242 tests) ru
On 12 Jan, 10:04 pm, mar...@v.loewis.de wrote:
[...]
I've done a fair bit of 3.x porting, and I'm firmly convinced that
2.x can do nothing:
[...]
Inherently, 2.8 can't improve on that.
I agree that there are limitations like the ones you've listed, but I
disagree with your conclusion. Maybe
> I'm not talking about Twisted moving to 3.x (FWIW, I think the only
> movement there so far is some patches for some -3 warnings). The
> situation I'm describing is a project X that:
>
> (a) has 2.x-only dependencies, and
> (b) would like to be as close as possible to 3.x (because they like
> Nick wrote:
>>> This has nothing to do with pushing 3.x, but all with managing
>>> available manpower and still providing quality software.
>>
>> Python 3.x needs more carrots.
>
> As Guido has said a few times, the gains are far greater for *new*
> Python developers than they are for existing on
On 1/12/2010 5:04 PM, "Martin v. Löwis" wrote:
But you won't *have* fewer differences. Just because your code runs
on 2.8 doesn't mean it will stop running on 2.3 (if you have a need
for that). This doesn't get you any closer - you can't use any of
the 2.8 features as long as you have to support
"Martin v. Löwis" wrote:
[...]
> > But a hypothetical 2.8 would also give people a way to move closer to
> > py3k without giving up on using all their 2.x-only dependencies.
>
> How so? If they use anything that is new in 2.8, they *will* need to
> drop support for anything before it, no???
>
>
> [...]
>> I've done a fair bit of 3.x porting, and I'm firmly convinced that
>> 2.x can do nothing:
> [...]
>> Inherently, 2.8 can't improve on that.
>
> I agree that there are limitations like the ones you've listed, but I
> disagree with your conclusion. Maybe you assume that it's just as hard
On Tue, Jan 12, 2010 at 22:56, "Martin v. Löwis" wrote:
>> Maybe not, but the Distribute feature is there because IMO the
>> distutils feature by itself isn't particularily useful. You need to
>> write your own distutils extensions, in practice, and they are not
>> trivial.
>
> I wouldn't say that
On 12/01/2010 21:53, "Martin v. Löwis" wrote:
a) telling people that they have to move to 2.6 first actually
hurts migration, instead of helping, because it implies to them
that they have to drop old versions (e.g. 2.3.) - just because
they had *always* dropped old versions before suppor
> Maybe not, but the Distribute feature is there because IMO the
> distutils feature by itself isn't particularily useful. You need to
> write your own distutils extensions, in practice, and they are not
> trivial.
I wouldn't say that. My Django port works with bare distutils (as
does Django itsel
>> a) telling people that they have to move to 2.6 first actually
>> hurts migration, instead of helping, because it implies to them
>> that they have to drop old versions (e.g. 2.3.) - just because
>> they had *always* dropped old versions before supporting new ones.
>
> Is it just an impli
On Tue, Jan 12, 2010 at 04:29, Michael Foord wrote:
> On 12/01/2010 12:16, Barry Warsaw wrote:
>
> On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
>
>
>
> Actually there's a solution to this one too:
>
>FooBase = Meta('FooBase', (), {})
>class Foo(FooBase):
>...
>
> That shou
On 12/01/2010 12:16, Barry Warsaw wrote:
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
Actually there's a solution to this one too:
FooBase = Meta('FooBase', (), {})
class Foo(FooBase):
...
That should work in Python 2.X and 3.X.
Ugly, but good call! :)
On Jan 11, 2010, at 09:57 PM, Steven Bethard wrote:
>Actually there's a solution to this one too:
>
>FooBase = Meta('FooBase', (), {})
>class Foo(FooBase):
>...
>
>That should work in Python 2.X and 3.X.
Ugly, but good call! :)
>I've got argparse running on Python 2.3-3.1, and th
On Jan 11, 2010, at 10:53 PM, Jack Diederich wrote:
>3) 100% of the module level assignments in public projects were the
>"__metaclass__ = type" variety which is why there isn't a fixer for
>that. Also, a fixer would have been really, really ugly (munge every
>class definition in this module beca
David Lyon wrote:
>> This has nothing to do with pushing 3.x, but all with managing
>> available manpower and still providing quality software.
>
> Python 3.x needs more carrots.
As Guido has said a few times, the gains are far greater for *new*
Python developers than they are for existing ones.
Lennart Regebro wrote:
> And, I just realized, it doesn't warn for you using cmp or __cmp__
> either, and 2to3 won't fix that, so it should actually warn for it.
I have a vague recollection that we tried to warn for that and ended up
nixing the warning due to vast swarms of false alarms (or becaus
On Tue, Jan 12, 2010 at 01:07, Andrew Bennetts wrote:
> But a hypothetical 2.8 would also give people a way to move closer to
> py3k without giving up on using all their 2.x-only dependencies. I
> think it's much more likely that libraries like Twisted can support 2.8
> in the near future than 3.
On Tue, Jan 12, 2010 at 01:11, Barry Warsaw wrote:
> Interesting. The only reason I never used it before is because I didn't know
> about it. Am I alone?
Maybe not, but the Distribute feature is there because IMO the
distutils feature by itself isn't particularily useful. You need to
write your
On Mon, Jan 11, 2010 at 23:55, Guido van Rossum wrote:
> +1 from me. (With the caveat that "time will tell" is definitely the
> ultimate answer. Plans may change unexpectedly, even though we don't
> expect them to.)
>
> PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
> helpful.
On Mon, Jan 11, 2010 at 4:11 PM, Barry Warsaw wrote:
> As an example, the one library I've already ported used a metaclass. I don't
> see any way to specify that the metaclass should be used in a portable way.
> In Python 2.6 it's:
>
> class Foo:
> __metaclass__ = Meta
>
> and in Python 3 it's
2010/1/11 Jack Diederich :
> On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw wrote:
>> As an example, the one library I've already ported used a metaclass. I don't
>> see any way to specify that the metaclass should be used in a portable way.
>> In Python 2.6 it's:
>>
>> class Foo:
>> __metaclas
On Mon, Jan 11, 2010 at 7:11 PM, Barry Warsaw wrote:
> As an example, the one library I've already ported used a metaclass. I don't
> see any way to specify that the metaclass should be used in a portable way.
> In Python 2.6 it's:
>
> class Foo:
> __metaclass__ = Meta
>
> and in Python 3 it's
Andrew Bennetts bemusement.org> writes:
>
> But a hypothetical 2.8 would also give people a way to move closer to
> py3k without giving up on using all their 2.x-only dependencies. I
> think it's much more likely that libraries like Twisted can support 2.8
> in the near future than 3.x.
I don't
"Martin v. Löwis" wrote:
[...]
> I've done a fair bit of 3.x porting, and I'm firmly convinced that
> 2.x can do nothing:
[...]
> Inherently, 2.8 can't improve on that.
I agree that there are limitations like the ones you've listed, but I
disagree with your conclusion. Maybe you assume that it's
On Jan 11, 2010, at 02:55 PM, Guido van Rossum wrote:
>PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
>helpful. But I trust he has ported a lot more code to 3.x than I have
>personally. Are there other experiences?
I've only done one small library so far, but it was helpful t
On Jan 11, 2010, at 10:42 PM, Martin v. Löwis wrote:
>Wrt. the distribute feature you've noticed: Python 3.0 already supports
>that in distutils. So from day one of Python 3.x, you could have used
>that approach for porting Python code. I had been promoting it ever
>since, but it's taking up only
Antoine writes:
> As someone who experiences the difference almost every day, I can say 3.x
> definitely has enough carrots for me. The simple fact that I will be able
> to
> raise exceptions with non-ASCII error messages without having to
> workaround a
> hopelessly broken conversion/reporting lo
> David Lyon preisshare.net> writes:
> >
> > > This has nothing to do with pushing 3.x, but all with managing
> > > available manpower and still providing quality software.
> >
> > Python 3.x needs more carrots.
I'd be happy to move UpLib to Python 3, when the various packages that I
need are a
David Lyon preisshare.net> writes:
>
> > This has nothing to do with pushing 3.x, but all with managing
> > available manpower and still providing quality software.
>
> Python 3.x needs more carrots.
As someone who experiences the difference almost every day, I can say 3.x
definitely has enough
Hi Martin,
> Of course, the less active fraction of Python contributors may not
> notice, since they just chose to not contribute (which, of course,
> is fine). However, asking me to work twice as much as I want to
> on the project to keep two branches alive is just unfair.
Totally true. Actuall
Guido van Rossum wrote:
> +1 from me. (With the caveat that "time will tell" is definitely the
> ultimate answer. Plans may change unexpectedly, even though we don't
> expect them to.)
>
> PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
> helpful.
That's really because I have
+1 from me. (With the caveat that "time will tell" is definitely the
ultimate answer. Plans may change unexpectedly, even though we don't
expect them to.)
PS. I'm surprised that Martin thinks that the -3 mode in 2.6 is not
helpful. But I trust he has ported a lot more code to 3.x than I have
perso
> So, it should say "Guido wants 2.7 to be the last main version of
> Python 2, so it probably will be. We promise to release bugfixes it
> for, like, ages".
>
> No need to be needlessly formal. :-D
That summarizes my understanding of what Guido said fairly well :-)
+1 for putting it into the an
> So the question we should be asking is: what's missing from Python
> 2.7 to help with this transition?
Wrt. the distribute feature you've noticed: Python 3.0 already supports
that in distutils. So from day one of Python 3.x, you could have used
that approach for porting Python code. I had been p
On Mon, Jan 11, 2010 at 18:46, MRAB wrote:
> "Official" is whatever the BDFL says it is! :-)
Heh, right.
So, it should say "Guido wants 2.7 to be the last main version of
Python 2, so it probably will be. We promise to release bugfixes it
for, like, ages".
No need to be needlessly formal. :-D
-
Lennart Regebro wrote:
On Mon, Jan 11, 2010 at 10:06, "Martin v. Löwis"
wrote:
I know you are just looking for a compromise, but this shouldn't be
it: the PSF has deliberately stayed out of the actual Python
engineering, so the release that Benjamin makes is not done by the
PSF (but by Benjamin
On Jan 10, 2010, at 6:07 PM, Martin v. Löwis wrote:
> As for decisions: I don't think there was an official BDFL pronouncent,
> but I recall Guido posting a message close to that, proposing that 2.7
> will be a release that will see bug fix releases for an indefinite
> period of time (where indefi
Neil Schemenauer writes:
> On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> > If people start taking the carrots we have added to 3.x and
> > backporting them to keep the 2.x series alive you are essentially
> > making the 3.x DOA by negating its benefits which I personally
> >
Neil Schemenauer, 11.01.2010 05:17:
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
[...] would it still be ok if I closed a 2.x feature request as
"won't fix", or only committed the new feature to the 3.x branch?
Yes. Non-bugfix development on 2.x would optional (i.e. done
On Mon, Jan 11, 2010 at 10:06, "Martin v. Löwis" wrote:
> I know you are just looking for a compromise, but this shouldn't be it:
> the PSF has deliberately stayed out of the actual Python engineering,
> so the release that Benjamin makes is not done by the PSF (but by
> Benjamin and his contribut
> "Python 2.7 is scheduled to be the last major version in the 2.x
> series released by the Python Software Foundation before it moves into
> 5 years of bugfix-only mode. "
>
> That doesn't exclude *others* making a Python 2.8 that could include
> all sorts of crazy features. :)
>
> This is mainl
This is what it says now:
"Python 2.7 is scheduled to be the last major version in the 2.x
series before it moves into 5 years of bugfix-only mode. "
And during this discussion it has been noted that others than the core
python team might pick up Python 2 and make releases. So maybe we can
and th
> I guess I have more confidence in Python 3 than you do. I don't see
> why Python 2.x needs to be artificially limited so that Python 3 can
> benefit.
Because it takes too much time. Too much of my time, but apparently
also too much of other people's time.
Of course, the less active fraction of
> I would guess over 99% of all Python code written doesn't run on
> Python 3. Given that, I think it is premature to close the door on
> new major versions of Python 2.x. Also, we as a project should be
> careful not to present the image that Python 2.x will not be
> supported in the future.
Why
after all these years, some people still run AmigaOS.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Neil Schemenauer wrote:
> On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
>> [...] would it still be ok if I closed a 2.x feature request as
>> "won't fix", or only committed the new feature to the 3.x branch?
>
> Yes. Non-bugfix development on 2.x would optional (i.e. done by
Brett Cannon wrote:
IMO keeping Python 2.x around past 2.7 is the equivalent of python-dev
saying "Python 3 is the future, but we are keeping the old Python 2.x
around because we don't have *that* much faith in the future we have
laid out". That's poison to Python 3 by showing a lack of confide
On Mon, Jan 11, 2010 at 06:27, Neil Schemenauer wrote:
> I think we have got to the heart of our disagreement. Assume that
> some superhuman takes all the backwards compatible goodies from 3.x
> and merges them into 2.x.
The superhumans of core developers pretty much already have. That's
pretty m
On Sun, Jan 10, 2010 at 21:27, Neil Schemenauer wrote:
> On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> > If people start taking the carrots we have added to 3.x and
> > backporting them to keep the 2.x series alive you are essentially
> > making the 3.x DOA by negating its benef
On Sun, Jan 10, 2010 at 09:06:15PM -0800, Brett Cannon wrote:
> If people start taking the carrots we have added to 3.x and
> backporting them to keep the 2.x series alive you are essentially
> making the 3.x DOA by negating its benefits which I personally
> don't agree with.
I think we have got t
On Sun, Jan 10, 2010 at 20:05, Neil Schemenauer wrote:
> On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote:
> > On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote:
> > > After the Python 2.7 release, the focus of Python development
> > > will be on Python 3. There will con
On Mon, Jan 11, 2010 at 12:02:01AM +0100, "Martin v. Löwis" wrote:
> [...] would it still be ok if I closed a 2.x feature request as
> "won't fix", or only committed the new feature to the 3.x branch?
Yes. Non-bugfix development on 2.x would optional (i.e. done by
people who want to spend the tim
On Sun, Jan 10, 2010 at 07:46:04PM -0800, Brett Cannon wrote:
> On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote:
> > After the Python 2.7 release, the focus of Python development
> > will be on Python 3. There will continue to be maintainance
> > releases of Python 2.x.
>
> No
On Sun, Jan 10, 2010 at 17:44, Neil Schemenauer wrote:
> On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
> > I don't think ending the 2.x series at 2.7 makes it look bad
> > compared to 3.2; it's simply the end of a development line like
> > any other software project. I suspect 2.7
On 1/10/2010 8:44 PM, Neil Schemenauer wrote:
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
I don't think ending the 2.x series at 2.7 makes it look bad
compared to 3.2; it's simply the end of a development line like
any other software project. I suspect 2.7 will have a protracte
On Sun, Jan 10, 2010 at 12:09:08PM -0800, Brett Cannon wrote:
> I don't think ending the 2.x series at 2.7 makes it look bad
> compared to 3.2; it's simply the end of a development line like
> any other software project. I suspect 2.7 will have a protracted
> bugfix window because so much code runs
> The announcement is precisely to avoid the situation where people commit
> new features to the 2.x main line of development (after the 2.7
> maintenance branch is created) in the expectation that they will be
> released as part of a hypothetical 2.8 release.
>
> Whether that info needs to be in
> I propose that the 2.x branch be treated like 2.x.y branches: as
> long as there is sufficient volunteer labour, it should continue to
> live. In order to avoid wasted development effort, it would be
> prudent to announce that unless a 2.8 release manager steps up,
> whatever is committed to the
Neil Schemenauer wrote:
> In order to avoid wasted development effort, it would be
> prudent to announce that unless a 2.8 release manager steps up,
> whatever is committed to the 2.x branch after the 2.7 release may
> never get released.
The announcement is precisely to avoid the situation where
On Sun, Jan 10, 2010 at 11:30, Neil Schemenauer wrote:
> Benjamin Peterson wrote:
> > On behalf of the Python development team, I'm gleeful to announce
> > the second alpha release of Python 2.7.
>
> Thanks to everyone who contributed.
>
> > Python 2.7 is scheduled to be the last major version i
Benjamin Peterson wrote:
> On behalf of the Python development team, I'm gleeful to announce
> the second alpha release of Python 2.7.
Thanks to everyone who contributed.
> Python 2.7 is scheduled to be the last major version in the 2.x
> series.
Has this really been decided already? Maybe I mi
2010/1/9 Karen Tracey :
> On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson
> wrote:
>>
>> On behalf of the Python development team, I'm gleeful to announce the
>> second
>> alpha release of Python 2.7.
>>
>
> Well yay. Django's test suite (1242 tests) runs with just one failure on
> the 2.7 alp
On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson wrote:
> On behalf of the Python development team, I'm gleeful to announce the
> second
> alpha release of Python 2.7.
>
>
Well yay. Django's test suite (1242 tests) runs with just one failure on
the 2.7 alpha 2 level, and that looks to be likely
On behalf of the Python development team, I'm gleeful to announce the second
alpha release of Python 2.7.
Python 2.7 is scheduled to be the last major version in the 2.x series. It
includes many features that were first released in Python 3.1. The faster io
module, the new nested with statement
70 matches
Mail list logo
