RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20080606/ffcea19a/attachment-0001.htm below:

<table cellspacing='0' cellpadding='0' border='0' background='none' style='font-family:arial;font-size:10pt;color:rgb(51, 51, 51);background-color:rgb(255, 255, 255);width:100%;'><tr><td valign='top' style='font: inherit;'>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@python.org <python-dev-request@python.org> wrote: <blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: python-dev-request@python.org <python-dev-request@python.org> Subject: Python-Dev Digest, Vol 59, Issue 24 To: python-dev@python.org Date: Friday, June 6, 2008, 2:30 PM <pre>Send Python-Dev mailing list submissions
to &nbsppython-dev@python.org To subscribe or unsubscribe via the World Wide Web, visit &nbsphttp://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to &nbsppython-dev-request@python.org You can reach the person managing the list at &nbsppython-dev-owner@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..."</pre><pre>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)</pre><pre>On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow <jflatow@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/)</pre><pre>In data 06 giugno 2008 alle ore 20:40:01, Alex Martelli <aleaxit@gmail.com> ha scritto: > On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <guido@python.org> wrote: >> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <python@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. Cesare</pre><pre>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@gmail.com> To: "Guido van Rossum" <guido@python.org> Cc: "Raymond Hettinger" <python@rcn.com>; <python-dev@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@python.org> wrote: >> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <python@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</pre><pre>On Jun 6, 2008, at 3:24 PM, Guido van Rossum wrote: > On Fri, Jun 6, 2008 at 1:10 PM, Jared Flatow > <jflatow@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. jared</pre><pre>Make that int() instead of long() and I'm okay with it. On Fri, Jun 6, 2008 at 1:33 PM, Raymond Hettinger <python@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@gmail.com> > To: "Guido van Rossum" <guido@python.org> > Cc: "Raymond Hettinger" <python@rcn.com>; <python-dev@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@python.org> >> wrote: >>> >>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger <python@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/)</pre><pre>From: "Guido van Rossum" <guido@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</pre><pre>> 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</pre><pre>_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev</pre></blockquote></td></tr></table>

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4