Re: const objects (was Re: Death to tuples!)

On Wed, 14 Dec 2005 18:35:51 +, Tom Anderson wrote: > On Wed, 14 Dec 2005, Steven D'Aprano wrote: > >> On Wed, 14 Dec 2005 10:57:05 +0100, Gabriel Zachmann wrote: >> >>> I was wondering why python doesn't contain a way to make things "const"? >>> >>> If it were possible to "declare" variables

Re: const objects (was Re: Death to tuples!)

On Wed, 14 Dec 2005, Steven D'Aprano wrote: > On Wed, 14 Dec 2005 10:57:05 +0100, Gabriel Zachmann wrote: > >> I was wondering why python doesn't contain a way to make things "const"? >> >> If it were possible to "declare" variables at the time they are bound >> to objects that they should not al

Re: const objects (was Re: Death to tuples!)

Gabriel Zachmann wrote: > > I was wondering why python doesn't contain a way to make things "const"? > > If it were possible to "declare" variables at the time they are bound to > objects that they should not allow modification of the object, then we > would have a concept _orthogonal_ to data

Re: const objects (was Re: Death to tuples!)

Gabriel Zachmann wrote: > > I was wondering why python doesn't contain a way to make things "const"? > > If it were possible to "declare" variables at the time they are bound to > objects that they should not allow modification of the object, then we > would have a concept _orthogonal_ to data

Re: const objects (was Re: Death to tuples!)

Gabriel Zachmann wrote: [...] > > It seems to me that implementing that feature would be fairly easy. > All that would be needed is a flag with each variable. > It seems to me like it should be quite easy to add a sixth forward gear to my car, but I'm quite sure an auto engineer would quickly be

Re: const objects (was Re: Death to tuples!)

On Wed, 14 Dec 2005 10:57:05 +0100, Gabriel Zachmann wrote: > I was wondering why python doesn't contain a way to make things "const"? > > If it were possible to "declare" variables at the time they are bound to > objects that they should not allow modification of the object, then we would > ha

const objects (was Re: Death to tuples!)

I was wondering why python doesn't contain a way to make things "const"? If it were possible to "declare" variables at the time they are bound to objects that they should not allow modification of the object, then we would have a concept _orthogonal_ to data types themselves and, as a by-produc

Re: Death to tuples!

Op 2005-12-02, Bengt Richter schreef <[EMAIL PROTECTED]>: > On 2 Dec 2005 13:05:43 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: > >>On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote: >>> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>> On 2005-11-30, Duncan Booth <

Re: Death to tuples!

On 2 Dec 2005 13:05:43 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote: >> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >> >>>On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: Antoon Pardon wrote: > >Perso

Re: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: > On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote: >> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >>>On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: Antoon Pardon wrote: >>>I think one could argue that since '[]'

Re: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: >>> Well there are two possibilities I can think of: >>> >>> 1) >>> arg_default = ... >>> def f(arg = arg_default): >>> ... >> >> Yuch. Mostly because it doesn't work: >> >> arg_default = ... >> def f(arg = arg_default): >> ... >> >> arg_default =

Re: Death to tuples!

On 2005-12-02, Bengt Richter <[EMAIL PROTECTED]> wrote: > On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: > >>On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: >>> Antoon Pardon wrote: >>> > The left one is equivalent to: > > __anon = [] > def Foo(l): >

Re: Death to tuples!

On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote: > Antoon Pardon <[EMAIL PROTECTED]> writes: >> On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote: >>> Antoon Pardon <[EMAIL PROTECTED]> writes: I know what happens, I would like to know, why they made this choice. One could argue that

Re: Death to tuples!

Bengt Richter wrote: > >> > >> Because the empty list expression '[]' is evaluated when the > >> expression containing it is executed. > > > >Again you are just stating the specific choice python has made. > >Not why they made this choice. > Why are you interested in the answer to this question? ;

Re: Death to tuples!

On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote: >On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: >> Antoon Pardon wrote: >> The left one is equivalent to: __anon = [] def Foo(l): ... Foo(__anon) Foo(__anon) >>> >>> So, why sho

Re: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: > On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote: >> Antoon Pardon <[EMAIL PROTECTED]> writes: >>> I know what happens, I would like to know, why they made this choice. >>> One could argue that the expression for the default argument belongs >>> to the

Re: Death to tuples!

On 2005-12-01, Mike Meyer <[EMAIL PROTECTED]> wrote: > Antoon Pardon <[EMAIL PROTECTED]> writes: >> I know what happens, I would like to know, why they made this choice. >> One could argue that the expression for the default argument belongs >> to the code for the function and thus should be execut

Re: Death to tuples!

Mike Meyer wrote: > Antoon Pardon <[EMAIL PROTECTED]> writes: > > I know what happens, I would like to know, why they made this choice. > > One could argue that the expression for the default argument belongs > > to the code for the function and thus should be executed at call time. > > Not at def

Re: Death to tuples!

Antoon Pardon <[EMAIL PROTECTED]> writes: > I know what happens, I would like to know, why they made this choice. > One could argue that the expression for the default argument belongs > to the code for the function and thus should be executed at call time. > Not at definion time. Just as other exp

Re: Death to tuples!

Antoon Pardon wrote: > I know what happens, I would like to know, why they made this choice. > One could argue that the expression for the default argument belongs > to the code for the function and thus should be executed at call time. > Not at definion time. Just as other expressions in the func

Re: Death to tuples!

On 2005-11-30, Christophe <[EMAIL PROTECTED]> wrote: > Antoon Pardon a écrit : >> On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: >> >>>Antoon Pardon wrote: >>> But lets just consider. Your above code could simply be rewritten as follows. res = list() for i in range

Re: Death to tuples!

On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: > >>> The left one is equivalent to: >>> >>> __anon = [] >>> def Foo(l): >>>... >>> >>> Foo(__anon) >>> Foo(__anon) >> >> So, why shouldn't: >> >>res = [] >>for i in range(10): >> res.append(i*i) >>

Re: Death to tuples!

Antoon Pardon a écrit : > On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: > >>Antoon Pardon wrote: >> >>>But lets just consider. Your above code could simply be rewritten >>>as follows. >>> >>> res = list() >>> for i in range(10): >>> res.append(i*i) >>> >> >>I don't understand your p

Re: Death to tuples!

Antoon Pardon wrote: >> The left one is equivalent to: >> >> __anon = [] >> def Foo(l): >>... >> >> Foo(__anon) >> Foo(__anon) > > So, why shouldn't: > >res = [] >for i in range(10): > res.append(i*i) > > be equivallent to: > > __anon = list() > ... > >res = __anon

Re: Death to tuples!

On 2005-11-30, Duncan Booth <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: >> But lets just consider. Your above code could simply be rewritten >> as follows. >> >> res = list() >> for i in range(10): >> res.append(i*i) >> > I don't understand your point here? You want list() to creat

Re: Death to tuples!

Antoon Pardon wrote: > But lets just consider. Your above code could simply be rewritten > as follows. > > res = list() > for i in range(10): > res.append(i*i) > I don't understand your point here? You want list() to create a new list and [] to return the same (initially empty) list thr

Re: Death to tuples!

On 2005-11-29, Duncan Booth <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: > >> The question is, should we consider this a problem. Personnaly, I >> see this as not very different from functions with a list as a default >> argument. In that case we often have a list used as a constant too. >>

Re: Death to tuples!

Mike Meyer wrote: >>> An object is compatible with an exception if it is either the object >>> that identifies the exception, or (for exceptions that are classes) >>> it is a base class of the exception, or it is a tuple containing an >>> item that is compatible with the exception. >> >> Requiring

Re: Death to tuples!

> The new intended use is as an immutable sequence type, not a > "lightweight C struct". The new name to denote this new use - > following in the footsteps of the set type - is "frozenlist". The > changes to the implementation would be adding any non-mutating methods > of list to tuple, which appea

Re: Death to tuples!

Duncan Booth <[EMAIL PROTECTED]> writes: > Dan Bishop wrote: >>> Is there any place in the language that still requires tuples instead >>> of sequences, except for use as dictionary keys? >> >> The % operator for strings. And in argument lists. >> >> def __setitem__(self, (row, column), value):

Unifying Attributes and Names (was: Re: Death to tuples!)

Bengt Richter wrote: > If we had a way to effect an override of a specific instance's attribute accesses > to make certain attribute names act as if they were defined in type(instance), and > if we could do this with function instances, and if function local accesses would > check if names were on

Re: Death to tuples!

On Tue, 29 Nov 2005 09:26:53 -0600, [EMAIL PROTECTED] wrote: > >--cvVnyQ+4j833TQvp >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline > >On Tue, Nov 29, 2005 at 10:41:13AM +, Bengt Richter wrote: >> Seems like str.__mod__ could take an arbitary (BTW, matching length, >>

Re: Death to tuples!

>> Actually, no, I hadn't. I don't use tuples that way. It's rare when >> I have a tuple whose elements are not all floats, strings or ints, >> and I never put mutable containers in them. Alex> You never have a dict whose values are lists? Sorry, incomplete explanation. I ne

Unifying Attributes and Names (was: Re: Death to tuples!)

Bengt Richter wrote: > If we had a way to effect an override of a specific instance's attribute > accesses > to make certain attribute names act as if they were defined in > type(instance), and > if we could do this with function instances, and if function local accesses > would > check if name

Re: Death to tuples!

Dan Bishop wrote: >> Is there any place in the language that still requires tuples instead >> of sequences, except for use as dictionary keys? > > The % operator for strings. And in argument lists. > > def __setitem__(self, (row, column), value): >... > Don't forget the exception specifica

Re: Death to tuples!

[EMAIL PROTECTED] wrote: > Having a general frozen() system makes a lot of sense. People use > tuples for two different things: as a lightweight record type (e.g., > (x, y) coordinate pairs), and as an immutable list. The latter is not > officially sanctioned but is widely believed to be the pur

Re: Death to tuples!

On Tue, Nov 29, 2005 at 10:41:13AM +, Bengt Richter wrote: > Seems like str.__mod__ could take an arbitary (BTW, matching length, > necessarily? > Or just long enough?) iterable in place of a tuple, just like it can take > an arbitrary mapping object in place of a dict for e.g. '%(name)s'% >

Re: Death to tuples!

On 28 Nov 2005 14:48:35 GMT, Duncan Booth <[EMAIL PROTECTED]> wrote: >Antoon Pardon wrote: > >>> >>> def func(x): >>> ... if x in [1,3,5,7,8]: >>> ... print 'x is really odd' >>> ... >>> >>> dis.dis(func) >>> ... >>>3 20 LOAD_FAST0 (x) >>> 23 LOAD_

Re: Death to tuples!

Having a general frozen() system makes a lot of sense. People use tuples for two different things: as a lightweight record type (e.g., (x, y) coordinate pairs), and as an immutable list. The latter is not officially sanctioned but is widely believed to be the purpose for tuples. And the value of

Re: Death to tuples!

Paddy wrote: > I would consider > t = ([1,2], [3,4]) > to be assigning a tuple with two list elements to t. > The inner lists will be mutable but I did not know you could change the > outer tuple and still have the same tuple object. you can't. but since hash(tuple) is defined in terms of map(

Re: Death to tuples!

Antoon Pardon wrote: > The question is, should we consider this a problem. Personnaly, I > see this as not very different from functions with a list as a default > argument. In that case we often have a list used as a constant too. > > Yet python doesn't has a problem with mutating this list so

Re: Death to tuples!

On 27 Nov 2005 23:33:27 -0800, "Dan Bishop" <[EMAIL PROTECTED]> wrote: >Mike Meyer wrote: >> It seems that the distinction between tuples and lists has slowly been >> fading away. What we call "tuple unpacking" works fine with lists on >> either side of the assignment, and iterators on the values

Re: Death to tuples!

On 2005-11-28, Duncan Booth <[EMAIL PROTECTED]> wrote: > Antoon Pardon wrote: > >>> >>> def func(x): >>> ... if x in [1,3,5,7,8]: >>> ... print 'x is really odd' >>> ... >>> >>> dis.dis(func) >>> ... >>>3 20 LOAD_FAST0 (x) >>> 23 LOAD_CONST

Re: Death to tuples!

Rikard Bosnjakovic wrote: > Steven Bethard wrote: > > > [1]http://www.python.org/dev/summary/2005-09-01_2005-09-15.html#string-formatting-in-python-3-0 > > Reading this link, I find this: > > "Currently, using % for string formatting has a number of inconvenient > consequences: > > * preceden

Re: Death to tuples!

Steven Bethard wrote: > [1]http://www.python.org/dev/summary/2005-09-01_2005-09-15.html#string-formatting-in-python-3-0 > Reading this link, I find this: "Currently, using % for string formatting has a number of inconvenient consequences: * precedence issues: "a%sa" % "b"*4 produces 'ab

Re: Death to tuples!

<[EMAIL PROTECTED]> wrote: ... > Actually, no, I hadn't. I don't use tuples that way. It's rare when I have > a tuple whose elements are not all floats, strings or ints, and I never put > mutable containers in them. You never have a dict whose values are lists? Or never call .items (or .iter

Re: Death to tuples!

Mike Meyer <[EMAIL PROTECTED]> wrote: ... > concept of tuple unpacking. When names are bound, you can use a > "tuple" for an lvalue, and the sequence on the rhs will be "unpacked" > into the various names in the lvalue: > > for key, value = mydict.iteritems(): ... > a, (b, c) =

Re: Death to tuples!

Mike Meyer wrote: > Steven Bethard <[EMAIL PROTECTED]> writes: > >>Dan Bishop wrote: >> >>>Mike Meyer wrote: >>> >>> Is there any place in the language that still requires tuples instead of sequences, except for use as dictionary keys? >>> >>>The % operator for strings. And in argument li

Re: Death to tuples!

Antoon Pardon wrote: > Op 2005-11-28, Peter Hansen schreef <[EMAIL PROTECTED]>: >>Mike Meyer wrote: >>>Is there any place in the language that still requires tuples instead >>>of sequences, except for use as dictionary keys? >> >>Would it be possible to optimize your "frozenlist" so that the object

Re: Death to tuples!

>>> For those of us not following this thread closely, can you identify >>> cases where tuples are mutable, not hashable or can't be used as >>> dictionary keys? I've never encountered any such cases. >> >> t = ([1,2], [3,4]) ... t = ([1,2], [3,4]) t[0

Re: Death to tuples!

[EMAIL PROTECTED] writes: > Mike> Tuples have the problem that they are immutable, except when > Mike> they're not (or for proper values of immutable, your > Mike> choice). They're hashable, except when they're not. Or > Mike> equivalently, they can be used as dictionary keys - or s

Re: Death to tuples!

"Paddy" <[EMAIL PROTECTED]> writes: > I would consider > t = ([1,2], [3,4]) > to be assigning a tuple with two list elements to t. > The inner lists will be mutable but I did not know you could change the > outer tuple and still have the same tuple object. Whether t is mutable is a question of d

Re: Death to tuples!

I would consider t = ([1,2], [3,4]) to be assigning a tuple with two list elements to t. The inner lists will be mutable but I did not know you could change the outer tuple and still have the same tuple object. - Pad. -- http://mail.python.org/mailman/listinfo/python-list

Re: Death to tuples!

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: >[EMAIL PROTECTED] writes: >> >> For those of us not following this thread closely, can you identify >> cases where tuples are mutable, not hashable or can't be used as >> dictionary keys? I've never encountered any such

Re: Death to tuples!

[EMAIL PROTECTED] writes: > For those of us not following this thread closely, can you identify cases > where tuples are mutable, not hashable or can't be used as dictionary keys? > I've never encountered any such cases. t = ([1,2], [3,4]) -- http://mail.python.org/mailman/listinfo/python-list

Re: Death to tuples!

Mike> Tuples have the problem that they are immutable, except when Mike> they're not (or for proper values of immutable, your Mike> choice). They're hashable, except when they're not. Or Mike> equivalently, they can be used as dictionary keys - or set Mike> elements - except wh

Re: Death to tuples!

Peter Hansen <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> It seems that the distinction between tuples and lists has slowly been >> fading away. What we call "tuple unpacking" works fine with lists on >> either side of the assignment, and iterators on the values side. IIRC, >> "apply" used to

Re: Death to tuples!

Steven Bethard <[EMAIL PROTECTED]> writes: > Dan Bishop wrote: >> Mike Meyer wrote: >> >>>Is there any place in the language that still requires tuples instead >>>of sequences, except for use as dictionary keys? >> The % operator for strings. And in argument lists. >> def __setitem__(self, (row, c

Re: Death to tuples!

In article <[EMAIL PROTECTED]>, Mike Meyer <[EMAIL PROTECTED]> wrote: > >Is there any place in the language that still requires tuples instead >of sequences, except for use as dictionary keys? > >If not, then it's not clear that tuples as a distinct data type >still serves a purpose in the languag

Re: Death to tuples!

Dan Bishop wrote: > Mike Meyer wrote: > >>Is there any place in the language that still requires tuples instead >>of sequences, except for use as dictionary keys? > > The % operator for strings. And in argument lists. > > def __setitem__(self, (row, column), value): >... Interesting that b

Re: Death to tuples!

Antoon Pardon wrote: >> >>> def func(x): >> ... if x in [1,3,5,7,8]: >> ... print 'x is really odd' >> ... >> >>> dis.dis(func) >> ... >>3 20 LOAD_FAST0 (x) >> 23 LOAD_CONST 2 (1) >> 26 LOAD_CONST 3 (3) >>

Re: Death to tuples!

Op 2005-11-28, Peter Hansen schreef <[EMAIL PROTECTED]>: > Mike Meyer wrote: >> It seems that the distinction between tuples and lists has slowly been >> fading away. What we call "tuple unpacking" works fine with lists on >> either side of the assignment, and iterators on the values side. IIRC, >>

Re: Death to tuples!

Mike Meyer wrote: > It seems that the distinction between tuples and lists has slowly been > fading away. What we call "tuple unpacking" works fine with lists on > either side of the assignment, and iterators on the values side. IIRC, > "apply" used to require that the second argument be a tuple; i

Re: Death to tuples!

Mike Meyer enlightened us with: > Is there any place in the language that still requires tuples > instead of sequences, except for use as dictionary keys? Anything that's an immutable sequence of numbers. For instance, a pair of coordinates. Or a value and a weight for that value. > If not, then

Re: Death to tuples!

Mike Meyer wrote: > It seems that the distinction between tuples and lists has slowly been > fading away. What we call "tuple unpacking" works fine with lists on > either side of the assignment, and iterators on the values side. IIRC, > "apply" used to require that the second argument be a tuple; i

Re: Death to tuples!

Mike Meyer <[EMAIL PROTECTED]> writes: > The new intended use is as an immutable sequence type, not a > "lightweight C struct". The new name to denote this new use - > following in the footsteps of the set type - is "frozenlist". The > changes to the implementation would be adding any non-mutating