FAQ
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

Search Discussions

  • Dave Brueck at Aug 23, 2003 at 10:44 am

    On Saturday 23 August 2003 09:39 am, Ryan Lowe 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.
    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
  • Bertrand Geston at Aug 23, 2003 at 9:49 pm
    "Ryan Lowe" <ryanlowe0 at msn.com> a ?crit dans le message news:
    PUL1b.166506$_R5.62801118 at news4.srv.hcvlny.cv.net...
    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
    You could start reading this:
    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 at Aug 23, 2003 at 10:43 pm
    much thanks

    "Bertrand Geston" <bergeston at yahoo.fr> wrote in message
    news:bi8nrd$1fnkl$1 at sinclair.be.wanadoo.com...
    "Ryan Lowe" <ryanlowe0 at msn.com> a ?crit dans le message news:
    PUL1b.166506$_R5.62801118 at news4.srv.hcvlny.cv.net...
    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
    You could start reading this:
    http://zephyrfalcon.org/labs/python_pitfalls.html
    http://www.amk.ca/python/writing/warts.html
    http://www.ferg.org/projects/python_gotchas.htmlv

    bg


  • Cy Edmunds at Aug 23, 2003 at 11:27 pm
    "Bertrand Geston" <bergeston at yahoo.fr> wrote in message
    news:bi8nrd$1fnkl$1 at sinclair.be.wanadoo.com...
    "Ryan Lowe" <ryanlowe0 at msn.com> a ?crit dans le message news:
    PUL1b.166506$_R5.62801118 at news4.srv.hcvlny.cv.net...
    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
    You could start reading this:
    http://zephyrfalcon.org/labs/python_pitfalls.html
    http://www.amk.ca/python/writing/warts.html
    http://www.ferg.org/projects/python_gotchas.htmlv

    bg
    Thanks for the links -- nice stuff there!
  • Geoff Howland at Aug 24, 2003 at 1:58 am

    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" 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.
    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 at Aug 24, 2003 at 3:52 am
    "Geoff Howland" <ghowland at lupineNO.SPAMgames.com> wrote in message
    news:7s6gkv031b940dsc522pbh5g30q4nj5vd1 at 4ax.com...
    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" 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.
  • Andrew Dalke at Aug 24, 2003 at 5:12 am

    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"})

    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
    dalke at dalkescientific.com
  • Ryan Lowe at Aug 24, 2003 at 3:42 pm
    "Andrew Dalke" <adalke at mindspring.com> wrote in message
    news:MOX1b.1042$Jh2.797 at 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?
    support for high-performance multiprocessor computing (like Fortran90)
    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)
    (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
    dalke at dalkescientific.com
  • Peter Hansen at Aug 24, 2003 at 4:09 pm

    Ryan Lowe wrote:
    "Andrew Dalke" 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 at Aug 24, 2003 at 6:01 pm

    Ryan Lowe:
    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
    dalke at dalkescientific.com
  • Nnes at Aug 24, 2003 at 10:50 pm
    Geoff Howland <ghowland at lupineNO.SPAMgames.com> wrote in message news:<7s6gkv031b940dsc522pbh5g30q4nj5vd1 at 4ax.com>...
    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" 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/
    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 at Aug 25, 2003 at 12:58 am
    "nnes" <pruebauno at latinmail.com> wrote in message
    news:d8778a53.0308241450.1a0d6645 at posting.google.com...
    Geoff Howland <ghowland at lupineNO.SPAMgames.com> wrote in message
    news:<7s6gkv031b940dsc522pbh5g30q4nj5vd1 at 4ax.com>...
    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" <ryanlowe0 at 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.

    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/
    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
    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
  • Robert Kern at Aug 25, 2003 at 2:52 am
    In article <d8778a53.0308241450.1a0d6645 at posting.google.com>,
    pruebauno at 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.

    http://tinyurl.com/l2gw

    """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
    kern at caltech.edu

    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
  • Colin J. Williams at Aug 25, 2003 at 2:22 pm

    nnes wrote:
    Geoff Howland <ghowland at lupineNO.SPAMgames.com> wrote in message news:<7s6gkv031b940dsc522pbh5g30q4nj5vd1 at 4ax.com>...
    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" <ryanlowe0 at 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.

    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/

    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().
    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.
  • Ryan Lowe at Aug 24, 2003 at 3:07 pm
    "Dave Brueck" <dave at pythonapocrypha.com> wrote in message
    news:mailman.1061701097.12913.python-list at 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?).
  • John Roth at Aug 25, 2003 at 12:31 am
    "Ryan Lowe" <ryanlowe0 at msn.com> wrote in message
    news:ex42b.177723$_R5.67051940 at news4.srv.hcvlny.cv.net...
    "Dave Brueck" <dave at pythonapocrypha.com> wrote in message
    news:mailman.1061701097.12913.python-list at 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?).
    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 at Aug 25, 2003 at 12:41 am
    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]

    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)]
  • Ryan Lowe at Aug 25, 2003 at 1:01 am
    "Patrick Lioi" <patrick at novaroot.com> wrote in message
    news:2a82921f.0308241641.5bf82d6d at 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 ;^)
  • Jeff Epler at Aug 25, 2003 at 2:08 am

    On Sun, Aug 24, 2003 at 05:41:35PM -0700, Patrick Lioi wrote:
    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 at Aug 25, 2003 at 11:39 am

    Jeff Epler <jepler at unpythonic.net> writes:
    On Sun, Aug 24, 2003 at 05:41:35PM -0700, Patrick Lioi wrote:

    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.
    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.


    ( http://www.python.org/peps/pep-0289.html )
  • Afanasiy at Aug 25, 2003 at 6:14 pm

    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" 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.
  • Dave Brueck at Aug 25, 2003 at 12:44 pm

    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.

    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
  • Bob Gailer at Aug 25, 2003 at 8:07 pm
    Is there a way for a Python program to interact with MS Excel on the
    Macintosh? My goal is to extract contents of cells.

    Bob Gailer
    bgailer at alum.rpi.edu
    303 442 2625
    -------------- next part --------------

    ---
    Outgoing mail is certified Virus Free.
    Checked by AVG anti-virus system (http://www.grisoft.com).
    Version: 6.0.506 / Virus Database: 303 - Release Date: 8/1/2003
  • Jordan Krushen at Aug 25, 2003 at 6:32 pm

    On Mon, 25 Aug 2003 18:14:30 GMT, Afanasiy 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:

    def f(x, y, z):
    return(z, y, x)

    a, b, c = f()
    print a, b, c # 3 2 1

    J.
  • Jordan Krushen at Aug 25, 2003 at 6:35 pm

    On Mon, 25 Aug 2003 18:32:35 GMT, 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)
    print a, b, c # 3 2 1
    J.
  • Afanasiy at Aug 25, 2003 at 7:45 pm

    On Mon, 25 Aug 2003 18:32:35 GMT, Jordan Krushen wrote:
    On Mon, 25 Aug 2003 18:14:30 GMT, Afanasiy 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
  • Jordan Krushen at Aug 25, 2003 at 8:11 pm

    On Mon, 25 Aug 2003 19:45:10 GMT, Afanasiy 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. 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.
  • Grant Edwards at Aug 25, 2003 at 8:20 pm

    In article <oprug80dwe5ctagx at localhost>, Jordan Krushen wrote:
    On Mon, 25 Aug 2003 19:45:10 GMT, Afanasiy 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
  • Cliff Wells at Aug 25, 2003 at 10:35 pm

    On Mon, 2003-08-25 at 11:14, 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.
    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
  • Gonçalo Rodrigues at Aug 28, 2003 at 2:15 pm

    On Mon, 25 Aug 2003 18:14:30 GMT, Afanasiy wrote:
    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" 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

    With my best regards,
    G. Rodrigues
  • Sismex01 at Aug 25, 2003 at 6:42 pm
    [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



    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 at Aug 25, 2003 at 8:05 pm

    On Mon, 25 Aug 2003 06:44:03 -0600, 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.

    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.
    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.
  • Ryan Lowe at Aug 25, 2003 at 9:52 pm
    "Afanasiy" <abelikov72 at hotmail.com> wrote in message
    news:0rqkkv481p8ob48ppbdikh95kn96jb9fe1 at 4ax.com...
    On Mon, 25 Aug 2003 06:44:03 -0600, 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

    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()

    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.
    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.
  • Donn Cave at Aug 25, 2003 at 10:27 pm
    In article <ayv2b.194710$_R5.72873618 at news4.srv.hcvlny.cv.net>,
    "Ryan Lowe" 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, donn at u.washington.edu
  • Afanasiy at Aug 25, 2003 at 8:06 pm

    On Mon, 25 Aug 2003 13:42:00 -0500, sismex01 at 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*.
    On the very specific level I was referring to, I really am not kidding.
  • Afanasiy at Aug 25, 2003 at 8:08 pm

    On Mon, 25 Aug 2003 13:42:00 -0500, sismex01 at 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.

    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.
  • Grant Edwards at Aug 25, 2003 at 8:26 pm

    In article <f2rkkv8fsc1olm7bsbmeo281plci6nh657 at 4ax.com>, Afanasiy wrote:
    On Mon, 25 Aug 2003 13:42:00 -0500, sismex01 at 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!!
  • Skip Montanaro at Aug 25, 2003 at 9:01 pm
    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
  • Josh at Aug 25, 2003 at 8:19 pm

    sismex01 at 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*.
    -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.
  • Skip Montanaro at Aug 25, 2003 at 8:49 pm
    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 at Aug 25, 2003 at 10:37 pm
    "Josh" <joshway_without_spam at myway.com> wrote in message
    news:bidr0d$p9g$1 at fred.mathworks.com...
    sismex01 at 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*.
    -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.
    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" <adalke at mindspring.com> wrote in message
    news:P372b.1862$Jh2.521 at 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...
  • Hannu Kankaanpää at Aug 26, 2003 at 8:44 am
    "Ryan Lowe" <ryanlowe0 at msn.com> wrote in message news:<0dw2b.194888$_R5.73038469 at news4.srv.hcvlny.cv.net>...
    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.
  • Grant Edwards at Aug 25, 2003 at 8:23 pm

    In article <mailman.1061838206.18981.python-list at 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.

    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...
  • Dave Brueck at Aug 25, 2003 at 2:44 pm

    On Monday 25 August 2003 02:23 pm, Grant Edwards wrote:
    In article <mailman.1061838206.18981.python-list at 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
  • Sismex01 at Aug 25, 2003 at 10:44 pm
    [Ryan Lowe]
    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.

    -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.
  • Ryan Lowe at Aug 26, 2003 at 2:27 am
    <sismex01 at hebmex.com> wrote in message
    news:mailman.1061851794.28843.python-list at 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?
  • Ville Vainio at Aug 26, 2003 at 7:21 am
    "Ryan Lowe" <ryanlowe0 at msn.com> wrote in message news:<pAz2b.195658$_R5.74002576 at news4.srv.hcvlny.cv.net>...
    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
  • Carroll at Aug 26, 2003 at 3:40 am

    On Sat, 23 Aug 2003 15:39:27 GMT, "Ryan Lowe" 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 at Aug 26, 2003 at 4:14 am

    carroll at 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 (""").

    --
    JanC

    "Be strict when sending and tolerant when receiving."
    RFC 1958 - Architectural Principles of the Internet - section 3.9
  • Peter Hansen at Aug 26, 2003 at 12:03 pm

    JanC wrote:
    carroll at 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

Related Discussions

People

Translate

site design / logo © 2022 Grokbase