Re: Least used builtins?

Discussion in 'Python' started by Sean 'Shaleh' Perry, Jul 4, 2003.

  1. On Friday 04 July 2003 10:27, Dan Bishop wrote:
    > (Sandy Norton) wrote in message
    > news:<>... [snip]
    >
    > > I know there some plans to reduce the number of builtins in some
    > > future version of python (Python 3.0?): So which builtins do you least
    > > use?
    > >
    > > Pesonally, I don't think I've ever used the following: intern, buffer,
    > > coerce

    >
    > I haven't used: apply, buffer, coerce, globals, intern, iter, locals,
    > oct, slice, super, unichr, unicode.


    apply isn't as useful as it used to be.

    locals and globals is useful in some interesting ways.

    iter is really new so no surprise you haven't used it yet.

    most people don't play with octal so I doubt oct() gets a lot of mileage.

    The unicode stuff is new and most English only coders don't use it. But the
    rest of the world does.
     
    Sean 'Shaleh' Perry, Jul 4, 2003
    #1
    1. Advertising

  2. |> I haven't used: apply, buffer, coerce, globals, intern, iter, locals,
    |> oct, slice, super, unichr, unicode.

    Sean 'Shaleh' Perry <> wrote previously:
    |apply isn't as useful as it used to be.
    |locals and globals is useful in some interesting ways.
    |iter is really new so no surprise you haven't used it yet.
    |most people don't play with octal so I doubt oct() gets a lot of mileage.
    |The unicode stuff is new and most English only coders don't use it.

    I wouldn't mind moving quite a bit of __builtins__ into standard
    modules. Doing that only creates a one-line incompatibility, i.e. you
    might need to add:

    from itertools import enumerate

    To the top of a module/script. Some quick thoughts:

    Current builtin Possible Home
    --------------- ---------------
    abs math
    apply functional
    basestring internal
    bool
    buffer
    callable sys
    chr
    classmethod new
    cmp
    coerce
    compile code
    complex math
    delattr
    dict
    dir
    divmod math
    enumerate itertools
    eval code
    execfile code
    file
    filter functional
    float
    getattr
    globals
    hasattr
    hash internal
    hex math
    id internal
    input
    int
    intern internal
    isinstance sys
    issubclass sys
    iter
    len
    list
    locals
    long
    map functional
    max math
    min math
    object internal
    oct math
    open
    ord
    pow math
    property new
    range
    raw_input
    reduce functinal
    reload
    repr
    round math
    setattr
    slice
    staticmethod new
    str
    super internal
    tuple
    type
    unichr
    unicode
    vars
    xrange itertools
    zip itertools

    This sort of thing would cleanup the minimal Python interpreter, while
    not deeply hiding/removing anything.

    Yours, Lulu...

    --
    mertz@ | The specter of free information is haunting the `Net! All the
    gnosis | powers of IP- and crypto-tyranny have entered into an unholy
    ..cx | alliance...ideas have nothing to lose but their chains. Unite
    | against "intellectual property" and anti-privacy regimes!
    -------------------------------------------------------------------------
     
    Lulu of the Lotus-Eaters, Jul 4, 2003
    #2
    1. Advertising

  3. I don't think any of these are a big deal. But I see several
    motivations for moving a number of the builtins that Bicking disagrees
    on. The breakage could be made small to non-existent by including a
    bunch of such things in a file like startup.py that gets loaded
    automatically, but that can be changed in principle.

    One general point is that getting rid of builtins can make a minimal
    Python footprint smaller (and load times slightly faster probably). For
    embedded systems, handhelds, etc. reducing the required memory usage is
    a good thing.

    A second issue is the PyPy project. I think it dovetails with that
    project to move everything that is a likely candidate for
    reimplementation *in* Python into non-core modules. Doing this is not
    strictly a requirement for PyPy, but it fits the style of thinking.

    A third matter is my support for the function decorator/mutator idea.
    classmethod, staticmethod, and property are nice method mutators, but as
    a number of people pointed out in that thread, they are not the only
    such modifiers one can imagine. Moreover, you can implement these in
    Python (I incorrectly once doubted this), so spinning them out of core
    makes sense from a #2 perspective.

    Yet a fourth matter is that I think it would be slightly easier to teach
    Python to beginners if __builtins__ did not include a number of
    functions that were extremely difficult to explain to novices... and
    that are really only of use to fairly expert Pythoneers. I find that
    callable, classmethod, id, intern, and a number of others fall in this
    category. My thinking is that anything meant for experts should need to
    get imported by specific request.

    All that said, I have neither any control of what happens, nor any
    strong attachment to any of my suggested homes for (former) builtins.

    |> enumerate itertools
    |Again, this is idiomatic, and it belongs in builtins.

    This one I strongly disagree with. The fact enumerate is builtin is a
    little bit of a wart. It's really -just like- the family of functions
    in itertools; only historical accident introduced it before itertools
    came into existence.

    |> filter functional
    |Only because it's become redundant.

    I don't at all think filter() is redundant... but I do think that a
    'functional' module could grow a lot of extra useful capabilities
    (currying, composition, etc). The usual filter/map/reduce would make a
    good start for such a module (and clean up the base interpreter for
    those FP-haters out there :)).

    |Definitely not -- these are very important, importing them would be
    |obnoxious. Especially since "isinstance(value, str)" is the preferred
    |technique over "type(value) is str".

    Actually, I considered listing type() for desired removal to a module.
    I suppose for consistency with my purport on isinstance() I ought to
    advocate that.

    |[super] Again, highly idiomatic, programmers should be discouraged from
    |using this name for anything else

    Indeed. But non-advanced programmer won't be using it for its builtin
    meaning either. Just look at all the threads by quite sophisticated
    Pythonistas trying to clarify exactly what super() really does. You
    cannot even understand this function without first getting C3
    linearization (and even then, figuring out what the different calling
    forms all do is still tricky).

    |zip, like enumerate, is idiomatic -- importing it does not imply
    |anything about your code, that it comes from itertools lends little
    |insight into what zip does.

    Actually, I don't think a separate zip/izip does any good, nor
    range/xrange. But those are more historical accidents. I wouldn't mind
    seeing itertools have the same kind of status that sys does now. What's
    the last script you wrote that didn't import sys? You don't technically
    need it... until you want to do something with input, output or
    arguments :).

    Yours, Lulu...

    --
    mertz@ | The specter of free information is haunting the `Net! All the
    gnosis | powers of IP- and crypto-tyranny have entered into an unholy
    ..cx | alliance...ideas have nothing to lose but their chains. Unite
    | against "intellectual property" and anti-privacy regimes!
    -------------------------------------------------------------------------
     
    Lulu of the Lotus-Eaters, Jul 5, 2003
    #3
    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. kkk
    Replies:
    0
    Views:
    322
  2. kkk
    Replies:
    3
    Views:
    441
    santosh
    Mar 5, 2007
  3. Alf P. Steinbach
    Replies:
    54
    Views:
    1,436
    Jorgen Grahn
    Sep 28, 2007
  4. AAaron123
    Replies:
    0
    Views:
    631
    AAaron123
    Oct 3, 2008
  5. DoomedLung
    Replies:
    1
    Views:
    100
    web.dev
    Sep 28, 2006
Loading...

Share This Page