Death to tuples!

[Antoon Pardon]

Op 2005-12-02, Bengt Richter schreef <bokr at oz.net>:
> On 2 Dec 2005 13:05:43 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>
>>On 2005-12-02, Bengt Richter <bokr at oz.net> wrote:
>>> On 1 Dec 2005 09:24:30 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>>>
>>>>On 2005-11-30, Duncan Booth <duncan.booth at invalid.invalid> wrote:
>>>>> Antoon Pardon wrote:
>>>>>
>>
>>Personnaly I expect the following pieces of code
>>
>>  a = <const expression>
>>  b = <same expression>
>>
>>to be equivallent with
>>
>>  a = <const expression>
>>  b = a
>>
>>But that isn't the case when the const expression is a list.
>>
> ISTM the line above is a symptom of a bug in your mental Python source interpreter.
> It's a contradiction. A list can't be a "const expression".
> We probably can't make real progress until that is debugged ;-)
> Note: assert "const expression is a list" should raise a mental exception ;-)

Why should "const expression is a list" raise a mental exception with
me? I think it should have raised a mental exception with the designer.
If there is a problem with const list expression, maybe the language
shouldn't have something that looks so much like one?


>>This seems to go against the pythonic spirit of explicit is
>>better than implicit.
> Unless you accept that '[' is explicitly different from '(' ;-)
>
>>
>>It also seems to go against the way default arguments are treated.
>>I suspect another bug ;-)

The question is where is the bug? You can start from the idea that
the language is how it was defined and thus by definition correct
and so any problem is user problem.

You can also notice that a specific construct is a stumbling block
with a lot a new people and wonder if that doens't say something
about the design.

>>> Do you want
>>> to write an accurate historical account, or are you expressing discomfort
>>> from having had to revise your mental model of other programming languages
>>> to fit Python? Or do you want to try to enhance Python in some way?
>>
>>If there is discomfort, then that has more to do with having revised
>>my mental model to python in one aspect doesn't translate to
>>understanding other aspects of python enough.
>>
> An example?

Well there is the documentation about function calls, which states
something like the first positional argument provided will go
to the first parameter, ... and that default values will be used
for parameters not filled by arguments. Then you stumble on
the build in function range with the signature:

  range([start,] stop[, step])

Why if you only provide one arguments, does it go to the second
parameter?

Why are a number of constructs for specifying/creating a value/object
limited to subscriptions? Why is it impossible to do the following:

  a = ...
  f(...)
  a = 3:8
  tree.keys('a':'b')

Why is how you can work with defaults in slices not similar with
how you work with defaults in calls. You can do:

  lst[:7]

So why can't you call range as follows:

  range(,7)


lst[::] is a perfect acceptable slice, so why doesn't, 'slice()' work?

Positional arguments must come before keyword arguments, but when
you somehow need to do the following:

  foo(arg0, *args, kwd = value)

You suddenly find out the above is illegal and it should be written

  foo(arg0, kwd = value, *args)


>>people are making use of that rule too much, making the total language
>>less pratical as a whole.
> IMO this is hand waving unless you can point to specifics, and a kind of
> unseemly propaganda/innuendo if you can't.

IMO the use of negative indexing is the prime example in this case.
Sure it is practical that if you want the last element of a list,
you can just use -1 as a subscript. However in a lot of cases -1,
is just as out of bounds as an index greater than the list length.

At one time I was given lower en upperlimit for a slice from a list,
Both could range from 0 to len - 1. But I really needed three slices,
I needed lst[low:up], lst[low-1,up-1] and lst[low+1,up+1].
Getting lst[low+1:up+1] wasn't a problem, The way python treated
slices gave me just what I wanted, even if low and up were to big.
But when low or up were zero, the lst[low-1,up-1] gave trouble.

If I want lst[low:up] in reverse, then the following works in general:

  lst[up-1 : low-1 : -1]

Except of course when low or up is zero.


Of course I can make a subclass list that works as I want it, but IMO that
is the other way around. People should use a subclass for special cases,
like indexes that wrap around, not use a subclass to remove the special
casing, that was put in the base class.

Of course this example fits between the examples above, and some of
those probably will fit here too.

>>> or what are we pursuing?
>>
>>What I'm pursuing I think is that people would think about what
>>impractical effects can arise when you drop purity for practicallity.
> I think this is nicely said and important. I wish it were possible
> to arrive at a statement like this without wading though massive irrelevancies ;-)

Well I hope you didn't have to wade such much this time.

> BTW, I am participating in this thread more out of interest in
> the difficulties of human communication that in the topic per se,
> so I am probably OT ;-)

Well I hope you are having a good time anyway.

-- 
Antoon Pardon