[ 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 kn
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 Pytho
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
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 i
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
> 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
> remo
> 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
be
> 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,
M
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 on
> 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 thi
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
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
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.
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 we
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 -
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
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 PYTHO
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, seman
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
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
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
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
___
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
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
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):
>
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.
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
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 ==
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 beh
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 s
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 th
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 v
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
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 cal
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
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 use
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 musin
> 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
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 alternati
39 matches
Mail list logo
