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 there anyone here who _likes_ it?
>>
>
>
State might cause people to
On Fri, Oct 23, 2009 at 1:49 AM, Nick Coghlan wrote:
> Brett Cannon wrote:
>> Another summit, another potential time to see if people want to change
>> anything about the issue tracker. I would bring up:
>>
>> - Dropping Stage in favor of some keywords (e.g. 'needs unit test',
>> 'needs docs')
>>
Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>>
>> Is it even wort doing a 2.7 release? Isn't the effort better spent on
>> 3.2 alone? (Note, these aren't rhetorical questions. It's well
>> possible that there are good reasons for pushing along with 2.7. Maybe
>> considering those
Sturla Molden wrote:
I'd just like to mention that the scientific community is highly
dependent on NumPy. As long as NumPy is not ported to Py3k, migration
is out of the question. Porting NumPy is not a trivial issue. It might
take a complete rewrite of the whole C base using Cython. NumPy's AB
Martin v. Löwis wrote:
>> +lots on adding a module field (independent of automatically adding
>> maintainers to the nosy list, it would assist in "I just did a major
>> cleanup of module X, are there any old bugs I can kill off").
>
> Link (1:1) or Multilink (1:n)? What is the impact on the Compon
On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord wrote:
> Sturla Molden wrote:
>>
>> I'd just like to mention that the scientific community is highly dependent
>> on NumPy. As long as NumPy is not ported to Py3k, migration is out of the
>> question. Porting NumPy is not a trivial issue. It might take
[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 the several premises that have arisen
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 decision making
> by putting "carrots" in one pile and
Sturla Molden molden.no> writes:
>
> Porting NumPy is not a trivial issue. It might take
> a complete rewrite of the whole C base using Cython.
I don't see why they would need a rewrite. Little of the C API has changed
between 2.x and 3.x. Cython itself is supposed to support both 2.x and 3.x,
David Cournapeau gmail.com> writes:
>
> 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.
> - how to maintain a compatible C API across 2.x and 3.x
> - is it prac
On Mon, 2 Nov 2009 at 22:06, Guido van Rossum wrote:
On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com wrote:
BeautifulSoup, which I use every day, is one such product. ?Since the crappy
old SMGL parser's gone, BeautifulSoup uses the one that's left in Python 3
and it makes BeautifulSoup comp
On Nov 3, 2009, at 1:07 AM, Martin v. Löwis wrote:
Barry Warsaw wrote:
On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
A better language, i.e. Python 3.x, will become better faster
without
dragging the 2.x series out any longer.
If Python 2.7 becomes the last of the 2.x series, th
On Nov 2, 2009, at 11:51 PM, sstein...@gmail.com wrote:
I agree as long as:
A> 2.7 comes out as soon as possible, even if it's missing helpful
porting features.
B> 2.7 will get ONLY new features that make it easier to port to
3.x, not every feature added to 3.x or all you've done is make
Raymond Hettinger wrote:
> 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
> decision making by putting "carrots" in one pile and aban
On Tue, Nov 3, 2009 at 8:40 PM, Antoine Pitrou wrote:
> Sturla Molden molden.no> writes:
>>
>> Porting NumPy is not a trivial issue. It might take
>> a complete rewrite of the whole C base using Cython.
>
> I don't see why they would need a rewrite.
(let me know if those numpy-specific discussio
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 have a lot of C code: the current
documentation is sparse :) The
On Nov 3, 2009, at 12:06 AM, Guido van Rossum wrote:
On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com > wrote:
BeautifulSoup, which I use every day, is one such product. Since
the crappy
old SMGL parser's gone, BeautifulSoup uses the one that's left in
Python 3
and it makes BeautifulSou
On Nov 3, 2009, at 1:07 AM, Martin v. Löwis wrote:
Barry Warsaw wrote:
On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
A better language, i.e. Python 3.x, will become better faster
without
dragging the 2.x series out any longer.
If Python 2.7 becomes the last of the 2.x series, t
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 Summer of Code project: to produce a pre-processor
that will flag all C constru
On Nov 3, 2009, at 4:58 AM, Raymond Hettinger wrote:
P.S. I found it curious that one of the strongest proponents of
killing 2.x also mentioned that he has never written a line of 3.x
code. Since this discussion is a matter of great consequence, I
would hope that advocates will only ta
On Nov 3, 2009, at 2:20 AM, Sturla Molden wrote:
I'd just like to mention that the scientific community is highly
dependent on NumPy. As long as NumPy is not ported to Py3k,
migration is out of the question. Porting NumPy is not a trivial
issue. It might take a complete rewrite of the whol
David Cournapeau gmail.com> writes:
>
> We can port to PEP 3118 without
> porting to 3.x, and we can port to 3.x without taking care of PEP
> 3118.
I'm not sure you can do the latter. The old buffer API (the one PEP 3118
replaces) doesn't exist in py3k.
Antoine.
_
On Tue, Nov 3, 2009 at 3:55 AM, David Cournapeau wrote:
> - are two branches are necessary or not ? If two branches are
> necessary, I think we simply do not have the resources at the moment.
> - how to maintain a compatible C API across 2.x and 3.x
> - is it practically possible to support an
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
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
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
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 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
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 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
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'
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
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
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
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
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
> 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
>> 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
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
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
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
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.
>> 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
>> 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
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
> 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
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
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
> 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
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
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
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
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
> 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
"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 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 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
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'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
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 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 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
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 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
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
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
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
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
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 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
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/
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
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 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
"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 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
> 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
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
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
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 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
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
> 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 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
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
>> 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
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
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
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
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
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
1 - 100 of 123 matches
Mail list logo
