On Tue, Nov 3, 2009 at 12:19 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
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
On Fri, Oct 23, 2009 at 1:49 AM, Nick Coghlan ncogh...@gmail.com 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
Antoine Pitrou wrote:
Guido van Rossum guido at 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
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 Component
On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord fuzzy...@voidspace.org.uk 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
[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 pyt...@rcn.com:
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
Sturla Molden sturla at 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
David Cournapeau cournape at 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
On Mon, 2 Nov 2009 at 22:06, Guido van Rossum wrote:
On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com 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
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,
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
On Tue, Nov 3, 2009 at 8:40 PM, Antoine Pitrou solip...@pitrou.net wrote:
Sturla Molden sturla at 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
On Tue, Nov 3, 2009 at 9:55 PM, Barry Warsaw ba...@python.org 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
On Nov 3, 2009, at 12:06 AM, Guido van Rossum wrote:
On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com 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
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,
On Nov 3, 2009, at 4:55 AM, David Cournapeau wrote:
On Tue, Nov 3, 2009 at 6:13 PM, Michael Foord fuzzy...@voidspace.org.uk
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
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
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
David Cournapeau cournape at 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 courn...@gmail.com 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
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
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 pull
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw ba...@python.org 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
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
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
On Tue, Nov 3, 2009 at 8:47 AM, sstein...@gmail.com 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 fuzzy...@voidspace.org.uk
wrote:
There is also little documentation on how to port a significant C
codebase to
On Tue, Nov 3, 2009 at 9:04 AM, James Y Knight f...@fuhm.net 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
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's
Paul Moore p.f.moore at 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
Guido van Rossum guido at 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
Arc Riley arcriley at 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
Arc Riley arcri...@gmail.com 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.
On Nov 3, 2009, at 12:38 PM, Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 9:35 AM, sstein...@gmail.com 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 f...@fuhm.net
wrote:
If that happens, it's not true
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
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 that
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 than 2.6, the
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
On Tue, Nov 3, 2009 at 9:37 AM, Martin v. Löwis mar...@v.loewis.dewrote:
(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
Antoine Pitrou wrote:
Guido van Rossum guido at 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
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 haven't
Georg Brandl g.brandl at gmx.net writes:
skip at 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 may
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 f...@fuhm.net 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'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, though
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 the
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
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 3
2009/11/3 Martin v. Löwis mar...@v.loewis.de:
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
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
On Tue, Nov 3, 2009 at 9:35 AM, sstein...@gmail.com 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 f...@fuhm.net wrote:
If that happens, it's not true that there's *nowhere* to go. A solution
would be to discard
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
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,
Martin v. Löwis mar...@v.loewis.de 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
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
On Nov 3, 2009, at 12:35 PM, Antoine Pitrou wrote:
Arc Riley arcriley at 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
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 expert
* 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
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
Well, that's certainly a
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
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
they'd be done
On Tue, Nov 3, 2009 at 10:42 AM, Georg Brandl g.bra...@gmx.net 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
Antoine Pitrou schrieb:
Georg Brandl g.brandl at gmx.net writes:
skip at 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
On Tue, Nov 3, 2009 at 4:46 PM, Steven D'Aprano st...@pearwood.info 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.
On Wed, Nov 4, 2009 at 3:25 AM, Martin v. Löwis mar...@v.loewis.de 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
Guido van Rossum writes:
On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg m...@egenix.com 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
On Tue, Nov 3, 2009 at 12:35 PM, Guido van Rossum gu...@python.org 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,
On Tue, Nov 3, 2009 at 11:23 AM, M.-A. Lemburg m...@egenix.com 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
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
Antoine Pitrou solip...@pitrou.net writes:
Paul Moore p.f.moore at 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
On Tue, Nov 3, 2009 at 2:46 PM, Steven D'Aprano st...@pearwood.info 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
Brett Cannon brett at 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)
Guido van Rossum guido at 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
On Tue, Nov 3, 2009 at 09:35, Guido van Rossum gu...@python.org 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
On Tue, Nov 3, 2009 at 10:20 AM, Martin v. Löwis mar...@v.loewis.de 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.
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:
Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 9:37 AM, Martin v. Löwis mar...@v.loewis.de 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.
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
fierce
On Tue, Nov 3, 2009 at 5:10 PM, Antoine Pitrou solip...@pitrou.net wrote:
Greg Ewing greg.ewing at 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
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.
Since 2.7 will be closer
On Tue, Nov 3, 2009 at 4:55 AM, Barry Warsaw ba...@python.org 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
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. And
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 standard
Greg Ewing greg.ewing at 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
On Tue, Nov 3, 2009 at 2:35 PM, Guido van Rossum gu...@python.org 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:
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 want
On Tue, Nov 3, 2009 at 1:00 PM, Georg Brandl g.bra...@gmx.net 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
On Tue, Nov 3, 2009 at 3:27 PM, Larry Bugbee bug...@seanet.com 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
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, barriers to
On Tue, Nov 3, 2009 at 12:20 AM, Yuvgoog Greenle ubershme...@gmail.com wrote:
On Tue, Nov 3, 2009 at 12:19 AM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the
On Nov 3, 2009, at 7:42 PM, Ben Finney wrote:
Antoine Pitrou solip...@pitrou.net writes:
Paul Moore p.f.moore at 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
On Tue, Nov 3, 2009 at 05:40, David Cournapeau courn...@gmail.com wrote:
On Tue, Nov 3, 2009 at 9:55 PM, Barry Warsaw ba...@python.org 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,
On Tue, Nov 3, 2009 at 9:37 AM, Martin v. Löwis mar...@v.loewis.de 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
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
1 - 100 of 123 matches
Mail list logo
