[EMAIL PROTECTED] wrote:
I'm not fond of using a property for this since it can lull you into the
false belief that what you are doing is less expensive than it really is
(attribute access vs method call). I think this is a case where explicit is
better than implicit.
Have you looked at what
Georg Brandl wrote:
Nick Coghlan schrieb:
2. Method lookup MAY bypass __getattribute__, shadowing the attribute
in the instance dictionary MAY have ill effects. (slots such as
__enter__ and __exit__ that are looked up via normal attribute lookup
in CPython will fit into this category)
I
Guido van Rossum wrote:
On Thu, Jun 12, 2008 at 8:49 PM, Neal Norwitz [EMAIL PROTECTED]
wrote:
Ben mentions this in the post, but it's a good reminder: comments
on python-checkins are *not* personal. The goal is to make the
code better and/or gain better understanding. We all make
mistakes,
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape') or
Guido van Rossum wrote:
[Barry]
http://bugs.python.org/issue643841
[Guido]
I've added a comment. Let me know if anything I said is unclear.
On Thu, Jun 12, 2008 at 3:35 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
The bugtracker seems to be offline atm - I'll reply
On 2008-06-13 11:32, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same
Guido van Rossum wrote:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether alpha, beta
or final) we should practice extra restraint, not rush to get
Steve Holden wrote:
Guido van Rossum wrote:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether alpha, beta
or final) we should practice extra restraint,
M.-A. Lemburg wrote:
On 2008-06-13 11:32, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It's unfortunate that I was not able to release the first betas on
Wednesday. The primary reason was that none of the 3.0 buildbots were
green.
My proposal is this: I will spin another release this coming
Wednesday, June 18. If we can get
2008/6/13 Barry Warsaw [EMAIL PROTECTED]:
My proposal is this: I will spin another release this coming Wednesday, June
18. If we can get both the 2.6 and 3.0 buildbots green by then, and close
out all remaining release critical bugs, then Wednesday's release will be
beta 1. In that case, I
On Fri, Jun 13, 2008 at 6:54 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/6/13 Barry Warsaw [EMAIL PROTECTED]:
My proposal is this: I will spin another release this coming Wednesday, June
18. If we can get both the 2.6 and 3.0 buildbots green by then, and close
out all remaining release
On Fri, Jun 13, 2008 at 7:27 AM, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum schrieb:
On Fri, Jun 13, 2008 at 6:54 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/6/13 Barry Warsaw [EMAIL PROTECTED]:
My proposal is this: I will spin another release this coming Wednesday,
June
On Fri, Jun 13, 2008 at 9:20 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm fine with whatever delay Barry approves, but I want EVERYONE to
stick to the purpose of the delay: get the buildbots green and close
out release critical bugs. This means no new last-minute features or
big
On Thu, Jun 12, 2008 at 10:41 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
Let's all remember this and make sure not to drop code bombs on each
other. :-)
Ok! I'd like everybody to know that I'm working on Python tests on a
Bazaar branch. [1] (That's only a bzr co --lightweight away.) Go
Benjamin Peterson musiccomposition at gmail.com writes:
On Thu, Jun 12, 2008 at 10:41 PM, Guido van Rossum guido at python.org
wrote:
Let's all remember this and make sure not to drop code bombs on each
other.
Ok! I'd like everybody to know that I'm working on Python tests on a
ACTIVITY SUMMARY (06/06/08 - 06/13/08)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
1899 open (+36) / 13028 closed (+15) / 14927 total (+51)
Open issues with patches: 574
In trying to solve a build problem with the multiprocessing code on
Solaris10 I visited multiprocessing.c in XEmacs and noticed the files all
appear to have Windows line endings. Should those maybe be stripped to
conform to the other Python source?
FWIW, it appears that Solaris doesn't define
Nick Have you looked at what the methods we're proposing to turn into
Nick properties are actually doing?:
Nick def getName(self):
Nick assert self.__initialized, Thread.__init__() not called
Nick return self.__name
...
Nick Checking whether or
Nick def getName(self):
Nick assert self.__initialized, Thread.__init__() not called
Nick return self.__name
Why is __name private to begin with? Any reason for the getters and setters?
Why isn't this just an attribute?
Raymond
On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Nick def getName(self):
Nick assert self.__initialized, Thread.__init__() not called
Nick return self.__name
Why is __name private to begin with? Any reason for the getters and
setters?
Let's all remember this and make sure not to drop code bombs on
each other. :-)
Benjamin Ok! I'd like everybody to know that I'm working on Python
Benjamin tests on a Bazaar branch. [1] (That's only a bzr co
Benjamin --lightweight away.) Go ahead and send me angry emails
On Thu, Jun 12, 2008 at 8:40 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
Ideally, I would like for those considerations [i.e. whether an access is
expensive]
to not enter into the API
design. I'd rather keep it clean, with sufficient documentation to give
hints about any additional costs
On Fri, Jun 13, 2008 at 9:42 AM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
Nick def getName(self):
Nick assert self.__initialized, Thread.__init__() not called
Nick return self.__name
On Fri, Jun 13, 2008 at 9:21 AM, [EMAIL PROTECTED] wrote:
In trying to solve a build problem with the multiprocessing code on
Solaris10 I visited multiprocessing.c in XEmacs and noticed the files all
appear to have Windows line endings. Should those maybe be stripped to
conform to the other
On Fri, Jun 13, 2008 at 12:14 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 9:42 AM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 11:40 AM, Raymond Hettinger [EMAIL PROTECTED]
wrote:
Nick def getName(self):
Nick assert
Walter Dörwald wrote:
[...]
Sure, we could do that, but please use a different name,
e.g. .encodeall() and .decodeall() - .encode() and .decode()
are already stateles (and so would the new methods be), so
stateless isn't all that meaningful in this context.
I like the names
On Fri, Jun 13, 2008 at 6:07 AM, Nick Coghlan [EMAIL PROTECTED] wrote:
Steve Holden wrote:
Guido van Rossum wrote:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a
On Thu, Jun 12, 2008 at 11:32 PM, Georg Brandl [EMAIL PROTECTED] wrote:
Guido van Rossum schrieb:
It's water under the bridge now, but IMO it was too rash to *remove*
the old threading API from Py3k, and doubly rash to do so one day
before the beta release. Running up to a release (whether
I don't know where the windows line endings came from honestly - I'm
on mac and linux boxes.
Yes, they should be stripped.
The solaris issue should be addressed in the setup.py section casing
the various sem implementations for the platforms
On Fri, Jun 13, 2008 at 12:21 PM, [EMAIL PROTECTED]
On Fri, Jun 13, 2008 at 12:17 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 9:21 AM, [EMAIL PROTECTED] wrote:
In trying to solve a build problem with the multiprocessing code on
Solaris10 I visited multiprocessing.c in XEmacs and noticed the files all
appear to have
On Fri, Jun 13, 2008 at 12:32 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 12:17 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 9:21 AM, [EMAIL PROTECTED] wrote:
In trying to solve a build problem with the multiprocessing code on
Solaris10 I
PEP-3141 outlines an approach to writing binary operators to allow the
right operand to override the operation if the left operand inherits
the operation from the ABC.
Here is my first approximation at how to write them for the Integral mixins:
class Integral(Rational):
def __and__(self,
On Fri, Jun 13, 2008 at 1:09 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 3:02 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 12:32 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
I've converted the line endings in the trunk and py3k.
Thanks!
On Fri, Jun 13, 2008 at 3:21 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm guessing Jesse uploaded the patch from a Windows box.
Actually he just told me that he uploaded it from a Mac, so it's my fault. :)
It would be good to have something in the toolchain to change this.
Perhaps a
On Fri, Jun 13, 2008 at 1:23 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 3:21 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
I'm guessing Jesse uploaded the patch from a Windows box.
Actually he just told me that he uploaded it from a Mac, so it's my fault. :)
On Fri, Jun 13, 2008 at 3:24 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 1:23 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
Actually he just told me that he uploaded it from a Mac, so it's my fault. :)
You're on Windows?!
Me!? I cringe at the accusation. No, I
On Fri, Jun 13, 2008 at 4:21 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 1:09 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 3:02 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 12:32 PM, Benjamin Peterson
[EMAIL
On Fri, Jun 13, 2008 at 1:26 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 3:24 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 1:23 PM, Benjamin Peterson
[EMAIL PROTECTED] wrote:
Actually he just told me that he uploaded it from a Mac, so it's
On Fri, Jun 13, 2008 at 4:28 PM, Benji York [EMAIL PROTECTED] wrote:
Subversion can be configured to normalize line endings, either manually
through properties, or automatically via ~/.subversion/config:
After sending this I though surely this is in the developer docs, and
indeed it is:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 12, 2008, at 11:41 PM, Guido van Rossum wrote:
My colleague and SVN developer Ben Sussman-Collins occasionally blogs
about the social side of (mostly open source) software development. He
just posted a new one that struck a chord:
The Python FAQ has the following entry:
4.26 Why doesn't Python have a with statement like some other languages?
From:
http://www.python.org/doc/faq/general/
Even if the content is still relevant (I know nothing of the use of
'with' outside Python), the entry probably needs at least
On Fri, 13 Jun 2008 18:22:42 -0400, Barry Warsaw [EMAIL PROTECTED] wrote:
[snip]
* small branches - we have a strict limit on diffs no greater than 800
lines. Yes we have exceptions, but they are rare and pre-arranged. Having
such a strict limit really forces you to be disciplined,
Guido == Guido van Rossum [EMAIL PROTECTED] writes:
Guido On Fri, Jun 13, 2008 at 9:21 AM, [EMAIL PROTECTED] wrote:
In trying to solve a build problem with the multiprocessing code on
Solaris10 I visited multiprocessing.c in XEmacs and noticed the files all
appear to have
44 matches
Mail list logo
