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
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
Raymond Hettinger pyt...@rcn.com 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
Stefan Krah stefan-usenet at 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.
Antoine Pitrou solip...@pitrou.net wrote:
Stefan Krah stefan-usenet at 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
Stefan Krah stefan-usenet at 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
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,
On Mon, Nov 9, 2009 at 12:21 PM, Stefan Krah stefan-use...@bytereef.org wrote:
I see the point, but Decimal(NaN) does not hash:
hash(Decimal(NaN))
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.7/decimal.py, line 937, in __hash__
raise
Ben Finney wrote:
anatoly techtonik techto...@gmail.com 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
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
On Sun, Nov 8, 2009 at 4:26 PM, Stefan Krah stefan-use...@bytereef.org 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
On Mon, Nov 9, 2009 at 10:42 AM, Stefan Krah stefan-use...@bytereef.org 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 =
Antoine Pitrou solip...@pitrou.net 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
On Mon, Nov 9, 2009 at 1:01 PM, Mark Dickinson dicki...@gmail.com 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:
On Mon, Nov 9, 2009 at 1:21 PM, Stefan Krah stefan-use...@bytereef.org wrote:
Antoine Pitrou solip...@pitrou.net 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
Stefan Krah stefan-usenet at 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
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
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
___
On Mon, Nov 9, 2009 at 2:42 AM, Martin v. Löwis mar...@v.loewis.dewrote:
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
On Mon, Nov 9, 2009 at 10:09 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Nov 9, 2009 at 2:42 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
Interesting. Something goes wrong, it seems: if items get removed over
and over again, I think the set should shrink (not sure
2009/11/6 Raymond Hettinger pyt...@rcn.com:
[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
On Sun, Nov 8, 2009 at 19:50, geremy condra debat...@gmail.com wrote:
On Sun, Nov 8, 2009 at 9:41 PM, Guido van Rossum gu...@python.org wrote:
On Sun, Nov 8, 2009 at 5:45 PM, geremy condra debat...@gmail.com wrote:
I quote:
This PEP proposes a temporary moratorium (suspension) of all changes
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
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
On Mon, Nov 9, 2009 at 5:26 PM, Jasper Lievisse Adriaanse
jas...@humppa.nl 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
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,
On Tue, 10 Nov 2009 03:40:11 am Björn Lindqvist wrote:
2009/11/6 Raymond Hettinger pyt...@rcn.com:
[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.
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
Alexander Belopolsky wrote:
On Mon, Nov 9, 2009 at 10:09 AM, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
On Mon, Nov 9, 2009 at 2:42 AM, Martin v. Löwis mar...@v.loewis.de
wrote:
Interesting. Something goes wrong, it seems: if items get removed over
and over again, I think the
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
Nick Coghlan wrote:
Ben Finney wrote:
anatoly techtonik techto...@gmail.com 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
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,
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
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,
On Mon, Nov 9, 2009 at 3:50 PM, Martin v. Löwis mar...@v.loewis.dewrote:
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
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
On Mon, Nov 09, 2009 at 07:15:20PM +, Mark Dickinson wrote:
On Mon, Nov 9, 2009 at 5:26 PM, Jasper Lievisse Adriaanse
jas...@humppa.nl 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
On Mon, Nov 9, 2009 at 2:51 PM, Terry Reedy tjre...@udel.edu 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.
[ 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
39 matches
Mail list logo
