Implicit conversion to boolean in if and while statements

[Chris Angelico]

Indeed. That wording was a bit clumsy on my part.


I may have spoken too soon on this issue. My reasoning for /not/ having a literal set syntax was due to symbol congestion, however as i described in another post, the problem can be solved by literally "type declaring" the literal.

Or doing what you were pointing and laughing at Pike for, and using
two-symbol delimiters. You could even make it majorly logical:

list_ = [[ 1, 2, 3 ]]
tuple_ = ([ 1, 2, 3 ])
dict_ = [{ 1, 2, 3 }]
frozendict_ = ({ 1, 2, 3 })
set_ = [< 1, 2, 3 >]
frozenset_ = (< 1, 2, 3 >)

I'm not actually sure where I stand on that argument. Some of those
types are distinctly unusual (when would you use frozendict?), and may
well not need literal notation. But it is nice to have them all.

ChrisA

 

[Chris Angelico]

Yes i could, however by doing so i would be ignoring the inconsistent elephant in the room. My crusade is to bring consistency and logic to languages, and if i have any free time afterwards, to remove multiplicity. There are two types of people in the world Chris, those that lead and those that follow.

In other words, you prefer to argue than to code.

Well i would expect anyone who considers himself a python programmer (notto mention "pythonista"!) to at minimum be familiar with the stdlib. That does not mean he must have attained black belt level kung-fu in /every/ stdlib module, but he must at least /know/ all the modules names and all typesthat Python offers. Is that really too much to ask Chris?

Actually, it is. How many modules and types does Python offer? Can you
tell me, without looking it up? Okay. Now how many does Ruby offer?
Presumably you extend the same courtesy to other languages. Now
imagine someone who knows twenty languages. Will s/he know their
entire stdlibs?

If there is anyone here who can honestly boast knowing the ENTIRE
stdlib of a language the size of Python, I would be impressed. Very
impressed.

ChrisA

 

[Rick Johnson]

[...]
Or doing what you were pointing and laughing at Pike for, and using
two-symbol delimiters. You could even make it majorly logical:

list_ = [[ 1, 2, 3 ]]
tuple_ = ([ 1, 2, 3 ])
dict_ = [{ 1, 2, 3 }]
frozendict_ = ({ 1, 2, 3 })
set_ = [< 1, 2, 3 >]
frozenset_ = (< 1, 2, 3 >)

I am vehemently against using more than one "opening seq char" and one "closing seq char". It works fine for single depth sequences, however, once youstart nesting the mental focus required to parse the doubled openers/closers is headache inducing. I would accept wrapping the literal in some sort of declaration though, something like i proposed earlier in the thread. The easiest is to use:

set({1,2,3})

but that looks like a function call! So we'd need a unique syntax. Either asingle tag like:

set{1,2,3}

Or we could use start and end tags like:

set{1,2,3}set

where "set{" and "}set" are delimiters. For lists, tuples, and dict we would use the short form because these literals are far too ubiquitous:

[1,2,3] # list
{k:v} # dict
(1,2,3) # tuple

However, the grouping chars for tuples has always been confusing because they can clash with grouping of expressions. What is this?

(1)

It's NOT a tuple! But it looks like a tuple! What is this:

1,2

it IS a tuple, but it does not look like a tuple!

That's an unfortunate side effect of a poorly thought-out tuple syntax.

 

[Rick Johnson]

[...]
Or doing what you were pointing and laughing at Pike for, and using
two-symbol delimiters. You could even make it majorly logical:

list_ = [[ 1, 2, 3 ]]
tuple_ = ([ 1, 2, 3 ])
dict_ = [{ 1, 2, 3 }]
frozendict_ = ({ 1, 2, 3 })
set_ = [< 1, 2, 3 >]
frozenset_ = (< 1, 2, 3 >)

I am vehemently against using more than one "opening seq char" and one "closing seq char". It works fine for single depth sequences, however, once youstart nesting the mental focus required to parse the doubled openers/closers is headache inducing. I would accept wrapping the literal in some sort of declaration though, something like i proposed earlier in the thread. The easiest is to use:

set({1,2,3})

but that looks like a function call! So we'd need a unique syntax. Either asingle tag like:

set{1,2,3}

Or we could use start and end tags like:

set{1,2,3}set

where "set{" and "}set" are delimiters. For lists, tuples, and dict we would use the short form because these literals are far too ubiquitous:

[1,2,3] # list
{k:v} # dict
(1,2,3) # tuple

However, the grouping chars for tuples has always been confusing because they can clash with grouping of expressions. What is this?

(1)

It's NOT a tuple! But it looks like a tuple! What is this:

1,2

it IS a tuple, but it does not look like a tuple!

That's an unfortunate side effect of a poorly thought-out tuple syntax.

 

[Rick Johnson]

Well i would expect anyone who considers himself a
python programmer (not to mention "pythonista"!) to at
minimum be familiar with the stdlib. [...]

[...]

If there is anyone here who can honestly boast knowing the ENTIRE
stdlib of a language the size of Python, I would be impressed. Very
impressed.

I am sure there are quite a few Chris. But if you expect to around making statements like: "Python does not have typed arrays", then don't get all upset when someone corrects you.

Maybe, before you go and pop your mouth off next time, if it isn't too muchtrouble, i mean, i don't want you to get a cramp in your wrist or a blister on your finger, much less a headache reading a few lines of documentation, but if is not too much to ask, "Mr. Angelico", i would suggest you stuff this tiny little code snippet into your favorite Python interpreter and runit!

py> help('modules')

See, some python functions are useful.

 

[Rick Johnson]

Well i would expect anyone who considers himself a
python programmer (not to mention "pythonista"!) to at
minimum be familiar with the stdlib. [...]

[...]

If there is anyone here who can honestly boast knowing the ENTIRE
stdlib of a language the size of Python, I would be impressed. Very
impressed.

I am sure there are quite a few Chris. But if you expect to around making statements like: "Python does not have typed arrays", then don't get all upset when someone corrects you.

Maybe, before you go and pop your mouth off next time, if it isn't too muchtrouble, i mean, i don't want you to get a cramp in your wrist or a blister on your finger, much less a headache reading a few lines of documentation, but if is not too much to ask, "Mr. Angelico", i would suggest you stuff this tiny little code snippet into your favorite Python interpreter and runit!

py> help('modules')

See, some python functions are useful.

 

[Chris Angelico]

I am vehemently against using more than one "opening seq char" and one "closing seq char". ... we could use start and end tags like:

set{1,2,3}set

where "set{" and "}set" are delimiters.

Interesting. So what you're actually against is the symbols. Okay. I
have a bit of a Scheme (rubs hands together with glee) for you. We can
thtandardithe on jutht one thymbol pair and uthe wordth for the retht.
And to make it clear that thith ith no function call, we'll put the
word *inthide* the parenthetheth.

(set 1 2 3)
(dict 1 2 3 4) ; implicitly pairs up the arguments
(tuple 1 2)
(list 1 2 3 4) ; This seems like a real good idea.

ChrisA

 

[Chris Angelico]

I am sure there are quite a few Chris. But if you expect to around makingstatements like: "Python does not have typed arrays", then don't get all upset when someone corrects you.

Oh, I don't mind being corrected on those sorts of points. And if ever
I say "Python doesn't have a module for creating a DNS server", I will
be quite happy to be corrected, because DNS servers are fun.

But my statement wasn't based on my own knowledge of the stdlib, but
rather on this:

I'm a bit unnerved by the sum function. Summing a sequence only makes sense if the sequence in question contains /only/ numeric types. For that reason i decided to create a special type for holding Numerics.

Why create a special type if it already exists?

Maybe, before you go and pop your mouth off next time, if it isn't too much trouble, i mean, i don't want you to get a cramp in your wrist or a blister on your finger, much less a headache reading a few lines of documentation, but if is not too much to ask, "Mr. Angelico", i would suggest you stuff this tiny little code snippet into your favorite Python interpreter and run it!

py> help('modules')

See, some python functions are useful.

Yep. By the way, how does the help function fit into your wonderfully
OOP model? What's it a method on?

ChrisA

 

[88888 Dihedral]

Rick Johnsonæ–¼ 2013å¹´2月11日星期一UTC+8下åˆ9時13分58秒寫é“：

[...]

Or doing what you were pointing and laughing at Pike for, and using

two-symbol delimiters. You could even make it majorly logical:
list_ = [[ 1, 2, 3 ]]

tuple_ = ([ 1, 2, 3 ])

dict_ = [{ 1, 2, 3 }]

frozendict_ = ({ 1, 2, 3 })

set_ = [< 1, 2, 3 >]

frozenset_ = (< 1, 2, 3 >)

I am vehemently against using more than one "opening seq char" and one "closing seq char". It works fine for single depth sequences, however, once you start nesting the mental focus required to parse the doubled openers/closers is headache inducing. I would accept wrapping the literal in some sortof declaration though, something like i proposed earlier in the thread. The easiest is to use:



set({1,2,3})



but that looks like a function call! So we'd need a unique syntax. Eithera single tag like:



set{1,2,3}



Or we could use start and end tags like:



set{1,2,3}set



where "set{" and "}set" are delimiters. For lists, tuples, and dict we would use the short form because these literals are far too ubiquitous:



[1,2,3] # list

{k:v} # dict

(1,2,3) # tuple



However, the grouping chars for tuples has always been confusing because they can clash with grouping of expressions. What is this?



(1)



It's NOT a tuple! But it looks like a tuple! What is this:



1,2



it IS a tuple, but it does not look like a tuple!



That's an unfortunate side effect of a poorly thought-out tuple syntax.

I am thinking a mutated list temporarily is useful when a list is to be used
to be iterated through all of its elements efficiently.

A permanently mutated list is a tuple of constant objects.

As for the set type, I prefer to use the operations of the list,
dictionaries in Python to act for the designed purposes.

 

[88888 Dihedral]

Rick Johnsonæ–¼ 2013å¹´2月11日星期一UTC+8下åˆ9時13分58秒寫é“：

[...]

Or doing what you were pointing and laughing at Pike for, and using

two-symbol delimiters. You could even make it majorly logical:
list_ = [[ 1, 2, 3 ]]

tuple_ = ([ 1, 2, 3 ])

dict_ = [{ 1, 2, 3 }]

frozendict_ = ({ 1, 2, 3 })

set_ = [< 1, 2, 3 >]

frozenset_ = (< 1, 2, 3 >)

I am vehemently against using more than one "opening seq char" and one "closing seq char". It works fine for single depth sequences, however, once you start nesting the mental focus required to parse the doubled openers/closers is headache inducing. I would accept wrapping the literal in some sortof declaration though, something like i proposed earlier in the thread. The easiest is to use:



set({1,2,3})



but that looks like a function call! So we'd need a unique syntax. Eithera single tag like:



set{1,2,3}



Or we could use start and end tags like:



set{1,2,3}set



where "set{" and "}set" are delimiters. For lists, tuples, and dict we would use the short form because these literals are far too ubiquitous:



[1,2,3] # list

{k:v} # dict

(1,2,3) # tuple



However, the grouping chars for tuples has always been confusing because they can clash with grouping of expressions. What is this?



(1)



It's NOT a tuple! But it looks like a tuple! What is this:



1,2



it IS a tuple, but it does not look like a tuple!



That's an unfortunate side effect of a poorly thought-out tuple syntax.

I am thinking a mutated list temporarily is useful when a list is to be used
to be iterated through all of its elements efficiently.

A permanently mutated list is a tuple of constant objects.

As for the set type, I prefer to use the operations of the list,
dictionaries in Python to act for the designed purposes.

 

[Rick Johnson]

Interesting. So what you're actually against is the symbols.

Nothing really. Chars are innocent creatures. They themselves know not of evil. However groups of chars have the capacity to collectively emit evil inthe form of density, of which who's demon spawn is "incomprehensibility"!

Okay. I
have a bit of a Scheme (rubs hands together with glee) for you.
[snip lisping]

(set 1 2 3)
(dict 1 2 3 4) ; implicitly pairs up the arguments
(tuple 1 2)
(list 1 2 3 4) ; This seems like a real good idea.

Well i must admit that this syntax would be beautifully consistent--except for the dict which is far too implicit! I would gravitate to something morelike:

(dict 'a':1 'b':2 'name':'fred')

But what happens when we start nesting?

(dict:
'employees':
(list
'sarahdict
'age':22,
'position:'CSR'),
'john'dict
'age':46,
'position':'grounds'),
'albert'dict
'age':85,
'position':'CEO'),
), # end list
'key1'tuple 1,2,10.1),
'key2'set 10,20,30),
) # end dict

As opposed to:

{
'employees':[
'sarah:{
'age':22,
'position:'CSR'},
'john':{
'age':46,
'position':'grounds'},
'albert':{
'age':85,
'position':'CEO'},
],
'key1'1,2,10.1),
'key2':set([10,20,30]),
}

But then again, literals are code smell anyway!

http://en.wikipedia.org/wiki/Code_smell

I use literals like anyone else, but i sometimes wonder if i could live without them (probably not string literals though!!!). Many of us can even remember a day (before we learned about recursion) when we would write out gobs and gobs of unnecessary literals that could easily be built with a for loop. I think _most_ literals could just as easily be replicated in code. Consider this alternative approach to building the the dict above:

database = d = {}
d['sarah'] = k = {}
k['age'] = 22
k['position'] = 'CSR'
d['john'] = k = {}
k['age'] = 46
k['position'] = 'grounds'
d['albert'] = k = {}
k['age'] = 85
k['position'] = 'CEO'
d['key1'] = (1,2,10.1)
d['key2'] = [10,20,30]

Not as structured as the literal, but by utilizing indention the message will become clearer. Oh, yeah, better make sure we built that structure correctly!

py> import pprint
py> pprint.pprint(d)
{'albert': {'age': 85, 'position': 'CEO'},
'john': {'age': 46, 'position': 'grounds'},
'key1': (1, 2, 10.1),
'key2': [10, 20, 30],
'sarah': {'age': 22, 'position': 'CSR'}}

But then the old "for x in LITERAL_SEQ" and the "if this in LITERAL_SEQ" will bite you. Damn literals! Can't live with them, can't live without them.

 

[Rick Johnson]

Interesting. So what you're actually against is the symbols.

Nothing really. Chars are innocent creatures. They themselves know not of evil. However groups of chars have the capacity to collectively emit evil inthe form of density, of which who's demon spawn is "incomprehensibility"!

Okay. I
have a bit of a Scheme (rubs hands together with glee) for you.
[snip lisping]

(set 1 2 3)
(dict 1 2 3 4) ; implicitly pairs up the arguments
(tuple 1 2)
(list 1 2 3 4) ; This seems like a real good idea.

Well i must admit that this syntax would be beautifully consistent--except for the dict which is far too implicit! I would gravitate to something morelike:

(dict 'a':1 'b':2 'name':'fred')

But what happens when we start nesting?

(dict:
'employees':
(list
'sarahdict
'age':22,
'position:'CSR'),
'john'dict
'age':46,
'position':'grounds'),
'albert'dict
'age':85,
'position':'CEO'),
), # end list
'key1'tuple 1,2,10.1),
'key2'set 10,20,30),
) # end dict

As opposed to:

{
'employees':[
'sarah:{
'age':22,
'position:'CSR'},
'john':{
'age':46,
'position':'grounds'},
'albert':{
'age':85,
'position':'CEO'},
],
'key1'1,2,10.1),
'key2':set([10,20,30]),
}

But then again, literals are code smell anyway!

http://en.wikipedia.org/wiki/Code_smell

I use literals like anyone else, but i sometimes wonder if i could live without them (probably not string literals though!!!). Many of us can even remember a day (before we learned about recursion) when we would write out gobs and gobs of unnecessary literals that could easily be built with a for loop. I think _most_ literals could just as easily be replicated in code. Consider this alternative approach to building the the dict above:

database = d = {}
d['sarah'] = k = {}
k['age'] = 22
k['position'] = 'CSR'
d['john'] = k = {}
k['age'] = 46
k['position'] = 'grounds'
d['albert'] = k = {}
k['age'] = 85
k['position'] = 'CEO'
d['key1'] = (1,2,10.1)
d['key2'] = [10,20,30]

Not as structured as the literal, but by utilizing indention the message will become clearer. Oh, yeah, better make sure we built that structure correctly!

py> import pprint
py> pprint.pprint(d)
{'albert': {'age': 85, 'position': 'CEO'},
'john': {'age': 46, 'position': 'grounds'},
'key1': (1, 2, 10.1),
'key2': [10, 20, 30],
'sarah': {'age': 22, 'position': 'CSR'}}

But then the old "for x in LITERAL_SEQ" and the "if this in LITERAL_SEQ" will bite you. Damn literals! Can't live with them, can't live without them.

 

[Rick Johnson]

[...]
But my statement wasn't based on my own knowledge of the stdlib, but
rather on this:

I'm a bit unnerved by the sum function. Summing a
sequence only makes sense if the sequence in question
contains /only/ numeric types. For that reason i decided
to create a special type for holding Numerics.

Why create a special type if it already exists?

Because at the time i made this statement we were discussing 100% true OOP (you know, the kind of paradigm where object definition identifiers start with a capital letter? *estoeric-wink*), but more importantly because i don't find the current implementation of array and list to be consistent.

Yep. By the way, how does the help function fit into your wonderfully
OOP model? What's it a method on?

Well since /all/ objects will have help available it should be defined Object#help and then propagate downwards. But even true OOP languages need a few global functions... *gasp*... oh yes! A few that come to mind include:

globals, locals, vars, compile, eval, exec, input, print, dir

And don't forget, we still have module namespace to deal with!

 

[Rick Johnson]

[...]
But my statement wasn't based on my own knowledge of the stdlib, but
rather on this:

I'm a bit unnerved by the sum function. Summing a
sequence only makes sense if the sequence in question
contains /only/ numeric types. For that reason i decided
to create a special type for holding Numerics.

Why create a special type if it already exists?

Because at the time i made this statement we were discussing 100% true OOP (you know, the kind of paradigm where object definition identifiers start with a capital letter? *estoeric-wink*), but more importantly because i don't find the current implementation of array and list to be consistent.

Yep. By the way, how does the help function fit into your wonderfully
OOP model? What's it a method on?

Well since /all/ objects will have help available it should be defined Object#help and then propagate downwards. But even true OOP languages need a few global functions... *gasp*... oh yes! A few that come to mind include:

globals, locals, vars, compile, eval, exec, input, print, dir

And don't forget, we still have module namespace to deal with!

 

[Mark Janssen]

Just because /everything/ in Python is an object does not mean that Python is 100% OOP.

The whole idea of "make everything an object" is possibly a misguided
sense of puritanism anyway. I wouldn't harp on that point to much.
But I really like your other developments. Like the following

If so, Python would have a supertype called "Collection" that wold defineall methods that operate on collections. Some of these include:

len, any, all, length, isempty, __getitem__, __setitem__, etc...

I think this is a great idea and fixes a language wart which put
irrelevant methods into the builtin namespace.

Then any collection subtype would inherit from this supertype and get themethods for free.

Yes. OOP encapsulation. But I question whether strings should be
considered collections. This is a spurious usage issue, not something
in an integrated object model (see below on what I mean).

Using built-in functions to operate on objects is foolish because you areplacing extra burden on the programmer to know which /functions/ work withwhich /types/. The *only* functions that should be global are the kind that will work on *ANY* object. But then again, the Object type could hold these methods!

Exactly. This gets us closer to the real Python3000 that I've been
waiting for....

len, all, and any (just to name a few) only work for collections types and as such should be methods of these types. The global functions:

sum, len, any, all, enumerate, map, max, min, reversed, sorted, zip

can only be applied to sequence types, or subtypes of a sequence type. Sousing a /real/ OOP paridigm we would do the following:

## START TRUE OOP PARIDIGM ##
[[snip]]

This is a great start, I think, but I think it's time to really
re-evaluate the whole data model again. Before Python was trying to
"have everything", and have the flexibility to adapt for everyone, but
sometimes I think there's too much flexibility and options and it
leads to sloppiness. I would argue it's time for a refactor and
re-think the object model.

class Object(SuperType):
def dir
def help
def id
def isinstance?(Type)
def issubclass?(Type)
def super
def type

I like the general line-of-thought, but some of these are
questionable. I think it's essential to have help() outside any class
-- the built-in, global methods serve an important purpose of setting
the culture for a language, and help, (and my proposed test()) builtin
are part of (or would be) the community.

class SequenceBase(Object):
def sum
def filter(proc)
def map
def max
def min
def reverse
def reduce(proc)

Here again, you see how the early python community put these in the
global namespace because of the bias that they had such (admittedly()
cool builtin collection types in the language. But now, it's
interesting to reconsider these ideas.

## END TRUE OOP PARIDIGM ##

You see, 100% OOP uses encapsulation, inheritance, sub-typing, etc, etc.... But most fundamental to OOP is interface (methods belonging to objects), not global functions applied to objects in some haphazard fashion that someself-appointed dictator pull from his backside due to his fear of true OOPstyle!

That's not quite fair to the BDFL; you're criticizing the community
that made Python great. That, of course, doesn't mean that it's still
logical to keep them out there in the global scope, exposed for all to
see.

Python is not 100% OOP. Heck you cannot fairly apply a specific percentage level because Python's level of OOP is defined by each user of the language. The best way to describe Python is as promiscuous language who secretlylongs to be 100% OOP, and to fulfill this fantasy it cross-dresses in OOP lingerie on the weekends.

That's a funny quote, besides its questionable accuracy, but your
initial sentences point out that having a unified data model might
actually be of use. A unified data model does for data what lexical
definitions and parsers do for code: organize it in a well-defined
way that is a *complete* specification for all possible data
organizations. (But see my other posts about that.... ;^)

Mark
Tacoma, Wa

 

[Chris Angelico]

A permanently mutated list is a tuple of constant objects.

I nominate this line as "bemusing head-scratcher of the week".

ChrisA

 

[Rick Johnson]

I nominate this line as "bemusing head-scratcher of the week".

Actually the statement is fact IF you can grok it through the eyes of clarity.

"A permanently mutated list..."

A list that has been mutated permanently, that is, it cannot be changed back into a list. psst: i have a sneaking suspicion that he his referring to tuples, let's see.

"...is a tuple..."

Ha! Well in Python the immutable sequence type /is/ a tuple after all.

"...of constant objects..."

The tuple contains objects, and it's objects will maintain a constant ordering (relatively in tuple structure) until until the tuple's death.

Your confusion may stem from interpreting "constant" as the CS term "CONSTANT"[1]; whereby the objects in the tuple are programming CONSTANTS, that is, unable to change. But in reality, although a tuple (bka:StaticList) cannot expand to add more objects, or shrink to eject existing objects, the objects themselves CAN change their own internal state WITHOUT disrupting the immutable harmony of the tuple.

Observe:

py> class Foo(object):
pass
py> foo = Foo()
py> t = (1,'1', foo)
py> t
(1, '1', <__main__.Foo object at 0x0267BF50>)
py> t[-1].bar = "abc"
py> t
(1, '1', <__main__.Foo object at 0x0267BF50>)

Or by expanding a list

py> t = (1,2,3)
py> t = t+([],)
py> t
(1, 2, 3, [])
py> t[-1].append('circus')
py> t
(1, 2, 3, ['circus'])

[1] Which is an unfortunate side-effect of polysemy and compounded exponentially by naive (and sometimes a purely malevolent intent when) transformation of words into esoteric problem domains.

 

[Rick Johnson]

I nominate this line as "bemusing head-scratcher of the week".

Actually the statement is fact IF you can grok it through the eyes of clarity.

"A permanently mutated list..."

A list that has been mutated permanently, that is, it cannot be changed back into a list. psst: i have a sneaking suspicion that he his referring to tuples, let's see.

"...is a tuple..."

Ha! Well in Python the immutable sequence type /is/ a tuple after all.

"...of constant objects..."

The tuple contains objects, and it's objects will maintain a constant ordering (relatively in tuple structure) until until the tuple's death.

Your confusion may stem from interpreting "constant" as the CS term "CONSTANT"[1]; whereby the objects in the tuple are programming CONSTANTS, that is, unable to change. But in reality, although a tuple (bka:StaticList) cannot expand to add more objects, or shrink to eject existing objects, the objects themselves CAN change their own internal state WITHOUT disrupting the immutable harmony of the tuple.

Observe:

py> class Foo(object):
pass
py> foo = Foo()
py> t = (1,'1', foo)
py> t
(1, '1', <__main__.Foo object at 0x0267BF50>)
py> t[-1].bar = "abc"
py> t
(1, '1', <__main__.Foo object at 0x0267BF50>)

Or by expanding a list

py> t = (1,2,3)
py> t = t+([],)
py> t
(1, 2, 3, [])
py> t[-1].append('circus')
py> t
(1, 2, 3, ['circus'])

[1] Which is an unfortunate side-effect of polysemy and compounded exponentially by naive (and sometimes a purely malevolent intent when) transformation of words into esoteric problem domains.

 

[Chris Angelico]

Your confusion may stem from interpreting "constant" as the CS term "CONSTANT"[1]; whereby the objects in the tuple are programming CONSTANTS, that is, unable to change.

Uhh, yeah. Not being Humpty Dumpty, I interpret "constants" to mean
"things that won't change". (Or, eliding the second t, as "I've found
a friend". But I digress.) There's just something about that word
"constant" that really suggests a meaning of "constant".

ChrisA

 

[88888 Dihedral]

Rick Johnsonæ–¼ 2013å¹´2月13日星期三UTC+8上åˆ1時48分07秒寫é“：

I nominate this line as "bemusing head-scratcher of the week".

Actually the statement is fact IF you can grok it through the eyes of clarity.



"A permanently mutated list..."



A list that has been mutated permanently, that is, it cannot be changed back into a list. psst: i have a sneaking suspicion that he his referring totuples, let's see.



"...is a tuple..."



Ha! Well in Python the immutable sequence type /is/ a tuple after all.



"...of constant objects..."



The tuple contains objects, and it's objects will maintain a constant ordering (relatively in tuple structure) until until the tuple's death.

a1=[1,2,3]
tuple1=(a1,4,5,6)
tuple1 ([1, 2, 3], 4, 5, 6)
a1=[1,2]
tuple1 ([1, 2, 3], 4, 5, 6)

Yes, a tuple of constant objects is still not clear.

Your confusion may stem from interpreting "constant" as the CS term "CONSTANT"[1]; whereby the objects in the tuple are programming CONSTANTS, that is, unable to change. But in reality, although a tuple (bka:StaticList) cannot expand to add more objects, or shrink to eject existing objects, the objects themselves CAN change their own internal state WITHOUT disrupting theimmutable harmony of the tuple.



Observe:



py> class Foo(object):

pass

py> foo = Foo()

py> t = (1,'1', foo)

py> t

(1, '1', <__main__.Foo object at 0x0267BF50>)

py> t[-1].bar = "abc"

py> t

(1, '1', <__main__.Foo object at 0x0267BF50>)



Or by expanding a list



py> t = (1,2,3)

py> t = t+([],)

py> t

(1, 2, 3, [])

py> t[-1].append('circus')

py> t

(1, 2, 3, ['circus'])



[1] Which is an unfortunate side-effect of polysemy and compounded exponentially by naive (and sometimes a purely malevolent intent when) transformation of words into esoteric problem domains.