[Python-Dev] Tracker reviews workflow and flags

[anatoly techtonik]

I want to push some of my patches before 2.7 and use 5-1 rule for
that, but I can't come up with any review workflow other than mailing
status of my comments to the issues here. I can't mark issues in any
way. How about giving users ability to set flags or keywords? Maybe
entering a separate field like "Review status"?

Real world example with issue8151. It is an issue with a trivial patch
in it. Everything what is needed is to dispatch it to stable `commit
queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
have no means to mark it as 'easy' either, so even this trivial fix
lies in tracker for three days waiting for review.

About 'easy' flag:
"6  easyThis is an easy task (e.g. suitable for GHOP or bug day 
beginners)"
It seems that it is for the issue that requires a patch, but if the
patch is already there and nobody wants to commit it - what should I
do?


Finally, review queue proposal.
To follow 5-1 rule, I need to review 5 issues, before mine is
reviewed, so I need some help from tracker.
1. I lack expertise in certain areas (C/C++, Mac OS, etc.), so I would
like to hide some issues under "Needs review" query, so they won't
bother me (if too many people marked issues in this way - the stats
may become a good reason for highly professional bug party)
2. I need ability to set "Needs review" flag back. Some issues were
once reviewed, but since then they've got modified and need further
comments.  The need the review again. That means pushed back _into the
end_ of patch queue.
3. Setting bug dependency by users. Often nobody wants to care about
issue, because it is just too long, there is much irrelevant comments
and nobody has time to read it. We don't have personal digg-like
comment filters to cope with the amount of text to be brain-loaded.
But it is possible to refactor such issue thread into separate
digestable issue/issues.


P.S.  About personal comment filters if anybody is interested in that.
Digg-like +1, -1 are good for voting, but for filtering it would be
nice to: 1. have several filters for different aspects of the thread,
2. have JS filter by marking individual phrases in comments and adding
ranges to filter using jquery / ajax

This way reviews will be more fun and easy.
-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Joel Spolsky on Mercurial

[Dirkjan Ochtman]

On Thu, Mar 18, 2010 at 22:38, Terry Reedy  wrote:
> Having gotten that far, I think this might be worth referencing in new dev
> docs.

Will do. I finally read hginit yesterday, after having seen people
rave about it on twitter for a few weeks, and it's a very friendly
introduction.

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

[Mark Dickinson]

On Thu, Mar 18, 2010 at 9:48 PM, Nick Coghlan  wrote:
> Note that even in Py3k there are some fairly serious weirdnesses kicking
> around due to the intransitive nature of numeric equality though:

Yep.  My personal favourite is:

>>> from decimal import Decimal as dec
>>> set((1, 1.0, dec(1))) == set((1.0, 1, dec(1)))
False

(The sets even have different sizes!)

Note that while the originally proposed change does fix problems with
sets of Decimals, ints and floats, and with sorting of lists of those
types, it's not a complete fix:  as soon as you throw Fractions into
the mix, all the same problems arise again.  Making hashes of int,
float, Decimal *and* Fraction all compatible with one another,
efficient for ints and floats, and not grossly inefficient for
Fractions and Decimals, is kinda hairy, though I have a couple of
ideas of how it could be done.  Making Decimal-to-Fraction comparisons
give correct results isn't easy either:  the conversion in one
direction (Fraction to Decimal) is lossy, while the conversion in the
other direction (Decimal to Fraction) can't be performed efficiently
if the Decimal has a large exponent (Decimal('1e123456'));  so you
can't just do the Decimal.from_float trick of whacking everything into
a single domain and comparing there.  Again, this is solvable, but not
trivially so.

See, this is what happens when a language conflates numeric equality
with the equivalence relation used for membership testing.  ;-).  (I'm
not really complaining, but this is definitely one of the downsides of
this particular design decision.)

> When there is a clear, correct way (based on Decimal.from_float) to make
> numeric comparison behave in accordance with the rules of mathematics,
> do we really want to preserve strange, unintuitive behaviour like the above?

No.  Not really, no.  :)

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

[Mark Dickinson]

On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson  wrote:
> Making hashes of int,
> float, Decimal *and* Fraction all compatible with one another,
> efficient for ints and floats, and not grossly inefficient for
> Fractions and Decimals, is kinda hairy, though I have a couple of
> ideas of how it could be done.

To elaborate, here's a cute scheme for the above, which is actually
remarkably close to what Python already does for ints and floats, and
which doesn't require any of the numeric types to figure out whether
it's exactly equal to an instance of some other numeric type.

After throwing out infinities and nans (which can easily be dealt with
separately), everything we care about is a rational number, so it's
enough to come up with some mapping from the set of all rationals to
the set of possible hashes, subject to the requirement that the
mapping can be computed efficiently for the types we care about.

For any prime P there's a natural 'reduce modulo P' map

  reduce : {rational numbers} --> {0, 1, ..., P-1, infinity}

defined in pseudocode by:

  reduce(m/n) = ((m % P) * inv(n, P)) % P  if n % P != 0  else infinity

where inv(n, P) represents the modular inverse to n modulo P.

Now let P be the handy Mersenne prime P = 2**31-1 (on a 64-bit
machine, the almost equally handy prime 2**61-1 could be used
instead), and define a hash function from the set of rationals to the
set [-2**31, 2**31) by:

hash(0) = 0
hash(m/n) = 1 + reduce(m/n - 1) if m/n > 0   # i.e., reduce m/n modulo
P, but to [1..P] rather than [0..P-1].
hash(m/n) = -hash(-m/n) if m/n < 0.

and in the last two cases, map a result of infinity to the unused hash
value -2**31.

For ints, this hash function is almost identical to what Python
already has, except that the current int hash does a reduction modulo
2**32-1 or 2**64-1 rather than 2**31-1.  For all small ints, hash(n)
== n, as currently.  Either way, the hash can be computed
digit-by-digit in exactly the same manner.  For floats, it's also easy
to compute:  express the float as m * 2**e for some integers m and e,
compute hash(m), and rotate e bits in the appropriate direction.  And
it's straightforward to implement for the Decimal and Fraction types,
too.

(One minor detail:  as usual, some postprocessing would be required to
replace a hash of -1 with something else, since a hash value of -1 is
invalid.)

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.

[Antoine Pitrou]

Glenn Linderman  nevcal.com> writes:
> 
> On the other hand, if the default behavior is to do an implicit 
> conversion, I don't know of any way that that could be turned into an 
> exception for those coders that don't want or don't like the particular 
> type of implicit conversion chosen.

You still haven't given a good reason why we should raise an exception rather
than do a comparison, though.

The fact that some particular coders don't like "the particular type of implicit
conversion chosen" is a particularly weak argument. Python isn't a language
construction framework; we try to choose useful defaults rather than simply give
out a box of tools. If some people don't like the defaults (significant
indentation, limitless precision integers, etc.), there are other choices out 
there.


Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Joel Spolsky on Mercurial

[Nick Coghlan]

Dirkjan Ochtman wrote:
> On Thu, Mar 18, 2010 at 22:38, Terry Reedy  wrote:
>> Having gotten that far, I think this might be worth referencing in new dev
>> docs.
> 
> Will do. I finally read hginit yesterday, after having seen people
> rave about it on twitter for a few weeks, and it's a very friendly
> introduction.

The key insight for me was the "manage versions" vs "manage change sets"
distinction between a traditional VCS and a DVCS. I kind of knew that
already, but that page expressed it really well.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GSoC 2010 is on -- projects?

[Arc Riley]

Hi Laurent

If your community project would like help porting to Python 3, and you feel
this work is enough for a student to work full time for several weeks on,
then please do add it to the GSoC ideas page on the wiki.

There will be another program running for high school students which is more
suitable for smaller tasks (2-3 days each), more on-par with the actual time
it takes to port most Python packages.


On Fri, Mar 19, 2010 at 2:23 AM, Laurent Gautier  wrote:

>
> Hi,
>
>
> Does this mean that any other python project could potentially see itself
> ported to Python 3 in the course of this SoC ? If so, can any project owner
> submit a request for help, or is there going to be a list of projects that
> would nice to port, or will a voting system of some sort be put in place ?
>
>
> Best,
>
>
> Laurent
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/arcriley%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Joel Spolsky on Mercurial

[M. Shuaib Khan]

On Fri, Mar 19, 2010 at 4:52 PM, Nick Coghlan  wrote:

> Dirkjan Ochtman wrote:
> > On Thu, Mar 18, 2010 at 22:38, Terry Reedy  wrote:
> >> Having gotten that far, I think this might be worth referencing in new
> dev
> >> docs.
> >
> > Will do. I finally read hginit yesterday, after having seen people
> > rave about it on twitter for a few weeks, and it's a very friendly
> > introduction.
>
> The key insight for me was the "manage versions" vs "manage change sets"
> distinction between a traditional VCS and a DVCS. I kind of knew that
> already, but that page expressed it really well.
>

Hi,

Is Python-dev going to consider shifting their repo to mercurial/git instead
of SVN? :)



>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ---
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/aries.shuaib%40gmail.com
>



-- 
M. Shuaib Khan
http://mshuaibkhan.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

[Nick Coghlan]

Mark Dickinson wrote:
> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson  wrote:
> For ints, this hash function is almost identical to what Python
> already has, except that the current int hash does a reduction modulo
> 2**32-1 or 2**64-1 rather than 2**31-1.  For all small ints, hash(n)
> == n, as currently.  Either way, the hash can be computed
> digit-by-digit in exactly the same manner.  For floats, it's also easy
> to compute:  express the float as m * 2**e for some integers m and e,
> compute hash(m), and rotate e bits in the appropriate direction.  And
> it's straightforward to implement for the Decimal and Fraction types,
> too.

It seems to me that given the existing conflation of numeric equivalence
and containment testing, going the whole hog and fixing the set
membership problem for all of our rational types would be the right
thing to do.

Would it be worth providing the underlying implementation of the hash
algorithm as a math.hash_rational function and then use it for Decimal
and Fraction?

That would have the virtue of making it easy for others to define
numeric types that "played well" with numeric equivalence.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Joel Spolsky on Mercurial

[Oleg Broytman]

On Fri, Mar 19, 2010 at 04:59:38PM +0500, M. Shuaib Khan wrote:
> Is Python-dev going to consider shifting their repo to mercurial/git instead
> of SVN? :)

http://mail.python.org/pipermail/python-dev/2009-March/087931.html

   The decision was made about a year ago.

http://www.python.org/dev/peps/pep-0374/
http://www.python.org/dev/peps/pep-0385/

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] binary operation heuristics -- bug or undocumented?

[Alex A. Naanou]

Hi,

A friend of mine stumbled upon the following behavior:


---cut---

>>> class A(object): pass
...
>>> class B(object):
... def __add__(self, other):
... print 'B: adding B and %s objects.' % other.__class__.__name__
...
>>> class C(object):
... def __radd__(self, other):
... print 'C: adding C and %s objects.' % other.__class__.__name__
...
>>> a, b, c = A(), B(), C()

>>> b + c
B: adding B and C objects.

>>> a + c
C: adding C and A objects.


# so far, quite logical. now let's do this:

>>> 1 + c
C: adding C and int objects.


--uncut--

My first expectation would be to get a TypeError here, as ints indeed
have an __add__ method, and they do not know anything about C objects
(obviously :) ). On second thought, giving client code priority to
handle things has it's merits.

The problem is that I found no mention of this behavior in the docs.


P.S. tested in 2.5 through 3.0 and PyPy

Thanks.

-- 
Alex.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Mark Dickinson]

On Fri, Mar 19, 2010 at 12:46 PM, Alex A. Naanou  wrote:
> A friend of mine stumbled upon the following behavior:
>
>
> ---cut---
>
 class A(object): pass
> ...
 class B(object):
> ...     def __add__(self, other):
> ...         print 'B: adding B and %s objects.' % other.__class__.__name__
> ...
 class C(object):
> ...     def __radd__(self, other):
> ...         print 'C: adding C and %s objects.' % other.__class__.__name__
> ...
 a, b, c = A(), B(), C()
>
 b + c
> B: adding B and C objects.
>
 a + c
> C: adding C and A objects.
>
>
> # so far, quite logical. now let's do this:
>
 1 + c
> C: adding C and int objects.
>
>
> --uncut--
>
> My first expectation would be to get a TypeError here, as ints indeed
> have an __add__ method, and they do not know anything about C objects
> (obviously :) ).

Yes:  the int.__add__ method is tried first.  Since it doesn't know
anything about C objects it returns NotImplemented, and then
C.__radd__ is given a chance to do the addition.  The rules are
documented here:

http://docs.python.org/reference/datamodel.html#coercion-rules

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Michael Foord]

On 19/03/2010 12:46, Alex A. Naanou wrote:

[snip...]

class C(object):
 

... def __radd__(self, other):
... print 'C: adding C and %s objects.' % other.__class__.__name__
...
   

a, b, c = A(), B(), C()
1 + c
 

C: adding C and int objects.


   


That is the whole point of the __radd__ method. ints don't know how to 
add themselves to C objects, so int.__add__ will return NotImplemented 
and then Python will try C.__radd__.


All the best,

Michael


--uncut--

My first expectation would be to get a TypeError here, as ints indeed
have an __add__ method, and they do not know anything about C objects
(obviously :) ). On second thought, giving client code priority to
handle things has it's merits.

The problem is that I found no mention of this behavior in the docs.


P.S. tested in 2.5 through 3.0 and PyPy

Thanks.

   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] right-side binary operations

[Oleg Broytman]

On Fri, Mar 19, 2010 at 03:46:07PM +0300, Alex A. Naanou wrote:
> >>> class C(object):
> ... def __radd__(self, other):
> ... print 'C: adding C and %s objects.' % other.__class__.__name__
> ...
> >>> 1 + c
> C: adding C and int objects.
> 
> My first expectation would be to get a TypeError here, as ints indeed
> have an __add__ method, and they do not know anything about C objects
> (obviously :) ). On second thought, giving client code priority to
> handle things has it's merits.
> 
> The problem is that I found no mention of this behavior in the docs.

   It's well-known and documented behavior. It's what r-methods are for.
See http://docs.python.org/reference/datamodel.html#emulating-numeric-types

   "These methods are called to implement the binary arithmetic operations
(+, -, *, /, %, divmod(), pow(), **, <<, >>, &, ^, |) with reflected
(swapped) operands. These functions are only called if the left operand
does not support the corresponding operation and the operands are of
different types. [3] For instance, to evaluate the expression x - y, where
y is an instance of a class that has an __rsub__() method, y.__rsub__(x) is
called if x.__sub__(y) returns NotImplemented."

Oleg.
-- 
 Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Joel Spolsky on Mercurial

[skip]

M> Is Python-dev going to consider shifting their repo to mercurial/git
M> instead of SVN? :)

Yes, Dirkjan has been working on it.  My initial experience with hg as a
quick way to revision control anything anywhere on a small scale ("hmmm, I
should track changes to /etc/hosts... cd /etc ; hg init ; hg add hosts")
worked quite well, but when I tried to use it for something where I was
actually working collaboratively (my lockfile module) I managed to get my
code/branches/heads/whatever completely f**ked up.  I gave up and just went
back to Subversion.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Alex A. Naanou]

Thanks!

On Fri, Mar 19, 2010 at 16:05, Michael Foord  wrote:
> On 19/03/2010 12:46, Alex A. Naanou wrote:
>>
>> [snip...]
>
> class C(object):
>
>>
>> ...     def __radd__(self, other):
>> ...         print 'C: adding C and %s objects.' % other.__class__.__name__
>> ...
>>
>
> a, b, c = A(), B(), C()
> 1 + c
>
>>
>> C: adding C and int objects.
>>
>>
>>
>
> That is the whole point of the __radd__ method. ints don't know how to add
> themselves to C objects, so int.__add__ will return NotImplemented and then
> Python will try C.__radd__.
>
> All the best,
>
> Michael
>
>> --uncut--
>>
>> My first expectation would be to get a TypeError here, as ints indeed
>> have an __add__ method, and they do not know anything about C objects
>> (obviously :) ). On second thought, giving client code priority to
>> handle things has it's merits.
>>
>> The problem is that I found no mention of this behavior in the docs.
>>
>>
>> P.S. tested in 2.5 through 3.0 and PyPy
>>
>> Thanks.
>>
>>
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.

P.S. like the licence :)

>
>
>



-- 
Alex.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

[Case Vanhorsen]

On Fri, Mar 19, 2010 at 3:07 AM, Mark Dickinson  wrote:
> On Fri, Mar 19, 2010 at 9:37 AM, Mark Dickinson  wrote:
>> Making hashes of int,
>> float, Decimal *and* Fraction all compatible with one another,
>> efficient for ints and floats, and not grossly inefficient for
>> Fractions and Decimals, is kinda hairy, though I have a couple of
>> ideas of how it could be done.
>
> To elaborate, here's a cute scheme for the above, which is actually
> remarkably close to what Python already does for ints and floats, and
> which doesn't require any of the numeric types to figure out whether
> it's exactly equal to an instance of some other numeric type.
>
> After throwing out infinities and nans (which can easily be dealt with
> separately), everything we care about is a rational number, so it's
> enough to come up with some mapping from the set of all rationals to
> the set of possible hashes, subject to the requirement that the
> mapping can be computed efficiently for the types we care about.
>
> For any prime P there's a natural 'reduce modulo P' map
>
>  reduce : {rational numbers} --> {0, 1, ..., P-1, infinity}
>
> defined in pseudocode by:
>
>  reduce(m/n) = ((m % P) * inv(n, P)) % P  if n % P != 0  else infinity
>
> where inv(n, P) represents the modular inverse to n modulo P.
>
> Now let P be the handy Mersenne prime P = 2**31-1 (on a 64-bit
> machine, the almost equally handy prime 2**61-1 could be used
> instead), and define a hash function from the set of rationals to the
> set [-2**31, 2**31) by:
>
> hash(0) = 0
> hash(m/n) = 1 + reduce(m/n - 1) if m/n > 0   # i.e., reduce m/n modulo
> P, but to [1..P] rather than [0..P-1].
> hash(m/n) = -hash(-m/n) if m/n < 0.
>
> and in the last two cases, map a result of infinity to the unused hash
> value -2**31.
>
> For ints, this hash function is almost identical to what Python
> already has, except that the current int hash does a reduction modulo
> 2**32-1 or 2**64-1 rather than 2**31-1.  For all small ints, hash(n)
> == n, as currently.  Either way, the hash can be computed
> digit-by-digit in exactly the same manner.  For floats, it's also easy
> to compute:  express the float as m * 2**e for some integers m and e,
> compute hash(m), and rotate e bits in the appropriate direction.  And
> it's straightforward to implement for the Decimal and Fraction types,
> too.
Will this change the result of hashing a long? I know that both gmpy
and SAGE use their own hash implementations for performance reasons. I
understand that CPython's hash function is an implementation detail,
but there are external modules that rely on the existing hash
behavior.

FWIW, I'd prefer 2.7 and 3.2 have the same behavior. I don't mind the
existing 3.1 behavior and I'd rather not have a difference between 3.1
and 3.2.

casevh
>
> (One minor detail:  as usual, some postprocessing would be required to
> replace a hash of -1 with something else, since a hash value of -1 is
> invalid.)
>
> Mark
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bug? syslog.openlog using ident "python" by default.

[Eric Smith]

Sean Reifschneider wrote:

If you call:

   from syslog import syslog, openlog
   syslog('My error message')

Something like the following gets logged:

   Mar 18 05:20:22 guin python: My error message
^^

Where I'm annoyed by the "python" in the above.  This is pulled from
the C argv[0].  IMHO, what we really want is the Python sys.argv[0].


I agree with this. The existing behavior is very annoying. I don't have 
any particular thoughts about the implementation.


Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[Brian Curtin]

On Fri, Mar 19, 2010 at 03:09, anatoly techtonik wrote:

> I want to push some of my patches before 2.7 and use 5-1 rule for
> that, but I can't come up with any review workflow other than mailing
> status of my comments to the issues here. I can't mark issues in any
> way. How about giving users ability to set flags or keywords? Maybe
> entering a separate field like "Review status"?
>

We already have "Patch Review" as a stage, and "needs review" as a flag,
which I feel is more than enough. If you don't have the privileges to modify
an issue, you can always comment on the issue with something like "can this
issue be set to the patch review stage?" Someone will probably take a look
at it and set it accordingly.

Real world example with issue8151. It is an issue with a trivial patch
> in it. Everything what is needed is to dispatch it to stable `commit
> queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
> have no means to mark it as 'easy' either, so even this trivial fix
> lies in tracker for three days waiting for review.
>

Given that we have hundreds of issues with patches waiting for review, three
days isn't so bad :) As with any project, there are only so many people and
so much time to get the work done.


> About 'easy' flag:
> "6  easyThis is an easy task (e.g. suitable for GHOP or bug day
> beginners)"
> It seems that it is for the issue that requires a patch, but if the
> patch is already there and nobody wants to commit it - what should I
> do?
>

Post a comment on the issue asking what the status is. If an approved patch
has been sitting for a few weeks, make a comment. If it has been there for a
few days, I'd let it slide but keep it on your radar.


>
> Finally, review queue proposal.
> To follow 5-1 rule, I need to review 5 issues, before mine is
> reviewed, so I need some help from tracker.
> 1. I lack expertise in certain areas (C/C++, Mac OS, etc.), so I would
> like to hide some issues under "Needs review" query, so they won't
> bother me (if too many people marked issues in this way - the stats
> may become a good reason for highly professional bug party)
>

There already exists a component field which has Macintosh as an option, so
you could filter on that. Same goes for Windows.

Drilling down to the language(s) involved in the issue feels like just
another step that would get limited use. I do see what you are saying,
though, because I'm sure it's frustrating to want to look out there for a
nice pure-Python issue, then the first 10 issues you click on require C code
(or vice versa).


> 2. I need ability to set "Needs review" flag back. Some issues were
> once reviewed, but since then they've got modified and need further
> comments.  The need the review again. That means pushed back _into the
> end_ of patch queue.
>

I don't think the "needs review" flag gets unset, but if it has been unset
manually and you've made changes, you can ask for another review. If you can
get the changes made quickly, you might be able to get the previous reviewer
to look at it again while it's still fresh in their mind.


> 3. Setting bug dependency by users. Often nobody wants to care about
> issue, because it is just too long, there is much irrelevant comments
> and nobody has time to read it. We don't have personal digg-like
> comment filters to cope with the amount of text to be brain-loaded.
> But it is possible to refactor such issue thread into separate
> digestable issue/issues.
>
>
> P.S.  About personal comment filters if anybody is interested in that.
> Digg-like +1, -1 are good for voting, but for filtering it would be
> nice to: 1. have several filters for different aspects of the thread,
> 2. have JS filter by marking individual phrases in comments and adding
> ranges to filter using jquery / ajax
>
> This way reviews will be more fun and easy.
> --
> anatoly t.
>

I think that would take away from the goal of fixing the issue. Even some -1
comments could contain helpful information, but you might have to explicitly
click on that hidden comment to find out.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[R. David Murray]

On Fri, 19 Mar 2010 10:09:16 +0200, anatoly techtonik  
wrote:
> I want to push some of my patches before 2.7 and use 5-1 rule for
> that, but I can't come up with any review workflow other than mailing
> status of my comments to the issues here. I can't mark issues in any
> way. How about giving users ability to set flags or keywords? Maybe
> entering a separate field like "Review status"?

With our current workflow, mailing the status of your reviews here is
pretty much the only option.  ("I've reviewed issues a, b, c, d, and e,
could someone please review y?").

> Real world example with issue8151. It is an issue with a trivial patch
> in it. Everything what is needed is to dispatch it to stable `commit
> queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
> have no means to mark it as 'easy' either, so even this trivial fix
> lies in tracker for three days waiting for review.

Three days?  That's nothing :)

> About 'easy' flag:
> "6easyThis is an easy task (e.g. suitable for GHOP or bug day 
> beginners)"
> It seems that it is for the issue that requires a patch, but if the
> patch is already there and nobody wants to commit it - what should I
> do?

If an issue has a patch the 'easy' flag doesn't really apply any more,
but it doesn't always get deleted, either.

Issues that have a patch should get set to "patch review" stage, unless
tests are missing, in which case it should get set to "needs test".

Making changes like that (and also updating keywords) requires tracker
privileges, but we give those out more freely than we do commit privs.
You could try hanging out on #python-dev on Freenode, where there will
(usually) be people who can respond to your requests to update the status
of tracker issues.  Make enough good requests and we'll get you tracker
privs so you can do it yourself.  ("Enough" is probably a pretty small
number, by the way :)

> Finally, review queue proposal.
> To follow 5-1 rule, I need to review 5 issues, before mine is
> reviewed, so I need some help from tracker.
> 1. I lack expertise in certain areas (C/C++, Mac OS, etc.), so I would
> like to hide some issues under "Needs review" query, so they won't
> bother me (if too many people marked issues in this way - the stats
> may become a good reason for highly professional bug party)

To avoid issues involving C coding, try restricting your search to
'Library' issues.  There is C code in some library modules, but less so
than in the core ;).  It would be nice if you could search on more than
one component, but currently the interface doesn't allow that.  (You might
be able to do it by hand constructing a query string, I haven't checked.)

> 2. I need ability to set "Needs review" flag back. Some issues were
> once reviewed, but since then they've got modified and need further
> comments.  The need the review again. That means pushed back _into the
> end_ of patch queue.

I'm not sure exactly what the 'needs review' keyword is for, frankly :)
Talking about pushing things back into the end of the patch queue makes
the assumption that there *is* a queue.  There isn't, there's just the
set of open issues with patches that committers look at when they can or
when they have an itch to scratch.  Making a comment on an issue (such
as doing a review) generates an email to everyone on the nosy list and
to the python-bugs list (for those people who are subscribed), and thus
in a fashion brings the issue to the 'top of the pile' in some sense and
for a short period.  Often things happen to the issue when a comment is
posted, but not always.  As with everything else, it depends on whether
anyone has both the time and the interest to take action.

> 3. Setting bug dependency by users. Often nobody wants to care about
> issue, because it is just too long, there is much irrelevant comments
> and nobody has time to read it. We don't have personal digg-like
> comment filters to cope with the amount of text to be brain-loaded.
> But it is possible to refactor such issue thread into separate
> digestable issue/issues.
>
> P.S.  About personal comment filters if anybody is interested in that.
> Digg-like +1, -1 are good for voting, but for filtering it would be
> nice to: 1. have several filters for different aspects of the thread,
> 2. have JS filter by marking individual phrases in comments and adding
> ranges to filter using jquery / ajax

-1 on comment filtering.  The text in the issue is the history of the
issue.  Reading it is part of doing an issue review.  I can't imagine that
the effort of manually blocking certain comments so that you didn't see
them when later looking at the issue again would be worth it.  It seems
to me you'd be much more likely to accidentally block something you should
be reading than you would be to make the issue usefully more readable.

If an issue needs to be refactored, new issues can be opened with
pointers to the old issue, and pointers added to the old issue to the new.
This can be done b

Re: [Python-Dev] GSoC 2010 is on -- projects?

[Laurent Gautier]

On 3/19/10 12:57 PM, Arc Riley wrote:

Hi Laurent

If your community project would like help porting to Python 3, and you
feel this work is enough for a student to work full time for several
weeks on, then please do add it to the GSoC ideas page on the wiki.


Whether this is worth weeks of work or not will depend on a given 
student's knowledge about Python 3, and I'd suspect that the GSoC would 
be an opportunity for a number of applicant to actually learn the 
intricacies of Python 3.
Developing Python 3-specific features could be used to increase the 
amount of work on the project, but I am uncertain of whether this is 
worth a full GSoC.



There will be another program running for high school students which is
more suitable for smaller tasks (2-3 days each), more on-par with the
actual time it takes to port most Python packages.



My project is roughly 6000 lines of Python and 6000 lines of C (Mostly 
C-level Python API bindings). I tried porting to Python 3 in the past, 
and it went fast (less than a day). The hurdle is that this resulted in 
segfaults for a lot of string-related features (You know, the 
byte/string thing). Tracing issues at the C level can be time-consuming, 
so I am hesitating to claim that 2-3 days of an high-school student 
would be enough.



Could several ports be bundled in a GSoC (the target projects would be 
grouped by theme, somehow).



L.




On Fri, Mar 19, 2010 at 2:23 AM, Laurent Gautier mailto:lgaut...@gmail.com>> wrote:


Hi,


Does this mean that any other python project could potentially see
itself ported to Python 3 in the course of this SoC ? If so, can any
project owner submit a request for help, or is there going to be a
list of projects that would nice to port, or will a voting system of
some sort be put in place ?


Best,


Laurent

___
Python-Dev mailing list
Python-Dev@python.org 
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/arcriley%40gmail.com




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

[Adam Olsen]

On Thu, Mar 18, 2010 at 12:41, Mark Dickinson  wrote:
> I'm only seeing two arguments against this at the moment: (1) it has
> the potential to break code that relies on being able to sort
> heterogeneous lists.  But given that heterogeneous lists can't be
> sorted stably anyway (see my earlier post about lists containing ints,
> floats and Decimals), perhaps this is an acceptable risk. (2) A few of
> the posters here (Steven, Nick, and me) feel that it's slightly more
> natural to allow these comparisons;  but I think the argument's fairly
> evenly balanced at the moment between those who'd prefer an exception
> and those who'd prefer to allow the comparisons.

Conceptually I like the idea of them all being comparable, but are
there any real use cases involving heterogeneous lists?  All the
examples I've seen have focused on how they're broken, not on how
they'd be correct (including possible math after the comparison!) if
the language compared properly.

Without such use cases allowing comparison seems like a lot of work for nothing.


-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.

[Raymond Hettinger]

On Mar 19, 2010, at 4:50 AM, Antoine Pitrou wrote:

> Glenn Linderman  nevcal.com> writes:
>> 
>> On the other hand, if the default behavior is to do an implicit 
>> conversion, I don't know of any way that that could be turned into an 
>> exception for those coders that don't want or don't like the particular 
>> type of implicit conversion chosen.
> 
> You still haven't given a good reason why we should raise an exception rather
> than do a comparison, though.
> 
> The fact that some particular coders don't like "the particular type of 
> implicit
> conversion chosen" is a particularly weak argument. Python isn't a language
> construction framework; we try to choose useful defaults rather than simply 
> give
> out a box of tools. If some people don't like the defaults (significant
> indentation, limitless precision integers, etc.), there are other choices out 
> there.


The reason to prefer an exception is that decimal/float comparisons
are more likely to be a programmer error than an intended behavior.
Real use cases for decimal/float comparisons are rare and would
be more clearly expressed with an explicit conversion using 
Decimal.from_float().

Of course there is a precedent, I can compare "120" < 140 in AWK
and get an automatic implicit conversion ;-)  

Just because we can compare, doesn't mean we should.


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[A.M. Kuchling]

On Fri, Mar 19, 2010 at 10:22:05AM -0400, R. David Murray wrote:
> > Real world example with issue8151. It is an issue with a trivial patch
> > in it. Everything what is needed is to dispatch it to stable `commit
> > queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
> > have no means to mark it as 'easy' either, so even this trivial fix
> > lies in tracker for three days waiting for review.
> 
> Three days?  That's nothing :)

I think Anatoly has a point, though; there are issues where the people
discussing the fix have come to a consensus, but none of them are
committers, or the committers involved are too busy.  There's a patch
ready to apply, but no committer knows about it.

> To avoid issues involving C coding, try restricting your search to
> 'Library' issues.  There is C code in some library modules, but less so
> than in the core ;).  It would be nice if you could search on more than

Actually Library should pretty much always be pure-Python.  Issues
related to C modules such as socket are classified under the
'Extension modules' component.  Of course, sometimes the ultimate
cause will migrate (a bug in SocketServer.py is traced to a flaw in
socket, for example).

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[Terry Reedy]

On 3/19/2010 10:22 AM, R. David Murray wrote:


This can be done by anyone just by saying, eg: 'see issue 1234' (roundup
turns that into a link),


That should be 'see issue #1234' to get the autolink.
From http://wiki.python.org/moin/TrackerDocs/

The tracker converts some specially formatted words in messages into 
links. The list includes

  "#" links to the issue 
  "msg" links to the message 
  "r, "rev", "revision " links to 
svn.python.org displaying the checked in changes.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Joel Spolsky on Mercurial

[Terry Reedy]

On 3/19/2010 5:00 AM, Dirkjan Ochtman wrote:

On Thu, Mar 18, 2010 at 22:38, Terry Reedy  wrote:

Having gotten that far, I think this might be worth referencing in new dev
docs.


Will do. I finally read hginit yesterday, after having seen people
rave about it on twitter for a few weeks, and it's a very friendly
introduction.


Having read further 'lessons', you might also want to note that the 
Python group workflow differs (and briefly how so) from that given as a 
possibility, assuming that it does.


Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] binary operation heuristics -- bug or undocumented?

[Terry Reedy]

On 3/19/2010 8:46 AM, Alex A. Naanou wrote:


A friend of mine stumbled upon the following behavior:

[snip]
Questions like this are more appropriately posted to python-list, where 
you would have gotten the same answer.


tjr


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal &amp; lt; -&am p; gt; float comparisons in py3k.

[Antoine Pitrou]

Raymond Hettinger  gmail.com> writes:
> 
> The reason to prefer an exception is that decimal/float comparisons
> are more likely to be a programmer error than an intended behavior.

Not more so than float/int or decimal/int or bool/int comparisons, which all 
work.

We forbid comparisons when there is a real danger or ambiguity, such as unicode
vs. bytes. There is no such danger or ambiguity when comparing a decimal with a
float. I don't see the point of being so restrictive; Python is not Java, and
typing is not supposed to be a synonym for bondage.

> Of course there is a precedent, I can compare "120" < 140 in AWK
> and get an automatic implicit conversion

The proper precedent in this context, though, is this one (py3k):

>>> 1 < 2.0
True
>>> 1 < Decimal("2.0")
True
>>> 1 > Decimal("2.0")
False
>>> 1 > 2.0
False
>>> True > 0.5
True
>>> True > 1.5
False
>>> True > Decimal("0.5")
True
>>> True > Decimal("1.5")
False

Are you suggesting to change all the above comparisons to raise a TypeError?

cheers

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[Zvezdan Petkovic]

On Mar 19, 2010, at 1:15 PM, Terry Reedy wrote:

> On 3/19/2010 10:22 AM, R. David Murray wrote:
> 
>> This can be done by anyone just by saying, eg: 'see issue 1234' (roundup
>> turns that into a link),
> 
> That should be 'see issue #1234' to get the autolink.
> From http://wiki.python.org/moin/TrackerDocs/

The list in the docs is not complete then.
David is right.  The words 'issue 1234' will become a link in roundup 
automatically.  As well as 'issue1234'.

Zvezdan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Raymond Hettinger]

On Mar 19, 2010, at 11:11 AM, Antoine Pitrou wrote:

> Raymond Hettinger  gmail.com> writes:
>> 
>> The reason to prefer an exception is that decimal/float comparisons
>> are more likely to be a programmer error than an intended behavior.
> 
> Not more so than float/int or decimal/int or bool/int comparisons, which all 
> work.

The float/int and decimal/int comparisons have valid and common use cases.
In contrast, comparing binary floats and decimal floats is rare, and more 
likely to be an accident.

When an int is converted to a float or decimal, the result usually isn't
surprising.  The conversion of a float to a decimal is not as straight-forward
(most people don't even know that an exact conversion is possible).

Also, the float and decimal constructors also natively accept ints as inputs,
but the decimal constructor intentionally excludes a float input.


Raymond



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.

[Glenn Linderman]

On 3/19/2010 4:50 AM, Antoine Pitrou wrote:

Glenn Linderman  nevcal.com>  writes:
   

On the other hand, if the default behavior is to do an implicit
conversion, I don't know of any way that that could be turned into an
exception for those coders that don't want or don't like the particular
type of implicit conversion chosen.
 

You still haven't given a good reason why we should raise an exception rather
than do a comparison, though.

The fact that some particular coders don't like "the particular type of implicit
conversion chosen" is a particularly weak argument. Python isn't a language
construction framework; we try to choose useful defaults rather than simply give
out a box of tools. If some people don't like the defaults (significant
indentation, limitless precision integers, etc.), there are other choices out
there.
   


The whole point of providing Decimal is for applications for which float 
is inappropriate.  I didn't think I needed to reproduce PEP 327 in my email.


So when a coder choose to use Decimal, it is because float is 
inappropriate.  Because float is inappropriate, mixing Decimal and float 
is inappropriate.  Having the language coerce implicitly, is 
inappropriate.  All this is in the PEP.  Note that the PEP actually says 
that the problem is not doing implicit arithmetic (as some have reported 
in this thread) but in doing implicit coercions.  In order to do 
implicit comparisons, one must do an implicit coercion.  Hence the PEP 
actually already prohibits implicit comparisons, as well as implicit 
arithmetic.


Now the proposal is to start down the slippery slope by allowing 
comparisons.  To start with, neither decimal nor float comparisons, are, 
in general, exact. (Although it is more common for decimal calculations 
to contain the code to do rounding and significant digit calculations 
than float code, due to its use in monetary calculations.  People that 
don't care about the precision tend to just use float, and no 
significant digit concerns are coded.)  Comparisons need to be done with 
full knowledge of the precision of the numbers.  The additional 
information necessary to do so cannot be encoded in a binary operator.


People that do care about precision would rather not have imprecise data 
introduced by accidentally forgetting to include a coercion constructor, 
and have it implicitly converted; hence, the exception is much better 
for them.


My original message pointed out that providing an exception solves the 
problem for people that care about precision, and doesn't hinder a 
solution (only a convenience) for people that somehow bothered to use 
Decimal but then suddenly lost interest in doing correct math.  For 
those people, the class I proposed can workaround the existence of the 
exception, so the language can better serve both types of people, those 
that care, and those that don't.


My personal opinion is that real applications that use Decimal are much 
more likely to care, and much more likely to appreciate the exception, 
whereas applications that don't care, aren't likely to use Decimal in 
the first place, and so won't encounter the problem anyway.  And if they 
do, for some reason, hop on the Decimal bandwagon, then it seems to be a 
simple matter to implement a class with implicit conversions using 
whatever parameters they choose to implement, for their sloppy endeavors.


Yes, if implicit coercions for comparisons exist, it is possible to 
write code that avoids using them... but much friendlier for people that 
wish to avoid them, if the exception remains in place, unless explicitly 
sidestepped through coding another class.


Implementing an exception for Decimal/float comparison attempts, rather 
than comparing their types, is a giant step forward.  Implementing an 
implicit coercion for Decimal/float comparisons is a step down a 
slippery slope, to reduce the benefits of Decimal for its users.


Glenn



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Terry Reedy]

On 3/19/2010 2:11 PM, Antoine Pitrou wrote:

Raymond Hettinger  gmail.com>  writes:


The reason to prefer an exception is that decimal/float comparisons
are more likely to be a programmer error than an intended behavior.


If you really believe that, then equality comparisons should also be 
disabled by raising NotImplemented or whatever. Clearly, someone who 
writes 'if somefloat == somedecimal:'assumes (now wrongly) that the test 
might be true. This is just as buggy as an order comparison. Raising an 
exception would consistently isolate decimals from other numbers and 
eliminate the equality intransitivity mess and its nasty effect on sets.


It still strikes me as a bit crazy for Python to say that 0.0 == 0 and 0 
== Decimal(0) but that 0.0 != Decimal(0). Who would expect such a thing?


Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.

[Raymond Hettinger]

On Mar 19, 2010, at 11:42 AM, Glenn Linderman wrote:
>> 
> 
> The whole point of providing Decimal is for applications for which float is 
> inappropriate.  I didn't think I needed to reproduce PEP 327 in my email.
> 
> So when a coder choose to use Decimal, it is because float is inappropriate.  
> Because float is inappropriate, mixing Decimal and float is inappropriate.  
> Having the language coerce implicitly, is inappropriate.  All this is in the 
> PEP.  Note that the PEP actually says that the problem is not doing implicit 
> arithmetic (as some have reported in this thread) but in doing implicit 
> coercions.  In order to do implicit comparisons, one must do an implicit 
> coercion.  Hence the PEP actually already prohibits implicit comparisons, as 
> well as implicit arithmetic.

Well said.


Raymond___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Antoine Pitrou]

Glenn Linderman  g.nevcal.com> writes:
> 
> So when a coder choose to use Decimal, it is because float is 
> inappropriate.  Because float is inappropriate, mixing Decimal and float 
> is inappropriate.  Having the language coerce implicitly, is 
> inappropriate.

I'm sorry but this is very dogmatic. What is the concrete argument against an
accurate comparison between floats and decimals?

> Comparisons need to be done with 
> full knowledge of the precision of the numbers.  The additional 
> information necessary to do so cannot be encoded in a binary operator.

This doesn't have anything to do with the mixing of floats and decimals, though,
since it also applies to unmixed comparisons. Again, is there an argument
specific to mixed comparisons?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal &amp; amp; lt; -&a mp;amp; amp; gt; float comparisons in py3k.

[Antoine Pitrou]

Raymond Hettinger  gmail.com> writes:
> 
> The conversion of a float to a decimal is not as straight-forward
> (most people don't even know that an exact conversion is possible).

I still don't follow you. You are saying that an exact conversion is possible,
but don't want it to be done because it is "not as straight-forward"?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Glenn Linderman]

On 3/19/2010 11:43 AM, Terry Reedy wrote:

On 3/19/2010 2:11 PM, Antoine Pitrou wrote:

Raymond Hettinger  gmail.com>  writes:


The reason to prefer an exception is that decimal/float comparisons
are more likely to be a programmer error than an intended behavior.


If you really believe that, then equality comparisons should also be 
disabled by raising NotImplemented or whatever. 


Totally agree.  While the example most used in this thread is a less 
than operator, the text of the thread has never (as far as I have read) 
distinguished between equality, inequality, or relative signed magnitude 
comparisons.  Sort has also been mentioned explicitly as an example.  I 
perceive that the whole thread is about _all_ comparison operators with 
one float and one decimal operand currently producing an exception (3.x) 
or a type-based ordering (2.x).


The type-based ordering has been demonstrated to produce unstable sorts 
in the presence of other types also, so is more of a problem than first 
perceived, and should be changed.



Clearly, someone who writes 'if somefloat == somedecimal:'assumes (now 
wrongly) that the test might be true. This is just as buggy as an 
order comparison. Raising an exception would consistently isolate 
decimals from other numbers and eliminate the equality intransitivity 
mess and its nasty effect on sets.


Totally agree.


It still strikes me as a bit crazy for Python to say that 0.0 == 0 and 
0 == Decimal(0) but that 0.0 != Decimal(0). Who would expect such a 
thing?


The same person that would expect both

0 == "0"
0.0 == "0.0"

to be False... i.e. anyone that hasn't coded in Perl for too many years.

Glenn

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Attribute lookup ambiguity

[Pascal Chambon]

Hello

I've already crossed a bunch of articles detailing python's attribute 
lookup semantic (__dict__, descriptors, order of base class 
traversing...), but I have never seen, so far, an explanation of WHICH 
method did waht, exactly.


I assumed that getattr(a, b) was the same as a.__getattribute__(b), and 
that this __getattribute__ method (or the hidden routine replacing it 
when we don't override it in our class) was in charge of doing the whole 
job of traversing the object tree, checking descriptors, binding 
methods, calling __getattr__ on failure etc.


However, the test case below shows that __getattribute__ does NOT call 
__getattr__ on failure. So it seems it's an upper levl machinery, in 
getattr(), which is in chrge of that last action.


Is that on purpose ? Considering that __getattribute__ (at lest, 
object.__getattribute__) does 90% of the hard job, why are these 10% left ?
Can we find somewhere the details of "who must do what" when customizing 
attribute access ?
Shouldn't we inform people about the fact that __getattribute__ isn't 
sufficient in itself to lookup an attribute ?


Thanks for the attention,
regards,
Pascal



===
INPUT
===

class A(object):

   def __getattribute__(self, name):
   print "A getattribute", name
   return object.__getattribute__(self, name)

   def __getattr__(self, name):
   print "A getattr", name
   return "hello A"


class B(A):


   def __getattribute__(self, name):
   print "B getattribute", name
   return A.__getattribute__(self, name)

   
   def __getattr__(self, name):

   print "B getattr", name
   return "hello B"
   
   


print A().obj
print "---"
print B().obj
print "---"
print getattr(B(), "obj")
print "-"
print object.__getattribute__(B(), "obj") # DOES NOT CALL __getattr__() !!!


===
OUTPUT
===

A getattribute obj
A getattr obj
hello A
---
B getattribute obj
A getattribute obj
B getattr obj
hello B
---
B getattribute obj
A getattribute obj
B getattr obj
hello B
-
Traceback (most recent call last):
 File "C:\Users\Pakal\Desktop\test_object_model.py", line 34, in 
   print object.__getattribute__(B(), "obj") # DOES NOT CALL 
__getattr__() !!!???

AttributeError: 'B' object has no attribute 'obj'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.1.2 tagging delayed a little

[Brett Cannon]

On Thu, Mar 18, 2010 at 20:20, Benjamin Peterson  wrote:
> Pending the resolution of a few Mac OS issues (#8068, #8069, and
> #8133), I'm not going to tag the release at the moment. Hopefully,
> we'll still be able to have a release in the next week.

Do you want issue8133 to be a release blocker? If you do I can make
sure it passes by the end of this weekend.

-Brett


>
> --
> Regards,
> Benjamin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[R. David Murray]

On Fri, 19 Mar 2010 14:09:28 -0400, Zvezdan Petkovic  wrote:
> On Mar 19, 2010, at 1:15 PM, Terry Reedy wrote:
> > On 3/19/2010 10:22 AM, R. David Murray wrote:
> >> This can be done by anyone just by saying, eg: 'see issue 1234' (roundup
> >> turns that into a link),
> > 
> > That should be 'see issue #1234' to get the autolink.
> > From http://wiki.python.org/moin/TrackerDocs/
> 
> The list in the docs is not complete then.
> David is right.  The words 'issue 1234' will become a link in roundup 
> automatically.  As well as 'issue1234'.

I've updated the wiki page.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[R. David Murray]

On Fri, 19 Mar 2010 12:39:58 -0400, "A.M. Kuchling"  wrote:
> On Fri, Mar 19, 2010 at 10:22:05AM -0400, R. David Murray wrote:
> > > Real world example with issue8151. It is an issue with a trivial patch
> > > in it. Everything what is needed is to dispatch it to stable `commit
> > > queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
> > > have no means to mark it as 'easy' either, so even this trivial fix
> > > lies in tracker for three days waiting for review.
> > 
> > Three days?  That's nothing :)
> 
> I think Anatoly has a point, though; there are issues where the people
> discussing the fix have come to a consensus, but none of them are
> committers, or the committers involved are too busy.  There's a patch
> ready to apply, but no committer knows about it.

Yes, this is a general problem with the workflow.

This is one reason for the creation of the 'committers.rst' file in py3k:
submitters can find committers there to add to the nosy list of issues
that are ready for commit, so that they do notice.

However, as you note, sometimes 'ready' bugs sit in the tracker for
a while even when one or more committers is already nosy.  As someone
else said, that's the nature of a volunteer driven process.  The best
solution as far as I know is to expand the pool of volunteers, so I
hope Anatoloy is inspired to continue to contribute so he can eventually
become a committer!

> > To avoid issues involving C coding, try restricting your search to
> > 'Library' issues.  There is C code in some library modules, but less so
> > than in the core ;).  It would be nice if you could search on more than
> 
> Actually Library should pretty much always be pure-Python.  Issues
> related to C modules such as socket are classified under the
> 'Extension modules' component.  Of course, sometimes the ultimate
> cause will migrate (a bug in SocketServer.py is traced to a flaw in
> socket, for example).

Good point.  Or at least, that's the theory.  In practice bugs sometimes
get miscategorized.  So, Anatoly, if you find bugs like that you can ask that
they be properly recategorized.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Mark Dickinson]

On Fri, Mar 19, 2010 at 6:43 PM, Terry Reedy  wrote:
> On 3/19/2010 2:11 PM, Antoine Pitrou wrote:
>>
>> Raymond Hettinger  gmail.com>  writes:
>>>
>>> The reason to prefer an exception is that decimal/float comparisons
>>> are more likely to be a programmer error than an intended behavior.
>
> If you really believe that, then equality comparisons should also be
> disabled by raising NotImplemented or whatever.

Hah.  This is a very good point, and one I'd somehow missed up until
now.  I don't think we *can* reasonably make equality comparisons
raise NotImplemented (in either 2.x or 3.x), since that messes up
containment tests:  something like "1.0 in {2, Decimal(3)}" would
raise a TypeError instead of correctly returning False.  (So the patch
I've put on the issue tracker is wrong, since it does raise TypeError
for equality and inequality, as well as for <, >, <= and >=.)

> Clearly, someone who writes
> 'if somefloat == somedecimal:'assumes (now wrongly) that the test might be
> true. This is just as buggy as an order comparison. Raising an exception
> would consistently isolate decimals from other numbers and eliminate the
> equality intransitivity mess and its nasty effect on sets.
>
> It still strikes me as a bit crazy for Python to say that 0.0 == 0 and 0 ==
> Decimal(0) but that 0.0 != Decimal(0). Who would expect such a thing?

Agreed.  A solution to the original problem that still has 0.0 ==
Decimal(0) evaluating to False isn't much of a solution.

This puts me firmly in the 'make numeric comparisons give the right
answer' camp.

Thanks,

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Mark Dickinson]

On Fri, Mar 19, 2010 at 7:50 PM, Mark Dickinson  wrote:
> So the patch
> I've put on the issue tracker is wrong, since it does raise TypeError ...

s/I've put/I have yet to put/

I really shouldn't admit to errors in things that I haven't even been
made public yet.  :)

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Glenn Linderman]

On 3/19/2010 12:50 PM, Mark Dickinson wrote:

Hah.  This is a very good point, and one I'd somehow missed up until
now.  I don't think we*can*  reasonably make equality comparisons
raise NotImplemented (in either 2.x or 3.x), since that messes up
containment tests:  something like "1.0 in {2, Decimal(3)}" would
raise a TypeError instead of correctly returning False.  (So the patch
I've put on the issue tracker is wrong, since it does raise TypeError
for equality and inequality, as well as for<,>,<= and>=.)
   


Sounds to me like containment checking is wrong; that if it gets an 
exception during the comparison that it should assume unequal, rather 
than aborting, and continue to the next entry.


Wouldn't the same issue arise for containment tests when disparate, 
incomparable objects are included in the same set?  Why is this different?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Attribute lookup ambiguity

[Michael Foord]

On 19/03/2010 18:58, Pascal Chambon wrote:

Hello

I've already crossed a bunch of articles detailing python's attribute 
lookup semantic (__dict__, descriptors, order of base class 
traversing...), but I have never seen, so far, an explanation of WHICH 
method did waht, exactly.


I assumed that getattr(a, b) was the same as a.__getattribute__(b), 
and that this __getattribute__ method (or the hidden routine replacing 
it when we don't override it in our class) was in charge of doing the 
whole job of traversing the object tree, checking descriptors, binding 
methods, calling __getattr__ on failure etc.


However, the test case below shows that __getattribute__ does NOT call 
__getattr__ on failure. So it seems it's an upper levl machinery, in 
getattr(), which is in chrge of that last action.


Python 3 has the behavior you are asking for. It would be a backwards 
incompatible change to do it in Python 2 as __getattribute__ *not* 
calling __getattr__ is the documented behaviour.


Python 3.2a0 (py3k:78770, Mar 7 2010, 20:32:50)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
>>> class x:
... def __getattribute__(s, name):
... print ('__getattribute__', name)
... raise AttributeError
... def __getattr__(s, name):
... print ('__getattr__', name)
...
>>> a = x()
>>> a.b
__getattribute__ b
__getattr__ b


This list is not really an appropriate place to ask questions like this 
though, comp.lang.python would be better.


All the best,

Michael Fooord



Is that on purpose ? Considering that __getattribute__ (at lest, 
object.__getattribute__) does 90% of the hard job, why are these 10% 
left ?
Can we find somewhere the details of "who must do what" when 
customizing attribute access ?
Shouldn't we inform people about the fact that __getattribute__ isn't 
sufficient in itself to lookup an attribute ?


Thanks for the attention,
regards,
Pascal



===
INPUT
===

class A(object):

def __getattribute__(self, name):
print "A getattribute", name
return object.__getattribute__(self, name)

def __getattr__(self, name):
print "A getattr", name
return "hello A"


class B(A):


def __getattribute__(self, name):
print "B getattribute", name
return A.__getattribute__(self, name)

def __getattr__(self, name):
print "B getattr", name
return "hello B"

print A().obj
print "---"
print B().obj
print "---"
print getattr(B(), "obj")
print "-"
print object.__getattribute__(B(), "obj") # DOES NOT CALL 
__getattr__() !!!



===
OUTPUT
===

A getattribute obj
A getattr obj
hello A
---
B getattribute obj
A getattribute obj
B getattr obj
hello B
---
B getattribute obj
A getattribute obj
B getattr obj
hello B
-
Traceback (most recent call last):
File "C:\Users\Pakal\Desktop\test_object_model.py", line 34, in 
print object.__getattribute__(B(), "obj") # DOES NOT CALL 
__getattr__() !!!???

AttributeError: 'B' object has no attribute 'obj'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk 




--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[R. David Murray]

On Fri, 19 Mar 2010 12:16:35 -0700, Glenn Linderman  
wrote:
> On 3/19/2010 11:43 AM, Terry Reedy wrote:
> > It still strikes me as a bit crazy for Python to say that 0.0 == 0 and 
> > 0 == Decimal(0) but that 0.0 != Decimal(0). Who would expect such a 
> > thing?
> 
> The same person that would expect both
> 
> 0 == "0"
> 0.0 == "0.0"
> 
> to be False... i.e. anyone that hasn't coded in Perl for too many years.

No, those two situations are not comparable.

"if a equals b and b equals c, then a equals c" is what most people
will expect.  In fact, only mathematicians are likely to know
that any other situation could possibly be valid.  Programmers are
generally going to view it as a bug.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.1.2 tagging delayed a little

[Benjamin Peterson]

2010/3/19 Brett Cannon :
> On Thu, Mar 18, 2010 at 20:20, Benjamin Peterson  wrote:
>> Pending the resolution of a few Mac OS issues (#8068, #8069, and
>> #8133), I'm not going to tag the release at the moment. Hopefully,
>> we'll still be able to have a release in the next week.
>
> Do you want issue8133 to be a release blocker? If you do I can make
> sure it passes by the end of this weekend.

That would be wonderful.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; amp; lt; -& amp; amp; gt; float comparisons in py3k.

[Guido van Rossum]

Antoine, I think your email client turns replies whose subject
contains '&' into new subjects containing sequences like this:

  & amp; lt; -& amp; gt;

There's a number of new threads with ever-more occurrences of "amp" in
the subject, and you are the first poster in each thread (and the
first post's subject already starts with "Re:").

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] "expected a character buffer object" messages

[aditya bhargava]

I found an old thread on Python-Dev that suggested replacing the error
"TypeError: expected a character buffer object" with something more helpful
for non-experts like "expected a string or character buffer". Here's the
thread: http://mail.python.org/pipermail/python-dev/2006-May/065301.html

I think this is an excellent idea, but besides this ticket:
http://bugs.python.org/issue6780
I haven't seen anything further about it. Does anyone know the status on
this? It would be nice to have a more descriptive error.

Aditya
-- 
wefoundland.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal [...] float comparisons in py3k.

[Antoine Pitrou]

Guido van Rossum  python.org> writes:
> 
> Antoine, I think your email client turns replies whose subject
> contains '&' into new subjects containing sequences like this:
> 
>   & amp; lt; -& amp; gt;
> 
> There's a number of new threads with ever-more occurrences of "amp" in
> the subject, and you are the first poster in each thread (and the
> first post's subject already starts with "Re:").

Hmm, indeed. It's the gmane Web posting interface, actually.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Mixing float and Decimal -- thread reboot

[Guido van Rossum]

I'd like to reboot this thread. I've been spinning this topic in my
head for most of the morning, and I think we should seriously
reconsider allowing mixed arithmetic involving Decimal, not just mixed
comparisons. [Quick summary: embed Decimal in the numeric tower but
add a context flag to disallow implicit mixing of float and Decimal.]

I tried to find the argumentation against it in PEP 327 (Decimal Data
Type) and found that it didn't make much of an argument against mixed
arithmetic beyond "it's not needed" and "it's not urgent". (It even
states that initially Decimal.from_float() was omitted for simplicity
-- but it got added later.)

We now also have PEP 3141 (A Type Hierarchy for Numbers) which
proposes a numeric tower. It has an explicit exclusion for Decimal,
but that exclusion is provisional: "After consultation with its
authors it has been decided that the ``Decimal`` type should not at
this time be made part of the numeric tower." That was a compromise
because at the time some contributors to Decimal were fiercely opposed
to including Decimal into the numeric tower, and I didn't want to have
a endless discussion at the time (there were many more pressing issues
to be resolved).

However now the subject is coming up again, and my gut keeps telling
me that Decimal ought to be properly embedded in Python's numeric
tower. Decimal is already *touching* the numeric tower by allowing
mixed arithmetic with ints. This causes the anomaly that Mark
mentioned earlier: the three values 1, 1.0 and Decimal(1) do not
satisfy the rule "if x == y and y == z then it follows that x == z".
We have 1.0 == 1 == Decimal(1) but 1 == 1.0 != Decimal(1). This also
causes problems with hashing, where {Decimal(1), 1, 1.0} !=
{Decimal(1), 1.0, 1}.

I'd like to look at the issue by comparing the benefits and drawbacks
of properly embedding Decimal into the numeric tower. As advantages, I
see consistent behavior in situations like the above and more
intuitive behavior for beginners. Also, this would be a possible road
towards eventually supporting a language extension where floating
point literals produce Decimal values instead of binary floats. (A
possible syntax could be "from __options__ import decimal_float",
which would work similar to "from __future__ import ..." except it's a
permanent part of the language rather than a forward compatibility
feature.)

As a downside, there is the worry that inadvertent mixing of Decimal
and float can compromise the correctness of programs in a way that is
hard to detect. But the anomalies above indicate that not fixing the
situation can *also* compromise correctness in a similar way. Maybe a
way out would be to add a new flag to the decimal Context class
indicating whether to disallow mixing Decimal and float -- that way
programs that care about this can force the issue, while the default
behavior can be more intuitive. Possibly the flag should not affect
comparisons.

There is one choice which I'm not sure about. Should a mixed
float/Decimal operation return a float or a Decimal? I note that
Fraction (which *is* properly embedded in the numeric tower) supports
this and returns a float result in this case. While I earlier proposed
to return the most "complicated" type of the two, i.e. Decimal, I now
think it may also make sense to return a float, being the most "fuzzy"
type in the numeric tower. This would also make checking for
accidental floats easier, since floats now propagate throughout the
computation (like NaN) and a simple assertion that the result is a
Decimal instance suffices to check that no floats were implicitly
mixed into the computation.

The implementation of __hash__ will be complicated, and it may make
sense to tweak the hash function of float, Fraction and Decimal to
make it easier to ensure that for values that can be represented in
either type the hash matches the equality. But this sounds a
worthwhile price to pay for proper embedding in the numeric tower.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Antoine Pitrou]

Glenn Linderman  g.nevcal.com> writes:
> 
> Sounds to me like containment checking is wrong; that if it gets an
> exception during the comparison that it should assume unequal, rather
> than aborting, and continue to the next entry.

Well as the Zen says:

Errors should never pass silently.
Unless explicitly silenced.

If there's a bug in your __eq__ method, rather than getting wrong containment
results, you get the proper exception.

> Wouldn't the same issue arise for containment tests when disparate,
> incomparable objects are included in the same set?  Why is this
> different?

That's why equality testing almost never fails between standard types. We do
have an (IMO unfortunate) exception in the datetime module, though:

>>> from datetime import tzinfo, timedelta, datetime
>>> ZERO = timedelta(0)
>>> class UTC(tzinfo): # UTC class ripped off from the official doc
... """UTC"""
... def utcoffset(self, dt):
... return ZERO
... def tzname(self, dt):
... return "UTC"
... def dst(self, dt):
... return ZERO
... 
>>> utc = UTC()
>>> a = datetime.now()
>>> b = datetime.now(utc)
>>> a == b
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't compare offset-naive and offset-aware datetimes


Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

[Raymond Hettinger]

On Mar 19, 2010, at 2:50 PM, Guido van Rossum wrote:

> I'd like to reboot this thread. I've been spinning this topic in my
> head for most of the morning, and I think we should seriously
> reconsider allowing mixed arithmetic involving Decimal, not just mixed
> comparisons. [Quick summary: embed Decimal in the numeric tower but
> add a context flag to disallow implicit mixing of float and Decimal.]


Making decimals first class citizens would sure help eliminate 
some special cases and anomalies. 

If a context flag were added, am wondering whether it should simply
provide a warning rather than flat-out disallowing the transaction.
The whole point is to highlight accidental mixing.

If the mixed arithmetic were allowed, then the decimal constructor
should be changed to match (i.e. accept float inputs instead of
requiring Decimal.from_float()).


Raymond


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] RELEASED Python 2.6.5

[Barry Warsaw]

On behalf of the Python community, I'm happy to announce the availability of
Python 2.6.5 final.  This is the latest production-ready version in the Python
2.6 series.

Python 2.6.5 fixes dozens of issues in the core, built-in modules, libraries,
and documentation since Python 2.6.4 was released back in October 2009.  We
highly recommend that you upgrade to Python 2.6.5.

Please see the NEWS file for all the gory details.

http://www.python.org/download/releases/2.6.5/NEWS.txt

Source tarballs and the Windows installers can be downloaded from the Python
2.6.5 page.  The Mac OS X disk image will be uploaded soon.

http://www.python.org/download/releases/2.6.5/

For more information on Python 2.6 in general, please see

http://docs.python.org/whatsnew/2.6.html

Please report bugs for any Python version in the Python tracker.

http://bugs.python.org

Enjoy,
-Barry

Barry Warsaw
ba...@python.org
Python 2.6 Release Manager
(on behalf of the entire python-dev team)


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GSoC 2010 is on -- projects?

[Martin v. Löwis]

> Whether this is worth weeks of work or not will depend on a given
> student's knowledge about Python 3, and I'd suspect that the GSoC would
> be an opportunity for a number of applicant to actually learn the
> intricacies of Python 3.
> Developing Python 3-specific features could be used to increase the
> amount of work on the project, but I am uncertain of whether this is
> worth a full GSoC.

I'd say this would definitely make a GSoC project; any non-trivial
porting will be.

As you get experienced with porting, it can indeed go fairly quickly.
However, the learning curve is not to be underestimated: the first few
changes will rather be in the "one change per week" range.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Terry Reedy]

On 3/19/2010 3:16 PM, Glenn Linderman wrote:


I perceive that the whole thread is about _all_ comparison operators with
one float and one decimal operand currently producing an exception (3.x)


Not true for equality comparison. That returns False regardless of 
value, just as order comparisons return what they do in 2.x regardless 
of value. I claim that the former is at least as bad as the latter for 
numbers.



or a type-based ordering (2.x).


3.x mixes type-based and value-based equality testing for Decimals and 
other numbers.


Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

[Mark Dickinson]

Just a couple of quick side comments on this;  I haven't got my head
around the whole mixed-operations idea yet.

On Fri, Mar 19, 2010 at 9:50 PM, Guido van Rossum  wrote:
> There is one choice which I'm not sure about. Should a mixed
> float/Decimal operation return a float or a Decimal?

I'll just say that it's much easier to return a Decimal if you want to
be able to make guarantees about rounding behaviour, basically because
floats can be converted losslessly to Decimals.  I also like the fact
that the decimal module offers more control (rounding mode, precision,
flags, wider exponent range) than float.

In general, the correct semantics for an arithmetic operation are to
produce a result that's equivalent to what would have been obtained by
performing the operation to infinite precision and then doing a single
round to fit that result into the output type format.  This is
trivially easy to do if mixed float and Decimal operations produce
Decimal, and much much harder if they produce floats;  if mixed-type
operations produced floats we'd probably have to go with algorithms
that involve two rounds (i.e., first coerce the Decimal to a float,
then do the operation as usual on the two floats), and there would
likely be some (small) numeric surprises as a result.

> The implementation of __hash__ will be complicated, and it may make
> sense to tweak the hash function of float, Fraction and Decimal to
> make it easier to ensure that for values that can be represented in
> either type the hash matches the equality. But this sounds a
> worthwhile price to pay for proper embedding in the numeric tower.

I don't think this is going to be a problem.  I've implemented most of
the scheme I outlined earlier (it's working for ints, floats and
Decimals;  still need to implement it for Fractions and complex
numbers) and it seems to work just fine, with essentially no more code
than was there before.  I'll post a proof-of-concept patch when I've
filled in the missing bits.

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

[Facundo Batista]

On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum  wrote:

> As a downside, there is the worry that inadvertent mixing of Decimal
> and float can compromise the correctness of programs in a way that is
> hard to detect. But the anomalies above indicate that not fixing the

Decimal already has something that we can use in this case, and fits
very nice here: Signals.

Signals represent conditions that arise during computation. Each
corresponds to one context flag and one context trap enabler.

So, if we add a signal like "MixedWithFloats", users will have a flag
in the context that they could check to see if a float was mixed in
the operations executed (and if the user set the trap accordingly, an
exception will be raised when the signal happens).

OTOH, returning a float the first time both are mixed is easy to
check... but if it has downsides, and we prefer to return a Decimal in
that case, note that we have a mechanism in Decimal we can use.

Furthermore, in case we want to ease the transition we can do the following:

- add this signal

- set *by default* the trap to raise an exception when float and
Decimal is mixed

So, the behaviour will be the same as we have now, but users can
easily change it.

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Glenn Linderman]

On 3/19/2010 3:02 PM, Antoine Pitrou wrote:

Glenn Linderman  g.nevcal.com>  writes:
   
>  
>  Sounds to me like containment checking is wrong; that if it gets an

>  exception during the comparison that it should assume unequal, rather
>  than aborting, and continue to the next entry.
 

Well as the Zen says:

Errors should never pass silently.
Unless explicitly silenced.

If there's a bug in your __eq__ method, rather than getting wrong containment
results, you get the proper exception.
   


If there's a bug in your __eq__ method, it may or may not raise an 
exception, which may or may not get you wrong containment results.  But 
it will probably get you buggy results, somehow or another.  That's what 
design, code reviews, and testing are for.


If the your __eq__ method uses exceptions (the only available method of 
out-of-band signalling for binary operators; not all exceptions are 
errors) to declare that it can't perform the comparison and produce a 
boolean result, that is a case where producing an exception is not an 
error, so your quoted Zen doesn't apply.


Glenn

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Antoine Pitrou]

Glenn Linderman  g.nevcal.com> writes:
> 
> If there's a bug in your __eq__ method, it may or may not raise an 
> exception, which may or may not get you wrong containment results.  But 
> it will probably get you buggy results, somehow or another.  That's what 
> design, code reviews, and testing are for.

We'll have to "agree to disagree" then. If you want error silencing by default,
Python is not the language you are looking for.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

[Greg Ewing]

Nick Coghlan wrote:

Mark Dickinson wrote:



It seems to me that given the existing conflation of numeric equivalence
and containment testing, going the whole hog and fixing the set
membership problem for all of our rational types would be the right
thing to do.


Isn't this only solving half the problem, though? Even if
you find that the hashes are equal, you still have to decide
whether the values themselves are equal.

Is there some similarly clever way of comparing two
rational numbers without having explicit access to the
numerators and denominators?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

[Glenn Linderman]

On 3/19/2010 2:50 PM, Guido van Rossum wrote:

I'd like to reboot this thread.


I'll go along with that idea!



  I've been spinning this topic in my
head for most of the morning, and I think we should seriously
reconsider allowing mixed arithmetic involving Decimal, not just mixed
comparisons. [Quick summary: embed Decimal in the numeric tower but
add a context flag to disallow implicit mixing of float and Decimal.]
   


As long as there is a way to avoid implicit mixing of float and Decimal, 
or to easily detect (preferably with an exception) the implicit mixing, 
then I think that solves the concerns of people trying to write 
numerically correct code using Decimal.  And if Mark (or someone) can 
solve the hashing anomoly problem without huge expense, then it could be 
a winner.



I tried to find the argumentation against it in PEP 327
   


Should Aahz be consulted, as some of the objections in PEP 327 are 
attributed to him, but he is pretty scarce around here these days?



Also, this would be a possible road
towards eventually supporting a language extension where floating
point literals produce Decimal values instead of binary floats. (A
possible syntax could be "from __options__ import decimal_float",
which would work similar to "from __future__ import ..." except it's a
permanent part of the language rather than a forward compatibility
feature.)
   


Nice touch here... rather than being forced to quote Decimal values as 
strings and convert from string, or use a tuple to represent the parts, 
both of which are warts.  Not sure what context would be used, though.


Glenn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Glenn Linderman]

On 3/19/2010 4:58 PM, Antoine Pitrou wrote:

Glenn Linderman  g.nevcal.com>  writes:
   
>  
>  If there's a bug in your __eq__ method, it may or may not raise an

>  exception, which may or may not get you wrong containment results.  But
>  it will probably get you buggy results, somehow or another.  That's what
>  design, code reviews, and testing are for.
 

We'll have to "agree to disagree" then. If you want error silencing by default,
Python is not the language you are looking for.
   


We can agree to disagree, if you like.  But taken to the limit, the Zen 
you quoted would prevent the try except clause from being used.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Greg Ewing]

Antoine Pitrou wrote:


We forbid comparisons when there is a real danger or ambiguity, such as unicode
vs. bytes. There is no such danger or ambiguity when comparing a decimal with a
float.


So do you think that float("0.1") and Decimal("0.1") should be
equal or not, and why?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Michael Foord]

On 20/03/2010 00:15, Glenn Linderman wrote:

On 3/19/2010 4:58 PM, Antoine Pitrou wrote:

Glenn Linderman g.nevcal.com> writes:

> > If there's a bug in your __eq__ method, it may or may not raise an
> exception, which may or may not get you wrong containment results. 
But
> it will probably get you buggy results, somehow or another. That's 
what

> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want error silencing 
by default,

Python is not the language you are looking for.


We can agree to disagree, if you like. But taken to the limit, the Zen 
you quoted would prevent the try except clause from being used.


No, that is what "unless explicitly silenced" means - you are proposing 
to silence them *without* an explicit try except clause.


Michael


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk 




--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Glenn Linderman]

On 3/19/2010 5:18 PM, Michael Foord wrote:

will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want error silencing 
by default,

Python is not the language you are looking for.


We can agree to disagree, if you like. But taken to the limit, the 
Zen you quoted would prevent the try except clause from being used.


No, that is what "unless explicitly silenced" means - you are 
proposing to silence them *without* an explicit try except clause.


Michael 


Who, me?  The containment checking code would contain the try/except, I 
was proposing.


Glenn

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Michael Foord]

On 20/03/2010 00:19, Glenn Linderman wrote:

On 3/19/2010 5:18 PM, Michael Foord wrote:

will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want error silencing 
by default,

Python is not the language you are looking for.


We can agree to disagree, if you like. But taken to the limit, the 
Zen you quoted would prevent the try except clause from being used.


No, that is what "unless explicitly silenced" means - you are 
proposing to silence them *without* an explicit try except clause.


Michael 


Who, me?  The containment checking code would contain the try/except, 
I was proposing.


Explicit by the programmer. That is what explicit means... Caught and 
silenced for you by Python is implicit.


Michael



Glenn




--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 0.1

[Antoine Pitrou]

Greg Ewing  canterbury.ac.nz> writes:
> 
> So do you think that float("0.1") and Decimal("0.1") should be
> equal or not, and why?

Given that float("0.1") is not the mathematical 0.1, while Decimal("0.1") is,
I'd say no.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Greg Ewing]

Glenn Linderman wrote:

Sounds to me like containment checking is wrong; that if it gets an 
exception during the comparison that it should assume unequal, rather 
than aborting, and continue to the next entry.


What exception would it catch, though? Catching something as
generic as TypeError would be a very bad idea, I think -- there
would be too much potential for it to mask bugs.

It might be acceptable if there were a special subclass of
TypeError for this, such as NotComparableError.

What happens in Py3 here, BTW? It must have the same problem
if it refuses to compare some things for equality.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & lt; -& gt; float comparisons in py3k.

[Greg Ewing]

Glenn Linderman wrote:
In order to do 
implicit comparisons, one must do an implicit coercion.  Hence the PEP 
actually already prohibits implicit comparisons, as well as implicit 
arithmetic.


Not necessarily -- you could compare them as though they
had both been converted to the equivalent rational numbers,
which can be done without loss of precision.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] containment checking

[Glenn Linderman]

On 3/19/2010 5:20 PM, Michael Foord wrote:

On 20/03/2010 00:19, Glenn Linderman wrote:

On 3/19/2010 5:18 PM, Michael Foord wrote:

will probably get you buggy results, somehow or another. That's what
> design, code reviews, and testing are for.
We'll have to "agree to disagree" then. If you want error 
silencing by default,

Python is not the language you are looking for.


We can agree to disagree, if you like. But taken to the limit, the 
Zen you quoted would prevent the try except clause from being used.


No, that is what "unless explicitly silenced" means - you are 
proposing to silence them *without* an explicit try except clause.


Michael 


Who, me?  The containment checking code would contain the try/except, 
I was proposing.


Explicit by the programmer. That is what explicit means... Caught and 
silenced for you by Python is implicit.


Should I really believe that there are no try/except clauses in the 
Python source code (nor their C equivalent, if (errno == blahblahblah) 
... )?


I mean, I haven't read very much of the source code... but that 
statement makes me want to download and grep...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mixing float and Decimal -- thread reboot

[Steven D'Aprano]

On Sat, 20 Mar 2010 08:50:04 am Guido van Rossum wrote:
> I'd like to reboot this thread. I've been spinning this topic in my
> head for most of the morning, and I think we should seriously
> reconsider allowing mixed arithmetic involving Decimal, not just
> mixed comparisons. [Quick summary: embed Decimal in the numeric tower
> but add a context flag to disallow implicit mixing of float and
> Decimal.]

The last few days, I've argued against changing the prohibition against 
mixed arithmetic operations. But you've inspired me to go take a look 
at a module I've been neglecting, fractions, and I've learned that the 
Fraction type already fully supports arithmetic and comparisons with 
floats and ints. I'm extremely impressed -- I had no idea the numeric 
tower in 2.6 was this advanced. (I still do most of my work with 2.5.)

Decimal appears to be the odd one:

>>> f = Fraction(0)
>>> d = Decimal(0)
>>> 0 == 0.0 == 0j == f
True
>>> 0 == 0.0 == 0j == f == d
False

Not just odd in the sense of "different", but also odd in the sense 
of "weird":

>>> d == 0 == 0.0 == 0j == f
True


[...]
> I'd like to look at the issue by comparing the benefits and drawbacks
> of properly embedding Decimal into the numeric tower. As advantages,
> I see consistent behavior in situations like the above and more
> intuitive behavior for beginners. Also, this would be a possible road
> towards eventually supporting a language extension where floating
> point literals produce Decimal values instead of binary floats. (A
> possible syntax could be "from __options__ import decimal_float",
> which would work similar to "from __future__ import ..." except it's
> a permanent part of the language rather than a forward compatibility
> feature.)

That's far more ambitious than I was willing to even imagine, but now 
that you've suggested it, I like it.



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Needs Review: 2to3 fixer for sys.exitfunc to atexit.

[Sean Reifschneider]

Issue 2356 ( http://bugs.python.org/issue2356 ) looks like it has a patch
candidate, but just needs review to put in place.  Seems like it may be
low hanging fruit critical that just needs a quick review to either apply
or at least get back to the folks who are working on a patch.

Thanks,
Sean
-- 
 The most important thing in communication is to hear what isn't being said.
 -- Peter Drucker
Sean Reifschneider, Member of Technical Staff 
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Needs Review: 2to3 fixer for sys.exitfunc to atexit.

[Benjamin Peterson]

2010/3/19 Sean Reifschneider :
> Issue 2356 ( http://bugs.python.org/issue2356 ) looks like it has a patch
> candidate, but just needs review to put in place.  Seems like it may be
> low hanging fruit critical that just needs a quick review to either apply
> or at least get back to the folks who are working on a patch.

"critical"? I'm not sure that a new 2to3 fixer or py3k warning is a
critical issue.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GSoC 2010 is on -- projects?

[C. Titus Brown]

On Sat, Mar 20, 2010 at 12:00:48AM +0100, "Martin v. L?wis" wrote:
> > Whether this is worth weeks of work or not will depend on a given
> > student's knowledge about Python 3, and I'd suspect that the GSoC would
> > be an opportunity for a number of applicant to actually learn the
> > intricacies of Python 3.
> > Developing Python 3-specific features could be used to increase the
> > amount of work on the project, but I am uncertain of whether this is
> > worth a full GSoC.
> 
> I'd say this would definitely make a GSoC project; any non-trivial
> porting will be.

Sounds good to me.  Line up a good student and bob's your uncle.

--titus
-- 
C. Titus Brown, c...@msu.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker reviews workflow and flags

[Alexander Belopolsky]

I am generally happy with the tracker workflow and in my experience,
issues that are lingering are lingering for a good reason.

I've decided to add my two cents to this thread because I've just had
a negative experience with how issue 8154 and my input to it were
handled.

I will not go into details here beyond referring to
http://bugs.python.org/issue8154, but if you follow the link, you'll
see that there was not a consensus on how the issue should be
addressed and even whether or not it was a bug.  Nevertheless the
patch was committed both to the trunk and to 2.6 without any answer to
my concerns and without  even an rNNN link to the committed revision.

I think it would be nice if committers would not cut the discussion
short without at least a note explaining their decision.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Nick Coghlan]

Glenn Linderman wrote:
> The same person that would expect both
> 
> 0 == "0"
> 0.0 == "0.0"
> 
> to be False... i.e. anyone that hasn't coded in Perl for too many years.

Completely different - that is comparing numbers to strings. What this
discussion is about is comparison between the different kinds of real
number in the interpreter core and standard library (ints, floats,
decimal.Decimal, fractions.Fraction).

For arithmetic, decimal.Decimal deliberately fails to interoperate with
binary floating point numbers (hence why it isn't registered as an
example of the numbers.Real ABC).

For comparison, it only sort of fails to interoperate - it gives either
an exception or silently returns the wrong answer, depending on Python
version and the exact operator involved.

Fractions are nowhere near as purist about things - they will happily
allow themselves to be implicitly converted to floating point values.

So currently (for arithmetic):

int op int -> int (or potentially float due to division)
int op float, float op int -> float
int op Fraction, Fraction op int -> Fraction
int op Decimal, Decimal op int -> Decimal

Fraction op Fraction -> Fraction
Fraction op float, float op Fraction -> float
Fraction op Decimal, Decimal op Fraction -> TypeError

Decimal op Decimal -> Decimal
Decimal op float, float op Decimal -> TypeError

float op float -> float

Nobody is arguing in this thread for any changes to that. I just want to
contrast it with the situation for the comparison operators:

int op int -> bool
int op float, float op int -> bool
int op Fraction, Fraction op int -> bool
int op Decimal, Decimal op int -> bool

Fraction op Fraction -> bool
Fraction op float, float op Fraction -> bool
Fraction op Decimal, Decimal op Fraction -> TypeError

Decimal op Decimal -> bool
Decimal op float, float op Decimal -> TypeError

float op float -> bool

In the case of floats and Decimals, there's no ambiguity here that
creates any temptation to guess - to determine a true/false result for a
comparison, floats can be converted explicitly to Decimals without any
loss of accuracy. For Fractions, the precedent has already been set by
allowing implicit (potentially lossy) conversion to binary floats - a
lossy conversion to Decimal wouldn't be any worse.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal & amp; lt; -& amp; gt; float comparisons in py3k.

[Glenn Linderman]

On 3/19/2010 9:20 PM, Nick Coghlan wrote:

Glenn Linderman wrote:
   

>  The same person that would expect both
>  
>  0 == "0"

>  0.0 == "0.0"
>  
>  to be False... i.e. anyone that hasn't coded in Perl for too many years.
 

Completely different - that is comparing numbers to strings.


One can argue that either way, that it is completely different, or 
completely the same.  Is the map the territory, or is the territory the 
map?  The human representation of the numbers in string form is 
meaningful numerically, and there are explicit conversions between them 
that prove that it is so.


But it is completely different, because Python doesn't do implicit 
coercion of strings to numbers, so they don't belong in the tree.


But it is completely the same, because Python doesn't do implicit 
coercion of Decimal to numbers, so they don't belong in the tree.


Completely different, because Python also doesn't do numeric operations 
on strings either... so the analogy only goes so far, admittedly.  Even 
Perl, which will implicitly coerce string to numbers, has very limited 
numeric operations that are performed on the string form.


Thanks, though for the nice chart from an internals guy, you confirmed 
all that I thought I knew about how this presently works, from PEP and 
manual reading, a bit of experimentation, and the discussions here.


I have no problem with Guido's latest proposal in the rebooted thread, 
as long as there is a way to wall off the Decimal type from creeping 
errors due to implicit conversions and inaccurate types.  It is 
presently an excellent feature of Python to have a way to be sure that 
conversions are explicit to retain proper accuracy.   Few languages have 
that without requiring the user to write the whole class himself (or 
beg, borrow, or buy it).  As he implicitly points out, while declaring 
that mixed arithmetic might be appropriate, that it either needs to be 
done correctly and completely, or not at all.


Glenn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com