My own 12 points list

Discussion in 'Python' started by nnes, Aug 26, 2003.

  1. nnes

    nnes Guest

    I have really no mayor gripes, and the few things I would change would
    break backward compatibility, but here is the list anyway:

    1.) Eliminate the whole long stuff. E.g. built-in long () function,
    "L", etc. It is a Python language implementation detail and I do not
    care about how it is done as long as it is fast and correct. Make
    python int adapt according to size of the integer and underlying
    architecture. 8088-80286=16 bit integers, 386-586=32
    bit, x86-64=64bit. If number overflows the CPU architecture
    auto-magically use internal (long) representation.

    2.) Eliminate map (), filter (), reduce (). It can be replaced with
    list comprehensions and for loops, which are easier to read.

    3.) Eliminate open (), use file () instead

    4.) Eliminate xrange(), replace range() with xrange() implementation

    5.) Eliminate built-in functions buffer(), callable(), delattr(),
    dir(), getattr(), hasattr(), hash(), help(), id(), isinstance(),
    len(), max(), min(), repr(), setattr(), sum(), str(), type(),
    unichr() and make them methods of the root or base object. Transform
    them into object.func(parameters). Most of them have as the first
    parameter an object anyway. Some of them can be moved to sys. Various
    other functions can be deprecated so that I do no have to scan over a
    dozen of functions each time I am looking something up. Especially if
    few people use them anyway and they can be replaced 1:1 with another
    simple construct.

    6.) Eliminate lambda, use local ‘def somename(param):return expr'
    instead.

    7.) Eliminate locals(), globals() and replace with a vars() that
    defaults to locals, and accept a parameter to get globals().

    8.) Eliminate `x` for repr()

    9.) Eliminate raw_input() and replace input() with raw_input()
    implementation. Input can be done using eval(input()). Do NOT simply
    eliminate input, print and put it in sys. Although it IS ugly, reading
    and writing to standard input and output is the bread and butter of
    admin scripts, CGI and all kinds of glue programs (python's core
    usage) and should be readily available. It also makes for a quick and
    dirty user input and output for debugging. sys.stdin.readline() is too
    verbose IMHO.

    10.) Eliminate the recursion limit on functions or better yet, include
    an option to change from the default to infinite. No need to change
    anything in the language. A lot of work in the implementation though.
    Could use regular method up to a number of calls and then switch to a
    less performant method.

    11.) Add a big decimal type (something like java) in the standard
    library. To be able to do bean counter type math easily. Are there so
    few python applications that deal with money?

    12.) Int division: return float (for engineers) or big decimal (for
    bean counters)

    Some of them are blatantly copied from Guidos regrets slides btw. I
    just happen to agree with most of the points on them.

    Nestor
    nnes, Aug 26, 2003
    #1
    1. Advertising

  2. nnes

    AdSR Guest

    (nnes) wrote...
    > 8.) Eliminate `x` for repr()


    I have a different idea for backticks use: something like `foo` in
    Unix shells. It would behave more or less like popen("foo"), just a
    bit smarter. You could either:

    >>> print `ls`


    and get the whole output of /bin/ls

    - or -

    >>> for line in `ls`

    .... print line

    and read output of /bin/ls line by line.

    I would add other behavior of string types, like % formatting, so you
    could do:

    >>> print `ls %s %s` % ('-a', '*foo*')


    One potential problem is closing the underlying popen() object early
    enough. And it's not really a big advantage over popen() either.

    > 11.) Add a big decimal type (something like java) in the standard
    > library. To be able to do bean counter type math easily. Are there so
    > few python applications that deal with money?


    I second that. We already have unlimited longs, but with floats we're
    limited to platform-specific values.

    > 12.) Int division: return float (for engineers) or big decimal (for
    > bean counters)


    Rational type also fits here to some extent. I wouldn't make it part
    of the language though, but rather a standard library type,
    rational(a, b=1).

    AdSR
    AdSR, Aug 26, 2003
    #2
    1. Advertising

  3. (nnes) writes:

    > I have really no mayor gripes, and the few things I would change would
    > break backward compatibility, but here is the list anyway:
    >
    > 1.) Eliminate the whole long stuff. E.g. built-in long () function,
    > "L", etc. It is a Python language implementation detail and I do not
    > care about how it is done as long as it is fast and correct. Make
    > python int adapt according to size of the integer and underlying
    > architecture. 8088-80286=16 bit integers, 386-586=32
    > bit, x86-64=64bit. If number overflows the CPU architecture
    > auto-magically use internal (long) representation.


    In progress. See PEP 217.

    > 2.) Eliminate map (), filter (), reduce (). It can be replaced with
    > list comprehensions and for loops, which are easier to read.


    I'm wary of "eliminate" -- why break old code for no very good reason?
    "discourage", maybe.

    > 3.) Eliminate open (), use file () instead


    Hmm. I think "open" reads better, myself.

    > 4.) Eliminate xrange(), replace range() with xrange() implementation


    Backward compatibility again: some code really does expect to get a
    list out of range(). But there are signs things are nudging in this
    direction, slowly.

    > 5.) Eliminate built-in functions buffer(), callable(), delattr(),
    > dir(), getattr(), hasattr(), hash(), help(), id(), isinstance(),
    > len(), max(), min(), repr(), setattr(), sum(), str(), type(),
    > unichr() and make them methods of the root or base object.


    Ye gods, no. This would be pure churn. And I'm not sure it's even a
    good idea for some of those listed.

    > 6.) Eliminate lambda, use local ‘def somename(param):return expr'
    > instead.


    With you here, modulo the usual "eliminate" concern.

    > 7.) Eliminate locals(), globals() and replace with a vars() that
    > defaults to locals, and accept a parameter to get globals().


    Why?

    [...]
    > 10.) Eliminate the recursion limit on functions or better yet, include
    > an option to change from the default to infinite. No need to change
    > anything in the language. A lot of work in the implementation though.
    > Could use regular method up to a number of calls and then switch to a
    > less performant method.


    See www.stackless.com :)

    > 11.) Add a big decimal type (something like java) in the standard
    > library. To be able to do bean counter type math easily. Are there so
    > few python applications that deal with money?


    Again, there is movement here.

    > 12.) Int division: return float (for engineers) or big decimal (for
    > bean counters)


    I really don't like the idea of having optional behaviour here.

    > Some of them are blatantly copied from Guidos regrets slides btw. I
    > just happen to agree with most of the points on them.


    I thought some of them looked familiar :)

    ----

    There's a distinction between "how would I do things if I could go
    back to the early 1990s and have a chat with Guido" and "what changes
    are worth making now". There's a price to any change (esp. ones like
    "eliminate open()"...) and I think my limit may be set a little lower
    than yours :)

    Cheers,
    mwh

    --
    ARTHUR: Why are there three of you?
    LINTILLAS: Why is there only one of you?
    ARTHUR: Er... Could I have notice of that question?
    -- The Hitch-Hikers Guide to the Galaxy, Episode 11
    Michael Hudson, Aug 26, 2003
    #3
  4. (nnes) wrote in message news:<>...
    > I have really no mayor gripes, and the few things I would change would
    > break backward compatibility, but here is the list anyway:
    >
    > 2.) Eliminate map (), filter (), reduce (). It can be replaced with
    > list comprehensions and for loops, which are easier to read.


    How do you pass a list comprehension to a function? With map
    as a function, you could do something wicked like

    do_something_wicked([map, my_map, his_map])

    Where my_map and his_map are alternative implementations for
    map, and do_something_wicked would use all those functions
    for something crazy. But sure, map could be implemented with
    list comprehensions if it was really needed, probably like this:

    def map(fn, *lists):
    return [fn(*args) for args in zip(*lists)]

    Soo.. Do I have an optinion? Maybe, maybe not.. I just wanted
    to point out that some things are useful as being functions
    instead of plain syntax.

    > 4.) Eliminate xrange(), replace range() with xrange() implementation


    Then people would have to use list(range[10]) to get the list when
    needed.. I always use range() since Psyco seems to optimize it
    to a simple for loop of integers (on my tests with Psyco,
    "for x in range(n)" is -faster- than "for x in xrange(n)"!).
    So xrange() could be removed, and then people would just rely
    on JIT compiler optimizations to do the right thing.
    Maybe not yet though.

    > 6.) Eliminate lambda, use local ?def somename(param):return expr'
    > instead.


    Noo, lambda is so lovely and compact. It only obfuscates on
    the purposedly obfuscated code. It's too long word for my taste
    though.. A symbol for it would be better (I'm not joking).
    =?ISO-8859-1?Q?Hannu_Kankaanp=E4=E4?=, Aug 26, 2003
    #4
  5. nnes

    Andrew Dalke Guest

    A. Lloyd Flanagan:
    > open() is deprecated [in favor of 'file'], I don't know about plans
    > to eliminate it.


    I think formally speaking it isn't deprecated. The docs say open
    is "An alias for the file() function"

    http://www.python.org/doc/2.3/lib/built-in-funcs.html


    Andrew
    Andrew Dalke, Aug 27, 2003
    #5
  6. nnes

    Gerrit Holl Guest

    A. Lloyd Flanagan wrote:
    > (nnes) wrote in message news:<>...
    > > I have really no mayor gripes, and the few things I would change would
    > > break backward compatibility, but here is the list anyway:
    > >
    > > 3.) Eliminate open (), use file () instead

    > open() is deprecated, I don't know about plans to eliminate it.


    Doesn't 'deprecated' mean it will once be elimineted?

    > > 5.) Eliminate built-in functions buffer(), callable(), delattr(),
    > > dir(), getattr(), hasattr(), hash(), help(), id(), isinstance(),
    > > len(), max(), min(), repr(), setattr(), sum(), str(), type(),

    > Many of these are being superseded by object meathods. I don't know
    > about eliminating them; you'd break nearly every old program.


    Python 3.0...?

    Gerrit.

    --
    173. If this woman bear sons to her second husband, in the place to
    which she went, and then die, her earlier and later sons shall divide the
    dowry between them.
    -- 1780 BC, Hammurabi, Code of Law
    --
    Asperger Syndroom - een persoonlijke benadering:
    http://people.nl.linux.org/~gerrit/
    Het zijn tijden om je zelf met politiek te bemoeien:
    http://www.sp.nl/
    Gerrit Holl, Aug 27, 2003
    #6
  7. nnes

    Peter Hansen Guest

    Gerrit Holl wrote:
    >
    > A. Lloyd Flanagan wrote:
    > > (nnes) wrote in message news:<>...
    > > > I have really no mayor gripes, and the few things I would change would
    > > > break backward compatibility, but here is the list anyway:
    > > >
    > > > 3.) Eliminate open (), use file () instead

    > > open() is deprecated, I don't know about plans to eliminate it.

    >
    > Doesn't 'deprecated' mean it will once be elimineted?


    It doesn't mean "will be", but usually means "might be". Nobody,
    except Guido with the time machine of course, can predict the
    future, so it expresses only intent. And sometimes a thing can
    be deprecated (as in "don't use this in new code") without anyone
    actually planning to eliminate it, ever.

    -Peter
    Peter Hansen, Aug 27, 2003
    #7
    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. Wong CS
    Replies:
    0
    Views:
    501
    Wong CS
    Jan 30, 2005
  2. Stefan Siegl
    Replies:
    1
    Views:
    754
  3. Saverio M.
    Replies:
    0
    Views:
    496
    Saverio M.
    Jul 3, 2006
  4. Roedy Green
    Replies:
    1
    Views:
    390
    John W Kennedy
    Oct 30, 2008
  5. David Filmer
    Replies:
    17
    Views:
    243
    J. Romano
    Aug 18, 2004
Loading...

Share This Page