Re: [Python-Dev] IDLE as default Python editor (Was: [pygame] Python IDE for windoz)

[Terry Reedy]

anatoly techtonik wrote:

Hello,

Quite an interesting question recently popped up in pygame community
that I'd like to ask to Python developers.

How many of you use IDLE?


I do, both shell and editor (for Python code).


What's wrong with it?


See tracker.

I agree that discussion of alternatives belongs elsewhere.

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] Retrieve an arbitrary element from asetwithoutremoving it

[Martin v. Löwis]

> The problem arises because we're systematically unbalancing the hash
> table.  The iterator returns the first valid entry in the hash table,
> which we remove.  Repeat several times and pretty soon the iterator has
> to spend O(n) time scanning through empty entries to find the first
> remaining valid entry.

Interesting. Something goes wrong, it seems: if items get removed over
and over again, I think the set should shrink (not sure whether it
actually does). Then, I think you should end up with an amortized O(1)
for selecting an element (assuming that the underlying hashes don't
collide).

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.py: == and != comparisons involving NaNs

[Stefan Krah]

Raymond Hettinger  wrote:
> [Stefan Krah]
> >in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
> >questioning the reasons for allowing NaN comparisons with == and !=
> >rather than raising InvalidOperation.
> 
> Do you have any actual use case issues or are these theoretical musings?
> I ask only because a good use case might suggest the best way to adapt
> the standard to the regular python api for equality/inequality operators.

I think my reasoning goes the opposite way:

The current behavior (raising InvalidOperation) of <, <=, >=, > is sensible
and as close to the standard as one can get.  This behavior was not chosen
for the equality/inequality operators because they _might_ be used for other
purposes.

But since Decimal("NaN") == Decimal("NaN") gives False, these non-decimal
use cases don't work:

>>> d = {0:Decimal("NaN")}
>>> Decimal("NaN") in d.values()
False


So, since non-decimal use cases are limited at best, the equality/inequality
operators might as well have the behavior of the other comparison operators,
which is safer for the user.


I can also give a decimal use case where the current behavior is problematic
A variable initialized to a signaling NaN should always cause an exception.

But this doesn't:

salary = Decimal("sNaN")
minimum_wage = 1000
if (salary == minimum_wage):
print "do stuff"
else:
print "do other stuff"



Stefan Krah



___
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.py: == and != comparisons involving NaNs

[Antoine Pitrou]

Stefan Krah  bytereef.org> writes:
> 
> >>> d = {0:Decimal("NaN")}
> >>> Decimal("NaN") in d.values()
> False
> 
> So, since non-decimal use cases are limited at best, the equality/inequality
> operators might as well have the behavior of the other comparison operators,
> which is safer for the user.

The problem is when searching for /another/ object which hashes the same as
Decimal("NaN"). Here is a made-up situation to show you the problem:

>>> class H(object):
...   def __hash__(self): return hash(1)
...   def __eq__(self, other): raise ValueError
... 
>>> h = H()
>>> d = {h: ""}
>>> d[1]
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __eq__
ValueError
>>> d[1] = 2
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __eq__
ValueError



___
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.py: == and != comparisons involving NaNs

[Stefan Krah]

Antoine Pitrou  wrote:
> Stefan Krah  bytereef.org> writes:
> > 
> > >>> d = {0:Decimal("NaN")}
> > >>> Decimal("NaN") in d.values()
> > False
> > 
> > So, since non-decimal use cases are limited at best, the equality/inequality
> > operators might as well have the behavior of the other comparison operators,
> > which is safer for the user.
> 
> The problem is when searching for /another/ object which hashes the same as
> Decimal("NaN"). Here is a made-up situation to show you the problem:
> 
> >>> class H(object):
> ...   def __hash__(self): return hash(1)
> ...   def __eq__(self, other): raise ValueError
> ... 
> >>> h = H()
> >>> d = {h: ""}
> >>> d[1]
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in __eq__
> ValueError
> >>> d[1] = 2
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in __eq__
> ValueError

I see the point, but Decimal("NaN") does not hash:

>>> hash(Decimal("NaN"))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/decimal.py", line 937, in __hash__
raise TypeError('Cannot hash a NaN value.')
TypeError: Cannot hash a NaN value.


Also, NaNs cause problems in non-decimal comparisons virtually everywhere:

>>> L = [1, 2, Decimal("NaN")]
>>> L.sort()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/decimal.py", line 877, in __lt__
ans = self._compare_check_nans(other, context)
  File "/usr/lib/python2.7/decimal.py", line 782, in _compare_check_nans
self)
  File "/usr/lib/python2.7/decimal.py", line 3755, in _raise_error
raise error(explanation)
decimal.InvalidOperation: comparison involving NaN
>>> 


I think problems like these would best be avoided by having a separate
__totalorder__ or __lexorder__ method instead of using __eq__, __lt__,
etc., but this is of course outside the scope of this discussion (and
I have no idea how difficult it would be to implement that).



Stefan Krah


___
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.py: == and != comparisons involving NaNs

[Antoine Pitrou]

Stefan Krah  bytereef.org> writes:
> 
> I see the point, but Decimal("NaN") does not hash:

Ok but witness again:

>>> L = [1, 2, Decimal("NaN"), 3]
>>> 3 in L
True
>>> class H(object):
...   def __eq__(self, other): raise ValueError
... 
>>> L = [1, 2, H(), 3]
>>> 3 in L
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in __eq__
ValueError


(NB: interestingly, float("nan") does hash)

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] Status of the Buildbot fleet and related bugs

[Nick Coghlan]

Neal Norwitz wrote:
> I'd just like to say thanks again to everyone for making the buildbots
> more green and also improving the general testing infrastructure for
> Python.

I'm *really* liking the new assertions in unittest.

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.py: == and != comparisons involving NaNs

[Mark Dickinson]

On Mon, Nov 9, 2009 at 12:21 PM, Stefan Krah  wrote:
> I see the point, but Decimal("NaN") does not hash:
>
 hash(Decimal("NaN"))
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "/usr/lib/python2.7/decimal.py", line 937, in __hash__
>    raise TypeError('Cannot hash a NaN value.')
> TypeError: Cannot hash a NaN value.

I think that may represent an excess of caution.  float nans do hash quite
happily, and I can't see a good reason for preventing Decimal nans from
having a hash.

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] IDLE as default Python editor

[Nick Coghlan]

Ben Finney wrote:
> anatoly techtonik  writes:
> 
>> Quite an interesting question recently popped up in pygame community
>> that I'd like to ask to Python developers.
> 
> This forum is specifically about development *of* Python.

Anatoly's question is actually a fair one for python-dev - we're the
ones that *ship* Idle, so it is legitimate to ask our reasons for
continuing to do so.

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] IDLE as default Python editor (Was: [pygame] Python IDE for windoz)

[Nick Coghlan]

anatoly techtonik wrote:
> Hello,
> 
> Quite an interesting question recently popped up in pygame community
> that I'd like to ask to Python developers.
> 
> How many of you use IDLE?

I use it if it's the only syntax highlighting Python editor on the box
(since machines in the lab usually aren't set up with full dev
environments). Otherwise I'm more likely to use a general syntax
highlighting text editor (e.g. Kate on KDE)

>>From my side I like the idea of having default Python editor that is
> small, fast, convenient and extensible/embeddable. IDLE is small and
> fast, but I feel really uncomfortable with its. The worst thing - I
> can't change it. Does anybody else feel the same to think if we could
> replace IDLE with something more maintainable by providing Scintilla
> bindings, for example?

I don't particularly *like* IDLE, but that's largely because I don't
like Tcl/Tk. However, as far as cross-platform widget sets that are
reasonable to bundle with Python go (both from a licensing and code size
perspective), choices are pretty limited (plus Tcl/Tk has the advantage
of incumbency).

So while I can't claim to like Idle in and of itself, I do like the fact
that the language comes with its own syntax highlighting editor.

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.py: == and != comparisons involving NaNs

[Mark Dickinson]

On Sun, Nov 8, 2009 at 4:26 PM, Stefan Krah  wrote:
> Hi,
>
> in a (misguided) bugreport (http://bugs.python.org/issue7279) I was
> questioning the reasons for allowing NaN comparisons with == and !=
> rather than raising InvalidOperation.

Some quick recent history:

For reference, the current behaviour dates from r60630.  Before this,
comparisons involving nans behaved even less coherently.  See

http://bugs.python.org/issue1979

for details.

Apart from Python's use of __eq__, the other motivation for the
current behaviour comes from the IEEE 854 standard;  given the
absence of helpful information in the Decimal standard, IEEE 854
is an obvious next place to look.  There's an unofficial copy of the
standard available at:

http://754r.ucbtest.org/standards/854.pdf

Section 5.7 describes twenty-six(!) distinct comparison operators.
So it's not immediately clear which of those twenty-six comparison
operators each of Python's six comparison operators should map
to.  However, in the standard, the first six operations in the table
are somewhat distinguished:  they're the ones that are marked
as corresponding to the usual mathematical operations, and to
Fortran's usual comparison operators (.EQ., etc.).  Given this,
and given that this behaviour seemed to fit well with Python's
needs for __eq__, it seemed to make sense at the time to
map Python's six operators to the first 6 operators in table 3.

> I think two main issues emerge from the brief discussion:
>
> 1. Should the comparison operators follow the 'compare' function
>   from the standard?

That's a possibility.  But see below.

> 2. What is the use of == and != outside the decimal scope?
>
> Mark mentions that Python uses == to test for set and dict memberships,
> but that you cannot put decimal NaNs into sets:
>
> 'TypeError: Cannot hash a NaN value'
>
>
> I want to add that Decimal('NaN') == Decimal('NaN') gives False, which
> should somewhat limit the uses of == for NaNs outside the decimal realm
> anyway.
>
>
> Are there cases where == and != are actually needed to give a result
> for NaNs?

Well, when running in some form of 'non-stop' mode, where (quiet) NaN
results are supposed to be propagated to the end of a computation, you
certainly want equality comparisons with nan just to silently return false.
E.g., in code like:

if x == 0:

else:


nans should just end up in the second branch, without the programmer
having had to think about it too hard.

So I think comparisons with nans should always return either True
or False when InvalidOperation is not trapped. The question is whether
comparisons should always signal when InvalidOperation is trapped
(which is what happens with the default context).

I'm -0.5 on changing the current behaviour:  it may not be exactly right,
and if I were implementing Decimal from scratch I might well do things
differently, but I don't think it's terribly wrong either.  While not based
on the Decimal standard itself, it's based on the next most closely-
related standard.  It works with Python's needs for __eq__ and __ne__.
And it's already out there in Python 2.6;  making minute adjustments
to existing behaviour without a good reason seems like asking for trouble.

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.py: == and != comparisons involving NaNs

[Mark Dickinson]

On Mon, Nov 9, 2009 at 10:42 AM, Stefan Krah  wrote:
> I can also give a decimal use case where the current behavior is problematic
> A variable initialized to a signaling NaN should always cause an exception.
>
> But this doesn't:
>
> salary = Decimal("sNaN")
> minimum_wage = 1000
> if (salary == minimum_wage):
>    print "do stuff"
> else:
>    print "do other stuff"

Hmm.  This does look suspicious.  It's possible we should be raising
for signalling nans here.  For most of what I wrote above I was thinking
of quiet nans.

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.py: == and != comparisons involving NaNs

[Stefan Krah]

Antoine Pitrou  wrote:
> > I see the point, but Decimal("NaN") does not hash:
> 
> Ok but witness again:
> 
> >>> L = [1, 2, Decimal("NaN"), 3]
> >>> 3 in L
> True
> >>> class H(object):
> ...   def __eq__(self, other): raise ValueError
> ... 
> >>> L = [1, 2, H(), 3]
> >>> 3 in L
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 2, in __eq__
> ValueError


Yes, but the list is already broken in two ways:

>>> L.sort()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/decimal.py", line 877, in __lt__
ans = self._compare_check_nans(other, context)
  File "/usr/lib/python2.7/decimal.py", line 782, in _compare_check_nans
self)
  File "/usr/lib/python2.7/decimal.py", line 3755, in _raise_error
raise error(explanation)
decimal.InvalidOperation: comparison involving NaN

>>> Decimal("NaN") in L
False



> (NB: interestingly, float("nan") does hash)


I wonder if it should:

>>> d = {float('nan'): 10, 0: 20}
>>> 0 in d
True
>>> float('nan') in d
False
>>> d[float('nan')]
Traceback (most recent call last):
  File "", line 1, in 
KeyError: nan
>>> 


I guess my point is that NaNs in lists and dicts are broken in so many
ways that it might be good to discourage this use. (And get the added
benefit of safer mathematical behavior for == and !=.)


Stefan Krah



___
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.py: == and != comparisons involving NaNs

[Mark Dickinson]

On Mon, Nov 9, 2009 at 1:01 PM, Mark Dickinson  wrote:
> current behaviour comes from the IEEE 854 standard;  given the
> absence of helpful information in the Decimal standard, IEEE 854
> is an obvious next place to look.  There's an unofficial copy of the
> standard available at:
>
> http://754r.ucbtest.org/standards/854.pdf
>
> Section 5.7 describes twenty-six(!) distinct comparison operators.

It's interesting to note that out of the 32 possible different comparison
behaviours (two choices of result for each of {equal, lessthan,
greaterthan, unordered}, together with a choice of whether to signal
or not for unordered in each case), the two interesting operators
that are missing from that IEEE 854 table are precisely the ones
that we're discussing:  signalling __eq__ (i.e., return False for
lessthan, greaterthan, unordered, True for equal, and signal on
unordered), and signalling __ne__ (the reverse of the above, but
still signalling on unordered).

(The other four missing operators are the uninteresting ones that
always return True or always return False.)

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.py: == and != comparisons involving NaNs

[Mark Dickinson]

On Mon, Nov 9, 2009 at 1:21 PM, Stefan Krah  wrote:
> Antoine Pitrou  wrote:
>> (NB: interestingly, float("nan") does hash)
>
>
> I wonder if it should:
>
 d = {float('nan'): 10, 0: 20}
 0 in d
> True
 float('nan') in d
> False
 d[float('nan')]
> Traceback (most recent call last):
>  File "", line 1, in 
> KeyError: nan

That's because you're creating two different float nans.
Compare with:

Python 3.2a0 (py3k:76132M, Nov  6 2009, 14:47:39)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> nan = float('nan')
>>> d = {nan: 10, 0: 20}
>>> nan in d
True
>>> d[nan]
10

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.py: == and != comparisons involving NaNs

[Antoine Pitrou]

Stefan Krah  bytereef.org> writes:
> 
> I guess my point is that NaNs in lists and dicts are broken in so many
> ways that it might be good to discourage this use. (And get the added
> benefit of safer mathematical behavior for == and !=.)

Giving users seemingly random and unexplainable exceptions would not be a good
way to discourage it, though.


___
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] Retrieve an arbitrary element from asetwithoutremoving it

[Nick Coghlan]

Martin v. Löwis wrote:
>> The problem arises because we're systematically unbalancing the hash
>> table.  The iterator returns the first valid entry in the hash table,
>> which we remove.  Repeat several times and pretty soon the iterator has
>> to spend O(n) time scanning through empty entries to find the first
>> remaining valid entry.
> 
> Interesting. Something goes wrong, it seems: if items get removed over
> and over again, I think the set should shrink (not sure whether it
> actually does). Then, I think you should end up with an amortized O(1)
> for selecting an element (assuming that the underlying hashes don't
> collide).

The behaviour is inherited (in spirit) from dicts. Courtesy of
dictnotes.txt:

"""
* Shrinkage rate upon exceeding maximum sparseness.  The current
CPython code never even checks sparseness when deleting a
key.  When a new key is added, it resizes based on the number
of active keys, so that the addition may trigger shrinkage
rather than growth.
"""

"""
Dictionary operations involving only a single key can be O(1) unless
resizing is possible.  By checking for a resize only when the
dictionary can grow (and may *require* resizing), other operations
remain O(1), and the odds of resize thrashing or memory fragmentation
are reduced. In particular, an algorithm that empties a dictionary
by repeatedly invoking .pop will see no resizing, which might
not be necessary at all because the dictionary is eventually
discarded entirely.
"""

So the rationale is to ensure that only add operations perform a resize
and so that sequential pop() operations don't incur excessive resizing
costs.

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] PEP 3003 - Python Language Moratorium

[A.M. Kuchling]

On Sun, Nov 08, 2009 at 10:27:46PM +0100, Georg Brandl wrote:
> Good point, I'll make that change if AMK agrees.

It's certainly fine with me. Do we want to only make that change to
the 2.7 "What's New", or should we also do it for the 2.6 one?

--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] Retrieve an arbitrary element from asetwithoutremoving it

[Daniel Stutzbach]

On Mon, Nov 9, 2009 at 2:42 AM, "Martin v. Löwis" wrote:

> Interesting. Something goes wrong, it seems: if items get removed over
> and over again, I think the set should shrink (not sure whether it
> actually does). Then, I think you should end up with an amortized O(1)
> for selecting an element (assuming that the underlying hashes don't
> collide).
>

I'm not sure if Python's implementation shrinks or not, but even if it did
shrink, it would still be amortized O(n).

Imagine a completely full hash table that currently contains n elements in n
slots (I know this cannot happen in Python's implementation but it's useful
for illustrative purposes).  Assume it will shrink when it gets down to n/2
elements.

Here is my pathological algorithm again, for reference purposes:

while s:
for i in s:
break
# Imagine a complex algorithm here that depends on i still being in s
s.remove(i)

We repeatedly search through the slots sequentially and remove the first
element we find.  The first removal requires checking 1 slot, the second
removal requires checking 2 slots, the third removal requires checking 3
slots, and so forth.  The hash table will shrink after the n/2-th removal,
when we have checked 1 + 2 + 3 + ... + n/2 = O(n**2) slots for n/2 removals
(or amortized O(n) per removal).  It's too late for shrinking to save us;
we've already performed too much work.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Retrieve an arbitrary element from asetwithoutremoving it

[Alexander Belopolsky]

On Mon, Nov 9, 2009 at 10:09 AM, Daniel Stutzbach
 wrote:
> On Mon, Nov 9, 2009 at 2:42 AM, "Martin v. Löwis" 
> wrote:
>>
>> Interesting. Something goes wrong, it seems: if items get removed over
>> and over again, I think the set should shrink (not sure whether it
>> actually does). Then, I think you should end up with an amortized O(1)
>> for selecting an element (assuming that the underlying hashes don't
>> collide).
>
> I'm not sure if Python's implementation shrinks or not,

It does not:

>>> s = set(range(10))
>>> from sys import getsizeof
>>> getsizeof(s)
4194536
>>> while s: x = s.pop()
...
>>> getsizeof(s)
4194536
>>> s.clear()
>>> getsizeof(s)
232
___
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] Retrieve an arbitrary element from asetwithoutremoving it

[Björn Lindqvist]

2009/11/6 Raymond Hettinger :
> [me]
>>
>> Why not write a short, fast get_first() function for your utils directory
>> and be done with it?
>> That could work with sets, mappings, generators, and other containers and
>> iterators.
>> No need to fatten the set/frozenset API for something so trivial and so
>> rarely needed.
>
> Forgot to post the code.  It is short, fast, and easy.  It is explicit about
> handing the case with an empty input.  And it is specific about which value
> it returns (always the first iterated value; not an arbitrary one).  There's
> no guessing about what it does.  It gets the job done.
>
> def first(iterable):
>   'Return the first value from a container or iterable.  If empty, raises
> LookupError'
>   for value in iterable:
>       return value
>   raise LookupError('no first value; iterable is empty')
>
> If desired, it is not hard to change to the last time to return a default
> value or some other exception.

That function is very nice and genericly lisp-like. Couldn't that one
be in the builtins? It would both solve the problem and avoid
fattening the set API.


-- 
mvh Björn
___
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] PEP 3003 - Python Language Moratorium

[Brett Cannon]

On Sun, Nov 8, 2009 at 19:50, geremy condra  wrote:
> On Sun, Nov 8, 2009 at 9:41 PM, Guido van Rossum  wrote:
>> On Sun, Nov 8, 2009 at 5:45 PM, geremy condra  wrote:
>>> I quote:
>>>
>>> "This PEP proposes a temporary moratorium (suspension) of all changes
>>> to the Python language syntax, semantics, and built-ins for a period
>>> of *at least two years* from the release of Python 3.1."
>>>
>>> Emphasis mine.
>>
>> I since added this:
>>
>> """In particular,
>> the moratorium would include Python 3.2 (to be released 18-24 months
>> after 3.1) but (unless explicitly extended) allow Python 3.3 to once
>> again include language changes."""
>>
>>> Like I say, a definite end point would be much preferred to n > 2.
>>
>> My time machine doesn't work very well in the future. So I can't tell
>> what we'll find necessary 2 years from now. But I would be fine with
>> defining the time limit to be max(time(3.1) + 2 years, time(3.2)).
>> I.e. the moratorium (unless explicitly extended) ends as soon as 3.2
>> has been released *and* at least 2 years have passed since 3.1.
>
> Ok, thanks for the clarification. Could you spell out what you would
> consider grounds for a future extension?
>

We feel it's necessary as a group or Guido does, simple as that. You
can't plan it since it's over two years away. If the time comes and
people feel the moratorium has been beneficial and should go longer,
we will extend it. It will most likely be for the same reasons we
started it.

>>> If possible, I'd also like to hear some of Steven's other points addressed.
>>
>> They haven't changed my mind.
>
> Ok, but the fact that you (or Steven) hold a particular set of beliefs
> is a singularly unconvincing argument.

I disagree. Guido is the BDFL so his set of beliefs is enough unless
faced with a huge number of people disagreeing. That has not occurred
on this topic.

>Could you explain why you
> don't agree, if only for the record?

Enough happens on python-dev based on gut feeling that there isn't a
need. If we had to spell out objections to every email we received
while discussing a PEP, threads would never end. Heck, I think this
PEP discussion as gone on long enough and that Guido could pronounce
at this point.

-Brett
___
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] Python 2.6: OverflowError: signed integer is greater than maximum

[Jasper Lievisse Adriaanse]

Hi,

while trying to get Python 2.6 working on OpenBSD/sgi (64-bit port)
I ran into the following during build:

OverflowError: signed integer is greater than maximum

I ran the command that triggered this by hand with -v added:

(sgi Python-2.6.3 40)$ export PATH; PATH="`pwd`:$PATH";  export PYTHONPATH; 
PYTHONPATH="`pwd`/Lib";  export DYLD_FRAMEWORK_PATH; 
DYLD_FRAMEWORK_PATH="`pwd`";  export EXE; EXE="";  cd ./Lib/plat-openbsd4;  
./regen
python$EXE -v ../../Tools/scripts/h2py.py -i '(u_long)' 
/usr/include/netinet/in.h
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc matches 
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py
import site # precompiled from 
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.pyc
'import site' failed; traceback:
Traceback (most recent call last):
  File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/site.py", line 61, in 

import sys
OverflowError: signed integer is greater than maximum
import encodings # directory 
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc matches 
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.py
import encodings # precompiled from 
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/encodings/__init__.pyc
Python 2.6.3 (r263:75183, Nov  6 2009, 09:50:33) 
[GCC 3.3.5 (propolice)] on openbsd4
Type "help", "copyright", "credits" or "license" for more information.
# /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc matches 
/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py
import re # precompiled from /usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.pyc
Traceback (most recent call last):
  File "../../Tools/scripts/h2py.py", line 24, in 
import sys, re, getopt, os
  File "/usr/obj/ports/Python-2.6.3/Python-2.6.3/Lib/re.py", line 104, in 

import sys
OverflowError: signed integer is greater than maximum
# clear __builtin__._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.exitfunc
# clear sys.exc_type
# clear sys.exc_value
# clear sys.exc_traceback
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.flags
# clear sys.float_info
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
# cleanup __main__
# cleanup[1] zipimport
# cleanup[1] signal
# cleanup[1] exceptions
# cleanup[1] _warnings
# cleanup sys
# cleanup __builtin__
# cleanup ints: 3 unfreed ints
# cleanup floats
(sgi plat-openbsd4 41)$ 

Does anyone know what's going on here, or how to fix it?
I can provide a full build and configure log if needed.

Cheers,
Jasper
-- 
"Intelligence should guide our actions, but in harmony with the
  texture of the situation at hand"
-- Francisco Varela
___
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] PEP 3003 - Python Language Moratorium

[Guido van Rossum]

Thanks Brett.  I've moved the moratorium PEP to Status: Accepted. I've
added the words about inclusion of 3.2 and exclusion of 3.3 (which
were eaten by a svn conflict when I previously tried to add them) and
added a section to th end stating that an extension will require
another PEP.

--Guido

On Mon, Nov 9, 2009 at 9:12 AM, Brett Cannon  wrote:
> On Sun, Nov 8, 2009 at 19:50, geremy condra  wrote:
>> On Sun, Nov 8, 2009 at 9:41 PM, Guido van Rossum  wrote:
>>> On Sun, Nov 8, 2009 at 5:45 PM, geremy condra  wrote:
 I quote:

 "This PEP proposes a temporary moratorium (suspension) of all changes
 to the Python language syntax, semantics, and built-ins for a period
 of *at least two years* from the release of Python 3.1."

 Emphasis mine.
>>>
>>> I since added this:
>>>
>>> """In particular,
>>> the moratorium would include Python 3.2 (to be released 18-24 months
>>> after 3.1) but (unless explicitly extended) allow Python 3.3 to once
>>> again include language changes."""
>>>
 Like I say, a definite end point would be much preferred to n > 2.
>>>
>>> My time machine doesn't work very well in the future. So I can't tell
>>> what we'll find necessary 2 years from now. But I would be fine with
>>> defining the time limit to be max(time(3.1) + 2 years, time(3.2)).
>>> I.e. the moratorium (unless explicitly extended) ends as soon as 3.2
>>> has been released *and* at least 2 years have passed since 3.1.
>>
>> Ok, thanks for the clarification. Could you spell out what you would
>> consider grounds for a future extension?
>>
>
> We feel it's necessary as a group or Guido does, simple as that. You
> can't plan it since it's over two years away. If the time comes and
> people feel the moratorium has been beneficial and should go longer,
> we will extend it. It will most likely be for the same reasons we
> started it.
>
 If possible, I'd also like to hear some of Steven's other points addressed.
>>>
>>> They haven't changed my mind.
>>
>> Ok, but the fact that you (or Steven) hold a particular set of beliefs
>> is a singularly unconvincing argument.
>
> I disagree. Guido is the BDFL so his set of beliefs is enough unless
> faced with a huge number of people disagreeing. That has not occurred
> on this topic.
>
>>Could you explain why you
>> don't agree, if only for the record?
>
> Enough happens on python-dev based on gut feeling that there isn't a
> need. If we had to spell out objections to every email we received
> while discussing a PEP, threads would never end. Heck, I think this
> PEP discussion as gone on long enough and that Guido could pronounce
> at this point.
>
> -Brett
>



-- 
--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] Python 2.6: OverflowError: signed integer is greater than maximum

[Mark Dickinson]

On Mon, Nov 9, 2009 at 5:26 PM, Jasper Lievisse Adriaanse
 wrote:
> Hi,
>
> while trying to get Python 2.6 working on OpenBSD/sgi (64-bit port)
> I ran into the following during build:
>
> OverflowError: signed integer is greater than maximum
>
> I ran the command that triggered this by hand with -v added:

[traceback snipped]

> Does anyone know what's going on here, or how to fix it?
> I can provide a full build and configure log if needed.

No idea.  Please could you file a report at http://bugs.python.org?
The build and configure log would be useful.  If you can diagnose
the source of the failure yourself any further that would be more
useful;  I suspect that the core developers will have a hard time
figuring the problem out without this.

I may well be barking up the wrong tree here, but as a first guess
it looks as though something in the _PySys_Init function in
Python/sysmodule.c is (directly or indirectly) causing the
OverflowError to be raised.  I'd try adding a bunch of
printf calls to that function that print the value of
PyErr_Occurred(), to see where (if at all) the Python exception
is being set.  (I suggest building with the --with-pydebug configure
option for this.)

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] PEP 3003 - Python Language Moratorium

[Georg Brandl]

A.M. Kuchling schrieb:
> On Sun, Nov 08, 2009 at 10:27:46PM +0100, Georg Brandl wrote:
>> Good point, I'll make that change if AMK agrees.
> 
> It's certainly fine with me. Do we want to only make that change to
> the 2.7 "What's New", or should we also do it for the 2.6 one?

Why not for 2.6 as well, it's an immediate benefit, especially since the
list of deprecations in 2.6 is huge.

Georg

___
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] Retrieve an arbitrary element from asetwithoutremoving it

[Steven D'Aprano]

On Tue, 10 Nov 2009 03:40:11 am Björn Lindqvist wrote:
> 2009/11/6 Raymond Hettinger :
> > [me]
> >
> >> Why not write a short, fast get_first() function for your utils
> >> directory and be done with it?
> >> That could work with sets, mappings, generators, and other
> >> containers and iterators.
> >> No need to fatten the set/frozenset API for something so trivial
> >> and so rarely needed.
> >
> > Forgot to post the code.  It is short, fast, and easy.  It is
> > explicit about handing the case with an empty input.  And it is
> > specific about which value it returns (always the first iterated
> > value; not an arbitrary one).  There's no guessing about what it
> > does.  It gets the job done.
> >
> > def first(iterable):
> >   'Return the first value from a container or iterable.  If empty,
> > raises LookupError'
> >   for value in iterable:
> >       return value
> >   raise LookupError('no first value; iterable is empty')
> >
> > If desired, it is not hard to change to the last time to return a
> > default value or some other exception.
>
> That function is very nice and genericly lisp-like. Couldn't that one
> be in the builtins? It would both solve the problem and avoid
> fattening the set API.


I'm not sure, but isn't that thread-unsafe?

Because sets aren't directly iterable, `for value in iterable` builds a 
set_iterator operator. If another thread modifies the set after the 
set_iterator is built, but before the value is looked up, you will get 
a mysterious RuntimeError almost impossible to debug.


>>> def first():  # simplified
... for value in iterator:
... return value
...
>>> dis.dis(first)
  2   0 SETUP_LOOP  15 (to 18)
  3 LOAD_GLOBAL  0 (iterator)
  6 GET_ITER
  7 FOR_ITER 7 (to 17)
 10 STORE_FAST   0 (value)

  3  13 LOAD_FAST0 (value)
 16 RETURN_VALUE
>>   17 POP_BLOCK
>>   18 LOAD_CONST   0 (None)
 21 RETURN_VALUE

 
Is it possible for another thread to be called between the GET_ITER and 
STORE_FAST? 




-- 
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

Re: [Python-Dev] decimal.py: == and != comparisons involving NaNs

[Greg Ewing]

Antoine Pitrou wrote:


The problem is when searching for /another/ object which hashes the same as
Decimal("NaN").


Maybe decimal NaNs should be unhashable, so that you can't
put them in a dictionary in the first place.

--
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] Retrieve an arbitrary element from asetwithoutremoving it

[Nick Coghlan]

Alexander Belopolsky wrote:
> On Mon, Nov 9, 2009 at 10:09 AM, Daniel Stutzbach
>  wrote:
>> On Mon, Nov 9, 2009 at 2:42 AM, "Martin v. Löwis" 
>> wrote:
>>> Interesting. Something goes wrong, it seems: if items get removed over
>>> and over again, I think the set should shrink (not sure whether it
>>> actually does). Then, I think you should end up with an amortized O(1)
>>> for selecting an element (assuming that the underlying hashes don't
>>> collide).
>> I'm not sure if Python's implementation shrinks or not,
> 
> It does not:
> 
 s = set(range(10))
 from sys import getsizeof
 getsizeof(s)
> 4194536
 while s: x = s.pop()
> ...
 getsizeof(s)
> 4194536
 s.clear()
 getsizeof(s)
> 232

Interestingly, it looks like there the sparseness check isn't triggering
on addition of items either (when dictnotes.txt says it should):

>>> from sys import getsizeof
>>> s = set(range(10))
>>> getsizeof(s)
2097264
>>> while s: x = s.pop()
...
>>> getsizeof(s)
2097264
>>> s.add(1)
>>> getsizeof(s)
2097264

I did a similar test with dict.fromkeys and that also didn't resize
until .clear() was invoked. I don't know the current criteria settings
for the sparseness check, but it seems odd that going from 100k active
keys to none wouldn't cause a resize...

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] Retrieve an arbitrary element from asetwithoutremoving it

[Martin v. Löwis]

> So the rationale is to ensure that only add operations perform a resize
> and so that sequential pop() operations don't incur excessive resizing
> costs.

I agree that the use case of repeated .pop() operations is reasonable,
and (IIUC) that case is also special-cased using a finger/index.

I think for regular removal, the same logic should not apply: if a
series of removals is performed, then further (non-pop) removals
see increasing costs, as do regular lookups. So I think that a removal
should trigger shrinking (with appropriate thresholds) unless it's a
.pop.

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] IDLE as default Python editor

[Martin v. Löwis]

Nick Coghlan wrote:
> Ben Finney wrote:
>> anatoly techtonik  writes:
>>
>>> Quite an interesting question recently popped up in pygame community
>>> that I'd like to ask to Python developers.
>> This forum is specifically about development *of* Python.
> 
> Anatoly's question is actually a fair one for python-dev - we're the
> ones that *ship* Idle, so it is legitimate to ask our reasons for
> continuing to do so.

But he didn't - instead, he asked how many of us use it. Usage by
committers is not (or shouldn't be) a primary criterion for including
or not including something. Instead, usage in the community should be,
and python-dev is indeed the wrong place to estimate that.

OTOH, the second (or, rather, third) question (does anybody think it
should be replaced) is indeed on-topic for python-dev.

I didn't really answer that question before, so I do now: I have not
personally plans to replace it, and I'm skeptical wrt. anybody else's
plans unless there is specific code in existence that IDLE could be
replaced *with*.

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] Retrieve an arbitrary element from asetwithoutremoving it

[Martin v. Löwis]

> I'm not sure, but isn't that thread-unsafe?

You are right; it's thread-unsafe.

I would fix it by catching the RuntimeError, and retrying. Given the
current GIL strategy (including proposed changes to it), it won't happen
two times in a row, so the number of retries would be bounded.

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] Python 2.6: OverflowError: signed integer is greater than maximum

[Martin v. Löwis]

> I may well be barking up the wrong tree here, but as a first guess
> it looks as though something in the _PySys_Init function in
> Python/sysmodule.c is (directly or indirectly) causing the
> OverflowError to be raised. 

My theory would be different. There is a pending unchecked OverflowError
before the import, and the err-occurred check after the import picks it
up.

Of course, your guess is as good as mine.

While barking up trees: My guess is that it's a compiler bug (i.e. the
compiler generating bad code).

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] Retrieve an arbitrary element from asetwithoutremoving it

[Martin v. Löwis]

> We repeatedly search through the slots sequentially and remove the first
> element we find.  The first removal requires checking 1 slot, the second
> removal requires checking 2 slots, the third removal requires checking 3
> slots, and so forth.  The hash table will shrink after the n/2-th
> removal, when we have checked 1 + 2 + 3 + ... + n/2 = O(n**2) slots for
> n/2 removals (or amortized O(n) per removal).  It's too late for
> shrinking to save us; we've already performed too much work.

Ah, right.

Perhaps people writing the loop the way you proposed deserve to get bad
performance, as they should use .pop in the first place.

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] Retrieve an arbitrary element from asetwithoutremoving it

[Daniel Stutzbach]

On Mon, Nov 9, 2009 at 3:50 PM, "Martin v. Löwis" wrote:

> I think for regular removal, the same logic should not apply: if a
> series of removals is performed, then further (non-pop) removals
> see increasing costs, as do regular lookups. So I think that a removal
> should trigger shrinking (with appropriate thresholds) unless it's a
> .pop.
>

Minor technicality, but it's the next() operation of the iterator that has
increasing cost as the set/dict becomes sparse. Removals are always O(1).
The removal uses the hash to find the item quickly.  The iterator has to
scan through the table for non-empty entries.

(the above assumes a good hash function with few collisions, of course)

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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.py: == and != comparisons involving NaNs

[Terry Reedy]

Mark Dickinson wrote:


That's because you're creating two different float nans.
Compare with:

Python 3.2a0 (py3k:76132M, Nov  6 2009, 14:47:39)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

nan = float('nan')
d = {nan: 10, 0: 20}
nan in d

True

d[nan]

10


This also suggests to me that nan should be a singleton, or at least 
that the doc should recommend that programs should make it be such for 
the program.


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] Python 2.6: OverflowError: signed integer is greater than maximum

[Jasper Lievisse Adriaanse]

On Mon, Nov 09, 2009 at 07:15:20PM +, Mark Dickinson wrote:
> On Mon, Nov 9, 2009 at 5:26 PM, Jasper Lievisse Adriaanse
>  wrote:
> > Hi,
> >
> > while trying to get Python 2.6 working on OpenBSD/sgi (64-bit port)
> > I ran into the following during build:
> >
> > OverflowError: signed integer is greater than maximum
> >
> > I ran the command that triggered this by hand with -v added:
> 
> [traceback snipped]
> 
> > Does anyone know what's going on here, or how to fix it?
> > I can provide a full build and configure log if needed.
> 
> No idea.  Please could you file a report at http://bugs.python.org?
> The build and configure log would be useful.  If you can diagnose
> the source of the failure yourself any further that would be more
> useful;  I suspect that the core developers will have a hard time
> figuring the problem out without this.
> 
> I may well be barking up the wrong tree here, but as a first guess
> it looks as though something in the _PySys_Init function in
> Python/sysmodule.c is (directly or indirectly) causing the
> OverflowError to be raised.  I'd try adding a bunch of
> printf calls to that function that print the value of
> PyErr_Occurred(), to see where (if at all) the Python exception
> is being set.  (I suggest building with the --with-pydebug configure
> option for this.)
> 
> Mark
Hi,

for the record, I filed the bug as: http://bugs.python.org/issue7296
In the meantime I'll try digging into this issue.

  Cheers,
  Jasper

-- 
"Intelligence should guide our actions, but in harmony with the
  texture of the situation at hand"
-- Francisco Varela
___
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.py: == and != comparisons involving NaNs

[Guido van Rossum]

On Mon, Nov 9, 2009 at 2:51 PM, Terry Reedy  wrote:
> This also suggests to me that nan should be a singleton, or at least that
> the doc should recommend that programs should make it be such for the
> program.

The IEEE std disagreed -- there's extra info hidden in the mantissa
bits. And the Python float implementation makes it pretty impractical
to do this at the application level since x+y will generate a new
NaN-valued float object each time it is called (if the outcome is
NaN).

-- 
--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] People want CPAN :-)

[Michael Sparks]

[ I'm posting this comment in reply to seeing this thread:
* http://thread.gmane.org/gmane.comp.python.distutils.devel/11359
Which has been reposted around - and I've read that thread. I lurk on
this list, in case anything comes up that I'd hope to be able to say
something useful to. I don't know if this will be, but that's my
reason for posting. If this is the wrong place, my apologies, I don't
sub to distutils-sig :-/ ]

On Sat, Nov 7, 2009 at 2:30 PM, sstein...@gmail.com  wrote:
> On Nov 7, 2009, at 3:20 AM, Ben Finney wrote:
>
>> Guido van Rossum  writes:
>>
>>> On Fri, Nov 6, 2009 at 2:52 PM, David Lyon 
>>> wrote:

[ lots of snippage ]
...
> All in all, I think this could be a big leap forward for the Python
> distribution ecosystem whether or not we eventually write the PyPan I wished
> for as a new Perl refugee.

Speaking as someone who left the perl world for the python world, many
years ago now, primarily due to working on one project, the thing I
really miss about Perl is CPAN. It's not the fact that you know you do
perl Makefile.PL && make && make test && make install. Nor the fact
that it's trivial to set up a skeleton package setup that makes that
work for you. It's not the fact that there's an installer than can
download & track dependencies.

The thing that makes the difference IMHO is two points:
* In a language which has a core ethos "There's more than one way
to do it", packaging is the one place where there is one, and only one
obvious way to do it. (Oddly with python, with packaging this is
flipped - do I as a random project use distutils? pip? setuptools?
distribute? virtualenv?)
* It has a managed namespace or perhaps better - a co-ordinated namespace.

CPAN may have lots of ills, and bad aspects about it (I've never
really trusted the auto installer due to seeing one too many people
having their perl installation as a whole upgraded due to a bug that
was squashed 6-8 years ago), but these two points are pretty much
killer.

All the other aspects like auto download, upload, dependency tracking,
auto doc extraction for the website etc, really follow from the
managed namespace really. I realise that various efforts like
easy_install & distribute & friends make that sort of step implicitly
- since there can only be one http://pypi.python.org/pypi/flibble .
But it's not quite the same - due to externally hosted packages.

For more detail about this aspect:
   * http://www.cpan.org/modules/04pause.html#namespace

I'm really mentioning this because I didn't see it listed, and I
really think that it's very easy to underestimate this aspect of CPAN.

IMHO, it is what matters the most about CPAN. The fact that they've
nabbed the CTAN idea of having an archive network for storing,
mirroring and grabbing stuff from is by comparison /almost/ irrelevant
IMHO. It is the sort of thing that leads to the DBI::DBD type stuff
that is being simple to use, because of the encouragement to talk and
share a namespace.

The biggest issue with this is retrofitting this to an existing world.

Personal opinion, I hope it's useful, and going back into lurk mode (I
hope :). If this annoys you, please just ignore it.


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/archive%40mail-archive.com