python idioms : some are confusing

Discussion in 'Python' started by Vineet, Sep 21, 2012.

  1. Vineet

    Vineet Guest

    Amongst the python idioms, how the below-mentioned make sense?

    ## There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.

    --- In programming, there can be a number of ways, equally efficient, to do certain thing.

    ## Although never is often better than *right* now.

    --- How come "never" is better that "right now" ?


    Any thoughts?...
     
    Vineet, Sep 21, 2012
    #1
    1. Advertising

  2. Vineet

    alex23 Guest

    On Sep 21, 3:34 pm, Vineet <> wrote:
    > Amongst the python idioms, how the below-mentioned make sense?
    > ## There should be one-- and preferably only one --obvious way to do it.
    > --- In programming, there can be a number of ways, equally efficient, to do certain  thing.


    This isn't talking about your Python code as much as about Python
    itself. For example, in Python 2.x you can use either `open` or `file`
    to open a file, with `file` being a factory function for creating file
    objects, and `open` using it internally. In Python 3.x, `file` is no
    longer a built-in, as it produced a point of confusion as to which was
    the one obvious way to open a file.

    > ## Although never is often better than *right* now.
    > --- How come "never" is better that "right now" ?


    It's better to not add a language feature than it is to add it poorly,
    especially when you endeavour to provide backwards compatibility as
    much as possible within major versions.
     
    alex23, Sep 21, 2012
    #2
    1. Advertising

  3. Vineet

    Chris Rebert Guest

    On Thu, Sep 20, 2012 at 10:34 PM, Vineet <> wrote:
    > Amongst the python idioms, how the below-mentioned make sense?


    These aren't idioms (that term has a specific technical meaning in
    programming); they're *way* too abstract to be idioms. "Design
    principles" or "design guidelines" would be a better description.

    > ## There should be one-- and preferably only one --obvious way to do it.
    > Although that way may not be obvious at first unless you're Dutch.
    >
    > --- In programming, there can be a number of ways, equally efficient, to do certain thing.


    Yes, but that brings with it the cost of having to understand/learn
    them all, because you'll encounter them when
    reading/maintaining/modifying others' code. And you'll have to
    evaluate them all to choose which one you should use (which might even
    vary from moment to moment depending on the circumstances). And you'll
    have to watch out for subtle variants that actually do something
    significantly different. Better to keep things simple in the X% of
    cases where the differences don't matter enough, and save those brain
    cycles for other, more important things.

    See also: the so-called "paradox of choice".
    Further reading: the criticisms on
    http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt

    > ## Although never is often better than *right* now.
    >
    > --- How come "never" is better that "right now" ?


    Because "right now" is so quick that it was likely hastily hacked
    together and thus of poor (or at least lesser) quality.

    Cheers,
    Chris
     
    Chris Rebert, Sep 21, 2012
    #3
  4. Vineet

    Vineet Guest

    Oh I see !
    On these lines mentioned by you, I can now sense the sense.
    Thanks.

    On Friday, 21 September 2012 11:22:45 UTC+5:30, alex23 wrote:
    > On Sep 21, 3:34 pm, Vineet <> wrote:
    >
    > > Amongst the python idioms, how the below-mentioned make sense?

    >
    > > ## There should be one-- and preferably only one --obvious way to do it..

    >
    > > --- In programming, there can be a number of ways, equally efficient, to do certain  thing.

    >
    >
    >
    > This isn't talking about your Python code as much as about Python
    >
    > itself. For example, in Python 2.x you can use either `open` or `file`
    >
    > to open a file, with `file` being a factory function for creating file
    >
    > objects, and `open` using it internally. In Python 3.x, `file` is no
    >
    > longer a built-in, as it produced a point of confusion as to which was
    >
    > the one obvious way to open a file.
    >
    >
    >
    > > ## Although never is often better than *right* now.

    >
    > > --- How come "never" is better that "right now" ?

    >
    >
    >
    > It's better to not add a language feature than it is to add it poorly,
    >
    > especially when you endeavour to provide backwards compatibility as
    >
    > much as possible within major versions.
     
    Vineet, Sep 21, 2012
    #4
  5. I'm responding to the OP here, not to Alex, but I'm quoting his text
    to expand on it. :)

    On Fri, Sep 21, 2012 at 3:52 PM, alex23 <> wrote:
    > On Sep 21, 3:34 pm, Vineet <> wrote:
    >> Amongst the python idioms, how the below-mentioned make sense?
    >> ## There should be one-- and preferably only one --obvious way to do it.
    >> --- In programming, there can be a number of ways, equally efficient, to do certain thing.

    >
    > This isn't talking about your Python code as much as about Python
    > itself.


    The "it" in the zen there refers to some programming task. For
    instance, there's only one obvious way to increment an integer:

    spam += 1

    Python's philosophy is to have just that, and to not trouble itself
    with "spam++" and "++spam" and the distinction between them. As a C
    programmer, I'm quite accustomed to them, and know what they mean, but
    not everyone does. And don't get me started on "&&" vs "and" in PHP...
    Python is a simpler and cleaner language for not having superfluous
    operators.

    >> ## Although never is often better than *right* now.
    >> --- How come "never" is better that "right now" ?

    >
    > It's better to not add a language feature than it is to add it poorly,
    > especially when you endeavour to provide backwards compatibility as
    > much as possible within major versions.


    The compatibility issue is the thing here. It's better to get
    something good now rather than dither for another fifty years, because
    the longer you dally, the more code will be written using third party
    libraries. But it's better to not put it into the standard library at
    all than to put in a messy API that now can't be changed because
    code's using it.

    The Zen of Python is a whole lot of tradeoffs and ideas. Several of
    them balance each other directly. Some, while not contradicted in the
    Zen itself, are still violated at times in the language and/or stdlib.
    They're principles, not laws, and need to be read with the
    understanding that people who write code are intelligent, thinking
    beings (though a quick look at TheDailyWTF.com proves that this is not
    universal).

    ChrisA
     
    Chris Angelico, Sep 21, 2012
    #5
  6. On Thu, 20 Sep 2012 22:34:48 -0700, Vineet wrote:

    > Amongst the python idioms, how the below-mentioned make sense?


    They're not Python idioms. Idioms are common pieces of code, like looping:

    for item in sequence:
    do_something

    What you have quoted are parts of the Zen of Python, which is
    deliberately named. Zen koans are notorious for being contradictory and
    impossible to understand.

    As Terry Pratchett wrote:

    In the second scroll of Wen the Eternally Surprised a story
    is written concerning one day when the apprentice Clodpool,
    in a rebellious mood, approached Wen and spake thusly:
    "Master, what is the difference between a humanistic, monastic
    system of belief in which wisdom is sought by means of an
    apparently nonsensical system of questions and answers, and a
    lot of mystic gibberish made up on the spur of the moment?"
    Wen considered this for some time, and at last said: "A fish!"
    And Clodpool went away, satisfied.
    -- (Terry Pratchett, Thief of Time)


    So be careful about over-interpreting the Zen of Python. Half of it is
    meant to followed seriously, half is meant as a joke, and half is meant
    as a guideline only.


    > ## There should be one-- and preferably only one --obvious way to do it.
    > Although that way may not be obvious at first unless you're Dutch.


    This tells us that for any task you might want to do in Python, there
    should be some way to do it which is obvious. It is not enough that there
    is some (hard to find, convoluted) way to do it, it should be obvious.
    And while it isn't forbidden to be two or more obvious ways, it is better
    if there is only one.

    The joke is that even this single sentence goes against its own advice.
    There are at least three obvious ways to put a parenthetical aside in a
    sentence:

    There should be one--and preferably only one--obvious way to do it.
    There should be one -- and preferably only one -- obvious way to do it.
    There should be one (and preferably only one) obvious way to do it.

    The author of the Zen deliberately choose a fourth, non-obvious way.

    Finally, the second line warns that although Python has many obvious ways
    to solve things, they may only be obvious to the creator of Python, Guido
    van Rossum, who is Dutch.


    > --- In programming, there can be a number of ways, equally efficient, to
    > do certain thing.


    The Zen refers to the philosophy that Python the language should provide
    an obvious way to solve a problem. The emphasis is on the *obvious* part,
    not the *one* part.


    > ## Although never is often better than *right* now.
    >
    > --- How come "never" is better that "right now" ?



    Solving a problem in the language -- adding a new language feature such
    as a keyword, new syntax, a library, etc. -- should only be done when
    that new feature brings more benefit than problems. But sometimes a new
    feature might bring more problems than benefits. In this case, it is
    better to *never* solve that problem *in the language* than to add a
    feature that solves the problem badly and causes more problems than it
    solves. E.g. multi-line lambdas.

    The problem is that once you add a feature to the language, it becomes
    almost impossible to remove it. You are stuck with it nearly forever, or
    at least for many years. So better to not add it than to be stuck with a
    bad feature.



    --
    Steven
     
    Steven D'Aprano, Sep 21, 2012
    #6
  7. On Thu, 20 Sep 2012 22:52:45 -0700, alex23 wrote:

    > On Sep 21, 3:34 pm, Vineet <> wrote:
    >> Amongst the python idioms, how the below-mentioned make sense? ## There
    >> should be one-- and preferably only one --obvious way to do it. --- In
    >> programming, there can be a number of ways, equally efficient, to do
    >> certain  thing.

    >
    > This isn't talking about your Python code as much as about Python
    > itself. For example, in Python 2.x you can use either `open` or `file`
    > to open a file, with `file` being a factory function for creating file
    > objects, and `open` using it internally. In Python 3.x, `file` is no
    > longer a built-in, as it produced a point of confusion as to which was
    > the one obvious way to open a file.


    I don't think that's the reason. I think the reason is that moving the
    built-in file into the _io library gives the developers a lot more
    flexibility in how they handle text and binary files. E.g.:


    py> open('junk', 'w')
    <_io.TextIOWrapper name='junk' mode='w' encoding='UTF-8'>

    py> open('junk', 'wb')
    <_io.BufferedWriter name='junk'>

    py> open('junk', 'wb', buffering=0)
    <_io.FileIO name='junk' mode='wb'>


    The open() function now can return three (or more?) types instead of
    having a single built-in type handle all cases.



    --
    Steven
     
    Steven D'Aprano, Sep 21, 2012
    #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. Eli Bendersky
    Replies:
    9
    Views:
    713
    Allan Herriman
    Apr 7, 2006
  2. Tad Marko

    Need help with Python class idioms

    Tad Marko, Jan 21, 2004, in forum: Python
    Replies:
    17
    Views:
    501
    engsol
    Jan 25, 2004
  3. Replies:
    9
    Views:
    696
    Carl Friedrich Bolz
    Feb 5, 2006
  4. learning python idioms

    , Jun 11, 2006, in forum: Python
    Replies:
    6
    Views:
    562
    James Stroud
    Jun 11, 2006
  5. Ben Charrow

    Idioms and Anti-Idioms Question

    Ben Charrow, Jun 22, 2009, in forum: Python
    Replies:
    11
    Views:
    541
    Lawrence D'Oliveiro
    Jul 4, 2009
Loading...

Share This Page