Re: [Python-Dev] PEP 8 and optional underscores
[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 the methods we're proposing to turn into
properties are actually doing?:
def getName(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__name
def setName(self, name):
assert self.__initialized, "Thread.__init__() not called"
self.__name = str(name)
def getIdent(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__ident
def isAlive(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__started.isSet() and not self.__stopped
def isDaemon(self):
assert self.__initialized, "Thread.__init__() not called"
return self.__daemonic
def setDaemon(self, daemonic):
if not self.__initialized:
raise RuntimeError("Thread.__init__() not called")
if self.__started.isSet():
raise RuntimeError("cannot set daemon status of active
thread");
self.__daemonic = daemonic
Checking whether or not an Event is set is hardly an expensive operation
and well within the limits of what I think it is reasonable for a
property access to do implicitly (e.g. it would also be reasonable for a
thread safe object to acquire and release a synchronisation lock while
retrieving or changing an attribute).
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
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 would argue that the __enter__ and __exit__ behavior should be changed too. The reason for the current behavior is this: 2 0 LOAD_GLOBAL 0 (a) 3 DUP_TOP 4 LOAD_ATTR1 (__exit__) 7 STORE_FAST 0 (_[1]) 10 LOAD_ATTR2 (__enter__) 13 CALL_FUNCTION0 16 STORE_FAST 1 (_[2]) 19 SETUP_FINALLY 18 (to 40) IOW, when "with" is compiled, the attributes are retrieved using bytecode. It wouldn't be hard to have a WITH_SETUP opcode (along with the already existing WITH_CLEANUP) that would make the bytecode read like: 2 0 LOAD_GLOBAL 0 (a) 3 WITH_SETUP 0 (_[1]) 6 STORE_FAST 1 (_[2]) 9 SETUP_FINALLY 18 (to 40) No argument here - the PEP 343 implementation is the way it is mainly because it involved the least messing around with the performance-sensitive ceval loop. That said, the with statement implementation is already a bit different in 2.6/3.0 (it moves things around on the stack so it can avoid the STORE_FAST/LOAD_FAST/DELETE_FAST operations): def f(): with a: pass Python 2.5 disassembly: 2 0 LOAD_GLOBAL 0 (a) 3 DUP_TOP 4 LOAD_ATTR1 (__exit__) 7 STORE_FAST 0 (_[1]) 10 LOAD_ATTR2 (__enter__) 13 CALL_FUNCTION0 16 POP_TOP 17 SETUP_FINALLY4 (to 24) 20 POP_BLOCK 21 LOAD_CONST 0 (None) >> 24 LOAD_FAST0 (_[1]) 27 DELETE_FAST 0 (_[1]) 30 WITH_CLEANUP 31 END_FINALLY Python 2.6 disassembly: 2 0 LOAD_GLOBAL 0 (a) 3 DUP_TOP 4 LOAD_ATTR1 (__exit__) 7 ROT_TWO 8 LOAD_ATTR2 (__enter__) 11 CALL_FUNCTION0 14 POP_TOP 15 SETUP_FINALLY4 (to 22) 18 POP_BLOCK 19 LOAD_CONST 0 (None) >> 22 WITH_CLEANUP 23 END_FINALLY Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
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, better to correct them early before they become big problems.. And this reminder applies to reviewer *and* reviewees! (I know I've made this mistake in both roles. :-) I still love the last entry from Raymond's school of hard knocks [1]: """do everything right (formatting, procedure, profiling, testing, etc) and watch the Timbot come along five minutes later and improve your code making it faster, clearer, more conformant, more elegant, and also gel neatly with the vaguaries of memory allocation, cache performance, and compilers you've never heard of.""" Cheers, Nick. [1] http://mail.python.org/pipermail/python-dev/2002-September/028725.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
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.transform('base64').
So what would a base64 codec do with the errors argument?
It could use it to e.g. try to recover as much data as possible
from broken input data.
Currently (in Py2.x), it raises an exception if you pass in anything
but "strict".
I think for transformations we don't need the full codec machinery:
> ...
No need to invent another wheel :-) The codecs already exist for
Py2.x and can be used by the .encode()/.decode() methods in Py2.x
(where no type checks occur).
By using a new API we could get rid of old warts. For example: Why
does the stateless encoder/decoder return how many input
characters/bytes it has consumed? It must consume *all* bytes anyway!
No, it doesn't and that's the point in having those return values :-)
Even though the encoder/decoders are stateless, that doesn't mean
they have to consume all input data. The caller is responsible to
make sure that all input data was in fact consumed.
You could for example have a decoder that stops decoding after
having seen a block end indicator, e.g. a base64 line end or
XML closing element.
So how should the UTF-8 decoder know that it has to stop at a closing
XML element?
Just because all codecs that ship with Python always try to decode
the complete input doesn't mean that the feature isn't being used.
I know of no other code that does. Do you have an example for this use.
The interface was designed to allow for the above situations.
Then could we at least have a new codec method that does:
def statelesencode(self, input):
(output, consumed) = self.encode(input)
assert len(input) == consumed
return output
Servus,
Walter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
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 there once I can get to it again (as well as switching this issue back to being a documentation one). I don't think we're going to see a major clamor for a value-based delegation mixin in the standard library until people using classic classes for value-based delegation start making serious attempts to port to Py3k (where that approach is no longer available). At the moment, such classes only need to care about the methods they want to fiddle with, leaving everything else to __getattr__ based delegation. Whether they'll care about this issue of course depends on whether they need overloaded operators and other special delegations to be delegated transparently. We'll have to see how important this is. New-style classes have been around and recommended for a long time -- why haven't people pushed for a proxy class before? It's only in Python 3 that old style classes are going away fully, so up until now you could at least use a classic class to do the proxying. I've written my own proxy classes before that look very similar to this, and there are other proxy classes around that do the same (I thought one was by Phillip J Eby but can't find a reference easily). The last one I wrote was to proxy CPython objects from IronPython via Python.NET... I would prefer it if the proxy class wrapped the return values of inplace operations. Michael Foord I've pushed as hard as I'm personally willing to for this without convincing anyone else that it's worth doing, What does *it* refer to? Changing the behavior, or adding a proxy class to the stdlib? I'm -1000 on the former, but only -0 on the latter -- as I wrote in the tracker, I just don't want to see an unproven proxy class (and I don't like the module name). so I'll start working on a documentation patch for the language reference instead which explicitly splits the special methods into the following categories: Thanks for doing this, it is needed regardless! 1. Method lookup MUST bypass __getattribute__, shadowing the attribute in the instance dictionary MUST NOT have any ill effects. (All tp_* C-level slots and slots looked up via _PyType_Lookup will fit into this category) Watch out: I think the term "method lookup" may be confusing here. Certainly when the user writes x.__foo__(), the instance dict *is* consulted. It is only on *implied* lookups (e.g. x[y] or x+y) where the instance dict is bypassed. 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) Why even have a MAY category? Are you expecting these to become tp_ slots at some point? 3. Technically a subcategory of group 1, these are special methods which can affect the interpreter's behaviour by their mere definition on a type. (The __get__, __set__ and __delete__ descriptor protocol methods fall into this category) I don't follow why this is relevant. This is a different, AFAIK orthogonal issue, used in many places: *if* an object used in a certain context has a specific attribute, *then* that attribute is used, *otherwise* a default action is taken. Applies to __repr__ just as much. These belong in category 1 if and only if the lookup bypasses the instance dict. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
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.
E.g. text.transform('xml-escape') or data.transform('base64').
So what would a base64 codec do with the errors argument?
It could use it to e.g. try to recover as much data as possible
from broken input data.
Currently (in Py2.x), it raises an exception if you pass in anything
but "strict".
I think for transformations we don't need the full codec machinery:
> ...
No need to invent another wheel :-) The codecs already exist for
Py2.x and can be used by the .encode()/.decode() methods in Py2.x
(where no type checks occur).
By using a new API we could get rid of old warts. For example: Why
does the stateless encoder/decoder return how many input
characters/bytes it has consumed? It must consume *all* bytes anyway!
No, it doesn't and that's the point in having those return values :-)
Even though the encoder/decoders are stateless, that doesn't mean
they have to consume all input data. The caller is responsible to
make sure that all input data was in fact consumed.
You could for example have a decoder that stops decoding after
having seen a block end indicator, e.g. a base64 line end or
XML closing element.
So how should the UTF-8 decoder know that it has to stop at a closing
XML element?
The UTF-8 decoder doesn't support this, but you could write a codec
that applies this kind of detection, e.g. to not try to decode
partial UTF-8 byte sequences at the end of input, which would then
result in error.
Just because all codecs that ship with Python always try to decode
the complete input doesn't mean that the feature isn't being used.
I know of no other code that does. Do you have an example for this use.
I already gave you a few examples.
The interface was designed to allow for the above situations.
Then could we at least have a new codec method that does:
def statelesencode(self, input):
(output, consumed) = self.encode(input)
assert len(input) == consumed
return output
You mean as method to the Codec class ?
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.
We could also add such a check to the PyCodec_Encode() and _Decode()
functions. They currently do not apply the above check.
In Python, those two functions are exposed as codecs.encode()
and codecs.decode().
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jun 13 2008)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania23 days to go
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000-checkins] r64217 - in python/branches/py3k/Lib: bsddb/test/test_associate.py bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py idlelib/rpc.py idle
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 in right before the deadline. Let's all be more careful the rest of this release cycle! (I think it wasn't just Benjamin who raced to get things in...) Well, it wouldn't be "adding a new feature" to reinstate the old API for beta two, would it, as long as we retain the new one too? It does seem that change was a little precipitate. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] [Python-3000-checkins] r64217 - in python/branches/py3k/Lib: bsddb/test/test_associate.py bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py idlel
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, not rush to get things in right before the deadline. Let's all be more careful the rest of this release cycle! (I think it wasn't just Benjamin who raced to get things in...) Well, it wouldn't be "adding a new feature" to reinstate the old API for beta two, would it, as long as we retain the new one too? It does seem that change was a little precipitate. Although if we weren't actually planning on removing the old API in 3.0, I'm a little confused as to why we were adding Py3k warnings to it in 2.6... Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
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 return the same type.
E.g. text.transform('xml-escape') or data.transform('base64').
So what would a base64 codec do with the errors argument?
It could use it to e.g. try to recover as much data as possible
from broken input data.
Currently (in Py2.x), it raises an exception if you pass in anything
but "strict".
I think for transformations we don't need the full codec machinery:
> ...
No need to invent another wheel :-) The codecs already exist for
Py2.x and can be used by the .encode()/.decode() methods in Py2.x
(where no type checks occur).
By using a new API we could get rid of old warts. For example: Why
does the stateless encoder/decoder return how many input
characters/bytes it has consumed? It must consume *all* bytes anyway!
No, it doesn't and that's the point in having those return values :-)
Even though the encoder/decoders are stateless, that doesn't mean
they have to consume all input data. The caller is responsible to
make sure that all input data was in fact consumed.
You could for example have a decoder that stops decoding after
having seen a block end indicator, e.g. a base64 line end or
XML closing element.
So how should the UTF-8 decoder know that it has to stop at a closing
XML element?
The UTF-8 decoder doesn't support this, but you could write a codec
that applies this kind of detection, e.g. to not try to decode
partial UTF-8 byte sequences at the end of input, which would then
result in error.
Just because all codecs that ship with Python always try to decode
the complete input doesn't mean that the feature isn't being used.
I know of no other code that does. Do you have an example for this use.
I already gave you a few examples.
Maybe I was unclear, I meant real world examples, not hypothetical ones.
The interface was designed to allow for the above situations.
Then could we at least have a new codec method that does:
def statelesencode(self, input):
(output, consumed) = self.encode(input)
assert len(input) == consumed
return output
You mean as method to the Codec class ?
No, I meant as a method for the CodecInfo clas.
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/decodeall!
We could also add such a check to the PyCodec_Encode() and _Decode()
functions. They currently do not apply the above check.
In Python, those two functions are exposed as codecs.encode()
and codecs.decode().
This change will probably have to wait for the 2.7 cycle.
Servus,
Walter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] First betas (perhaps) on June 18
-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 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 will update PEP 361 and push the entire schedule back by 2 weeks to account for our slippage. If we can't get these releases stable by then, Wednesday's release will be alpha and I will make the July 2 release the first beta, updating and pushing back the PEP 361 schedule accordingly. Thanks for all your help in getting 3.0 stable! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFJ6fXEjvBPtnXfVAQJekgP/XzGR0h6Kcgwe/eo/hlAP2RJiEBny7iIT avSkq5sDD4YiUHeSSVy/8A5rahjR3Bsrzgh0MSePrf8coUHz3N+OCGsJK07BVJIT 9wan/OXTkpsrqa2xQgrokk0PqCE80S2Lp6+P5jMW06tujx3fFn+NJNDjaNUOKPUc nlfjFpdwYxc= =Nwmx -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] First betas (perhaps) on June 18
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 will update PEP 361 and push the entire schedule > back by 2 weeks to account for our slippage. Next weekend, 21 and 22, it will be the Python Bug days. Maybe it's worth to delay the betas one week to include this work? Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] First betas (perhaps) on June 18
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 critical bugs, then Wednesday's release will be >> beta 1. In that case, I will update PEP 361 and push the entire schedule >> back by 2 weeks to account for our slippage. > > Next weekend, 21 and 22, it will be the Python Bug days. > > Maybe it's worth to delay the betas one week to include this work? You mean one more week? (Barry's already delaying them one week.) 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 refactorings (unless there's really no more conservative way to fix a critical bug). It also means try to get at least one other person to review every change, no matter how small (or big!) *before* submitting. It also means run the tests before submitting. On the specific purpose of delaying for the bug day, I'm hesitant -- bug days tend to cause a great deal of commits of code by relatively new developers, which is counter to our purpose of stability. I would almost say it's better for the bug day to fall right after the beta. That also has the advantage that the bug day can focus on new bugs in the beta, and squash them right away... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] First betas (perhaps) on June 18
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 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 will update PEP 361 and push the entire schedule back by 2 weeks to account for our slippage. >>> >>> Next weekend, 21 and 22, it will be the Python Bug days. >>> >>> Maybe it's worth to delay the betas one week to include this work? >> >> You mean one more week? (Barry's already delaying them one week.) >> >> 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 refactorings (unless there's really no more conservative way to >> fix a critical bug). It also means try to get at least one other >> person to review every change, no matter how small (or big!) *before* >> submitting. It also means run the tests before submitting. > > That is a new policy, isn't it? Yes -- one that seems appropriate during a beta release period (i.e. until 2.6 and 3.0 final are out). >> On the specific purpose of delaying for the bug day, I'm hesitant -- >> bug days tend to cause a great deal of commits of code by relatively >> new developers, which is counter to our purpose of stability. I would >> almost say it's better for the bug day to fall right after the beta. >> That also has the advantage that the bug day can focus on new bugs in >> the beta, and squash them right away... > > +1. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] First betas (perhaps) on June 18
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 refactorings (unless there's really no more conservative way to > fix a critical bug). It also means try to get at least one other > person to review every change, no matter how small (or big!) *before* > submitting. It also means run the tests before submitting. I will quite happily abide by this; it's already causing more than enough stress over here. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
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 ahead and send me angry emails about how it's totally wrong, and your cat could do better. [1] http://code.python.org/python/users/benjamin.peterson/new_testing/main/ -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] Interesting blog post by Ben Sussman-Collins
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. [1] (That's only a bzr co --lightweight away.) Go ahead > and send me angry emails about how it's totally wrong, and your cat > could do better. If I had a cat it would probably use Mercurial instead :-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
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 duration of open issues: 713 days. Median duration of open issues: 1464 days. Open Issues Breakdown open 1873 (+35) pending26 ( +1) Issues Created Or Reopened (54) ___ merge pickle and cPickle in 3.0 06/12/08 CLOSED http://bugs.python.org/issue2917reopened benjamin.peterson patch Implement PEP 371: multiprocessing module06/11/08 CLOSED http://bugs.python.org/issue3050reopened benjamin.peterson patch heapq change breaking compatibility 06/09/08 http://bugs.python.org/issue3051reopened rhettinger patch test_disutils fails 06/06/08 http://bugs.python.org/issue3054created ronaldoussoren patch test_list on 64-bit platforms06/06/08 http://bugs.python.org/issue3055created ronaldoussoren Simplify the Integral ABC06/07/08 http://bugs.python.org/issue3056created rhettinger patch 2.6 abc fixes06/07/08 CLOSED http://bugs.python.org/issue3057created georg.brandl patch, 26backport Let SimpleXMLRPCServer pass client_address to called functions. 06/07/08 http://bugs.python.org/issue3058created cloverprince Removing .decode calls from Lib/calendar.py 06/07/08 CLOSED http://bugs.python.org/issue3059created gpolo patch Warn about tuple parameters 06/08/08 CLOSED http://bugs.python.org/issue3060created benjamin.peterson patch time.strftime() always decodes result with UTF-8 06/08/08 http://bugs.python.org/issue3061created georg.brandl Turtle speed() function has no effect under Mac OS X 06/08/08 http://bugs.python.org/issue3062created delroth memory leak in random number generation 06/08/08 CLOSED http://bugs.python.org/issue3063created gtang new turtle module for Python 3.0 06/08/08 CLOSED http://bugs.python.org/issue3064created gregorlingl patch Fix pickling bug of collections.namedtuple 06/08/08 CLOSED http://bugs.python.org/issue3065created alexandre.vassalotti patch, patch FD leak in urllib2 06/09/08 http://bugs.python.org/issue3066created bohdan setlocale Tracebacks on unicode locale strings 06/09/08 http://bugs.python.org/issue3067created vincent.chute IDLE - Add an extension configuration dialog 06/09/08 http://bugs.python.org/issue3068created taleinat patch Let set.union and set.intersection accept multiple arguments 06/09/08 http://bugs.python.org/issue3069created arno patch Wrong size calculation in posix_execve
[Python-Dev] multiprocessing source not "Unix clean"
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_VALUE_MAX but does define _SEM_VALUE_MAX in sys/params.h. .../Modules/_multiprocessing/multiprocessing.c: In function 'init_multiprocessing': .../Modules/_multiprocessing/multiprocessing.c:253: error: 'SEM_VALUE_MAX' undeclared (first use in this function) .../Modules/_multiprocessing/multiprocessing.c:253: error: (Each undeclared identifier is reported only once .../Modules/_multiprocessing/multiprocessing.c:253: error: for each function it appears in.) On Windows the author simple #defines SEM_VALUE_MAX to be LONG_MAX. I used a little cpp action to define it: #ifndef SEM_VALUE_MAX # ifdef _SEM_VALUE_MAX #define SEM_VALUE_MAX _SEM_VALUE_MAX # else #define SEM_VALUE_MAX INT_MAX # endif #endif Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 and optional underscores
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 not an Event is set is hardly an expensive Nick> operation... Precisely my point. The fact that the body of the method does almost nothing means that the cost of method lookup and function call will likely be much greater than the actual work being done. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 and optional underscores
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 and optional underscores
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? Why isn't this just an attribute? In 3.x, it's just an attribute. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
>> 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 about Benjamin> how it's totally wrong, and your cat could do better. No problem, as long as it doesn't take five months and touch every file in the distribution. I don't think Ben was suggesting there is never a good reason to work in relative isolation. I interpreted it as a rule of thumb for joint projects. In your case, while it can have a wide-ranging effect on the unit test code it's likely that you will be able to manage syncing from trunk/py3k just fine and you already have plenty of examples of how things work now and how they should work when you're done. That said, if you can commit in chunks that would probably still be a win. Where I work most of the projects are one-person, due largely to the business we are in and thus how management wants things done. I think that contributes to a number of issues, the most problematic being that APIs are developed largely in isolation, often with the needs of only one or two applications in mind. That creates problems for people who come along later and need to use those APIs, only to discover that they are fundamentally flawed in some way. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 and optional underscores
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 involved. Logically .alive is a property, > so I'd like to write it that way. I beg to differ. Ideally, API design should suggest which operations are efficient and which ones aren't, in order to (subconsciously) help the developer develop a mental model about the performance characteristics of an API. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 and optional underscores
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 >> >> Why is __name private to begin with? Any reason for the getters and >> setters? Why isn't this just an attribute? > > In 3.x, it's just an attribute. Oh, is it? Where's the PEP with the API redesign? Did I miss some kind of decision-making process, weighing compatibility concerns against other issues? Really, I think this all went way too fast, and should be rolled back and discussed properly *in detail* first. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 Python source? Ow. definitely. > FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does define > _SEM_VALUE_MAX in sys/params.h. > >.../Modules/_multiprocessing/multiprocessing.c: In function > 'init_multiprocessing': >.../Modules/_multiprocessing/multiprocessing.c:253: error: 'SEM_VALUE_MAX' > undeclared (first use in this function) >.../Modules/_multiprocessing/multiprocessing.c:253: error: (Each > undeclared identifier is reported only once >.../Modules/_multiprocessing/multiprocessing.c:253: error: for each > function it appears in.) > > On Windows the author simple #defines SEM_VALUE_MAX to be LONG_MAX. I used > a little cpp action to define it: > >#ifndef SEM_VALUE_MAX ># ifdef _SEM_VALUE_MAX >#define SEM_VALUE_MAX _SEM_VALUE_MAX ># else >#define SEM_VALUE_MAX INT_MAX ># endif >#endif Does this enable you to submit a patch? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8 and optional underscores
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 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? >> >> In 3.x, it's just an attribute. > > Oh, is it? Where's the PEP with the API redesign? Did I miss some kind > of decision-making process, weighing compatibility concerns against > other issues? meaning that it only has one underscore. They methods still live. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Betas today - I hope
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/decodeall!
We could also add such a check to the PyCodec_Encode() and _Decode()
functions. They currently do not apply the above check.
In Python, those two functions are exposed as codecs.encode()
and codecs.decode().
This change will probably have to wait for the 2.7 cycle.
BTW, what I noticed is that the unicode-internal codec seems to be broken:
>>> import codecs
>>> codecs.getencoder("unicode-internal")(u"abc")
('a\x00b\x00c\x00', 6)
I would have expected it to return:
>>> import codecs
>>> codecs.getencoder("unicode-internal")(u"abc")
('a\x00b\x00c\x00', 3)
Servus,
Walter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] [Python-3000-checkins] r64217 - in python/branches/py3k/Lib: bsddb/test/test_associate.py bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py idlel
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 release (whether alpha, beta >>> or final) we should practice extra restraint, not rush to get things >>> in right before the deadline. Let's all be more careful the rest of >>> this release cycle! (I think it wasn't just Benjamin who raced to get >>> things in...) >> >> Well, it wouldn't be "adding a new feature" to reinstate the old API for >> beta two, would it, as long as we retain the new one too? It does seem that >> change was a little precipitate. > > Although if we weren't actually planning on removing the old API in 3.0, I'm > a little confused as to why we were adding Py3k warnings to it in 2.6... It all went way too fast for anyone to think about the decision, so I suspect these two issues are directly related. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] [Python-3000-checkins] r64217 - in python/branches/py3k/Lib: bsddb/test/test_associate.py bsddb/test/test_join.py bsddb/test/test_lock.py bsddb/test/test_thread.py idlel
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 alpha, beta >> or final) we should practice extra restraint, not rush to get things >> in right before the deadline. Let's all be more careful the rest of >> this release cycle! (I think it wasn't just Benjamin who raced to get >> things in...) > > Also, for any method or module renaming, there is no way around a full > grep through the code base to really catch all uses of the old API. Eh? Even a full grep won't reveal 3rd party uses of the old API. While 3.x is intentionally breaking some things, this is not (and was never meant to be) as a blanket approval to break any API we feel like breaking. Each specific breakage must have a good motivation, e.g. the old API is confusing, or inefficient, or disallows certain uses -- non-PEP-8-conformance alone is not enough! In addition, each specific breakage must be weighed against the cost of updating 3rd party code, and whether a good (or at least fair) automatic conversion can be added to 2to3. > It may be tedious, especially with common names, but such bugs really > must be avoided as they can easily be -- I still could find uses of > old-style threading names, even in the stdlib. (Fixed in r64222.) All the more reason not to rush into API renamings without due process and lots of discussion. Let's err on the side of the status quo -- otherwise we'll never be ready for beta. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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]> 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 Python source? > > FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does define > _SEM_VALUE_MAX in sys/params.h. > >.../Modules/_multiprocessing/multiprocessing.c: In function > 'init_multiprocessing': >.../Modules/_multiprocessing/multiprocessing.c:253: error: 'SEM_VALUE_MAX' > undeclared (first use in this function) >.../Modules/_multiprocessing/multiprocessing.c:253: error: (Each > undeclared identifier is reported only once >.../Modules/_multiprocessing/multiprocessing.c:253: error: for each > function it appears in.) > > On Windows the author simple #defines SEM_VALUE_MAX to be LONG_MAX. I used > a little cpp action to define it: > >#ifndef SEM_VALUE_MAX ># ifdef _SEM_VALUE_MAX >#define SEM_VALUE_MAX _SEM_VALUE_MAX ># else >#define SEM_VALUE_MAX INT_MAX ># endif >#endif > > Skip > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 Windows line endings. Should those maybe be stripped to >> conform to the other Python source? > > Ow. definitely. I've converted the line endings in the trunk and py3k. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 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? >> >> Ow. definitely. > > 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 first place without anybody noticing? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Advice on numbers.py implementation of binary mixins.
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, other): if isinstance(other, (type(self), int, long)): # XXX return int(self) & int(other) return NotImplemented def __rand__(self, other): if isinstance(other, Integral): return int(other) & int(self) return NotImplemented 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 can be reasonably converted to an int; however, it means that any int/long subtype cannot use __rand__ to override the mixin's __and__. 3. Emulate the PEP as closely as possible and accomodate subclassing without changing behaviors. This approach is a bit complex: knowntypes = (set(type(self).__mro__) & set(type(other.__mro__)) - set(type(Integral.__mro__)) | set([int, long])) if isinstance(other, tuple(knowntypes)): I got this by analyzing the possible paths in an inheritance tree: class P(Integral): pass class Q(P): pass class R(Q): pass r = R(3) class S(Q): def __rand__(s,o) ... s = S(6) class T(Integral): def __rand__(s,o) ... t = T(5) With r&t, there is no common ancestor below Integral, so we want Integral.__and__() to return NotImplemented and allow T.__rand__() to do its thing. With r&s, both r and s share Q as a common ancenstor. By using the mixin and not overriding __and__(), Q specifies that __and__() should mean int(r)&int(s) whenever isinstance(r,Q) and isinstance(s,Q). Approaches 1 & 2 don't search the mro for shared ancestors below the level of Integral. So, when evaluating r&s, Integral.__and__() only checks that r is not an instance of S, int or long, and it erroneously returns NotImplemented , leaving s.__rand__() to take over. What do you guys think? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 first place without anybody noticing? svn cat tells me that they were CRLF when I initially imported them. I wonder if this has something to do with the patch utility I used to apply Jesse's patch. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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! Can we have a post-mortem of this? How did they get in there >> in the first place without anybody noticing? > > svn cat tells me that they were CRLF when I initially imported them. I > wonder if this has something to do with the patch utility I used to > apply Jesse's patch. I'm guessing Jesse uploaded the patch from a Windows box. It would be good to have something in the toolchain to change this. Perhaps a submit trigger (like the whitespace check) can look for this? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 submit trigger (like the whitespace check) can look for > this? I'll figure out how to do that if you give me shell access. ;) -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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. :) You're on Windows?! >> It would be good to have something in the toolchain to change this. >> Perhaps a submit trigger (like the whitespace check) can look for >> this? > > I'll figure out how to do that if you give me shell access. ;) Talk to MvL. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 just think I have emacs set up wrong. > >>> It would be good to have something in the toolchain to change this. >>> Perhaps a submit trigger (like the whitespace check) can look for >>> this? >> >> I'll figure out how to do that if you give me shell access. ;) > > Talk to MvL. I will do. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 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 first place without anybody noticing? >> >> svn cat tells me that they were CRLF when I initially imported them. I >> wonder if this has something to do with the patch utility I used to >> apply Jesse's patch. > > I'm guessing Jesse uploaded the patch from a Windows box. > > It would be good to have something in the toolchain to change this. Subversion can be configured to normalize line endings, either manually through properties, or automatically via ~/.subversion/config: [miscellany] enable-auto-props = yes [auto-props] *.c = svn:eol-style=native *.h = svn:eol-style=native etc. -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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 my fault. >>> :) >> >> You're on Windows?! > > Me!? I cringe at the accusation. No, I just think I have emacs set up wrong. Ow. Are you sure you haven't made this mistake in other situations? Please do try to debug your setup and avoid repeats! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
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: http://www.python.org/dev/faq/#what-configuration-settings-should-i-use -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
-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://blog.red-bean.com/sussman/?p=96 The story's main moral: submit your code for review early and often; work in a branch if you need to, but don't hide your code from review in a local repository until it's "perfect". Let's all remember this and make sure not to drop "code bombs" on each other. :-) Very interesting article. I'm short on time and don't want to rant (though I likely will ;), but I whole-heartedly agree with the moral of the story! I disagree with some of the details though. I actually think that a dvcs is /better/ suited to transparency, when used right, and when coupled with a public open code hosting facility. Sure, a lot depends on social engineering, and I agree with Ben that the tools make a difference, I just think that a good dvcs solves more problems than it creates. Also, there are a few things we do at my job that I think contribute significantly and positively to our productivity, quality and sense of shared community code. Briefly: * pre-implementation "calls" - you do not start hacking code until you've discussed your design or approach with at least one other person, either over the phone or on irc (preferably the former). Yes, there are exceptions but they are discouraged. This means that when you actually sit in front of your editor, you have a much better idea of what you are trying to accomplish. * 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, organized and very effectively diffuses code bombs. * everyone can see (lots of) everyone else's code - this is great because everyone needs some advice or guidance along the way. If you get stuck, you can push a branch and I can pull it and look at it, run it, test it, even modify it and push my own branch for you to see. This is /much/ more effective than trading patches, and I don't see how this could even work without a dvcs. * nothing lands without being reviewed - this is a hard and fast rule, no exceptions. Someone else has to review your code, and most developers are also reviewers (we have a mentoring program to train new reviewers). You get over the fear pretty quickly, and learn /a lot/ both by reviewing and getting reviewed. Coding standards emerge, best practices are established, and overall team productivity goes way up. Small branches are critical to this process, as is our goal of reviewing every branch within 24 hours of its submission. * nothing lands without passing all tests - speaking from experience, this is the one thing I wish Python would adopt! This means the trunk is /always/ releasable and stable. The trade-off is that it can take quite a while for your branch to land once it's been approved, since this process is serialized and is dependent on full test suite execution time. Python's challenge here is that what passes on one platform does not necessarily pass on another. Still, if this week is any indication, passing on /any/ platform would be nice. ;) I'm not saying Python can or should adopt these guidelines. An open source volunteer project is different than a corporate environment, even if the latter is very open-source-y. But it is worthwhile to continually evaluate and improve the process because over time, you definitely improve efficiency in ways that are happily adopted by the majority of the community. - -Barry P.S. I can't leave this without one little plug. Some folks really like the model that a non-dvcs imposes on development, others thrive on the freedom a dvcs gives you. Bazaar is flexible enough to support both models, even at the same time. It's not either-or. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFLzMnEjvBPtnXfVAQLm3QQAptABUXBoWeshMJAvHno1IDMZavL9D2BG q9d3wz8O5u2pbvuZyh44w4fhm7w7fscGvmPygifNbjPTVMeUYQUkunuEfWEIzf6B f6hm1KQm5gi9B4eqSUh3ItIAjGAnkVnCJ8VHeRH/Hff9FZhHqPhtP26LBrecMoho q0g80DrALB8= =J936 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python FAQ: Why doesn't Python have a "with" statement?
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 clarifying now that Python does have a 'with' statement. Michael Foord -- http://www.ironpythoninaction.com/ http://www.theotherdelia.co.uk/ http://www.voidspace.org.uk/ http://www.ironpython.info/ http://www.resolverhacks.net/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Interesting blog post by Ben Sussman-Collins
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, organized and very effectively diffuses code bombs. * everyone can see (lots of) everyone else's code - this is great because everyone needs some advice or guidance along the way. If you get stuck, you can push a branch and I can pull it and look at it, run it, test it, even modify it and push my own branch for you to see. This is /much/ more effective than trading patches, and I don't see how this could even work without a dvcs. * nothing lands without being reviewed - this is a hard and fast rule, no exceptions. Someone else has to review your code, and most developers are also reviewers (we have a mentoring program to train new reviewers). You get over the fear pretty quickly, and learn /a lot/ both by reviewing and getting reviewed. Coding standards emerge, best practices are established, and overall team productivity goes way up. Small branches are critical to this process, as is our goal of reviewing every branch within 24 hours of its submission. * nothing lands without passing all tests - speaking from experience, this is the one thing I wish Python would adopt! This means the trunk is /always/ releasable and stable. The trade-off is that it can take quite a while for your branch to land once it's been approved, since this process is serialized and is dependent on full test suite execution time. Python's challenge here is that what passes on one platform does not necessarily pass on another. Still, if this week is any indication, passing on /any/ platform would be nice. ;) I'm not saying Python can or should adopt these guidelines. An open source volunteer project is different than a corporate environment, even if the latter is very open-source-y. But it is worthwhile to continually evaluate and improve the process because over time, you definitely improve efficiency in ways that are happily adopted by the majority of the community. A big +1 on all these points. I can also add that Twisted is developed following many of these rules so it *can* work for open source volunteer projects, if the developers want it to. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Advice on numbers.py implementation of binary mixins.
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 can be reasonably converted to an int; however, it means that any int/long subtype cannot use __rand__ to override the mixin's __and__. 3. Emulate the PEP as closely as possible and accomodate subclassing without changing behaviors. This approach is a bit complex: knowntypes = (set(type(self).__mro__) & set(type(other.__mro__)) - set(type(Integral.__mro__)) | set([int, long])) if isinstance(other, tuple(knowntypes)): 4. As 2, but skip int/long subclasses: if type(other) in (int, long) or isinstance(other, type(self)): Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multiprocessing source not "Unix clean"
> "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 Windows line endings. Should those maybe be stripped to >> conform to the other Python source? Guido> Ow. definitely. Yes. If I have some time Saturday and nobody beats me to it I'll fix this. >> FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does >> define _SEM_VALUE_MAX in sys/params.h. >> >> .../Modules/_multiprocessing/multiprocessing.c: In function 'init_multiprocessing': >> .../Modules/_multiprocessing/multiprocessing.c:253: error: 'SEM_VALUE_MAX' undeclared (first use in this function) >> .../Modules/_multiprocessing/multiprocessing.c:253: error: (Each undeclared identifier is reported only once >> .../Modules/_multiprocessing/multiprocessing.c:253: error: for each function it appears in.) >> >> On Windows the author simple #defines SEM_VALUE_MAX to be LONG_MAX. I used >> a little cpp action to define it: >> >> #ifndef SEM_VALUE_MAX >> # ifdef _SEM_VALUE_MAX >> #define SEM_VALUE_MAX _SEM_VALUE_MAX >> # else >> #define SEM_VALUE_MAX INT_MAX >> # endif >> #endif Guido> Does this enable you to submit a patch? Sure, I can submit a patch, though while that got me going I have no real idea if that is the correct way to worm around the problem. I sort of think this is something which should be tested for in configure. The code above was just a guess. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python FAQ: Why doesn't Python have a "with" statement?
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 know that name resolution in Python uses the LEGB rule: first it starts
looking at locals, then to enclosing functions, then to globals, and finally to
the built-ins.
Assignament usually acts on locals (and with global statement, we can can even
change globals).
A "with" statement (such as Pascal's one) can be implemented adding a new scope
resolution on top of LEGB. So, taking the FAQ's example, and using a new
keyword (because with is already assigned to a different kind of work):
def foo(a):
on a:
print x
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:
def foo(a):
on a:
x += 1
print x
will be equivalent to:
def foo(a):
a.x += 1
print a.x
A more complex example (taking "A Simple Hello World Program" in
http://docs.python.org/lib/node688.html ) will show a major benefit on using
this statement:
from Tkinter import *
class Application(Frame):
def say_hi(self):
print "hi there, everyone!"
def createWidgets(self):
on Button(self):
text = "QUIT"
fg = "red"
command = self.quit
pack({"side": "left"})
on Button(self):
text = "Hello",
command = self.say_hi
pack({"side": "left"})
def __init__(self, master=None):
Frame.__init__(self, master)
self.pack()
self.createWidgets()
root = Tk()
on Application(master=root):
mainloop()
root.destroy()
Notice that adding a new step in scope resolution doesn't necessarily increase
execution speed. Taking a look at the above example, accessing to the Button
instance's attributes can be as fast as the original example, if not better.
Also, the new step in scope resolution will be needed only inside the block
defined by the "on" statement. Outside the "on" statement, the usual LEGB
method will be used.
Obviously "on" statements can be nested, adding each one a new step on scope
resolution.
IMO such kind of statement can be very useful to make the source code more
readable, especially working with GUIs.
If somebody knows SmallTalk, it looks similar to the "cascade messages" syntax:
(Window new)
label: 'Hello';
open
Cesare Di Mauro
In data 14 giugno 2008 alle ore 00:42:52, Michael Foord <[EMAIL PROTECTED]> ha
scritto:
> 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 clarifying now
> that Python does have a 'with' statement.
>
> Michael Foord
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python FAQ: Why doesn't Python have a "with" statement?
> 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 such, but I don't think this approach can work. People will want to assign to local variables in an "ob" block, and then be surprised that the assignment actually modified their object: def f(L): total = 0 for h in L: on h: more code accessing h's attributes if x: # reads h.x total = total+1 return total People will be surprised that total is always 0 (and that some objects have an attribute total with a value of 1). Likewise on x: for e in L: counts[e] += 1 # modifies x.counts People will be surprised that x also grows an attribute e, as the for loop involves an assignment, which you say goes to the object's namespace, of course. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
