Mailman 3 June 2008 - Python-Dev

Modules for 2.6 inclusion
by Georg Brandl June 7, 2008

June 7, 2008

Hi, PEP 361 lists the following modules for possible inclusion in 2.6 (next to pyprocessing, which is now accepted): - winerror http://python.org/sf/1505257 (Owner: MAL) This patch has been marked as rejected, so I'll remove the entry from the PEP. - setuptools BDFL pronouncement for inclusion in 2.5: http://mail.python.org/pipermail/python-dev/2006-April/063964.html PJE's withdrawal from 2.5 for inclusion in 2.6: http://mail.python.org/pipermail/python-dev/2006-April/… [View More]

5 6

ABC issues
by Georg Brandl June 7, 2008

June 7, 2008

Some ABC issues: * The 2.6-backported Mapping ABC has the 3.0 dict API, that is, it uses keys() that returns a view etc. * The 2.6 UserDict is not registered as a mapping. * collections.deque isn't registered as a MutableSequence. If there are no objections, I will correct these issues in the 2.6 and 3.0 branches. Georg

5 12

Mini-Pep: Simplifying the Integral ABC
by Raymond Hettinger June 7, 2008

June 7, 2008

Target: Py2.6 and Py3.0 Author: Raymond Hettinger Date: May 31, 2008 Motivation ---------- The principal purpose of an abstract base class is to support multiple implementations of an API; thereby allowing one concrete class to be substitutable for another. This purpose is defeated when useful substitutions are precluded because the ABC is too aggressive in its behavioral requirements -- mandating too many methods, mandating methods that are difficult to implement, or too closely following … [View More]

13 27

Different cpu python code usage between embedded mode and standalone mode
by Pau Freixes June 7, 2008

June 7, 2008

Hi list, First Hello to all, I have a serious problem for understand some results when I'm comparing cpu usages between same python code in embedded mode and standalone mode ( python name_script.py ) This last months I have been writing a program in c like to mod_python for embedding python language, it's a middleware for dispatch and execute python batch programs into several nodes. Now I'm writing some python program for test how scale this into several nodes and comparing with "standalone"… [View More] performance. I found a very strange problem with one application named md5challenge, this aplication try to calculate the max number md5 digest in several seconds, md5challenge use a simple signal alarm for stop program when time has passed. This is the code of python script _nrdigest = 0 _const_b = 20 _f = None _signal = False def handler_alrm(signum, frame): global _signal global _nrdigest global _f _signal = True def try_me(): global _nrdigest global _f global _signal _f = open("/dev/urandom","r") while _signal is not True: buff = _f.read(_const_b) md5.md5(buff).hexdigest() _nrdigest = _nrdigest + 1 if _f is not None : _f.close() # Define entry point with one input variable # req is a instance of Request object, usefull members of this object are: # req.input is a dictionary with input.xml variables # req.constants is a dictionary with constants defined into signature.xml # req.output is void dictionary for full with output variables # req.config is a dictionary with config values take from namespace # req.apdn_pid is a pid of aplication def main( req ): global _nrdigest signal.signal(signal.SIGALRM, handler_alrm) signal.alarm(req.input['time']) try_me() req.output['count'] = _nrdigest return req.OK if __name__ == "__main__": # test code class test_req: pass req = test_req() req.input = { 'time' : 10 } req.output = { 'ret' : 0, 'count' : 0 } req.OK = 1 main(req) print "Reached %d digests" % req.output['count'] When I try to run this program in standalone into my Pentium Dual Core md5challenge reached 1.000.000 milion keys in 10 seconds but when i try to run this code in embedded mode md5challenge reached about 200.000 more keys !!! I repeat this test many times and always wins embedded mode !!! What's happen ? Also I tested to erase read dependencies from /dev/random, and calculate all keys from same buffer. In this case embedded mode win always also, and the difference are more bigger !!! The alarm time expires in both case in 10 seconds. Thks to all, can anybody help to me for understand this results ? -- Pau Freixes Linux GNU/User [View Less]

2 1

Postponing the first betas
by Barry Warsaw June 7, 2008

June 7, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We are going to postpone the first beta releases by one week. We had some problems with mail.python.org today, which prompted a query to Guido from me about the postponement. mail.python.org should now be back up normally now, as evidenced by the emailfloodl but in the meantime, Guido said: "I'd also like to see PEP 3138 (CJK-friendly repr()) and the pyprocessing PEP implemented by then, and perhaps some other small stuff." So we're … [View More]

6 5

on Python's tests (and making them better)
by Benjamin Peterson June 7, 2008

June 7, 2008

Hi, This summer, I am going to be revamping Python's test suite. Major things I plan to do include - rewriting regrtest.py to be a simple test driver - implementing CPython only decorators - moving skipping data to the tests themselves (perhaps with decorators) - completing the transition to unittest/docttest - removing old test_support crud (like verify) - increasing the testing of unicode inputs and fixing bugs the appear - write new testing docs for newbie contributors - merging related … [View More]

13 22

New Developer
by James Thomas June 7, 2008

June 7, 2008

Hi All, I'm a new developer with Python. I have a solid knowledge of both Python and C. Are there any tasks that would be suitable for a beginner to the Python codebase? I haven't been able to find a list of such tasks on python.org or bugs.python.org. Thanks, James Thomas --- On Fri, 6/6/08, python-dev-request(a)python.org <python-dev-request(a)python.org> wrote: From: python-dev-request(a)python.org <python-dev-request(a)python.org> Subject: Python-Dev Digest, Vol … [View More]59, Issue 24 To: python-dev(a)python.org Date: Friday, June 6, 2008, 2:30 PM Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request(a)python.org You can reach the person managing the list at python-dev-owner(a)python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..."Today's Topics: 1. Re: Assumed reflexivity of rich comparison operators (Guido van Rossum) 2. Re: Mini-Pep: Simplifying the Integral ABC (Cesare Di Mauro) 3. Re: Mini-Pep: Simplifying the Integral ABC (Raymond Hettinger) 4. Re: Assumed reflexivity of rich comparison operators (Jared Flatow) 5. Re: Mini-Pep: Simplifying the Integral ABC (Guido van Rossum) 6. Re: Mini-Pep: Simplifying the Integral ABC (Raymond Hettinger) 7. Re: Modules for 2.6 inclusion (Martin v. L?wis)On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow <jflatow(a)northwestern.edu> wrote: > PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the fourth > clause of the proposed resolutions to concerns: > > "The reflexivity rules *are* assumed by Python. Thus, the interpreter may > swap y>x with x<y, y>=x with x<=y, and may swap the arguments of x==y and > x!=y." > > However, if this is the case, why does Python allow the definition of both > pairs of __le__, __ge__ and __lt__, __gt__ for a single class, since users > have no guarantee over which will be called? Currently, if I do not want x >>= y to mean the same thing as y <= x (and believe it or not I believe I > have a good use case for doing this), I find it hard to believe that your users will be happy with that though. :-) > there is no reliable way of doing this. Does it help if I tell you that for "x <binop> y" we always try x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the case where y is an instance of a subclass of the class of x? > However, if the decision is to not allow users to do this at all using > operators (and force them to create specially named methods), what is the > point of allowing the definition of both? The same reason we allow (require) you to define __add__ and __radd_. It is quite possible that for any particular binary operation "x <binop> y", the class of x doesn't know how to implement it, and then the class of y is tried with the reversed operation. > It seems very confusing to me (and > indeed I was at first very confused what was going on), to tempt users to be > able to define both but give no promise that if they do, the appropriate one > will be called. Does anyone have a good explanation for this? I have explained it as well as I can. -- --Guido van Rossum (home page: http://www.python.org/~guido/)In data 06 giugno 2008 alle ore 20:40:01, Alex Martelli <aleaxit(a)gmail.com> ha scritto: > On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <guido(a)python.org> wrote: >> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <python(a)rcn.com> wrote: >>> Does anyone actually need an int lookalike with binary methods but >>> cannot just inherit from int? >> >> Does anyone actually need an int lookalike with operations like +, - >> etc. but cannot just inherit from int? If the answer is yes, is there >> a compelling reason why they wouldn't want to support binary methods >> as well? > > Yes, there's a use case for implementing long integers as arrays of > decimal digits -- addition is roughly as efficient as for binary > integers (x86 chips still have instructions to help with that), and > emitting as decimal digits is MUCH more efficient of course -- so if > I/O in decimal form is the most common operation, with a little > arithmetic (particularly sums), you could gain performance; binary > operations, however, would be as inefficient as decimal form > conversion is for ordinary binary ints, and not needed for the typical > applications that would use these "decimal coded integers" > (accounting), so why not save the implementer of such an extension > from having to write that unneeded and slow extra code? > > > Alex I don't know if you are talking about BCD numbers, but they are quite inefficient and slow in x86 architecture. There are instructions only to add and subtract packed BCD numbers which uses just two decimal digits (packed in two nibbles into a single byte). For unpacked BCDs, there are instructions to add, subtract, multiply and divide numbers, but which uses only one digit at the time. So using packed BCDs to store 8 decimal digits in 32 bits, for example, requires 4 instructions to make addictions or subractions, plus the required shift & mask instructions to put every couple digits into the AL register to execute BCD operations. Unpacked BCDs need double of them. Also, these instructions still use microcode to execute on modern processors, slowing down the execution pipeline (most of the simpler instructions do not require microcode, and execute "directly"). Last but not least, on x86-64 architecture BCD instructions were completely removed from the ISA; opcodes are assigned to new instructions. Obviously, binary operations can be performed twice faster thanks to the 64 bit registers and ALUs. The only practical advantage on using BCD numbers is the conversion-to-string operation, which can be done faster than binary numbers. Binary addition, subtraction, multiplication and division are greatly faster than BCD ones, and should be the preferred way to do integer math. CesareNew idea! I missed an obvious solution. Let the binary methods in Integral be mixins instead of abstract methods. That minimizes the burden on the class implementer while providing maximum support for clients. class Integral(Rational): ... def __lshift__(self, other): """self << other""" return long(self) << long(other) def __xor__(self, other): """self ^ other""" return long(self) ^ long(other) I worried a bit about changing type, but this kind of thing is already baked into numbers.py: @property def imag(self): """Real numbers have no imaginary component.""" return 0 @property def denominator(self): """Integers have a denominator of 1.""" return 1 Raymond ----- Original Message ----- From: "Alex Martelli" <aleaxit(a)gmail.com> To: "Guido van Rossum" <guido(a)python.org> Cc: "Raymond Hettinger" <python(a)rcn.com>; <python-dev(a)python.org> Sent: Friday, June 06, 2008 11:40 AM Subject: Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC > On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <guido(a)python.org> wrote: >> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <python(a)rcn.com> wrote: >>> Does anyone actually need an int lookalike with binary methods but >>> cannot just inherit from int? >> >> Does anyone actually need an int lookalike with operations like +, - >> etc. but cannot just inherit from int? If the answer is yes, is there >> a compelling reason why they wouldn't want to support binary methods >> as well? > > Yes, there's a use case for implementing long integers as arrays of > decimal digits -- addition is roughly as efficient as for binary > integers (x86 chips still have instructions to help with that), and > emitting as decimal digits is MUCH more efficient of course -- so if > I/O in decimal form is the most common operation, with a little > arithmetic (particularly sums), you could gain performance; binary > operations, however, would be as inefficient as decimal form > conversion is for ordinary binary ints, and not needed for the typical > applications that would use these "decimal coded integers" > (accounting), so why not save the implementer of such an extension > from having to write that unneeded and slow extra code? > > > AlexOn Jun 6, 2008, at 3:24 PM, Guido van Rossum wrote: > On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow > <jflatow(a)northwestern.edu> wrote: >> PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the >> fourth >> clause of the proposed resolutions to concerns: >> >> "The reflexivity rules *are* assumed by Python. Thus, the >> interpreter may >> swap y>x with x<y, y>=x with x<=y, and may swap the arguments of >> x==y and >> x!=y." >> >> However, if this is the case, why does Python allow the definition >> of both >> pairs of __le__, __ge__ and __lt__, __gt__ for a single class, >> since users >> have no guarantee over which will be called? Currently, if I do not >> want x >>> = y to mean the same thing as y <= x (and believe it or not I >>> believe I >> have a good use case for doing this), > > I find it hard to believe that your users will be happy with that > though. :-) In this case, I am my users and I would be very happy with it (but I won't try to justify it :). >> there is no reliable way of doing this. > > Does it help if I tell you that for "x <binop> y" we always try > x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the > case where y is an instance of a subclass of the class of x? Yes, actually that explains quite a bit, and now I see that is the case I am dealing with. y is an instance of a subclass of x, but the class of x is the one that defines both the binops. I suppose it is too much to ask to only call the __reverse_binop__ if the subclass overrides it. >> However, if the decision is to not allow users to do this at all >> using >> operators (and force them to create specially named methods), what >> is the >> point of allowing the definition of both? > > The same reason we allow (require) you to define __add__ and __radd_. > It is quite possible that for any particular binary operation "x > <binop> y", the class of x doesn't know how to implement it, and then > the class of y is tried with the reversed operation. > >> It seems very confusing to me (and >> indeed I was at first very confused what was going on), to tempt >> users to be >> able to define both but give no promise that if they do, the >> appropriate one >> will be called. Does anyone have a good explanation for this? > > I have explained it as well as I can. Thanks very much, at least that is enough information to work around reliably. jaredMake that int() instead of long() and I'm okay with it. On Fri, Jun 6, 2008 at 1:33 PM, Raymond Hettinger <python(a)rcn.com> wrote: > New idea! I missed an obvious solution. Let the binary methods in Integral > be mixins instead of abstract methods. That minimizes the burden on the > class implementer while providing maximum support for clients. > > class Integral(Rational): > ... > def __lshift__(self, other): > """self << other""" > return long(self) << long(other) > def __xor__(self, other): > """self ^ other""" > return long(self) ^ long(other) > > I worried a bit about changing type, but this kind of thing is already baked > into numbers.py: > > @property > def imag(self): > """Real numbers have no imaginary component.""" > return 0 > > @property > def denominator(self): > """Integers have a denominator of 1.""" > return 1 > > Raymond > > > ----- Original Message ----- From: "Alex Martelli" <aleaxit(a)gmail.com> > To: "Guido van Rossum" <guido(a)python.org> > Cc: "Raymond Hettinger" <python(a)rcn.com>; <python-dev(a)python.org> > Sent: Friday, June 06, 2008 11:40 AM > Subject: Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC > > >> On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <guido(a)python.org> >> wrote: >>> >>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <python(a)rcn.com> wrote: >>>> >>>> Does anyone actually need an int lookalike with binary methods but >>>> cannot just inherit from int? >>> >>> Does anyone actually need an int lookalike with operations like +, - >>> etc. but cannot just inherit from int? If the answer is yes, is there >>> a compelling reason why they wouldn't want to support binary methods >>> as well? >> >> Yes, there's a use case for implementing long integers as arrays of >> decimal digits -- addition is roughly as efficient as for binary >> integers (x86 chips still have instructions to help with that), and >> emitting as decimal digits is MUCH more efficient of course -- so if >> I/O in decimal form is the most common operation, with a little >> arithmetic (particularly sums), you could gain performance; binary >> operations, however, would be as inefficient as decimal form >> conversion is for ordinary binary ints, and not needed for the typical >> applications that would use these "decimal coded integers" >> (accounting), so why not save the implementer of such an extension >> from having to write that unneeded and slow extra code? >> >> >> Alex > > -- --Guido van Rossum (home page: http://www.python.org/~guido/)From: "Guido van Rossum" <guido(a)python.org> > Make that int() instead of long() and I'm okay with it. Does anyone know why Integral says that __long__ is a required abstract method, but not __int__? Likewise, why is index() defined as long(self) instead of int(self)? There may be some design nuance that I'm not seeing. Raymond> I created an issue 1 week ago (http://bugs.python.org/issue2983) > suggesting the addition of the ttk module to lib-tk, and to the new > tkinter package. Is there any chance to this be accepted for Python > 2.6 ? Is it complete? In principle, it's for the mentor to decide (who would need to decide before the first beta, of course - afterwards it's for the release manager to decide). Regards, Martin_______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev [View Less]

3 2

Location of uname in os.py
by James Thomas June 7, 2008

June 7, 2008

Can anyone give me an idea as to where the function uname is located in os? I am unable to find it explicitly defined within the os.py file in the current svn repository. I also need to know how a call to os.uname() interacts with platform.uname(). I apologize if there is an obvious answer to this question; I just began to work on the Python project a few days ago and therefore am relatively unacqainted with the codebase. Thanks, James Thomas

2 1

Assumed reflexivity of rich comparison operators
by Jared Flatow June 6, 2008

June 6, 2008

Hi all, PEP 207 (http://www.python.org/dev/peps/pep-0207/) states in the fourth clause of the proposed resolutions to concerns: "The reflexivity rules *are* assumed by Python. Thus, the interpreter may swap y>x with x<y, y>=x with x<=y, and may swap the arguments of x==y and x!=y." However, if this is the case, why does Python allow the definition of both pairs of __le__, __ge__ and __lt__, __gt__ for a single class, since users have no guarantee over which will be … [View More]

2 2

PEP 8 vs PEP 371: Additional Discussion
by Jim Jewett June 6, 2008

June 6, 2008

Guido van Rossum wrote: > I consider multiprocessing a new API -- while it bears > a superficial resemblance with the threading API the > similarities are just that, and it should not be > constrained by mistakes in that API. The justification for including it is precisely that it is *not* a new API. For multiple processes in general, there are competing APIs, which may well be better. The advantage of this API is that (in many cases) it is a drop-in replacement for threading. … [View More]

2 1