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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Subject: Python-Dev Digest, Vol 59, Issue 24
To: [email protected]
Date: Friday, June 6, 2008, 2:30 PM
Send Python-Dev mailing list submissions to
[email protected]
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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
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
<[EMAIL PROTECTED]> ha scritto:
> On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
>> On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger
<[EMAIL PROTECTED]> 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 tal
