On 2007-04-25, Steve Holden <[EMAIL PROTECTED]> wrote:
> Neil Cerutti wrote:
>> That would be documented as undefined behavior, and users
>> exhorted not to do such things.
>>
>> Python's dictionaries are a proven winner--I'm definitely not an
>> advocate for changing them. But the general require
Neil Cerutti wrote:
> On 2007-04-24, Thomas Nelson <[EMAIL PROTECTED]> wrote:
>> On Apr 23, 10:38 pm, Mel Wilson <[EMAIL PROTECTED]> wrote:
>>> Even with a balanced tree, if a key in a node changes value,
>>> you may have to re-balance the tree. Nothing in a Python list
>>> says that a dictionary
On 2007-04-24, Thomas Nelson <[EMAIL PROTECTED]> wrote:
> On Apr 23, 10:38 pm, Mel Wilson <[EMAIL PROTECTED]> wrote:
>> Even with a balanced tree, if a key in a node changes value,
>> you may have to re-balance the tree. Nothing in a Python list
>> says that a dictionary tree would have to be re-b
On Apr 23, 10:38 pm, Mel Wilson <[EMAIL PROTECTED]> wrote:
> Neil Cerutti wrote:
> > The interpreter explains it: "A list is not a hashable object."
> > Choosing a hash table instead of some kind of balanced tree seems
> > to be just an optimization. ;)
>
> Even with a balanced tree, if a key in a
Neil Cerutti wrote:
> The interpreter explains it: "A list is not a hashable object."
> Choosing a hash table instead of some kind of balanced tree seems
> to be just an optimization. ;)
Even with a balanced tree, if a key in a node changes value, you may
have to re-balance the tree. Nothing in
On 2007-04-23, Steve Holden <[EMAIL PROTECTED]> wrote:
> Neil Cerutti wrote:
>> So the question becomes: Why do Python dictionaries require
>> keys to be of an immutable type?
>
> Because otherwise people would expect to be able to use a list
> to select a dictionary entry even after they'd modifie
Neil Cerutti wrote:
> On 2007-04-21, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>> On Fri, 20 Apr 2007 15:36:00 -0700, [EMAIL PROTECTED] wrote:
The article explains that, amongst other things, tuples are
faster than lists, so if you are working with constant values
(inmutables) they
En Mon, 23 Apr 2007 12:46:13 -0300, Neil Cerutti <[EMAIL PROTECTED]>
escribió:
> On 2007-04-23, Chris Cioffi <[EMAIL PROTECTED]> wrote:
>> On 23 Apr 2007 17:19:15 +0200, Neil Cerutti <[EMAIL PROTECTED]>
>> wrote:
>>> So the question becomes: Why do Python dictionaries require
>>> keys to be of a
On 2007-04-23, Chris Cioffi <[EMAIL PROTECTED]> wrote:
> On 23 Apr 2007 17:19:15 +0200, Neil Cerutti <[EMAIL PROTECTED]>
> wrote:
>> So the question becomes: Why do Python dictionaries require
>> keys to be of an immutable type?
>
> Dictionary keys are hashed values. If you change the key, you
> c
On 23 Apr 2007 17:19:15 +0200, Neil Cerutti <[EMAIL PROTECTED]> wrote:
> So the question becomes: Why do Python dictionaries require keys
> to be of an immutable type?
Dictionary keys are hashed values. If you change the key, you change
the hash and lose the pointer to the referenced object.
Or:
On 2007-04-21, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Fri, 20 Apr 2007 15:36:00 -0700, [EMAIL PROTECTED] wrote:
>>> The article explains that, amongst other things, tuples are
>>> faster than lists, so if you are working with constant values
>>> (inmutables) they are more indicated than li
On 2007-04-20, Gabriel Genellina <[EMAIL PROTECTED]> wrote:
> En Fri, 20 Apr 2007 15:28:51 -0300, Bjoern Schliessmann
><[EMAIL PROTECTED]> escribió:
>
>> Luis M. González wrote:
>>
>>> I don't remember exactly where I read about it, but Guido said
>>> once that tuples are being kept mainly for hi
[EMAIL PROTECTED] a écrit :
> Please help me think of an example where immutable tuples are
> essential.
Well, I don't know if they are "essential" - much of Python can be seen
as 'unessential' syntactic sugar (my, even the class statement is not
"essential" if you go that way).
> It seems that
[EMAIL PROTECTED] a écrit :
> On Apr 20, 4:37 pm, John Machin <[EMAIL PROTECTED]> wrote:
>
>>One inessential but very useful thing about tuples when you have a lot
>>of them is that they are allocated the minimum possible amount of
>>memory. OTOH lists are created with some slack so that appending
On Fri, 20 Apr 2007 15:36:00 -0700, [EMAIL PROTECTED] wrote:
>
>
>> The article explains that, amongst other things, tuples are faster
>> than lists, so if you are working with constant values (inmutables)
>> they are more indicated than lists.
>
> Thanks. I thought Python's design wasn't so c
On Fri, 20 Apr 2007 15:53:45 -0700, garrickp wrote:
> Speaking of inessential but very useful things, I'm also a big fan of
> the tuple swap...
> a = 2
> b = 3
> (a, b) = (b, a)
Since tuples are made by commas, not brackets, that can be written more
cleanly as:
a, b = b, a
The only exception is
[EMAIL PROTECTED] wrote:
> On Apr 20, 4:37 pm, John Machin <[EMAIL PROTECTED]> wrote:
>
>>One inessential but very useful thing about tuples when you have a lot
>>of them is that they are allocated the minimum possible amount of
>>memory. OTOH lists are created with some slack so that appending et
On Apr 20, 4:37 pm, John Machin <[EMAIL PROTECTED]> wrote:
> One inessential but very useful thing about tuples when you have a lot
> of them is that they are allocated the minimum possible amount of
> memory. OTOH lists are created with some slack so that appending etc
> can avoid taking quadratic
On Apr 21, 7:09 am, Luis M. González <[EMAIL PROTECTED]> wrote:
> On Apr 20, 3:28 pm, Bjoern Schliessmann
> [EMAIL PROTECTED]> wrote:
> > Luis M. González wrote:
> > > I don't remember exactly where I read about it, but Guido said
> > > once that tuples are being kept mainly for historical reasons
> The article explains that, amongst other things, tuples are faster
> than lists, so if you are working with constant values (inmutables)
> they are more indicated than lists.
Thanks. I thought Python's design wasn't so concerned with
optimizations.
Adding a new type "just" for optimization re
On Apr 20, 6:09 pm, Bjoern Schliessmann wrote:
> [EMAIL PROTECTED] wrote:
> > Please help me think of an example where immutable tuples are
> > essential.
>
> When used as dictionary keys (also everywhere else where they must
> be in a constant order).
>
> Yes, this *is* used in practice.
>
Yup -
On Apr 20, 3:28 pm, Bjoern Schliessmann wrote:
> Luis M. González wrote:
> > I don't remember exactly where I read about it, but Guido said
> > once that tuples are being kept mainly for historical reasons.
>
> Weren't tuples added when lists already existed?
>
> Regards,
>
> Björn
>
> --
> BOFH e
En Fri, 20 Apr 2007 15:28:51 -0300, Bjoern Schliessmann
<[EMAIL PROTECTED]> escribió:
> Luis M. González wrote:
>
>> I don't remember exactly where I read about it, but Guido said
>> once that tuples are being kept mainly for historical reasons.
>
> Weren't tuples added when lists already existe
Iou need only consider having cartesian coordinate sets as the keys
for an example. A 2 dimensional list might be overly expensive if your
coordinates span a large area but are relatively sparse.
--
http://mail.python.org/mailman/listinfo/python-list
Luis M. González wrote:
> I don't remember exactly where I read about it, but Guido said
> once that tuples are being kept mainly for historical reasons.
Weren't tuples added when lists already existed?
Regards,
Björn
--
BOFH excuse #101:
Collapsed Backbone
--
http://mail.python.org/mailm
On Apr 20, 2:06 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Please help me think of an example where immutable tuples are
> essential.
>
> It seems that everywhere a tuple is used one could just as easily use
> a list instead.
>
> chris
I don't remember exactly where I read about it, but
[EMAIL PROTECTED] wrote:
> Please help me think of an example where immutable tuples are
> essential.
When used as dictionary keys (also everywhere else where they must
be in a constant order).
Yes, this *is* used in practice.
Regards,
Björn
--
BOFH excuse #14:
sounds like a Windows probl
Please help me think of an example where immutable tuples are
essential.
It seems that everywhere a tuple is used one could just as easily use
a list instead.
chris
--
http://mail.python.org/mailman/listinfo/python-list
28 matches
Mail list logo
