[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 t
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 wou
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 data.
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 type.
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 things
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, n
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 indeed
-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 bo
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 cas
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 remain
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 thi
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 re
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.) G
Benjamin Peterson gmail.com> writes:
>
> On Thu, Jun 12, 2008 at 10:41 PM, Guido van Rossum 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
> Bazaar branch. [
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
Average
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 SEM
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 whet
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
>> 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 e
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 cost
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> retu
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 o
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>
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 encodeall/decode
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
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 (
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
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
>>>
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, oth
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! Can we have a post-mortem of this? How did they get in there
> in the
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
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.
> Perhap
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
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
>>>
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
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:
h
-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:
http://blo
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 clari
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, organ
Raymond Hettinger wrote:
The question for the group is what to put on the XXX line.
1. Limit it to type(self). This approach claims the least knowledge
about other types and uses their __rand__ methods().
2. Use type(self), int, and long. This approach says that we know that
ints and longs
> "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
>> a
I agree: Python's with statement does have a completely different meaning of
the same Pascal & Co 's statement.
However, I don't agree with the FAQ on this point. I think that a Pascal-like
with statement can be achieved, even with a dynamic language such as Python,
and in a simple way.
We kno
> the block defined by the "on" statement first must starts looking at
> the object's namespace. If no symbol was defined inside a, then it
> follows the traditional LEGB name resolution.
>
> Assignament must work on the object's namespace, of course:
This probably belongs to python-ideas or some
48 matches
Mail list logo
