Re: python gripes survey

Discussion in 'Python' started by Geoff Howland, Aug 24, 2003.

  1. 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/
     
    Geoff Howland, Aug 24, 2003
    #1
    1. Advertising

  2. Geoff Howland

    Ryan Lowe Guest

    "Geoff Howland" <> wrote in message
    news:...
    > 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.
     
    Ryan Lowe, Aug 24, 2003
    #2
    1. Advertising

  3. Geoff Howland

    Peter Hansen Guest

    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
     
    Peter Hansen, Aug 24, 2003
    #3
  4. Geoff Howland

    Andrew Dalke Guest

    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
     
    Andrew Dalke, Aug 24, 2003
    #4
  5. Geoff Howland

    nnes Guest

    Geoff Howland <> wrote in message news:<>...
    > 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
     
    nnes, Aug 24, 2003
    #5
  6. Geoff Howland

    John Roth Guest

    "nnes" <> wrote in message
    news:...
    > Geoff Howland <> wrote in message

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


    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
     
    John Roth, Aug 25, 2003
    #6
  7. Geoff Howland

    Robert Kern Guest

    In article <>,
    (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


    "In the fields of hell where the grass grows high
    Are the graves of dreams allowed to die."
    -- Richard Harter
     
    Robert Kern, Aug 25, 2003
    #7
  8. nnes wrote:
    > Geoff Howland <> wrote in message news:<>...
    >
    >>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().


    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.
     
    Colin J. Williams, Aug 25, 2003
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ryan Lowe

    Re: python gripes survey

    Ryan Lowe, Aug 24, 2003, in forum: Python
    Replies:
    1
    Views:
    329
    John Roth
    Aug 25, 2003
  2. Patrick Lioi

    Re: python gripes survey

    Patrick Lioi, Aug 25, 2003, in forum: Python
    Replies:
    3
    Views:
    327
    Jacek Generowicz
    Aug 25, 2003
  3. Dave Brueck

    Re: python gripes survey

    Dave Brueck, Aug 25, 2003, in forum: Python
    Replies:
    13
    Views:
    521
    Gonçalo Rodrigues
    Aug 28, 2003
  4. Replies:
    6
    Views:
    364
    Skip Montanaro
    Aug 25, 2003
  5. Replies:
    3
    Views:
    295
    Ville Vainio
    Aug 26, 2003
Loading...

Share This Page