I should maybe point out that although I'm generally +1 on
backporting, I'm not specifically anything on backporting the nonlocal
keyword. There are probably things that would help more from a
compatibility standpoint than that.
For example, from __future__ import unicode_literals doesn't switch
t
I'm not aware of any currently active project that isn't in the process of
adding Py3 support (or who has already done so). By "most maintainers" I'm
referring to the long tail; the hundreds of 3rd party modules used in niche
cases and can be easily replaced by those who need the functionality the
2009/11/3 Charles Cazabon :
> "Martin v. Löwis" wrote:
> It's pretty easy to make Python source that works under 2.6 and 3.x. It's
> basically impossible to make Python source that works under 2.4/2.5 and
> 3.x.
Without using 2to3, yes.
See http://code.google.com/p/python-incompatibility/ wh
Personally, I have found it useful in doco I write to have a section on
"Common Tasks", with recommended/suggested examples of how to do them and
short rationale for the chosen method. It seems to me that if .pick()
is frequently desired and "None of the standard solutions are obvious
or easily di
2009/11/3 Paul Moore :
> Has that port been integrated back into the zodb project?
That is on the way. Setuptools has been ported via the distribute
project, I'm hoping to make a test release of the zope.interface
branch (to test Python 2 compatibility mainly) soon, and then
hopefully merge it, et
>> But only if NumPy would drop support for 2.x, for x < 7, right?
>> That would probably be many years in the future.
>
> Yes. Today, given the choice of supporting py 3.x and dropping python
> < 2.7 and continue support for 2.4, the latter is by far my preferred
> choice today (RHEL still requir
2009/11/3 sstein...@gmail.com :
>
> On Nov 2, 2009, at 7:26 PM, James Y Knight wrote:
>>
>> It really sounds like you're saying that switching to 3.x isn't worth the
>> cost to you, but you want to force people (including yourself) to do so
>> anyways, because ...?
>
> Because that's the future of
2009/11/3 sstein...@gmail.com :
> Not that anyone has asked yet, but here's my opinion on two issues that have
> been raised on the python-dev mailing list lately:
>
> +1 on 2.7 release with as much 3.0 "easy-port goo" as is practicable
> without delaying the product beyond the tentative sch
On Nov 3, 2009, at 6:23 AM, Paul Moore wrote:
2009/11/3 Raymond Hettinger :
In all these matters, I think the users should get a vote. And
that vote
should be cast with their decision to stay with 2.x, or switch to
3.x, or
try to support both. We should not muck with their rational
decis
On 04Nov2009 09:46, Steven D'Aprano wrote:
| On Tue, 3 Nov 2009 09:19:38 am Greg Ewing wrote:
| > Cameron Simpson wrote:
| > > Personally, I'm for the iteration spec in a lot of ways.
For the record, I've since, in mere hours or day, been convinced my
preference was misguided.
I _do_ still feel
On Nov 3, 2009, at 5:16 PM, Paul Moore wrote:
2009/11/3 Brett Cannon :
I'm afraid there is some FUD going around here, which is
understandable since no one wants to burn a ton of time on something
that will be difficult or take a lot of time. But I have not heard
anyone in this email thread (or
On Tue, Nov 3, 2009 at 6:14 AM, Daniel Stutzbach
wrote:
> It's pretty easy to make Python source that works under 2.6 and 3.x. It's
> basically impossible to make Python source that works under 2.4/2.5 and
> 3.x.
This keeps getting quoted later in the thread so I just wanted to say
again that th
On Tue, Nov 3, 2009 at 6:27 PM, Larry Bugbee wrote:
> This is my problem to solve... I work with a lot of [non-production] crypto
> where byte strings are a normal way of manipulating and storing keys and
> other artifacts. Under Python2 I have few/no Unicode issues. With
> Python3's default st
On Tue, Nov 3, 2009 at 3:27 PM, Larry Bugbee wrote:
> This is my problem to solve... I work with a lot of [non-production] crypto
> where byte strings are a normal way of manipulating and storing keys and
> other artifacts. Under Python2 I have few/no Unicode issues. With
> Python3's default st
Guido van Rossum python.org> writes:
>
> You're obviously talking about a *random* element. This is a separate
> use case (though I agree many people don't know the difference).
>
> Picking a random element can be done in O(1) only if the data
> structure supports access by index, which Python's
Antoine Pitrou writes:
> Paul Moore gmail.com> writes:
> > TurboGears - Python 3 "currently unsupported", no timescale given
>
> TurboGears is Pylons-based, so I suppose the actual question is when
> Pylons gets ported.
And there's the rub. I expect this general problem of “project FOO
depends
On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano wrote:
> On Tue, 3 Nov 2009 09:19:38 am Greg Ewing wrote:
>> Cameron Simpson wrote:
>> > Personally, I'm for the iteration spec in a lot of ways.
>> >
>> > Firstly, a .get()/.pick() that always returns the same element
>> > feels horrible. Is there a
Brett Cannon python.org> writes:
>
> I'm afraid there is some FUD going around here, which is
> understandable since no one wants to burn a ton of time on something
> that will be difficult or take a lot of time. But I have not heard
> anyone in this email thread (or anywhere for that matter) say
This is my problem to solve... I work with a lot of [non-production]
crypto where byte strings are a normal way of manipulating and storing
keys and other artifacts. Under Python2 I have few/no Unicode
issues. With Python3's default string type being Unicode, there are a
lot of subtle wa
Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 9:37 AM, "Martin v. Löwis" wrote:
(and no, adding things like nonlocal to 2.7 doesn't making porting of
a real application or library any easier, since the existing application
or library simply doesn't use that keyword.
Agreed.
In fact, no cha
On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg wrote:
>> This suspension of features is designed to allow non-CPython implementations
>> to "catch up" to the core implementation of the language, help ease adoption
>> of Python 3.x, and provide a more stable base for the community.
>
> I'd also add
On Tue, Nov 3, 2009 at 12:35 PM, Guido van Rossum wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
>
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) b
Hello,
It seems that there is no buildbot to test a wide unicode build.
On http://www.python.org/dev/buildbot/3.x/ all outputs of the "configure"
steps show this message::
checking what type to use for str... unsigned short
which looks like a ucs2 build to me.
Since wide unicode is the standar
On Nov 3, 2009, at 1:42 PM, Georg Brandl wrote:
sstein...@gmail.com schrieb:
On Nov 3, 2009, at 12:28 PM, Arc Riley wrote:
The main thing holding back the community are lazy and/or obstinate
package maintainers. If they spent half the time they've put into
complaining about Py3 into actual
On Wed, Nov 4, 2009 at 3:25 AM, "Martin v. Löwis" wrote:
> But only if NumPy would drop support for 2.x, for x < 7, right?
> That would probably be many years in the future.
Yes. Today, given the choice of supporting py 3.x and dropping python
< 2.7 and continue support for 2.4, the latter is by
On Tue, 3 Nov 2009 09:19:38 am Greg Ewing wrote:
> Cameron Simpson wrote:
> > Personally, I'm for the iteration spec in a lot of ways.
> >
> > Firstly, a .get()/.pick() that always returns the same element
> > feels horrible. Is there anyone here who _likes_ it?
>
> It doesn't sound very useful to
Guido van Rossum writes:
> On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg wrote:
> > One question:
> >
> > There are currently number of patch waiting on the tracker for
> > additional Unicode feature support and it's also likely that we'll
> > want to upgrade to a more recent Unicode versi
On Tue, Nov 3, 2009 at 4:46 PM, Steven D'Aprano wrote:
> def pick_two_cards(hand):
>assert isinstance(hand, (set, frozenset))
>assert len(hand) == 5
>return (hand.pick(), hand.pick())
>
Even if pick() chose random, you still might end up picking the same card
twice. Is that really w
On Tue, Nov 03, 2009 at 12:28:47PM -0500, Arc Riley wrote:
>
> The main thing holding back the community are lazy and/or obstinate package
> maintainers. If they spent half the time they've put into complaining about
> Py3 into actually working to upgrade their code they'd be done now.
The main
+1. There are no compelling language changes on the horizon ("yield
from" is nice but not necessary). I see the main benefit of a
moratorium as social rather than technical by encouraging people to
work on the lib instead of the language. Plus, I'd gladly proxy my
vote to any one of the three PE
On Tue, Nov 3, 2009 at 11:21 AM, Brett Cannon wrote:
> Are you going to gauge it roughly from python-dev feedback, or should
> we take a more formal vote on python-committers once the PEP has
> settled?
I'll not take a formal vote unless the discussion suggests there's a
lot of pushback. So far I
2009/11/3 Brett Cannon :
> I'm afraid there is some FUD going around here, which is
> understandable since no one wants to burn a ton of time on something
> that will be difficult or take a lot of time. But I have not heard
> anyone in this email thread (or anywhere for that matter) say that
> they
On Tue, Nov 3, 2009 at 1:00 PM, Georg Brandl wrote:
> From my experience, string to unicode migration really is the biggest
> pain when porting anything that handles real-world data.
Of course, handling Unicode right is also the biggest pain when
writing code for 2.x in the first place -- writing
Greg Ewing canterbury.ac.nz> writes:
> >
> >>Picking a random element can be done in O(1) only if the data
> >>structure supports access by index, which Python's hash tables don't.
> >
> > Well, at the implementation level, they can. You'd just have to pick a new
> > random index until it points
On 4/11/2009 4:35 AM, Guido van Rossum wrote:
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
Good move, +1.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http
Terry Reedy schrieb:
> James Y Knight wrote:
>
>> If that happens, it's not true that there's *nowhere* to go. A solution
>> would be to discard 3.x as a failed experiment, take everything that is
>> useful from it and port it to 2.x, and simply continue development from
>> the last 2.x release
On Nov 3, 2009, at 12:35 PM, Guido van Rossum wrote:
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected, in fact) but I'm brac
James Y Knight wrote:
If that happens, it's not true that there's *nowhere* to go. A solution
would be to discard 3.x as a failed experiment, take everything that is
useful from it and port it to 2.x, and simply continue development from
the last 2.x release. And from there, features can be de
On Tue, Nov 3, 2009 at 2:35 PM, Guido van Rossum wrote:
> fierce discussion here on python-dev. It's important to me that if if
> this is accepted it is a "rough consensus" decision (working code we
+1 to the PEP.
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.pytho
On Tue, Nov 3, 2009 at 5:10 PM, Antoine Pitrou wrote:
> Greg Ewing canterbury.ac.nz> writes:
>> >
>> >>Picking a random element can be done in O(1) only if the data
>> >>structure supports access by index, which Python's hash tables don't.
>> >
>> > Well, at the implementation level, they can. Yo
>>> I wouldn't say that. For instance, I'm just starting a refactoring that
>>> will
>>> result in getmail v.5, but I need to target Python 2.5 and up, so there's
>>> essentially no way the code will run in Python 3.x (as another list member
>>> posted).
>> That's a common myth. It is very well p
On Tue, Nov 3, 2009 at 05:40, David Cournapeau wrote:
> On Tue, Nov 3, 2009 at 9:55 PM, Barry Warsaw wrote:
>
>>
>> Then clearly we can't back port features.
>>
>> I'd like to read some case studies of people who have migrated applications
>> from 2.6 to 3.0.
>
> +1, especially for packages which
Guido> I've checked draft (!) PEP 3003, "Python Language Moratorium",
Guido> into SVN.
LGTM.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
"Martin v. Löwis" wrote:
>>> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
>>> object), which means it is better for people wanting to ease transition to
>>> 3.x.
>>>
>>> But of course, as Martin said, few people will want to support 2.7 only and
>>> not
>>> 2.6.
>>
>
On Nov 3, 2009, at 7:42 PM, Ben Finney wrote:
Antoine Pitrou writes:
Paul Moore gmail.com> writes:
TurboGears - Python 3 "currently unsupported", no timescale given
TurboGears is Pylons-based, so I suppose the actual question is when
Pylons gets ported.
And there's the rub. I expect th
Guido van Rossum wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
>
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) but I'm bracing myself for
> fierc
On Tue, Nov 3, 2009 at 09:35, Guido van Rossum wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
>
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) but
On Tue, Nov 3, 2009 at 12:20 AM, Yuvgoog Greenle wrote:
> On Tue, Nov 3, 2009 at 12:19 AM, Greg Ewing
> wrote:
>>
>> Cameron Simpson wrote:
>>
>>> Personally, I'm for the iteration spec in a lot of ways.
>>>
>>> Firstly, a .get()/.pick() that always returns the same element feels
>>> horrible. Is
sstein...@gmail.com schrieb:
>
> On Nov 3, 2009, at 12:28 PM, Arc Riley wrote:
>>
>> The main thing holding back the community are lazy and/or obstinate
>> package maintainers. If they spent half the time they've put into
>> complaining about Py3 into actually working to upgrade their code
>> the
On Tue, Nov 3, 2009 at 10:42 AM, Georg Brandl wrote:
> sstein...@gmail.com schrieb:
> >
> > On Nov 3, 2009, at 12:28 PM, Arc Riley wrote:
> >>
> >> The main thing holding back the community are lazy and/or obstinate
> >> package maintainers. If they spent half the time they've put into
> >> comp
Antoine Pitrou schrieb:
> Georg Brandl gmx.net> writes:
>>
>> skip pobox.com schrieb:
>> > Martin> And if *2.6* becomes the last of the 2.x series?
>> >
>> > With all due respect, I don't think you can make that decision now. The
>> > time to have stated 2.6 would be the end of the 2.x lin
On Tue, Nov 3, 2009 at 9:37 AM, "Martin v. Löwis" wrote:
> (and no, adding things like nonlocal to 2.7 doesn't making porting of
> a real application or library any easier, since the existing application
> or library simply doesn't use that keyword.
Agreed.
> In fact, no change to 2.x
> can reas
I'm not ready for that yet. I think there's plenty of time before we
have to agree to such a bleak view. In the mean time let's do
something practical like help NumPy port to Py3k.
>>>
>>> Or, for example, Django...
>>
>> See
>>
>> http://wiki.python.org/moin/PortingDjangoTo3k
>
> W
Martin v. Löwis wrote:
I would be really surprised if 2.7 would simplify porting to 3.x. How
could that possibly work?
The only things I can think of that would go into this category are
features like:
- PEP 3118, revised buffer protocol. If the buffer API that numpy
uses is not present in py3
Barry Warsaw wrote:
On Nov 3, 2009, at 12:35 PM, Guido van Rossum wrote:
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected,
>> I would be really surprised if 2.7 would simplify porting to 3.x. How
>> could that possibly work?
>
> The only things I can think of that would go into this category are
> features like:
> - PEP 3118, revised buffer protocol. If the buffer API that numpy
> uses is not present in py3k (I'm no
> * General language semantics
> The language operates as-is with only specific exemptions (see
> below).
Would PEP 382 (namespace packages) fall under the moratorium?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Nov 3, 2009, at 12:35 PM, Antoine Pitrou wrote:
Arc Riley gmail.com> writes:
+1 on ending with 2.6.I'm the maintainer of 3rd party Python 3-only
packages
and have ported a few modules that we needed with some help from
the 2to3
tool. It's really not a big deal - and Py3 really is a m
> I wouldn't say that. For instance, I'm just starting a refactoring that will
> result in getmail v.5, but I need to target Python 2.5 and up, so there's
> essentially no way the code will run in Python 3.x (as another list member
> posted).
That's a common myth. It is very well possible, using
"Martin v. Löwis" wrote:
> > I wouldn't say that. For instance, I'm just starting a refactoring that
> > will
> > result in getmail v.5, but I need to target Python 2.5 and up, so there's
> > essentially no way the code will run in Python 3.x (as another list member
> > posted).
>
> That's a co
On Nov 3, 2009, at 12:28 PM, Arc Riley wrote:
The main thing holding back the community are lazy and/or obstinate
package maintainers. If they spent half the time they've put into
complaining about Py3 into actually working to upgrade their code
they'd be done now.
That's an inflammato
On Tue, Nov 3, 2009 at 10:20 AM, "Martin v. Löwis" wrote:
>> * General language semantics
>> The language operates as-is with only specific exemptions (see
>> below).
>
> Would PEP 382 (namespace packages) fall under the moratorium?
Import semantics are a bit of a gray area. However I thi
> Wasn't Django ported to Py3k by MvL as a demo? The problem seems to be
> more to port the Django *community* to Py3k...
Exactly so. At the last Pycon, we then agreed that I would get a branch
in the Django code repository, but then progress stalled due to
inactivity on boths sides.
Regards,
Mar
> yet another feature request or two to be lost to a mailing list thread
> along those lines:
>
> Maintainer or not i'd like to be able to setup triggers so that i'm
> automatically cc'ed on any bugs matching a simple search query i
> specify.
Please add that to the meta tracker (if you really wa
On Nov 3, 2009, at 10:54 AM, Guido van Rossum wrote:
Ouch. sets. I'm guessing you are referring to code that was still
using the pre-2.4 sets.py module? Yes, that must have been painful.
Indeed. :) What's nice though is that these changes could be made for
the Python 2.5 branch and didn't h
On Tue, Nov 3, 2009 at 9:35 AM, sstein...@gmail.com wrote:
>
> On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote:
>
>> On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight wrote:
>>>
>>> If that happens, it's not true that there's *nowhere* to go. A solution
>>> would be to discard 3.x as a failed ex
s...@pobox.com schrieb:
> Martin> And if *2.6* becomes the last of the 2.x series?
>
> With all due respect, I don't think you can make that decision now. The
> time to have stated 2.6 would be the end of the 2.x line was when 2.6 was
> released. At that point instead of opening up the trunk
Steven D'Aprano wrote:
I don't know how expensive it is to create a set iterator,
Not expensive enough to justify burdening the set type with
extra functionality that will be extremely rarely used.
--
Greg
___
Python-Dev mailing list
Python-Dev@pyth
> To answer your question, the main issues are:
> - are two branches are necessary or not ? If two branches are
> necessary, I think we simply do not have the resources at the moment.
No, it should be well possible to have the same source being used in
both 2.x and 3.x. I've ported ZODB to Python
Martin v. Löwis wrote:
A Python 3 version of NumPy might be enough of an improvement to bring
*more* scientists and engineers onboard if the Python 3.x version shows
what great productivity gains are to be had with Python 3.x over 2.x.
I would be really surprised if 2.7 would simplify porting t
Raymond Hettinger schrieb:
> [Michael Foord]
>> What will it take to *start* the port? (Or is it already underway?) For
>> many projects I fear that it is only the impending obsolescence (real
>> rather than theoretical) of Python 2 that will convince projects to port.
>
> FWIW, I do not buy into
2009/11/3 "Martin v. Löwis" :
>>> I'd like to read some case studies of people who have migrated applications
>>> from 2.6 to 3.0.
>>
>> +1, especially for packages which have a lot of C code: the current
>> documentation is sparse :) The only helpful reference I have found so
>> far is an email by
On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight wrote:
If that happens, it's not true that there's *nowhere* to go. A
solution
would be to discard 3.x as a failed experiment, take everything
that is
useful from it and port it to 2.x, and
>> You may also want to take a look at my ZODB port:
>>
>> https://www.dcl.hpi.uni-potsdam.de/home/loewis/zodb/
>
> Has that port been integrated back into the zodb project?
Only partially so.
> If not, it
> would be interesting to know the reasons (zodb project maintainers not
> interested, bar
>> I'd like to read some case studies of people who have migrated applications
>> from 2.6 to 3.0.
>
> +1, especially for packages which have a lot of C code: the current
> documentation is sparse :) The only helpful reference I have found so
> far is an email by MvL concerning psycopg2 port.
You
> It's pretty easy to make Python source that works under 2.6 and 3.x.
> It's basically impossible to make Python source that works under 2.4/2.5
> and 3.x. You may be able to write code that works under 2.4/2.5 and
> works cleanly with 2to3 to produce 3.x code. I haven't tried that
> route, tho
>> I'm not ready for that yet. I think there's plenty of time before we
>> have to agree to such a bleak view. In the mean time let's do
>> something practical like help NumPy port to Py3k.
>
> Or, for example, Django...
See
http://wiki.python.org/moin/PortingDjangoTo3k
Regards,
Martin
Georg Brandl gmx.net> writes:
>
> skip pobox.com schrieb:
> > Martin> And if *2.6* becomes the last of the 2.x series?
> >
> > With all due respect, I don't think you can make that decision now. The
> > time to have stated 2.6 would be the end of the 2.x line was when 2.6 was
> > released.
Martin v. Löwis schrieb:
>> It's pretty easy to make Python source that works under 2.6 and 3.x.
>> It's basically impossible to make Python source that works under 2.4/2.5
>> and 3.x. You may be able to write code that works under 2.4/2.5 and
>> works cleanly with 2to3 to produce 3.x code. I ha
On Tue, Nov 3, 2009 at 9:37 AM, "Martin v. Löwis" wrote:
>
> (and no, adding things like nonlocal to 2.7 doesn't making porting of
> a real application or library any easier, since the existing application
> or library simply doesn't use that keyword. In fact, no change to 2.x
> can reasonably simp
Antoine Pitrou wrote:
Guido van Rossum python.org> writes:
Picking a random element can be done in O(1) only if the data
structure supports access by index, which Python's hash tables don't.
Well, at the implementation level, they can. You'd just have to pick a new
random index until it poin
Folks:
I really don't want to make anyone feel bad or to criticize, but I
should mention that I have no plans to use Python 3 or to support
Python 3. My best guess at this time is that the current projects
that I'm involved in will still require Python 2 for the forseeable
future (let's say 5 yea
>> 2.7 has an up-to-date backport of the C IO lib (as well as the memoryview
>> object), which means it is better for people wanting to ease transition to
>> 3.x.
>>
>> But of course, as Martin said, few people will want to support 2.7 only and
>> not
>> 2.6.
>
> Since 2.7 will be closer to 3.2
> A Python 3 version of NumPy might be enough of an improvement to bring
> *more* scientists and engineers onboard if the Python 3.x version shows
> what great productivity gains are to be had with Python 3.x over 2.x.
I would be really surprised if 2.7 would simplify porting to 3.x. How
could tha
On Nov 3, 2009, at 12:43 PM, Martin v. Löwis wrote:
I'm not ready for that yet. I think there's plenty of time before we
have to agree to such a bleak view. In the mean time let's do
something practical like help NumPy port to Py3k.
Or, for example, Django...
See
http://wiki.python.org/moi
On Nov 3, 2009, at 12:38 PM, Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 9:35 AM, sstein...@gmail.com > wrote:
On Nov 3, 2009, at 12:23 PM, Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight
wrote:
If that happens, it's not true that there's *nowhere* to go. A
so
Arc Riley wrote:
> +1 on ending with 2.6.
That seems precipitous.
> I'm the maintainer of 3rd party Python 3-only packages and have ported a few
> modules that we needed with some help from the 2to3 tool. It's really not a
> big deal - and Py3 really is a massive improvement.
>
> The main thin
+1 on ending with 2.6.
I'm the maintainer of 3rd party Python 3-only packages and have ported a few
modules that we needed with some help from the 2to3 tool. It's really not a
big deal - and Py3 really is a massive improvement.
The main thing holding back the community are lazy and/or obstinate
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw wrote:
> I'd like to read some case studies of people who have migrated applications
> from 2.6 to 3.0.
For what it's worth, it was pretty easy to migrate argparse:
http://code.google.com/p/argparse/source/detail?r=12
It was mostly just adding a fe
Guido van Rossum python.org> writes:
>
> The PEP tries to spell out some gray areas but I'm sure there will be
> others; that's life. Do note that the PEP proposes to be *retroactive*
> back to the 3.1 release, i.e. the "frozen" version of the language is
> the state in which it was released as 3
Arc Riley gmail.com> writes:
>
> +1 on ending with 2.6.I'm the maintainer of 3rd party Python 3-only packages
> and have ported a few modules that we needed with some help from the 2to3
> tool. It's really not a big deal - and Py3 really is a massive improvement.
> The main thing holding back t
Paul Moore gmail.com> writes:
>
> FWIW, I did a quick survey of some packages (a sampling of packages
> I've used or considered using in the past):
>
> Twisted - no plans yet for Python 3
Well Twisted depends on zope.interface which is not ported yet.
Twisted apparently has plans to reduce or r
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
On python-ideas the moratorium idea got fairly positive responses
(more positive than I'd expected, in fact) but I'm bracing myself for
fierce discussion here on python-dev. It'
On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight wrote:
> If that happens, it's not true that there's *nowhere* to go. A solution
> would be to discard 3.x as a failed experiment, take everything that is
> useful from it and port it to 2.x, and simply continue development from the
> last 2.x release
On Tue, Nov 3, 2009 at 8:47 AM, sstein...@gmail.com wrote:
>
> On Nov 3, 2009, at 4:55 AM, David Cournapeau wrote:
>
>> On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord
>> wrote:
>>
>> There is also little documentation on how to port a significant C
>> codebase to py3k.
>
> Now there's a good Summe
On Nov 3, 2009, at 8:55 AM, sstein...@gmail.com wrote:
And, as you point out, if 3.x doesn't start getting the crap beat
out of it in the real world sooner rather than later, we may find
ourselves, collectively with a stale 2.x, an under battle-tested
3.x, and nowhere to go.
If that happen
s...@pobox.com wrote:
mal> I don't think users will really go for carrots. Python 2.x is
mal> mature enough already and at least the users I know are really
mal> happy with it (including myself).
Taking that thought further back one step (or three), from
http://effbot.org/tkinte
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw wrote:
> I'd like to read some case studies of people who have migrated applications
> from 2.6 to 3.0. Having just gone through a 2 week sprint to migrate
> Launchpad from 2.4 to 2.6, and only making it to 2.5, I can say that I was
> unpleasantly surp
mal> I don't think users will really go for carrots. Python 2.x is
mal> mature enough already and at least the users I know are really
mal> happy with it (including myself).
Taking that thought further back one step (or three), from
http://effbot.org/tkinterbook/listbox.htm
I pu
Martin> And if *2.6* becomes the last of the 2.x series?
With all due respect, I don't think you can make that decision now. The
time to have stated 2.6 would be the end of the 2.x line was when 2.6 was
released. At that point instead of opening up the trunk for changes you
would have close
1 - 100 of 123 matches
Mail list logo
