Python-Dev March 2006

python-dev@python.org

135 participants
255 discussions

Re: [Python-Dev] .len() instead of __len__() (was: iterator API in Py3.0)
by Oleg Broytmann 05 Mar '06

05 Mar '06

Hello! On Sat, Mar 04, 2006 at 04:31:26PM -0500, Phillip J. Eby wrote: > I'm not sure that "more object-oriented" should be equated with "good" in > this context, or indeed any context. :) I am sure it is. > A function is no more or less > polymorphic than a method in any case, especially if the function is > normally delegating to a slot or special method in any case. Advantages of a method over a function: -- a method is a more natural way to query or manipulate objects; -- a direct method call is faster than two-level call (len() => .__len__()); -- unnecessary cluttering of builtin namespace; the namespace should(1) contains only really global functions (__import__(), eval(), etc.) What are the advantages of a function over a method? What are disadvantages of a direct .len() instead of .__len__()? Footnote: (1) I am a perfectionist and I partially disagree with "practicality beats purity"; I would really love a small uncluttered builtin namespace in Python. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd(a)phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

2 2

Slightly OT: Replying to posts
by Talin 05 Mar '06

05 Mar '06

Just a quick question about the mechanics of replying to this list. I am a subscriber to the list, however I much prefer readiing the list archives on the web instead of having the postings delivered to my email account. Because of this, I have delivery turned off in the mailing list preferences. I particularly dislike the idea of wasting bandwidth and disk space on something that I am not going to read. However, I would like to be able to reply to posts in such a way as to have them appear in the appropriate place in the thread hierarchy. Since I don't have the original email, I cannot reply to it directly; instead I have to create a new, non-reply email and send it to the list. Simply editing the subject line to put "Re: subject" would seem to be insufficient. Does anyone have a trick for managing this? Or is there a FAQ that someone can point me to that addresses this issue? -- Talin

2 1

Re: [Python-Dev] iterator API in Py3.0
by Phillip J. Eby 04 Mar '06

04 Mar '06

At 04:44 PM 3/4/2006 -0500, Raymond Hettinger wrote: >> As far as I can understand your position, you seem to be arguing that >> whatever we have now is correct, and therefore changing it would be wrong. > >Yes, that's pretty much it. IMO, introducing __builtin__.next() would >suck. The sublime feeling of consistency isn't worth the cost of an extra >builtin and adding an unnecessary global lookup to an otherwise >lightweight inner-loop construct. You mean, versus an unnecessary attribute lookup? :) Guido has stated many times that future versions of Python should be able to optimize references to builtins so that the global cost isn't required. Optimization of attribute lookups is a bit more speculative at this point, and can currently involve *more* dictionary lookups than a global lookup, depending on the inheritance depth. IIRC, looking for a 'next' method on a new-style object requires a minimum of two dictionary accesses already: one to look in the class, and one in the instance to make sure it's not shadowed. In contrast, __next__() could be a fast slot access, since slots are copied directly to subclasses. (But neither the performance argument nor the "extra builtin" argument make sense to me anyway, since they would both apply equally to len() and iter().)

1 0

Another Windows buildbot slave
by Josiah Carlson 04 Mar '06

04 Mar '06

It took me a while to get it set up, but we've got another Windows XP buildbot slave running. - Josiah

1 1

Re: [Python-Dev] defaultdict and on_missing()
by Michael Chermside 04 Mar '06

04 Mar '06

A minor related point about on_missing(): Haven't we learned from regrets over the .next() method of iterators that all "magically" invoked methods should be named using the __xxx__ pattern? Shouldn't it be named __on_missing__() instead? -- Michael Chermside

17 34

My buildbot host upgraded to OSX 10.4
by skip＠pobox.com 04 Mar '06

04 Mar '06

I upgraded my PowerMac G5 to OSX 10.4. ZopeInterface isn't recompiling after the upgrade to XCode 2.1. You probably ought to just pull "g5 osx.3" from the buildbot host list, certainly until I have time to figure this problem out. (Probably after as well. My machine configuration is now not substantially different from the loaner XServer.) Skip

2 2

Outdated Python Info on www.unicode.org (fwd)
by skip＠pobox.com 04 Mar '06

04 Mar '06

Someone here (Martin, MAL, /F?) would probably be able to write a short, authoritative description of Python's Unicode powers. Any takers? Skip

1 0

.py and .txt files missing svn:eol-style in trunk
by Tim Peters 03 Mar '06

03 Mar '06

These .py and .txt files don't have the svn:eol-style property set. I'm not sure they all _should_, though. Some of them are particularly bizarre, e.g. Lib\email\test\data\msg_26.txt has the svn:mime-type property set to application/octet-stream (WTF?), and then svn refuses to set the eol-style property. .\Lib\bsddb\test\test_1413192.py .\Lib\email\test\data\msg_26.txt .\Lib\email\test\data\msg_44.txt .\Lib\encodings\utf_8_sig.py .\Lib\test\bad_coding2.py .\Lib\test\outstanding_bugs.py .\Lib\test\test_defaultdict.py .\Lib\test\test_exception_variations.py .\Lib\test\test_pep263.py .\Lib\test\test_platform.py .\Lib\test\crashers\coerce.py .\Lib\test\crashers\dangerous_subclassing.py .\Lib\test\crashers\infinite_rec_1.py .\Lib\test\crashers\infinite_rec_2.py .\Lib\test\crashers\infinite_rec_3.py .\Lib\test\crashers\infinite_rec_4.py .\Lib\test\crashers\infinite_rec_5.py .\Lib\test\crashers\loosing_dict_ref.py .\Lib\test\crashers\modify_dict_attr.py .\Lib\test\crashers\recursive_call.py .\Lib\test\crashers\weakref_in_del.py .\Lib\test\crashers\xml_parsers.py .\Lib\xmlcore\etree\cElementTree.py .\Modules\zlib\algorithm.txt .\PC\readme.txt .\PC\testpy.py .\PC\example_nt\readme.txt .\PC\os2vacpp\readme.txt OK, I tried to set eol-style on all of those. svn refused to change these: svn: File 'Lib\email\test\data\msg_26.txt' has binary mime type property svn: File 'Lib\test\test_pep263.py' has binary mime type property svn: File 'PC\readme.txt' has binary mime type property svn: File 'PC\testpy.py' has binary mime type property svn: File 'PC\example_nt\readme.txt' has binary mime type property svn: File 'PC\os2vacpp\readme.txt' has binary mime type property test_pepe263 probably should be binary (it contains "funny characters"). I'll wrestle with the ones under PC/.

3 4

Re: [Python-Dev] bytes.from_hex()
by Greg Ewing 03 Mar '06

03 Mar '06

Bill Janssen wrote: > bytes -> base64 -> text > text -> de-base64 -> bytes It's nice to hear I'm not out of step with the entire world on this. :-) -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing(a)canterbury.ac.nz +--------------------------------------+

8 18

bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]
by Jason Orendorff 03 Mar '06

03 Mar '06

Instead of byte literals, how about a classmethod bytes.from_hex(), which works like this: # two equivalent things expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a') expected_md5_hash = bytes([92, 83, 80, 36, 202, 197, 25, 145, 83, 227, 131, 79, 229, 201, 46, 106]) It's just a nicety; the former fits my brain a little better. This would work fine both in 2.5 and in 3.0. I thought about unicode.encode('hex'), but obviously it will continue to return a str in 2.x, not bytes. Also the pseudo-encodings ('hex', 'rot13', 'zip', 'uu', etc.) generally scare me. And now that bytes and text are going to be two very different types, they're even weirder than before. Consider: text.encode('utf-8') ==> bytes text.encode('rot13') ==> text bytes.encode('zip') ==> bytes bytes.encode('uu') ==> text (?) This state of affairs seems kind of crazy to me. Actually users trying to figure out Unicode would probably be better served if bytes.encode() and text.decode() did not exist. -j

20 118

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev March 2006