Thoughts about Python

[Andres Rosado-Sepulveda]

Re: Thoughts about Python

Marco Aschwanden wrote:[color=blue][color=green][color=darkred]
>>>*** Problem: tuples are not necessary[/color]
>>
>>Says you! Here's a hint: hash([]).
>>
>>[...][/color]
>
>
> I suppose this is the argument: list are not immutable that is why
> they cannot be used a dict key... I wonder how many people use a tuple
> as dict key. This seems to be a common practice to justify its own
> "type". I admit, I can think of simple workarounds when there wouldn't
> be tuples (eg. Instead of transforming a list into tuple why not
> transforming it into a string).[/color]

I sometimes I use it. Especially if I use dates, where it makes sorting
so much easier. But it does have its usefulness.

Transforming a list to a string is not very good, because tuples may
contain user-defined classes that overwrite __lt__ and not __str__.

--
Andres Rosado
Email: andresr@despamm ed.com
ICQ: 66750646
AIM: pantear
Homepage: http://andres980.tripod.com/

Random Thought:[color=blue]
>[/color]
I'm just as sad as sad can be!
I've missed your special date.
Please say that you're not mad at me
My tax return is late.
-- Modern Lines for Modern Greeting Cards

[Mike C. Fletcher]

Re: Thoughts about Python

Marco Aschwanden wrote:
....
[color=blue]
>Maybe I don't get the point here: Why do dictionaries need tuples to
>work? I know that tuples can be used as keys... but how many times do
>you need tuples as dictionary keys (it would be simple to turn a list
>into an immutable string if really needed ("::".join(["a","b"]). But
>maybe tuples are used within dictionary in a way I don't know. If you
>could clarify on this point I will never ever say anything about
>"useless" tuples... instead I will start asking for "immutable
>dictionaries " 8o)
>
>[/color]
x = [1,2]
d = { x : 32 }
x.append( 3 )
d[ [1,2] ]

Does that last line raise a key-error, or return 32? Tuples are useful
as keys precisely because they are immutable, and hash based on their
contents/value. Mutable keys in dictionaries either need to be
"identity" based (which is far less useful that "value" based, (as then
you can only test whether a particular list is used as a key, not any
list with the same value)), or have some funky book-keeping rules
regarding what happens when the key changes (for example, convert the
key to a tuple under the covers so that all further changes to the key
are ignored in the dictionary).

To clarify regarding identity:

x = (1,2)
d = { x : 32 }
d[ x ]
d[ (1,2) ]

because they hash and compare based on value, tuples here can
unambiguously be used as value-based keys. With a list, were we to use
identity-based comparisons:

x = [1,2]
d = { x : 32 }
d[ x ] # would return a value
d[ [1,2] ] # would raise a key-error,
# defeating one of the most common usage patterns for
tuples-in-dictionaries

while if we were to use value-based comparisons set at key-specification
time:

x = [1,2]
d = { x: 32 }
x.append( 3 ) # possibly done in another thread...
del d[ x ] # would raise a key-error

to do lots of common operations (such as iterating through the keys of a
dictionary and deleting those which meet a particular test) in this
scenario you'd need to be able to return a static key in order to be
sure not to have it mutate while you're working, so you'd need an
exposed list-like immutable data-type (sound familiar).

Now, as shown above, we could do an explicit cast on setting a
dictionary value to make a list a tuple "under the covers" and thus get
back... but this is another "explicit is better than implicit" things.
The magic would up and bite in debugging weird corner cases more times
than it saved you a few seconds of thinking in the design stage. We
still have the static type, it would need to be dealt with in code, and
it would be surprising to see it show up instead of the lists we
originally used as the keys.

Using lists forced to strings would be a difficult sell even without the
problems described above, particularly as you can quite readily have
strings as keys already, so you get difficult-to-debug collisions where
a string just happens to equal the string-ified list representation of
some other value. The "explicit is better than implicit" axiom of
"import this" would then suggest that having an explicitly defined
immutable type (tuple) that hashes by value and is used to set keys in a
dictionary is a better choice than automagically coercing the lists to a
hidden type (or a string).

Don't worry about asking questions like this, by the way, it's good for
the perceptions of the community to be stirred every once in a while.
Enjoy yourself,
Mike

_______________ _______________ _________
Mike C. Fletcher
Designer, VR Plumber, Coder

http://members.rogers.com/mcfletch/

[David H Wild]

Re: Thoughts about Python

In article <15c2d03b.04022 41237.708cb4e8@ posting.google. com>, Marco
Aschwanden <PPNTWIMBXFFC@s pammotel.com> wrote:[color=blue][color=green]
> > Forget the speed and memory difference. The main argument for tuples
> > as a separate type are to use as dictionary keys. How do you propose
> > to handle dictionary keys without tuples?[/color][/color]
[color=blue]
> Maybe I don't get the point here: Why do dictionaries need tuples to
> work? I know that tuples can be used as keys... but how many times do
> you need tuples as dictionary keys (it would be simple to turn a list
> into an immutable string if really needed ("::".join(["a","b"]). But
> maybe tuples are used within dictionary in a way I don't know.[/color]

One of the reasons for doing this is that you can use a dictionary to
represent points with coordinates in a space of two or more dimensions. In
this case you need an immutable type, and you may need to get at its
elements.

--
__ __ __ __ __ ___ _______________ _______________ _______________
|__||__)/ __/ \|\ ||_ | / Acorn StrongArm Risc_PC
| || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines
_______________ ____________/ dhwild@argonet. co.uk

[Sean Ross]

Re: Thoughts about Python

----- Original Message -----
From: "Duncan Booth" <me@privacy.net >[color=blue][color=green]
> > *** Problem: tuples are not necessary
> >
> > Throw them away in the long run - for now make them depracted. It is
> > hard to argue in favour of tuples. There might to 2 reason:
> >
> > 1. It is MUCH faster than a list
> > 2. We can't live without an immutable list[/color]
>
> Forget the speed and memory difference. The main argument for tuples as a
> separate type are to use as dictionary keys. How do you propose to handle
> dictionary keys without tuples?[/color]

Well, you _could_ (you won't, but you could ;) take some ideas from Ruby:

"""
obj.freeze -> obj

Prevents further modifications to obj. A TypeError will be raised if
modification is attempted. There is no way to unfreeze a frozen object. See
also Object#frozen? .
"""

I would think that myList.freeze() should allow myList to be used as a
dictionary key. Of course, now you'd have to freeze your lists before using
them in a dictionary ... I don't know why I bother ...

[David M. Cooke]

Re: Thoughts about Python

At some point, PPNTWIMBXFFC@sp ammotel.com (Marco Aschwanden) wrote:
[color=blue][color=green]
>> Forget the speed and memory difference. The main argument for tuples as a
>> separate type are to use as dictionary keys. How do you propose to handle
>> dictionary keys without tuples?[/color]
>
> Maybe I don't get the point here: Why do dictionaries need tuples to
> work? I know that tuples can be used as keys... but how many times do
> you need tuples as dictionary keys (it would be simple to turn a list
> into an immutable string if really needed ("::".join(["a","b"]).[/color]

Simple, yes. Practicable, no. Wrong, certainly. For instance, I have a
lot of use cases where I use tuples of numbers -- (3, 4, 20.0101), eg.
It'd be a *hack* to convert that into a string, and the representation
would not be unique. This ain't Perl.

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)phy sics(dot)mcmast er(dot)ca

[Greg Ewing (using news.cis.dfn.de)]

Re: Thoughts about Python

Marco Aschwanden wrote:[color=blue]
> I know that tuples can be used as keys... but how many times do
> you need tuples as dictionary keys (it would be simple to turn a list
> into an immutable string if really needed ("::".join(["a","b"]).[/color]

Having used other languages where dictionary keys have to
be strings, I very much like the fact that I *don't* have to
do this in Python. Uniquely deriving a string from a non-flat
data structure is fraught with difficulties (e.g. in your example,
what if one of the list elements contains "::"? Or what if you
wanted to stringify [42, "elephant", myFunkyClassIns tance]?) You
end up having to carefully design a stringifying scheme for each
particular case. It's a big can of hassles that I can do without.

And using a tuple as a dict key is a more common thing to do than
you might think. It synergises with another feature of the Python
syntax, that commas (and not parentheses) are what generate tuples,
to give a very nice way of using a dict as a multi-dimensional table:

my_sparse_matri x = {}
my_sparse_matri x[17, 42] = 88

This works because '17, 42' is an expression yielding a
tuple, and tuples can be used as dict keys.

I hope you can see now that expecting Python programmers to
"simply" turn their lists into strings for use as dict
keys would *not* go down well in the Python community. :-)

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Greg Ewing (using news.cis.dfn.de)]

Re: Thoughts about Python

Marco Aschwanden wrote:[color=blue]
> Well, yeah, this is true and isn't. It is true that there is no rule
> how to name a class. To me a list / dict / string is a (basic) class
> (you take about types - the manuals does also) but why introduce new
> words, when the class-idiom is enough to explain everything.[/color]

Types and classes used to be very different things, but somewhere
around Python 2.1 or 2.2 a project was begun to unify the two
concepts, and nowadays the terms "type" and "class" are very
nearly synonymous. (There still exist what are now called "old-style
classes", but these are expected to disappear eventually, at which
time we will be able to stop talking about types at all and just
speak of classes.)

Before the type/class unification, builtins such as list and str
were functions. After the unification, it made sense to re-define
them as types/classes for compatibility, and for consistency the
new ones such as dict were named in the same style.

You're right that naming conventions (or lack thereof) in Python
leave something to be desired, but we're stuck with many of them
for historical reasons. Personally, I *like* that the most
fundamental built-in functions and classes have the shortest
and simplest names.

Your suggested convention (classes start with uppercase, functions
with lowercase) has its uses, and I tend to follow it in most of
the code that I write, but it has its drawbacks as well. A
counterargument often put forward is that users of a class usually
don't care whether something is really a class or whether it's
a factory function, and often you would like to be free to change
the implementation from one to the other without affecting client
code. With a naming convention that distinguishes classes from
functions, you can't do that.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Paul Prescod]

Re: Thoughts about Python

Greg Ewing (using news.cis.dfn.de ) wrote:
[color=blue]
>....
> You're right that naming conventions (or lack thereof) in Python
> leave something to be desired, but we're stuck with many of them
> for historical reasons.[/color]

Not really. If "open" can be renamed "file" it could also have been
renamed File. To be honest I think that the real problem is that Guido
is allergic to caps. I don't know how None snuck in. ;)
[color=blue]
> Your suggested convention (classes start with uppercase, functions
> with lowercase) has its uses, and I tend to follow it in most of
> the code that I write, but it has its drawbacks as well. A
> counterargument often put forward is that users of a class usually
> don't care whether something is really a class or whether it's
> a factory function, and often you would like to be free to change
> the implementation from one to the other without affecting client
> code. With a naming convention that distinguishes classes from
> functions, you can't do that.[/color]

Changing from a function to a class is _always_ easy.

def open(filename, flags):
return File(filename, flags)

The trickier issue is having the class itself export the interface the
client code is used to.

Changing from a class to a function is never really very safe:

class myobject(File):
...

if isinstance(myob ject, File):
....

How can you change File to be just a function safely? But anyhow, why
would you want to?

Paul Prescod

[Greg Ewing (using news.cis.dfn.de)]

Class == factory function considered harmful? (Re: Thoughts aboutPython)

Paul Prescod wrote:[color=blue]
> Changing from a class to a function is never really very safe:
>
> class myobject(File):
> ...
>
> if isinstance(myob ject, File):
> ....
>
> How can you change File to be just a function safely?[/color]

You can't, obviously. This demonstrates that there *is*
an important distinction to be made between classes and
functions -- you can subclass one and not the other!

Arguments like this (and others, such as the capability-based
security model problems) are making me re-consider whether
having classes also be factory functions is really such
a good idea. There are two distinct ways of using classes
in Python:

1. As a base class
2. As a factory function

and these have different degrees of coupling to the
implementation. Use (1) requires it to really be a
class, whereas (2) only requires it to be a callable
object.

For use (1), there is an advantage in having classes
named differently from functions -- if it's named like
a class, you know it's a class and can therefore
subclass it.

But for use (2), it's a disadvantage, since if something
starts out as a factory function and later changes into
a (published) class, all code using it has to change.

The only way I can see of reconciling these is to adopt
the convention that whenever you publish a class Foo,
you also publish a factory function foo() that instantiates
Foo. Users of it are expected to use Foo when subclassing
and foo() when instantiating.

Now, if you change the implementation so that Foo is
no longer a class, code which subclasses Foo will break --
there's no avoiding that. But code which only instantiates,
using foo(), will keep working.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand

http://www.cosc.canterbury.ac.nz/~greg

[Rainer Deyke]

Re: Thoughts about Python

Sean Ross wrote:[color=blue]
> """
> obj.freeze -> obj
>
> Prevents further modifications to obj. A TypeError will be raised if
> modification is attempted. There is no way to unfreeze a frozen
> object. See also Object#frozen? .
> """[/color]

An interesting idea. This would also allow other mutable types such as
dictionaries to be used as dictionary keys. I'm not sure if I like it, but
I am sure that I am not happy with the current list/tuple situation.

An alternate approach would be for the dictionary to lock the key objects
when they are inserted and unlock them when they are removed. Another would
be for dictionaries to keep a private copy of their keys.


--
Rainer Deyke - rainerd@eldwood .com - http://eldwood.com

[Joe Mason]

Re: Thoughts about Python

In article <c1gtlk$1iaul2$ 1@ID-169208.news.uni-berlin.de>, Greg Ewing (using news.cis.dfn.de ) wrote:[color=blue]
> Having used other languages where dictionary keys have to
> be strings, I very much like the fact that I *don't* have to
> do this in Python. Uniquely deriving a string from a non-flat
> data structure is fraught with difficulties (e.g. in your example,
> what if one of the list elements contains "::"? Or what if you
> wanted to stringify [42, "elephant", myFunkyClassIns tance]?) You
> end up having to carefully design a stringifying scheme for each
> particular case. It's a big can of hassles that I can do without.[/color]

TCL-style strings provice a good universal escaping mechanism for this,
as long as you're consistent.

Joe

[Marco Aschwanden]

Re: Thoughts about Python

"Mike C. Fletcher" <mcfletch@roger s.com> wrote in message news:<mailman.6 5.1077658396.85 94.python-list@python.org >...

I can see that tuples have their utility as a dict key. And from other
postings as well, I conclude: Tuples as dictionary keys are common
practice and are therefore here to stay.

Thanks,
Cheers,
Marco

[Marco Aschwanden]

Re: Thoughts about Python

cookedm+news@ph ysics.mcmaster. ca (David M. Cooke) wrote in message news:<qnk4qtgt7 j9.fsf@arbutus. physics.mcmaste r.ca>...[color=blue]
> At some point, PPNTWIMBXFFC@sp ammotel.com (Marco Aschwanden) wrote:
>[color=green][color=darkred]
> >> Forget the speed and memory difference. The main argument for tuples as a
> >> separate type are to use as dictionary keys. How do you propose to handle
> >> dictionary keys without tuples?[/color]
> >
> > Maybe I don't get the point here: Why do dictionaries need tuples to
> > work? I know that tuples can be used as keys... but how many times do
> > you need tuples as dictionary keys (it would be simple to turn a list
> > into an immutable string if really needed ("::".join(["a","b"]).[/color]
>
> Simple, yes. Practicable, no. Wrong, certainly. For instance, I have a
> lot of use cases where I use tuples of numbers -- (3, 4, 20.0101), eg.
> It'd be a *hack* to convert that into a string, and the representation
> would not be unique. This ain't Perl.[/color]
[color=blue][color=green][color=darkred]
>>> tup = (3, 4, 20.0101)
>>> stringified = str(tup)
>>> stringified[/color][/color][/color]
'(3, 4, 20.010100000000 001)' # 8o)
What is not unique about this string?
Okay, I can think of cases where this approach is problematic -
foremost when sorting is involved.
It is also a bit complicated to retrieve the values from the string
(it has to be "split"ted or "eval"ed back to a tuple or list).
If this pattern would be seldom used... but it seems, that everybody
except me uses this dicts as keys.

And yes, luckily this is not Perl.

Cheers,
Marco

[Marco Aschwanden]

Re: Thoughts about Python

> >*** Problem: clumsy properties for classes[color=blue]
>
> The problem is currently under discussion. Your fix is based on thinking
> 'self' to be a keyword, which it is not, instead of a usage convention for
> English language programmers.[/color]

Thanks! Now I know where my thinking went wrong... self is "another"
soft Python contract. This was now a real enlightment! I intermingled
Java's <this> with Python's <self>. They are not the same and <self>
is not "automatic" .
[color=blue]
> Quiz: how would you rewrite map(len, ['abc', (1,2,3,4), [5,6]]) if len()
> were a method?[/color]

The quiz is already (and very elegantly and better readable) solved
with a comprehension list. The OO-technique used is called
polymorphism... 8o).

Thanks for the hint on <self> is not "system var".
Cheers,
Marco

[Marco Aschwanden]

Re: Thoughts about Python

> > *** Problem: tuples are not necessary[color=blue]
>
> Frankly, there is very little in any programming language that is
> necessary. Back when I brushed up against computability theory,
> I found that all programs can be written in a language with one operation:
> a combination of subtract and conditional branch. That's hardly
> practical, though. The question is whether a feature serves a useful
> purpose.[/color]

I once read an interesting article that a programming language can be
reduced to 4 instructions: (1) input (2) output (3) if-then (4) goto.
All other commands / functions are built upon those 4 "basic ideas".

I would say: Python struggles for a maximum functionalty by preserving
optimal "simplicity ". And it does a good job at that! That's why I
like it so much.

I am not a reductionist. And I am not asking to create a reduced
Python. I had just the feeling that to learn about all specialities of
tuples is not worth the hassle... obviously I was wrong and you bring
some more aspects in favour tuples further down below:
[color=blue]
> Tuples serve two distinct purposes. One is as a cheap version
> of a C struct: that is, a data structure in which each element
> serves a conceptually different purpose.
>
> The other is as a structure that is immutable so it can be used
> as a key in a dict.
>
> One thing to understand about this is that immutability is key:
> dicts depend on having a hash key that is somehow derived
> from the content of the object, and if the content of a key
> changes that key will probably simply be unlocatable: it will be
> filed in the dict under the old rather than the new hash code.[/color]

Cheers,
Marco