Michael Foord wrote:
Note that the behaviour here is still different from that of a data
descriptor: with a data descriptor, once it gets shadowed in the
instance dictionary, the descriptor is ignored *completely*. The only
way to get the descriptor involved again is to eliminate the
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 because
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.
Le Mon, 11 Jan 2010 19:57:46 -0600, Brian Curtin a écrit :
For example, there are currently over
1500 open issues with no stage set, some of which seemingly haven't been
read by anyone at all.
I think most issues /have/ been read. It's just that for many of them,
nobody is interested enough
Le Tue, 12 Jan 2010 10:20:27 +, Antoine Pitrou a écrit :
I don't think this has anything to do with properly setting the stage
field. We just have limited time and manpower. Perhaps one of our goals
should be to reach out more to potential contributors.
Speaking of which, Steve had
Antoine Pitrou wrote:
Le Mon, 11 Jan 2010 19:57:46 -0600, Brian Curtin a écrit :
For example, there are currently over
1500 open issues with no stage set, some of which seemingly haven't been
read by anyone at all.
I think most issues /have/ been read. It's just that for many of them,
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 because
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 the
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! :)
Brett Cannon wrote:
Michael has given me the hg transition/stdlib time slot at the language
summit this year. In regards to that I plan to lead a discussion on:
* where we are at w/ the Hg transition (Dirkjan should be there and I did a
blog post on this topic recently:
On Tue, 12 Jan 2010 22:10:14 +1000, Nick Coghlan ncogh...@gmail.com wrote:
There are actually a whole host of reasons issues can stagnate:
- a feature request may seem reasonable (hence it doesn't get rejected
outright), but the right API may not be clear (hence it doesn't get
implemented in
On Tue, Jan 12, 2010 at 05:09, M.-A. Lemburg m...@egenix.com wrote:
Brett Cannon wrote:
Michael has given me the hg transition/stdlib time slot at the language
summit this year. In regards to that I plan to lead a discussion on:
* where we are at w/ the Hg transition (Dirkjan should be
On Mon, Jan 11, 2010 at 17:57, Brian Curtin brian.cur...@gmail.com wrote:
On Sun, Jan 10, 2010 at 14:25, Brett Cannon br...@python.org wrote:
* any changes needed to the issue tracker to help with the workflow?
(stage field seems like a failed experiment and we now have several
effective
On Tue, Jan 12, 2010 at 04:29, Michael Foord fuzzy...@voidspace.org.ukwrote:
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):
On Tue, 12 Jan 2010 09:47:50 -0800, Brett Cannon wrote:
On Mon, Jan 11, 2010 at 17:57, Brian Curtin brian.cur...@gmail.com wrote:
On Sun, Jan 10, 2010 at 14:25, Brett Cannon br...@python.org wrote:
* any changes needed to the issue tracker to help with the workflow?
(stage field seems like
On Tue, Jan 12, 2010 at 10:31, R. David Murray rdmur...@bitdance.comwrote:
On Tue, 12 Jan 2010 09:47:50 -0800, Brett Cannon wrote:
On Mon, Jan 11, 2010 at 17:57, Brian Curtin brian.cur...@gmail.com
wrote:
On Sun, Jan 10, 2010 at 14:25, Brett Cannon br...@python.org wrote:
* any changes
Brett Cannon wrote:
I expect there will be at least summary emails on what gets discussed.
There is also a chance that it will be videotaped.
The Wiki makes for a better summary archive though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
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 implication,
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 itself),
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
On Tue, Jan 12, 2010 at 22:56, Martin v. Löwis mar...@v.loewis.de 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
[...]
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
to move
I think it would be interesting to see how people are using the tracker,
or how they want to be using it. For example, there are currently over
1500 open issues with no stage set, some of which seemingly haven't been
read by anyone at all. Would a properly set stage field save issues from
Hi all,
I'm back on the regex module after doing other things and I'd like your
opinion on a number of matters:
Firstly, the current re module has a bug whereby it doesn't split on
zero-width matches. The BDFL has said that this behaviour should be
retained by default in case any existing
I presume the email below is about the Windows binary. Does the AMD64
release work on intel 64bit and can we make the wording clearer on the
download page?
The current description is Windows AMD64 binary.
All the best,
Michael
Original Message
Subject:Download
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 think
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
On 1/12/2010 5:10 PM, MRAB wrote:
Hi all,
I'm back on the regex module after doing other things and I'd like your
opinion on a number of matters:
Firstly, the current re module has a bug whereby it doesn't split on
zero-width matches. The BDFL has said that this behaviour should be
retained by
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 ones.
Well
I presume the email below is about the Windows binary. Does the AMD64
release work on intel 64bit and can we make the wording clearer on the
download page?
intel 64bit is as clear as mud. It could mean the Intel 64
architecture, or it could mean the IA-64 architecture, both
are 64-bit
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
On 12/01/2010 23:28, Martin v. Löwis wrote:
[snip...]
The binaries for AMD64 will also work on processors that implement
the Intel 64 architecture (formerly EM64T), i.e. the architecture that
Microsoft calls x64, and AMD called x86-64 before calling it AMD64.
They will not work on Intel Itanium
Michael Foord wrote:
I presume the email below is about the Windows binary. Does the AMD64
release work on intel 64bit and can we make the wording clearer on the
download page?
The current description is Windows AMD64 binary.
The installer works on all AMD64 compatible Intel CPUs. *scnr*
On 12/01/2010 23:40, Michael Foord wrote:
On 12/01/2010 23:28, Martin v. Löwis wrote:
[snip...]
The binaries for AMD64 will also work on processors that implement
the Intel 64 architecture (formerly EM64T), i.e. the architecture that
Microsoft calls x64, and AMD called x86-64 before calling it
Terry Reedy wrote:
On 1/12/2010 5:10 PM, MRAB wrote:
Hi all,
I'm back on the regex module after doing other things and I'd like your
opinion on a number of matters:
Firstly, the current re module has a bug whereby it doesn't split on
zero-width matches. The BDFL has said that this behaviour
On 12/01/2010 23:41, Christian Heimes wrote:
Michael Foord wrote:
I presume the email below is about the Windows binary. Does the AMD64
release work on intel 64bit and can we make the wording clearer on the
download page?
The current description is Windows AMD64 binary.
The
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.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Karen Tracey wrote:
On Sat, Jan 9, 2010 at 12:29 PM, Benjamin Peterson benja...@python.orgwrote:
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
MRAB wrote:
Hi all,
I'm back on the regex module after doing other things and I'd like your
opinion on a number of matters:
Firstly, the current re module has a bug whereby it doesn't split on
zero-width matches. The BDFL has said that this behaviour should be
retained by default in case any
On Tue, Jan 12, 2010 at 14:10, MRAB pyt...@mrabarnett.plus.com wrote:
Hi all,
I'm back on the regex module after doing other things and I'd like your
opinion on a number of matters:
Firstly, the current re module has a bug whereby it doesn't split on
zero-width matches. The BDFL has said
How about:
* Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 /
X86-64 binary -- does not include source)
instead of:
* Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does
not include source)
-1. AMD doesn't want us to use the term x86-64 anymore, but
On 1/12/2010 2:46 PM, Michael Foord wrote:
I presume the email below is about the Windows binary. Does the AMD64
release work on intel 64bit and can we make the wording clearer on the
download page?
The current description is Windows AMD64 binary.
FWIW, we simply use (64-bit, x64).
Christian Heimes lists at cheimes.de writes:
How about:
* Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 /
X86-64 binary -- does not include source)
+1. I don't care about trademarks or official names, we should call it whatever
is obvious for our users.
As for Itanium,
43 matches
Mail list logo
