python gripes survey
Ryan Lowe
language is perfect. id like to make a list of some of the aspects people
find most annoying, regardless of their feasibility of implementation. for
instance, i discussed putting if clauses in for loops, and i noticed another
thread about allowing {} and [] to be added and subtracted. if its something
from another language (especially an obscure one), please explain how it
works in case people like myself dont know the language.
thanks,
ryan
Bertrand Geston
PUL1b.166506$_R5.62...@news4.srv.hcvlny.cv.net...
http://zephyrfalcon.org/labs/python_pitfalls.html
http://www.amk.ca/python/writing/warts.html
http://www.ferg.org/projects/python_gotchas.htmlv
bg
Ryan Lowe
"Bertrand Geston" <berg...@yahoo.fr> wrote in message
news:bi8nrd$1fnkl$1...@sinclair.be.wanadoo.com...
Cy Edmunds
news:bi8nrd$1fnkl$1...@sinclair.be.wanadoo.com...
Thanks for the links -- nice stuff there!
--
Cy
http://home.rochester.rr.com/cyhome/
Geoff Howland
wrote:
Just to point some things out since I started the {} [] thread. I was
trying to do something hacky, and while I wanted the [].len() type
calls for my team mates, I never had a problem with the current len()
and understand the reasoning behind it. [].len() is more uniform, but
it also changes the requirements for the language in a duplicated
fashion, since the test for __len__() will always exist as well.
So while I think they may have been reasonable requests, Im not sure
theyre really pitfalls, and Im not sure they would even work out that
well on a large scale which is why I wanted to implement it and test
it out myself.
-Geoff Howland
http://ludumdare.com/
Ryan Lowe
news:7s6gkv031b940dsc5...@4ax.com...
> On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" <ryan...@msn.com>
> wrote:
>
> Just to point some things out since I started the {} [] thread. I was
> trying to do something hacky, and while I wanted the [].len() type
> calls for my team mates, I never had a problem with the current len()
> and understand the reasoning behind it. [].len() is more uniform, but
> it also changes the requirements for the language in a duplicated
> fashion, since the test for __len__() will always exist as well.
i was actually more impressed with the union/intersection of lists and
dictionaries. why the hell cant you join two dictionaries like you can two
list? the len thing is a pretty minor issue in my mind.
> So while I think they may have been reasonable requests, Im not sure
> theyre really pitfalls, and Im not sure they would even work out that
> well on a large scale which is why I wanted to implement it and test
> it out myself.
i guess my request was a little vague. im actually more interested in
missing funtionality of the python language, as opposed to pitfalls, warts,
minor syntax issues. to put it another way, why should anyone want to use a
general language other than python (ignoring speed and not including
languages designed for a specific/limited domain)? what types of things are
just plain easier to achieve in smalltalk, perl, icon, lisp, ruby, etc?
there must be plenty of ideas that people have had, but havent bothered to
write a PEP for or couldnt even begin to find a way to integrate them into
python.
Dave Brueck
Well, will your list include anti-gripes, as in things a few people gripe
about but that many others consider to be positive features? Here's a short
list of my anti-gripes - features that I like but some people complain about;
features that, if removed or changed too much, would make me like Python
less:
- no assignment in if/while
- whitespace significant to both programmer and the language
- {} + {} not allowed ;-)
- private variables are a language-encouraged convention instead of an attempt
to babysit the programmer
- no macros
- no end-block tag required
- list comprehensions
- a "self" parameter is passed to all class methods, and by convention we all
call it "self"
- tendency to prefer keywords over special characters
- thread-safe operations on fundamental objects (e.g. two threads doing
somedict['foo'] = x at the same time won't cause Python to crash or corrupot
somdict)
- list.sort() doesn't return the sorted list
There are more, but this list is just off the top of my head. :)
-Dave
Andrew Dalke
> i was actually more impressed with the union/intersection of lists and
> dictionaries. why the hell cant you join two dictionaries like you can two
> list? the len thing is a pretty minor issue in my mind.
Mostly because there isn't a good reason for what
a = {1: "a"} + {1: "b"}
should be. The most likely solution is
a = {1: "a"}
a.update({1:"b"})
However, there is something tricky even here. Watch this:
>>> d = {1: "a"}
>>> d.update({True: "b"})
>>> d
{1: 'b'}
>>>
The key came from the first dict, the value came from the
second.
BTW, an alternative to
a = d1.copy()
a.update(d2)
is
d = dict(d1.items() + d2.items())
> i guess my request was a little vague. im actually more interested in
> missing funtionality of the python language
Missing language functionality is not the same as missing Python
functionality. What you're asking is - why do other languages
exist? Python lacks native support for:
code blocks (like Smalltalk)
macros (like Lisp)
lazy evaluation (like .. Haskell? One of the functional languages)
rich N-dimensional operators (like APL)
predicate logic (like Prolog)
symbolic math manipulation (like Mathematica)
literate programming (like WEB -> Pascal/TeX)
aspect-oriented programming (like AspectJ)
stack nature (like Postscript (I had Forth here but didn't want a dup :))
color as part of syntax (like ColorForth)
programming by contract (like Eiffel)
fixed-point data types, as for money (like REXX)
control over the memory arenas use by an object (like C++)
direct access to memory, eg, as for I/O to periphials (like C)
support for high-performance multiprocessor computing (like Fortran90)
(some are available as external modules, like FixedPoint, but are
not native.)
There's easily more - just look at how many languages have
been invented over the last few decades.
Andrew
da...@dalkescientific.com
Ryan Lowe
news:mailman.1061701097...@python.org...
> Here's a short list of my anti-gripes - features that I like but some
people complain about;
> features that, if removed or changed too much, would make me like Python
> less:
>
> - no assignment in if/while
> - whitespace significant to both programmer and the language
> - {} + {} not allowed ;-)
> - private variables are a language-encouraged convention instead of an
attempt
> to babysit the programmer
> - no macros
> - no end-block tag required
> - list comprehensions
> - a "self" parameter is passed to all class methods, and by convention we
all
> call it "self"
> - tendency to prefer keywords over special characters
> - thread-safe operations on fundamental objects (e.g. two threads doing
> somedict['foo'] = x at the same time won't cause Python to crash or
corrupot
> somdict)
> - list.sort() doesn't return the sorted list
>
> There are more, but this list is just off the top of my head. :)
> -Dave
id agree with most of those too. i hadnt really thought about the sort()
function, but that does seem a little inconsistent with other methods which
do return a value. im sure there is a good reason for this (speed?).
Ryan Lowe
news:MOX1b.1042$Jh2...@newsread4.news.pas.earthlink.net...
> Ryan Lowe:
> > i was actually more impressed with the union/intersection of lists and
> > dictionaries. why the hell cant you join two dictionaries like you can
two
> > list? the len thing is a pretty minor issue in my mind.
>
> Mostly because there isn't a good reason for what
>
> a = {1: "a"} + {1: "b"}
>
> should be. The most likely solution is
>
> a = {1: "a"}
> a.update({1:"b"})
works for me, but i dont want to argue about it when there is another thread
about this.
>
> However, there is something tricky even here. Watch this:
>
> >>> d = {1: "a"}
> >>> d.update({True: "b"})
> >>> d
> {1: 'b'}
that is weird; i thought 2.3 made bool its own type? but i guess its still a
subtype of int. though, i cant imagine when this would come up in a real
situation anyway.
> Missing language functionality is not the same as missing Python
> functionality. What you're asking is - why do other languages
> exist? Python lacks native support for:
yea, this is what im talking about. maybe you could explain a couple of
these a bit?
> code blocks (like Smalltalk)
is this what it sounds like? do you name a block of code and call it like an
inline function with no parameters?
> macros (like Lisp)
> lazy evaluation (like .. Haskell? One of the functional languages)
i learned and forgot what lazy evaluation was. does it buy you anything
other than speed in certain cases
> rich N-dimensional operators (like APL)
python could do the same with functions or named operators
> symbolic math manipulation (like Mathematica)
this is approaching the limited domain area. plus mathematica spent a LOT of
money and time writing that software. its not something your average
open-sourcer would probably wish to tackle in their spare time. of course,
it would be nice to have a symbolic module :)
> color as part of syntax (like ColorForth)
color meaning built-in? this i have never heard of. how does it work?
> predicate logic (like Prolog)
> literate programming (like WEB -> Pascal/TeX)
> aspect-oriented programming (like AspectJ)
> stack nature (like Postscript (I had Forth here but didn't want a dup
:))
> programming by contract (like Eiffel)
can any of these be explained quickly?
Peter Hansen
>
> "Andrew Dalke" <ada...@mindspring.com> wrote:
> > >>> d = {1: "a"}
> > >>> d.update({True: "b"})
> > >>> d
> > {1: 'b'}
>
> that is weird; i thought 2.3 made bool its own type? but i guess its still a
> subtype of int. though, i cant imagine when this would come up in a real
> situation anyway.
It could easily come up, and in any case notice that the result is
the same even if the True is replaced with a floating point value 1.0
in the above example. Dictionary keys are not matched by identity.
-Peter
Andrew Dalke
> > >>> d = {1: "a"}
> > >>> d.update({True: "b"})
> > >>> d
> > {1: 'b'}
>
> that is weird; i thought 2.3 made bool its own type? but i guess its still
a
> subtype of int. though, i cant imagine when this would come up in a real
> situation anyway.
Let k1 and k2 be two keys. If k1==k2 then dicts consider that
either one may be used as the key. Since 1 exists in d, and 1 == True
(== 1.0, == complex(1,0)) then the update keeps the old key rather
than do the extra work of replacing it.
It isn't quite this easy. k1 and k2 must also have aligned hashs,
which is used to prune the number of == tests done.
> > code blocks (like Smalltalk)
>
> is this what it sounds like? do you name a block of code and call it like
an
> inline function with no parameters?
Consider the following Ruby code
[ 1, 3, 5 ].each { |i| puts i }
The
|i| puts i
is an *unnamed* code block which does take parameters.
The [] is a container, and [].each sends the code block to
each of the elements in the container. See
http://www.rubycentral.com/book/tut_containers.html
> i learned and forgot what lazy evaluation was. does it buy you anything
> other than speed in certain cases
Sometimes it's easier to work with infinite sets directly
rather than work on iterators going through infinite sets.
Eg, suppose you wanted the first 5 primes which were
fibonacci sequences. Then you can do something like
(primes && fibonacci)[:5]
> > rich N-dimensional operators (like APL)
>
> python could do the same with functions or named operators
Sure. But they aren't built-in, and there is something
cool about using non-ASCII symbols in your code.
(As someone with a now-dusty math degree, I am
pretty used to glyphs like greek letters in my work.)
> > symbolic math manipulation (like Mathematica)
>
> this is approaching the limited domain area. plus mathematica spent a LOT
of
> money and time writing that software. its not something your average
> open-sourcer would probably wish to tackle in their spare time. of course,
> it would be nice to have a symbolic module :)
Agreed for the first. The point remains that it is something
which Python doesn't have. It could be added as modules, but
Mathematica's syntax makes it easier to express some equations
than Python does.
> > color as part of syntax (like ColorForth)
>
> color meaning built-in? this i have never heard of. how does it work?
Google. "color forth". "I'm feeling lucky"
http://www.colorforth.com/
] In Forth, a new word is defined by a preceeding colon, words inside
] a definition are compiled, outside are executed. In colorForth a new
] word is red, green words are compiled, yellow executed. This use of
] color further reduces the syntax, or punctuation, needed. It also makes
] explicit how the computer will interpret each word.
> > predicate logic (like Prolog)
> > literate programming (like WEB -> Pascal/TeX)
> > aspect-oriented programming (like AspectJ)
> > stack nature (like Postscript (I had Forth here but didn't want a dup
> :))
> > programming by contract (like Eiffel)
>
> can any of these be explained quickly?
Google. "predicate logic" prolog. "I'm feeling lucky"
http://remus.rutgers.edu/cs314/f2002/uli/lectures/lec24.pdf
Google. "literate programming" web. "I'm feeling lucky"
http://www.literateprogramming.com/
Google. "aspect-oriented programming". "I'm feeling lucky"
http://aosd.net/
Google. "FORTH". "I'm feeling lucky". Browse a few links
to the FAQ
ftp://ftp.forth.org/pub/Forth/FAQ/general
Here's another route. Go to FOLDOC ("Free on-line dictionary
of computing"). Search for "FORTH"
] 1. <language> An interactive extensible language using postfix
] syntax and a data stack, developed by Charles H. Moore in
] the 1960s.
Follow the link for "postfix notation"
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?postfix+syntax
"Programming by contract" should be "Design by contract".
In addition to Google for these searches, try the PPR wiki,
eg http://c2.com/cgi/wiki?DesignByContract
Andrew
da...@dalkescientific.com
nnes
Can you post a link to that thread?
I have never understood why python has [].count() or "".count() but
len([]) and len("").
Why not make len, sum, str, repr, etc just methods of the base object
class with specific implementations for different types. Instead of
doing len([]) we could do [].len().
This is actually possible already in part. I think you can do
[].__len__(). But I never understood the reasoning behind making these
special __x__() methods instead of doing a plain x() and using it like
obj.x().
The only case I can think of, where it would look kind of odd would be
floating points like:
niceoutput=2.3.str()
Anyway since Pythonistas are smart, it can not be a wart of the
language and must be some lack in my understanding :)
awaiting-to-be-enlightened-yours
Nestor
John Roth
"Ryan Lowe" <ryan...@msn.com> wrote in message
news:ex42b.177723$_R5.67...@news4.srv.hcvlny.cv.net...
It's because <list>.sort modifies the list in place. All of the list
functions that do this return None instead of the modified list.
The reason is to baby-sit the programmer: Guido thought that
if these methods returned the list, people would think that the
original, unmodified list still existed soemwhere.
As far as I'm concerned, it's a wart. Ruby (IMO) deals with this
issue better.
John Roth
>
>
>
>
Patrick Lioi
foo = [1, 2, 3]
foo[] = 4 # foo now equals [1, 2, 3, 4]
I would also like to see what would probably end up being called
"generator comprehensions". That is definitely not my own idea, but
for the life of me I can't remember where I first heard about it.
Imagine being able to throw the yield keyword into a list
comprehension syntax in order to take advantage of list
comprehension's in a memory-efficient way, something kinda like this:
foo = [yield i*i for i in xrange(100)]
John Roth
"nnes" <prue...@latinmail.com> wrote in message
news:d8778a53.03082...@posting.google.com...
Mostly history. Python doesn't have a standard class that's
a base class for everything, although it's moving that way
with the object class in 2.2 So while it would have been
a nice idea for there to be an object.len() method inherited
by all classes, this wasn't (and still isn't) really possible.
The __method__ methods are implementation details;
they are (mostly) required private methods that are
used by the various operators and global functions.
The len() global function, for example, calls the
__len__() method.
I'm not sure what the ramifications of just
dumping the relevant global functions into the
type and object classes would be. I suspect that,
since old code isn't expecting most of them, you'd
get a strange mismash of methods that sometimes
work, sometimes don't, and sometimes are used
for unrelated purposes.
John Roth
>
> Nestor
Ryan Lowe
"Patrick Lioi" <pat...@novaroot.com> wrote in message
news:2a82921f.03082...@posting.google.com...
> I would like to see a shorthand for list.append(), borrowed from PHP:
>
> foo = [1, 2, 3]
> foo[] = 4 # foo now equals [1, 2, 3, 4]
well, you can just concatenate a list like this:
>>> foo += [4]
the meaning of this is even clearer i think.
> I would also like to see what would probably end up being called
> "generator comprehensions". That is definitely not my own idea, but
> for the life of me I can't remember where I first heard about it.
> Imagine being able to throw the yield keyword into a list
> comprehension syntax in order to take advantage of list
> comprehension's in a memory-efficient way, something kinda like this:
>
> foo = [yield i*i for i in xrange(100)]
i like this idea too. someone wrote a PEP for it:
http://www.python.org/peps/pep-0289.html
but alas it was rejected, like so many good ideas 'round here ;^)
Robert Kern
prue...@latinmail.com (nnes) writes:
[snip]
> I have never understood why python has [].count() or "".count() but
> len([]) and len("").
>
> Why not make len, sum, str, repr, etc just methods of the base object
> class with specific implementations for different types. Instead of
> doing len([]) we could do [].len().
Like John said, "mostly history."
This is in the General FAQ, question 4.6, in fact.
"""4.6 Why does Python use methods for some functionality (e.g.
list.index()) but functions for other (e.g. len(list))?
The major reason is history. Functions were used for those operations
that were generic for a group of types and which were intended to work
even for objects that didn't have methods at all (e.g. tuples). It is
also convenient to have a function that can readily be applied to an
amorphous collection of objects when you use the functional features of
Python (map(), apply() et al).
In fact, implementing len(), max(), min() as a built-in function is
actually less code than implementing them as methods for each type. One
can quibble about individual cases but it's a part of Python, and it's
too late to make such fundamental changes now. The functions have to
remain to avoid massive code breakage.
Note that for string operations Python has moved from external functions
(the string module) to methods. However, len() is still a function.
"""
> This is actually possible already in part. I think you can do
> [].__len__(). But I never understood the reasoning behind making these
> special __x__() methods instead of doing a plain x() and using it like
> obj.x().
I think one of the benefits is that it promotes generic programming. If
I'm designing a class which acts like a sequence or collection, the
canonical way for me to expose the length or size of the object is to
define a __len__ method. If I'm using someone else's class which acts
like a collection, I know that I can almost certainly call len(obj) and
get the length. I don't have to remember if they called it .len(),
.length(), .getLength(), .size(), .cardinality(), .length (as an
attribute or property), .numKeys(), etc. And each one of those would be
used somewhere (exclusively) even if all of the builtins used only
.len().
> The only case I can think of, where it would look kind of odd would be
> floating points like:
>
> niceoutput=2.3.str()
Actually it works fine for floats. Try it in the interpreter (using
__str__ or one of the other magic method, though).
Plain ints, on the other hand, are problematic.
> Anyway since Pythonistas are smart, it can not be a wart of the
> language and must be some lack in my understanding :)
>
> awaiting-to-be-enlightened-yours
In fine Zen koan tradition, consider yourself whacked on the head with
a large stick. :-)
> Nestor
--
Robert Kern
ke...@caltech.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Jeff Epler
> I would also like to see what would probably end up being called
> "generator comprehensions". That is definitely not my own idea, but
> for the life of me I can't remember where I first heard about it.
> Imagine being able to throw the yield keyword into a list
> comprehension syntax in order to take advantage of list
> comprehension's in a memory-efficient way, something kinda like this:
>
> foo = [yield i*i for i in xrange(100)]
I also think that this would be a nice thing to have. I think that one
barrier to it was the lack of an implementation. I don't remember what
other objections were recorded in the PEP mentioned in another followup.
Jeff
Jacek Generowicz
For the URL-challeneged :-) ...
BDFL Pronouncements
Generator comprehensions are REJECTED. The rationale is that the
benefits are marginal since generators can already be coded
directly and the costs are high because implementation and
maintenance require major efforts with the parser.
Colin J. Williams
Or why not make it plainer still, so that len, str etc become properties
or attributes, without the need to add the redundant parentheses?
>
> The only case I can think of, where it would look kind of odd would be
> floating points like:
>
> niceoutput=2.3.str()
>
> Anyway since Pythonistas are smart, it can not be a wart of the
> language and must be some lack in my understanding :)
>
> awaiting-to-be-enlightened-yours
>
> Nestor
Colin W.
Afanasiy
I have a bunch, many of them hard to define, but one that I just thought
of I find strange sometimes is the use of tuples as near-mystery return
values. I can't help but thinking a C struct with named fields is easier
to remember than a tuple with fields accessed by integer.
Sure you can return an associative array, but in my experience the
preference is to return a tuple. I'll probably get flamed for saying so,
but this is how I feel and it is unavoidable. Returning a struct in C is
easier to deal with than returning a near-mystery tuple in Python.
Jordan Krushen
> Sure you can return an associative array, but in my experience the
> preference is to return a tuple. I'll probably get flamed for saying so,
> but this is how I feel and it is unavoidable. Returning a struct in C is
> easier to deal with than returning a near-mystery tuple in Python.
On one hand, you could always return a dict in your own code. On the
other, I find dealing with returned tuples to be as easy as it gets:
def f(x, y, z):
return(z, y, x)
a, b, c = f()
print a, b, c # 3 2 1
J.
Jordan Krushen
wrote:
> def f(x, y, z):
> return(z, y, x)
>
> a, b, c = f()
Woops. Make that a, b, c = f(1, 2, 3)
Afanasiy
wrote:
>On Mon, 25 Aug 2003 18:14:30 GMT, Afanasiy <abeli...@hotmail.com> wrote:
>
>> Sure you can return an associative array, but in my experience the
>> preference is to return a tuple. I'll probably get flamed for saying so,
>> but this is how I feel and it is unavoidable. Returning a struct in C is
>> easier to deal with than returning a near-mystery tuple in Python.
>On one hand, you could always return a dict in your own code. On the
>other, I find dealing with returned tuples to be as easy as it gets:
Obviously, in my own go I do not use near-mystery tuples.
>def f(x, y, z):
> return(z, y, x)
>
>a, b, c = f()
>print a, b, c # 3 2 1
Yes, returning multiple values, ie. tuples, is useful, but using them as
you would use structs in C is common and the root of my gripe. The problem
I explained above has nothing to do with the code you write. The problem
is knowing what integer position in the tuple represents what field. In C
structs have named fields, but in Python tuple have integer fields. The
meaning of tuple integer fields, for tuples used this way, is only known
in the documentation, not the code directly.
When tuples are used this way, to me, it is akin to using small arrays in
C for multiple values, where it is common to define globals in all caps
for the integer index supposed to be represented. This is not done in
Python because it is very un-python, yet the same type of code which
_causes_ this helpful convention *is* used in Python. Curious.
Often this is not even done in C, because a struct is used instead.
I thought this thread was for gripes, not detailed explanations and
solutions. However, for a solution... Perhaps people should use dicts in
the libraries more often than near-mystery tuples. It's much more explicit
that way.
When I have to re-explain and re-gurgitate something like this for benefit
of one confused person I leave myself open to more confused attacks, and I
don't like that. So if that happens this time, I will make sure not to
elaborate so much next time, and will reply abruptly instead.
"I have made this letter longer than usual because I lack the time to make
it shorter." - Blaise Pascal
Dave Brueck
> I have a bunch, many of them hard to define, but one that I just thought
> of I find strange sometimes is the use of tuples as near-mystery return
> values. I can't help but thinking a C struct with named fields is easier
> to remember than a tuple with fields accessed by integer.
>
> Sure you can return an associative array, but in my experience the
> preference is to return a tuple. I'll probably get flamed for saying so,
> but this is how I feel and it is unavoidable. Returning a struct in C is
> easier to deal with than returning a near-mystery tuple in Python.
A bit of an apples-to-oranges comparison, isn't it? If you prefer to return a
named structure in C, the Python equivalent certainly wouldn't be a tuple.
-Dave
sism...@hebmex.com
> Returning a struct in C is
> easier to deal with than returning a near-mystery tuple in Python.
>
You *really* *must* *be* *kidding*.
-gustavo
Advertencia:La informacion contenida en este mensaje es confidencial y
restringida, por lo tanto esta destinada unicamente para el uso de la
persona arriba indicada, se le notifica que esta prohibida la difusion de
este mensaje. Si ha recibido este mensaje por error, o si hay problemas en
la transmision, favor de comunicarse con el remitente. Gracias.
Afanasiy
wrote:
That's exactly my point. The Python equivalent certainly isn't a tuple.
The comparison with C is to explain, AND also happens to point to WHY code
like this exists in libraries which come with Python.
Afanasiy
>[Afanasiy]
>> Returning a struct in C is
>> easier to deal with than returning a near-mystery tuple in Python.
>>
>
>You *really* *must* *be* *kidding*.
On the very specific level I was referring to, I really am not kidding.
Afanasiy
>[Afanasiy]
>> Returning a struct in C is
>> easier to deal with than returning a near-mystery tuple in Python.
>>
>
>You *really* *must* *be* *kidding*.
Last post on this topic, I knew it would get all retarded.
Try to figure out what I am actually saying before reading
"C is easier than Python". Since I cannot explain this well
enough to satisfy, I am giving up. I will not post again,
feel free to post your snide personal attacks now hounds.
Jordan Krushen
> Yes, returning multiple values, ie. tuples, is useful, but using them as
> you would use structs in C is common and the root of my gripe. The
> problem
> I explained above has nothing to do with the code you write. The problem
> is knowing what integer position in the tuple represents what field. In C
> structs have named fields, but in Python tuple have integer fields. The
> meaning of tuple integer fields, for tuples used this way, is only known
> in the documentation, not the code directly.
I agree here. Returning tuples is only useful when very few arguments are
being returned. I must admit, I haven't seen many cases where they're used
as [larger] C structs are -- in most of those cases, some kind of
methodless container object is usually returned. For trivial cases, it's
much less work for the developer to simply return a tuple than to create a
class just for the result.
Therein lies much of the problem, I believe. Developers tend to code to
whatever method makes life easier for them. This is fine for closed
application development, but developers working on libraries often forget
that a little extra work up front will save time for many other coders as
they continue to use the library.
> Often this is not even done in C, because a struct is used instead.
Indeed. In Python, I prefer to simply toss a methodless object back,
instead. Obviously, this incurs some overhead though (both finger-and run-
time). I wonder if occurences of tuples being returned in the standard
library are there for performance reasons (select.select, etc).
> I thought this thread was for gripes, not detailed explanations and
> solutions. However, for a solution... Perhaps people should use dicts in
> the libraries more often than near-mystery tuples. It's much more
> explicit that way.
I'm just trying to determine where you have most of an issue with this --
in the standard library, in other libraries, or what is being recommended
as Pythonic. If it's an inconsistency/readability issue in the standard
library, we can fix it! Isn't that the point of this thread? Simply
detailing gripes without any attempt to fix them is quite unproductive,
IMO.
If the complaint is more specifically what you deem or perceive others to
deem as Pythonic, then I can't say I have seen many cases of mystery-tuples
being returned, except for the low-layer library wrappers (win32all comes
to mind), but those seem to often be written as shims, with the expectation
that another, more OO and developer-friendly API will be exposed afterward.
I can't say I've seen many cases where people *recommend* returning
tuples, as readability does tend to suffer.
> When I have to re-explain and re-gurgitate something like this for
> benefit of one confused person I leave myself open to more confused
> attacks, and I don't like that. So if that happens this time, I
> will make sure not to elaborate so much next time, and will reply
> abruptly instead.
I'm neither confused or attacking. This is a concern of mine that lines up
with your own, but I'm looking at a potential fix for the problem, and
trying to clarify where you perceive the issue to exist.
J.
Josh
> [Afanasiy]
>> Returning a struct in C is
>> easier to deal with than returning a near-mystery tuple in Python.
>>
> You *really* *must* *be* *kidding*.
> -gustavo
It's really pretty easy:
typedef struct {
int x;
int y;
} T;
T f() {
T t = { 1, 2 };
return t;
}
int main() {
T t = f();
return 0;
}
And arguably easier to deal with than Python in that the fields are
named. I think that's all Afanasiy was getting at.
Grant Edwards
> On Mon, 25 Aug 2003 19:45:10 GMT, Afanasiy <abeli...@hotmail.com> wrote:
>
>> Yes, returning multiple values, ie. tuples, is useful, but using them as
>> you would use structs in C is common and the root of my gripe. The
>> problem
>> I explained above has nothing to do with the code you write. The problem
>> is knowing what integer position in the tuple represents what field. In C
>> structs have named fields, but in Python tuple have integer fields. The
>> meaning of tuple integer fields, for tuples used this way, is only known
>> in the documentation, not the code directly.
>
> I agree here. Returning tuples is only useful when very few
> arguments are being returned.
In my experience, two is the maximum useful value. I don't
have t0o much trouble remembering the order of a pair of
returned values, but with three or more, I often get it wrong.
--
Grant Edwards grante Yow! I'd like MY data-base
at JULIENNED and stir-fried!
visi.com
Grant Edwards
> On Monday 25 August 2003 12:14 pm, Afanasiy wrote:
>> I have a bunch, many of them hard to define, but one that I just thought
>> of I find strange sometimes is the use of tuples as near-mystery return
>> values. I can't help but thinking a C struct with named fields is easier
>> to remember than a tuple with fields accessed by integer.
[...]
> A bit of an apples-to-oranges comparison, isn't it? If you prefer to return a
> named structure in C, the Python equivalent certainly wouldn't be a tuple.
If you look at the library, it is.
In instances where the "return" value to an ioctl or system
call is a C struct, the Python return value is often a tuple.
stat() leaps to mind as a good example. In that case, symbolic
indexes into the tuple are provided -- this mitigates the
situation somewhat.
--
Grant Edwards grante Yow! SHHHH!! I hear SIX
at TATTOOED TRUCK-DRIVERS
visi.com tossing ENGINE BLOCKS into
empty OIL DRUMS...
Grant Edwards
> On Mon, 25 Aug 2003 13:42:00 -0500, sism...@hebmex.com wrote:
>
>>[Afanasiy]
>>> Returning a struct in C is
>>> easier to deal with than returning a near-mystery tuple in Python.
>>>
>>
>>You *really* *must* *be* *kidding*.
>
> Last post on this topic, I knew it would get all retarded.
Not "all retarded" -- just one post.
> Try to figure out what I am actually saying before reading "C
> is easier than Python". Since I cannot explain this well enough
> to satisfy, I am giving up.
Relax. Everybody else understood what you wrote. c.l.p is
better than most groups, but this is Usenet. No matter what you
write, somebody is going to interpret it as a proposal to cook
and eat babies.
> I will not post again, feel free to post your snide personal
> attacks now hounds.
--
Grant Edwards grante Yow! I'm continually
at AMAZED at th'breathtaking
visi.com effects of WIND EROSION!!
Bob Gailer
Macintosh? My goal is to extract contents of cells.
Bob Gailer
bga...@alum.rpi.edu
303 442 2625
Dave Brueck
> In article <mailman.1061838206...@python.org>, Dave Brueck
wrote:
> > On Monday 25 August 2003 12:14 pm, Afanasiy wrote:
> >> I have a bunch, many of them hard to define, but one that I just thought
> >> of I find strange sometimes is the use of tuples as near-mystery return
> >> values. I can't help but thinking a C struct with named fields is easier
> >> to remember than a tuple with fields accessed by integer.
>
> [...]
>
> > A bit of an apples-to-oranges comparison, isn't it? If you prefer to
> > return a named structure in C, the Python equivalent certainly wouldn't
> > be a tuple.
>
> If you look at the library, it is.
Ah, now I get it, thanks. This is such a goofy thread anyway, but I thought it
was about language gripes, and in the general case a simple class is the
Python analog to a C struct.
> In instances where the "return" value to an ioctl or system
> call is a C struct, the Python return value is often a tuple.
> stat() leaps to mind as a good example. In that case, symbolic
> indexes into the tuple are provided -- this mitigates the
> situation somewhat.
Even better, the commonly-used elements have os.path.get* acessors
(os.path.getsize, getmtime, etc.).
-Dave
Skip Montanaro
josh> And arguably easier to deal with than Python in that the fields
josh> are named. I think that's all Afanasiy was getting at.
Yeah, that was my impression as well. Note that there is a "super tuple"
type used in some places in the Python C code which allows both positional
and attribute access to fields:
>>> import time
>>> t = time.localtime()
>>> t
(2003, 8, 25, 15, 45, 46, 0, 237, 1)
>>> t.tm_year
2003
>>> type(t)
<type 'time.struct_time'>
I don't know if the in-memory storage is more like a tuple or more like a
dict.
Exposing something like this to the Python programmer was suggested a few
years ago. I don't recall why it wasn't adopted, though any obvious reason
might be that it's fairly easy to create container classes for that purpose.
Skip
Ryan Lowe
news:0rqkkv481p8ob48pp...@4ax.com...
> On Mon, 25 Aug 2003 06:44:03 -0600, Dave Brueck <da...@pythonapocrypha.com>
> wrote:
>
> >On Monday 25 August 2003 12:14 pm, Afanasiy wrote:
> >
> >> I have a bunch, many of them hard to define, but one that I just
thought
id like to hear them if you get the chance.
> >> of I find strange sometimes is the use of tuples as near-mystery return
> >> values. I can't help but thinking a C struct with named fields is
easier
> >> to remember than a tuple with fields accessed by integer.
dont access the return values by their index; just unpack 'em.
def getFruit() :
return 'apples', 'oranges'
apples, oranges = getFruit()
Skip Montanaro
Grant> ... this is Usenet. No matter what you write, somebody is going
Grant> to interpret it as a proposal to cook and eat babies.
QOTW if ever I saw one. ;-)
Skip
Ryan Lowe
"Josh" <joshway_wi...@myway.com> wrote in message
news:bidr0d$p9g$1...@fred.mathworks.com...
is it that hard to send a dictionary? i dont know how that compares to a
tuple in terms of speed/memory usage, but its not a whole lot harder to use
than a tuple.
def fruit() :
return {'apple' : 'A', 'orange' : 'B'}
>>> food = fruit()
>>> food['apple']
... 'A'
anyone have any more things they dont like or, better yet, feel are missing
from python? ive got a pretty big list going. ill post a link when i get it
uploaded.
"Andrew Dalke" <ada...@mindspring.com> wrote in message
news:P372b.1862$Jh2...@newsread4.news.pas.earthlink.net
[...]
> > > code blocks (like Smalltalk)
> >
> > is this what it sounds like? do you name a block of code and call it
like
> an
> > inline function with no parameters?
>
> Consider the following Ruby code
>
> [ 1, 3, 5 ].each { |i| puts i }
>
> The
> |i| puts i
> is an *unnamed* code block which does take parameters.
> The [] is a container, and [].each sends the code block to
> each of the elements in the container. See
> http://www.rubycentral.com/book/tut_containers.html
>
i looked into code blocks. they still seem a bit confusing, but from what i
learned i dont see any advantage over python's generators. for example take
these two versions of code that produces the fibonacci series:
RUBY
def fibUpTo(max)
a, b = 1, 1 # parallel assignment
while a <= max
yield i1
a, b = b, a+b
end
end
fibUpTo(1000) { |f| print f, " " }
PYTHON
def fibUpTo(max) :
a, b = 1, 1
while a <= max :
yield a
a, b = b, a+b
>>> for f in fibUpTo(1000) :
print f,
i think the python version is much more intuitive. are there more
complicated uses of code blocks that would make them more powerful than
python's generators? i think i read a PEP or something about adding the
ability to pass info into a generator. if this doesnt exist yet or ever,
that would probably be a good difference, but i cant think of a good example
to illustrate this...
Donn Cave
"Ryan Lowe" <ryan...@msn.com> wrote:
> dont access the return values by their index; just unpack 'em.
>
> def getFruit() :
> return 'apples', 'oranges'
>
> apples, oranges = getFruit()
Not a solution, as he has already pointed out in another
followup. Why not
oranges, apples = getFruit()
? Well, obviously because that's wrong, but the problem
is that you may not realize it's wrong. Able to remember
the order of items in the return from posix.stat()? I am
not, and I've been using Python on UNIX for about a decade.
Here it is, in case you're wondering what I mean -
(mode, ino, dev, nlink, uid, gid, size, atime,
mtime, ctime) = os.stat('.')
So this particular case is actually resolved in 2.2 - the
return isn't really a tuple.
>>> st = os.stat('.')
>>> print st.st_uid
501
>>> type(a)
<type 'posix.stat_result'>
which is probably the best that can be done for Python.
If you were starting over from scratch, I think you'd
want to have and use a record type.
Donn Cave, do...@u.washington.edu
Cliff Wells
> I have a bunch, many of them hard to define, but one that I just thought
> of I find strange sometimes is the use of tuples as near-mystery return
> values. I can't help but thinking a C struct with named fields is easier
> to remember than a tuple with fields accessed by integer.
As someone else mentioned, you don't have to access them via an integer,
but your point is still taken. The return value of time.localtime()
method is a fine example of a mystery tuple. Fortunately it offers
attribute access as well.
> Sure you can return an associative array, but in my experience the
> preference is to return a tuple. I'll probably get flamed for saying so,
> but this is how I feel and it is unavoidable. Returning a struct in C is
> easier to deal with than returning a near-mystery tuple in Python.
This isn't so much a problem with Python as the programmers using it nor
do I see it as particularly "unavoidable". If you're returning only a
few (preferably homogenous) items, a tuple makes sense:
x, y, z = getpoint()
More complex return values should probably be in a class instance (which
would seem to be equivalent to returning a C struct in this case):
t = time.localtime(time.time())
print t.tm_hour, t.tm_min, t.tm_sec
makes better sense than:
year, month, mday, hour, min, sec, wday, yday, isdst =
time.localtime(time.time())
Regards,
--
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 (800) 735-0555
sism...@hebmex.com
> is it that hard to send a dictionary? i dont know how that
> compares to a tuple in terms of speed/memory usage, but its
> not a whole lot harder to use than a tuple.
And much more flexible. You can also create a "holder" kind
of class, which goes something like:
class Values:
def __init__(self, **values):
self.__dict__.update(values)
>
> def fruit() :
> return {'apple' : 'A', 'orange' : 'B'}
>
> >>> food = fruit()
> >>> food['apple']
> ... 'A'
>
Or, using the above Values class:
...
return Values(apple="A", orange="B")
What you use the class for, is up to your own imagination
and needs.
>
> ... are there more
> complicated uses of code blocks that would make them more
> powerful than python's generators?
>
Generators yielding to other generators, to form a
quasi-cooperative-multitasking environ seems quite
powerful to me.
Ryan Lowe
<sism...@hebmex.com> wrote in message
news:mailman.1061851794...@python.org...
> > ... are there more
> > complicated uses of code blocks that would make them more
> > powerful than python's generators?
> >
>
> Generators yielding to other generators, to form a
> quasi-cooperative-multitasking environ seems quite
> powerful to me.
>
not that i have any clue what you just said, but is this possible in python?
or only in code-block languages?
car...@tjc.com
wrote:
> id like to make a list of some of the aspects people
>find most annoying, regardless of their feasibility of implementation.
No kidding: I'd really like a GOTO. I know, that's heresy, but I like
it during development. Sometimes I have a whole bunch of tests, and
change something that will only affect a test near the end. I'd love
to GOTO around the early stuff.
If Python used {} to delimit blocks, I could just make the skipped
code a block and add a condition to skip it, but with the indentation
as the way of showing block scope (which I *love*), I have to indent a
big chunk of code to use that method.
JanC
> No kidding: I'd really like a GOTO. I know, that's heresy, but I like
> it during development. Sometimes I have a whole bunch of tests, and
> change something that will only affect a test near the end. I'd love
> to GOTO around the early stuff.
>
> If Python used {} to delimit blocks, I could just make the skipped
> code a block and add a condition to skip it, but with the indentation
> as the way of showing block scope (which I *love*), I have to indent a
> big chunk of code to use that method.
If it doesn't contain docstrings, you can put that "unwanted" test code
between triple quotes (""").
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9
smarter_than_you
def sumdif(a, b):
sum = a + b
dif = a - b
return sum, dif
#normal syntax:
s, d = sumdif(5,7)
#additional syntax with named returns:
(s=sum, d=dif)=sumdif(5, 7)
#eqivalent to:
(d=dif, s=sum)=sumdif(5, 7)
#I call it 'symmetrical' because we can do this:
(s=sum, d=dif)=sumdif(a=5, b=7)
Not sure how easy to implement this would be, or how it affects the
scope of locals and such, but it looks nice on paper.
sism...@hebmex.com wrote in message news:<mailman.1061851794...@python.org>...
Ville Vainio
> > Generators yielding to other generators, to form a
> > quasi-cooperative-multitasking environ seems quite
> > powerful to me.
> >
>
> not that i have any clue what you just said, but is this possible in python?
> or only in code-block languages?
Check out the back issues of "Charming Python", on generators as
lightweight thread-equivalents:
http://www-106.ibm.com/developerworks/linux/library/l-pythrd.html
Hannu Kankaanpää
> are there more
> complicated uses of code blocks that would make them more powerful than
> python's generators?
When you want to do something else than iteration. Such as the
common example (adapting Ruby's |variable|-syntax)
with_file('file.dat', 'rb') |f|:
data = f.read()
Which currently has to be written as
f = file('file.dat', 'rb')
try:
data = f.read()
finally:
f.close()
And that's pretty verbose. If an exception is thrown inside
iteration, there's no way for the generator to catch it.
So Python can't do it like this:
for f in with_file('file.dat', 'rb'):
data = f.read()
def with_file(*args):
f = file(*args)
try:
yield f
finally:
f.close()
It would look pretty strange too.
One could do this with lambdas or nested functions in Python,
since they are "code blocks". But their definition and access
to local variables is awkward (for this situation):
data = [None]
def reader(f):
data[0] = f.read()
with_file('file.dat', 'rb', reader)
Way too ugly to be used.
Peter Hansen
>
> car...@tjc.com schreef:
>
> > No kidding: I'd really like a GOTO. I know, that's heresy, but I like
> > it during development. Sometimes I have a whole bunch of tests, and
> > change something that will only affect a test near the end. I'd love
> > to GOTO around the early stuff.
> >
> > If Python used {} to delimit blocks, I could just make the skipped
> > code a block and add a condition to skip it, but with the indentation
> > as the way of showing block scope (which I *love*), I have to indent a
> > big chunk of code to use that method.
>
> If it doesn't contain docstrings, you can put that "unwanted" test code
> between triple quotes (""").
OR if you're consistent in using only one kind of docstring, say '''
only, then you can almost always use """ to comment out a block...
-Peter
Skip Montanaro
carroll> If Python used {} to delimit blocks, I could just make the
carroll> skipped code a block and add a condition to skip it, but with
carroll> the indentation as the way of showing block scope (which I
carroll> *love*), I have to indent a big chunk of code to use that
carroll> method.
In Emacs python-mode, C-c > intends the highlighted region one "step". C-c
< goes the other way. This obviously won't help if you're not an Emacs
user, but you might want to check your editor's reference manual for
something similar.
Skip
sism...@hebmex.com
> > Generators yielding to other generators, to form a
> > quasi-cooperative-multitasking environ seems quite
> > powerful to me.
[Ryan Lowe]
> not that i have any clue what you just said, but is this
> possible in python?
> or only in code-block languages?
Nope, it's quite possible, and not too complicated to
do (but comprehend) in Python.
You just need a bunch of routines which need to run
in an "interleaved" fashion. You put "yield" statements
where you intend to pause execution of each routine,
the secret is in which value you yield.
One approach is to put all obtained generators into a
list, and simply iterate through it repeatedly, taking
each one and calling it's .next() You can use a sentinel
value to signal that you should take this generator off
the list. The loop would look something like:
while 1:
for I in GeneratorsList:
I.next()
The next approach is to yield in each iterator the reference
to the next subroutine to be called. This is especially
neat in state machines, because each state *knows* which
other state follows given a certain condition. So, you
replace the generator-list-iteration loop given above for
something like below:
state = InitialStateGenerator
while state:
state = state.next()
and this will loop until a certain state returns a false
value. Neat.
The final approach is for a generator to yield TO the final
state; in this case you don't yield a reference to the next
generator, but you directly call it's .next() method, which
directly continues it's execution, etc. So, the loop actually
disappears and becomes
state = InitialStateGenerator
state.next()
and by the time it returns, it's done.
:-)
NEAT.
John J. Lee
> Is there a way for a Python program to interact with MS Excel on the
> Macintosh? My goal is to extract contents of cells.
I'd be interested in the answer to that, too. Surely COM must be in
there somewhere? This is the wrong newsgroup to find out, though.
Actually, I'm sure I googled on this a while ago, and found something
somewhere that implied that that is the case -- but I've never seen
any reference to people actually using it, let alone any support from
win32all (which I presume would be a big job).
Maybe one of the lightweight things with COM support like ctypes
(IIRC) might help??
John
Gonçalo Rodrigues
wrote:
>python is a big improvement on most languages that came before it, but no
>language is perfect. id like to make a list of some of the aspects people
>find most annoying, regardless of their feasibility of implementation. for
>instance, i discussed putting if clauses in for loops, and i noticed another
>thread about allowing {} and [] to be added and subtracted. if its something
>from another language (especially an obscure one), please explain how it
>works in case people like myself dont know the language.
>
Major gripes: names bound in nested scopes are read-only, not
rebindable. Related with this is the global declaration -- the only
declaration in Python! There should be another way to handle this:
something like scopes becoming objects where the names bound in it are
it's attributes and then you would have two functions global() and
enclosing() returning the global and the enclosing scope. Or something
to this effect :-)
Minor gripes:
- trimming down the builtins, e.g. move enumerate to itertools, get
rid of map and filter, etc.
- Get rid of lambda or find a way for lambda to accept statements.
- Some of the more advanced Python stuff (super, metaclasses) has some
dark corners (check the bugs tracker). Bring on the light.
Things that I still haven't decided if they are gripes or not:
- __slots__. Dangerous hack, makes generic code much more difficult.
- names in for loops/list comprehensions leak out.
With my best regards,
G. Rodrigues
Michael Hudson
> Bob Gailer <bga...@alum.rpi.edu> writes:
>
> > Is there a way for a Python program to interact with MS Excel on the
> > Macintosh? My goal is to extract contents of cells.
>
> I'd be interested in the answer to that, too. Surely COM must be in
> there somewhere? This is the wrong newsgroup to find out, though.
The Mac-ish anser is apple events. I don't know whether Excel's Apple
Event support is useful on the Mac, though.
Cheers,
mwh
--
For every complex problem, there is a solution that is simple,
neat, and wrong. -- H. L. Mencken
John J. Lee
> j...@pobox.com (John J. Lee) writes:
>
> > Bob Gailer <bga...@alum.rpi.edu> writes:
> >
> > > Is there a way for a Python program to interact with MS Excel on the
> > > Macintosh? My goal is to extract contents of cells.
> >
> > I'd be interested in the answer to that, too. Surely COM must be in
> > there somewhere? This is the wrong newsgroup to find out, though.
>
> The Mac-ish anser is apple events. I don't know whether Excel's Apple
> Event support is useful on the Mac, though.
Interesting. I was wondering about COM itself, though.
John
Sean Ross
news:15dpkvsfatkrlode3...@4ax.com...
[snip]
> Related with this is the global declaration -- the only
> declaration in Python! There should be another way to handle this:
> something like scopes becoming objects where the names bound in it are
> it's attributes and then you would have two functions global() and
> enclosing() returning the global and the enclosing scope. Or something
> to this effect :-)
>
This is probably not what you want, and it's probably worse than just using
a global declaration, but it *is* "another way to handle this":
>>> # put this at the top of your module,
>>> # to grab hold of this module's namespace
>>> import __main__ as main
>>> g = "global variable"
>>> def f():
... main.g = "re-bound global"
...
>>> f()
>>> g
're-bound global'
>>>
If you want a global() function that returns the namespace, you can do this:
#
# your_utils.py
#
# I'll use the name 'main' rather than shadow the global keyword
def main():
import __main__
return __main__
# other_module.py
from your_utils import main
foo = "foo"
def bar():
print main().foo
# output
foo
I have no idea what issues this raises, but that is not my concern here -
I'm just seeing whether there is "another way to handle this". It looks like
there is. Usual disclaimers apply: "Don't do that", "Use at your own risk",
"Yada, Yada"
I can't help you with "names bound in nested scopes are read-only, not
rebindable". I tried to implement your enclosing() idea. I made a
'namespace' class to use as follows:
def foo():
x = 1
def bar():
# context is the number of frames to go back
outer = namespace(context=1)
# outer keeps a reference to foo's frame
outer.x = 2
# so, I tried to re-bind the x in foo using something like
# self.frame.f_locals['x'] = 2, but f_locals is not writable!
# I made several attempts to circumvent this, but no success.
bar()
print x
foo()
# output
1
Oh well...
"just seeing if it can be done-ly yours"
Sean
Neil Hodgson
> Interesting. I was wondering about COM itself, though.
COM will still be being used by Microsoft for Internet Explorer and maybe
Office on the Mac. Several years ago they tried to promote ActiveX on MacOS
but dropped it. There was an interesting post on this subject by Steven D.
Majewski.
Go to Google Groups Advanced Search
http://www.google.com.au/advanced_group_search?hl=en
search for "mac activex" in comp.lang.python.
Neil
car...@tjc.com
wrote:
>JanC wrote:
>> If it doesn't contain docstrings, you can put that "unwanted" test code
>> between triple quotes (""").
>
>OR if you're consistent in using only one kind of docstring, say '''
>only, then you can almost always use """ to comment out a block...
Thanks; this is actually pretty helpful.
Terry Reedy
"Sean Ross" <sr...@connectmail.carleton.ca> wrote in message
news:HE73b.2610$_F1.4...@news20.bellglobal.com...
> This is probably not what you want, and it's probably worse than
just using
> a global declaration, but it *is* "another way to handle this":
>
> >>> # put this at the top of your module,
> >>> # to grab hold of this module's namespace
> >>> import __main__ as main
> >>> g = "global variable"
> >>> def f():
> ... main.g = "re-bound global"
> ...
> >>> f()
> >>> g
> 're-bound global'
Unless there is flaw neither of us see, I like this.
Names bound in nested scopes are not read-only, just not rebindable.
Mutables *are* writeable and immutables can be wrapped in [] or
another mutable to make them effectively writable.
def fun():
x=[1]
print x
def ny():
x[0]=2
ny()
print x
>>> fun()
[1]
[2]
Slightly clumsy, but workable.
Terry J. Reedy
Gonçalo Rodrigues
wrote:
>On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" <ryan...@msn.com> wrote:
>
>>python is a big improvement on most languages that came before it, but no
>>language is perfect. id like to make a list of some of the aspects people
>>find most annoying, regardless of their feasibility of implementation. for
>>instance, i discussed putting if clauses in for loops, and i noticed another
>>thread about allowing {} and [] to be added and subtracted. if its something
>>from another language (especially an obscure one), please explain how it
>>works in case people like myself dont know the language.
>>
>>thanks,
>>ryan
>>
>
>I have a bunch, many of them hard to define, but one that I just thought
>of I find strange sometimes is the use of tuples as near-mystery return
>values. I can't help but thinking a C struct with named fields is easier
>to remember than a tuple with fields accessed by integer.
>
>Sure you can return an associative array, but in my experience the
>preference is to return a tuple. I'll probably get flamed for saying so,
>but this is how I feel and it is unavoidable. Returning a struct in C is
>easier to deal with than returning a near-mystery tuple in Python.
Look up my recipe in the ActiveState cookbook:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/218485
Ryan Lowe
[smarter_than_you]
>How about this for a symmetrical, Pythonesque syntax:
>
>def sumdif(a, b):
> sum = a + b
> dif = a - b
> return sum, dif
>
>#normal syntax:
>s, d = sumdif(5,7)
>
>#additional syntax with named returns:
>
>(s=sum, d=dif)=sumdif(5, 7)
>
>#eqivalent to:
>
>(d=dif, s=sum)=sumdif(5, 7)
>
>#I call it 'symmetrical' because we can do this:
>
>(s=sum, d=dif)=sumdif(a=5, b=7)
>
>Not sure how easy to implement this would be, or how it affects the
>scope of locals and such, but it looks nice on paper.
not bad. heres an alternative:
s, d = (sum, dif) from sumdif(5, 7)
d, s = (dif, sum) from sumdif(5, 7)
uses the from keyword. makes it look like a parallel assignment.