[Python-Dev] New Developer
James Thomas
jjt009 at yahoo.com
Fri Jun 6 23:40:24 CEST 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 at python.org <python-dev-request at python.org> wrote:
From: python-dev-request at python.org <python-dev-request at python.org>
Subject: Python-Dev Digest, Vol 59, Issue 24
To: python-dev at python.org
Date: Friday, June 6, 2008, 2:30 PM
Send Python-Dev mailing list submissions to
python-dev at 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 at python.org
You can reach the person managing the list at
python-dev-owner at 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 at 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 at gmail.com> ha scritto:
> On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <guido at python.org>
wrote:
>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger
<python at 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 at gmail.com>
To: "Guido van Rossum" <guido at python.org>
Cc: "Raymond Hettinger" <python at rcn.com>;
<python-dev at 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 at python.org>
wrote:
>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger
<python at 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 at 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 at 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 at gmail.com>
> To: "Guido van Rossum" <guido at python.org>
> Cc: "Raymond Hettinger" <python at rcn.com>;
<python-dev at 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 at python.org>
>> wrote:
>>>
>>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger
<python at 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 at 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 at python.org
http://mail.python.org/mailman/listinfo/python-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20080606/ffcea19a/attachment-0001.htm>
More information about the Python-Dev
mailing list