Thoughts about Python

[Marco Aschwanden]

Re: Thoughts about Python

> I agree with you in all but that tuples are not[color=blue]
> necessary. Lists are the ones that are actually a
> hack for speed! :-)[/color]

Did you do some time profiling? I would be interested in the results.

[color=blue]
> 3_ I prefer reading from left to right instead from right
> to left (it makes the parenthesis less confusing too).
> Compare to:
>
> count=len(rever sed(sorted(appe nded(lst,3)))).
>
> Maybe I should learn Hebrew :-)
> Or we could always change it to
>
> $ lst|append -3|sort|reverse| len
>
> (in the end all are just filter patterns :))[/color]

This is an excellent example!
count = lst.append(3).s ort().reverse() .len()
is extremly readable but chaining of method calls is not supported in
Python. And I can live with it... Python has a more "expressive " path:
[color=blue][color=green][color=darkred]
>>> lst = []
>>> lst.append(3)
>>> lst.sort()
>>> lst.reverse()
>>> count = len(lst)[/color][/color][/color]

The last line looks a bit odd after all the dot-notations to see a
function-call in the last line.

[color=blue]
> 4_ If the python interpreter was smart enough sort()
> [...]
> Inmutable types are usually less "magical" than their
> mutable counterpart.
>
> For instance:
>[color=green][color=darkred]
> >>> lst1=[1,2]
> >>> lst2=lst1
> >>> lst2.append(3)
> >>> lst1[/color][/color]
> [1, 2, 3][color=green][color=darkred]
> >>> lst2[/color][/color]
> [1, 2, 3][color=green][color=darkred]
> >>> tup1=(1,2)
> >>> tup2=tup1
> >>> tup2=tup2+(3,)
> >>> tup1[/color][/color]
> (1, 2)[color=green][color=darkred]
> >>> tup2[/color][/color]
> (1, 2, 3)[color=green][color=darkred]
> >>>[/color][/color]
>
> Do you think a newbie would expect that a modification
> on one variable would have a effect on another?[/color]

Good point.

Thanx,
Marco

[Mike C. Fletcher]

Re: Thoughts about Python

Marco Aschwanden wrote:
....
[color=blue]
>'(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.
>
>[/color]
Actually, this is the classic problem of data-escaping. It's *possible*
to guarantee unique values when encoding as a string, but it's a *lot*
harder than just doing str( data ). You need to make sure that
different things are going to show up with different values:

d = {}
myWorkingList = (3,4,20.0101000 00000001)
somePieceOfData FromSomewhere = '(3, 4, 20.010100000000 001)'
d[ myWorkingList ] = 32
d[ somePieceOfData FromSomewhere ] = 34

That is, you'd need to encode into your string information regarding the
*type* and internal structure of the object to avoid collisions where
something just happens to look the same as another object, so something
like:

'(I3\nI4\nF20.0 10100000000001\ nt.' # for the tuple and
"S'(3,4,20.0101 00000000001)'\n p1\n." # for the string

Thing is, creating those static string representations is a major PITA
(in case you're wondering, the above are pickles of the values), and
would waste a lot of memory and processing cycles (to build the safe
string representation, (a task which is somewhat involved)) compared to
just using a pointer to the object and the object's built-in __hash__
and comparison methods.
[color=blue]
>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.
>
>[/color]
Round-trip-eval-capable objects are considered good style, but are not
by any means universal even among the built-in objects:
[color=blue][color=green][color=darkred]
>>> x = object()
>>> x[/color][/color][/color]
<object object at 0x00C7D3B8>

pickle/cPickle is closer to the idea of a robust mechanism for coercion
to/from string values, but even it has its limits, particularly with
respect to older built-in types that assumed they'd never be pickled.

wrt sorting, it's not really a huge issue, dictionaries are not ordered,
so to produce a sorted set you'd need to produce the keys as a
list/sequence of reconstituted objects anyway.

Have fun, and enjoy yourself,
Mike

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

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

[Michael Hudson]

Re: Thoughts about Python

PPNTWIMBXFFC@sp ammotel.com (Marco Aschwanden) writes:
[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.[/color]

I do, on occasion.
[color=blue]
> 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]

Oh yeah, transforming it into a string is really clean.
[color=blue][color=green]
> > I think you might be expecting something other of Python than what it
> > is. Nothing you suggest is completely ridiculous, just, well,
> > slightly un-Pythonic.[/color]
>
> un-Pythonic... this bytes ... hmm... why? Reading your comments it
> does not justify such a hard judgment - or does it?[/color]

I was trying to be polite...

I've been reading this list for about six (eek!) years now. You kind
of get used to posts like yours, and also to their posters realizing
that there is perhaps more sense behind Python's existing form than
they first imagine.

Cheers,
mwh

--
(Unfortunately, while you get Tom Baker saying "then we
were attacked by monsters", he doesn't flash and make
"neeeeooww-sploot" noises.)
-- Gareth Marlow, ucam.chat, from Owen Dunn's review of the year

[b-blochl]

Re: Thoughts about Python

Marco Aschwanden schrieb:
[color=blue]
>.............. .
>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".
>.............. .......
>
>[/color]

I am absolutely horrified to find goto as a necessary instruction of
programming! Real (modern) programming languages dont have a goto
statement, since extensive use is considered bad programming practice
in every language. If there is a goto statement - ignore it. "jump" or
"goto" hides the difference between selection and repetition und
unclarifies the program structure.

Bohm C. and G. Jacopini "Flow Diagrams, Turing Machines, and Languages
with Only Two Formation Rules." Communications of the ACM, Vol 9, No.5,
May 1966, pp336-371.
In this article they have shown, that any progrm can be written without
any goto statement. Structured programming is common goal since about
1970. (See O. J. Dahl and C. A. R Hoare, Notes on Structured
Programming, 1972)

Bernhard

[Richard Brodie]

Re: Thoughts about Python


"b-blochl" <bblochl2@compu serve.de> wrote in message
news:mailman.98 .1077714939.859 4.python-list@python.org ...
[color=blue]
> I am absolutely horrified to find goto as a necessary instruction of
> programming![/color]
[color=blue]
> ..Bohm C. and G. Jacopini "Flow Diagrams, Turing Machines, and Languages
> with Only Two Formation Rules."[/color]

You'll be sticking to the infinitely long tape then. ;)

[Terry Reedy]

Re: Thoughts about Python


"Marco Aschwanden" <PPNTWIMBXFFC@s pammotel.com> wrote in message
news:15c2d03b.0 402250123.151f0 6db@posting.goo gle.com...[color=blue]
> cookedm+news@ph ysics.mcmaster. ca (David M. Cooke) wrote in message[/color]
news:<qnk4qtgt7 j9.fsf@arbutus. physics.mcmaste r.ca>...[color=blue][color=green][color=darkred]
> >>> tup = (3, 4, 20.0101)
> >>> stringified = str(tup)
> >>> stringified[/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.[/color]

Mike pointed out the problem of making sure that different things get
different strings. For dict keys, there is also the problem of making sure
that 'different' things that hash equal and which have the same value as a
key get the same string, and you cannot do that without inventing a new
*non-invertible* stringify function. In particular, numbers are hashed by
value, with 0 == 0L == 0.0 => hash(0) == hash(0L) == hash(0.0), whereas
these would give three different strings with either str() or repr().
Example:
[color=blue][color=green][color=darkred]
>>> d={1:'one'}
>>> d[1.0][/color][/color][/color]
'one'

So, you make newstr((1,2)) == newstr((1.0,2L) ). Which means you must
eliminate the number type information and make newstr *not* invertible! Or
you could change the dict key rules;=).

Terry J. Reedy

[Rainer Deyke]

Re: Thoughts about Python

Mike C. Fletcher wrote:[color=blue]
> Actually, this is the classic problem of data-escaping. It's
> *possible* to guarantee unique values when encoding as a string, but
> it's a *lot* harder than just doing str( data ).[/color]

In Python it's one extra line of code.

from pickle import dumps
dumps(data)



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

[Mike C. Fletcher]

Re: Thoughts about Python

Rainer Deyke wrote:
[color=blue]
>Mike C. Fletcher wrote:
>
>[color=green]
>>Actually, this is the classic problem of data-escaping. It's
>>*possible* to guarantee unique values when encoding as a string, but
>>it's a *lot* harder than just doing str( data ).
>>
>>[/color]
>
>In Python it's one extra line of code.
>
>from pickle import dumps
>dumps(data)
>
>[/color]
Sure, even used that to create the examples :) , but it instantiates and
invokes a huge class (~500 lines of Python code) built using multiple
other dictionaries, each of which would need to be serviced themselves
without getting into weird recursion problems. Pickling machinery is
*really heavy* (i.e. a lot harder for the computer to do, and a lot more
hairy to program) than a few structure lookups to find functions
computing hashes and/or equalities and the inclusion of a static
sequence type.

Peace and lava lamps,
Mike

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

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

[Paul Prescod]

Re: Class == factory function considered harmful? (Re: Thoughtsabout Python)

Greg Ewing (using news.cis.dfn.de ) wrote:
[color=blue]
>...
>
> 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.[/color]

Okay, but is this ever a serious problem? Is changing classes into
functions and vice versa actually a common enough problem to worry about?

Paul Prescod

[Bob Ippolito]

Re: Thoughts about Python

On 2004-02-25 05:18:54 -0500, PPNTWIMBXFFC@sp ammotel.com (Marco
Aschwanden) said:
[color=blue][color=green]
>> I agree with you in all but that tuples are not
>> necessary. Lists are the ones that are actually a
>> hack for speed! :-)[/color]
>
> Did you do some time profiling? I would be interested in the results.
>
>[color=green]
>> 3_ I prefer reading from left to right instead from right
>> to left (it makes the parenthesis less confusing too).
>> Compare to:
>>
>> count=len(rever sed(sorted(appe nded(lst,3)))).
>>
>> Maybe I should learn Hebrew :-)
>> Or we could always change it to
>>
>> $ lst|append -3|sort|reverse| len
>>
>> (in the end all are just filter patterns :))[/color]
>
> This is an excellent example!
> count = lst.append(3).s ort().reverse() .len()
> is extremly readable but chaining of method calls is not supported in
> Python. And I can live with it... Python has a more "expressive " path:[/color]

You can 'chain method calls' all you want.. what you're missing here is
a python idiom: methods that mutate an object shall not return the
same object.

If the above code were to actually work, then "lst" would contain an
extra element and be stored in reverse sorted order, while "count"
would be the number you were trying to extract. The intent probably
was not to modify "lst", so this particular idiom just saved you the
time of debugging your broken code by encouraging you to do it the
right way the first time.

-bob