Re: "as" keyword woes

Discussion in 'Python' started by Warren DeLano, Dec 4, 2008.


  1. > I don't know how you infer any of those from what I said, nor
    > from the process of introducing features in Python. None of
    > what you say there rings at all true with anything I've
    > experienced in Python's core or the attitudes surrounding
    > development if the language; indeed, quite the opposite.


    That has been my experience as well, which is why this particular action
    seems surprising and out of character.

    > Speaking of irony, you're complaining about namespace
    > conflicts with a -two character identifier- you've chosen.
    > Here's a hint: choose better names.


    Hey, come on now -- developers working on top of an existing language
    bear nowhere near the responsibility as the language & implementation
    maintainers. Also, note that the fields of math and science are filled
    with short identifiers with well-defined meanings -- brevity doesn't
    mean ambiguous within a given application domain! But regardless, our
    scripts use "as" in the same way as Python -- to change the effective
    appearance of an object, albeit in a representational rather than naming
    space. So if we're wrong in our choice, then so is Python.

    In addition, note that my choice of a concise method identifier affects
    only my users. Python's introduction of a new keyword affects the
    entire Python world code base, so perhaps you should be directing your
    "choose better names" criticism in another direction?

    > To match your honesty, I'm somewhat tired with the trend of
    > some people to hit -one- issue with Python and suddenly lash
    > out like children over all the same old tired crap. Have you
    > even looked at multiprocessing? Have you contributed to any
    > projects working on GIL- less implementations? Or are you
    > just regurgitating the same bullet points we've heard time
    > and time again?


    Multiprocessing solves some problems, but it is unsuitable for
    high-frequency handoffs of large (in memory) objects between many
    independent threads/processes -- the HPC object/data flow
    parallelization model in a nutshell.

    Furthermore, not every coder has the compsci chops to work on language &
    VM implementations (my PhD involved programming DNA and directing
    evolution in a test tube, not parse trees and state machines). But that
    isn't to say I didn't try: at one point I even sketched out a possible
    TLS-based GIL workaround for handling the issue without breaking the
    existing C/API. It was of course shunned by those who knew better...for
    performance reasons IIRC.

    > For chrissake, if you cannot do ANYTHING but BITCH about a
    > change, then you've no damn right to consider yourself a
    > programmer. Real programmers find solutions, not excuses.


    Though I have certainly bitched about the threading issue multiple times
    on mailing lists including baypiggies and python-dev, bitching is not
    the only thing I've done. Having come to grips with my own coding
    limitations, I also offered to contribute financial resources from my
    own Python-enhanced business in support of GIL-removal -- before Python
    3.0 was finalized. Unfortunately, no one responded to my offer.

    Even today, I am indirectly proposing the solution of "as" not being a
    reserved keyword since it has worked just fine for years without it.
    Yes that's late, but I didn't see this particular trainwreck coming
    (since it is not actually our current code which breaks, but rather,
    quantities of code created years ago but which must still run with
    fidelity into the far off future). Installing a Python macro
    preprocessor is another after-the-fact possible solution which may bear
    further investigation...

    Also today, I am proposing a pragmatic general solution for projects
    like ours in addressing both the 2.6/3.0 compatibility and threading
    situations. Specifically: deliberate migration away from C/Python and
    on to alternate VMs which happen to support Python syntax.

    Obviously none of my past efforts yielded fruit -- but it is wrong and
    unfair of you to assume and accuse me of not trying to come up with
    solutions. Solutions are virtually the entire game!

    > > And if so, then thank you all for so many wonderful years of effort
    > > and participation!

    >
    > You're welcome. Don't let the door hit you on the ass on your way out.


    But who's leaving who exactly? Surely a language as beautiful as Python
    will easily transcend the limitations of its flagship implementation (if
    or to the extent that such an implementation cannot keep pace with the
    times). That's all well and good -- it may even end up being the next
    great leap forward for the language. I believe Guido has even said as
    much himself.

    Warren
    Warren DeLano, Dec 4, 2008
    #1
    1. Advertising

  2. Warren DeLano

    James Mills Guest

    One of the things I'd like to point out here is
    what we've been learning in new job during
    Induction Training...

    That is, it's part of the coding standard and
    design standards to name variables sensibly.

    For instance, naming a variable "db" when it's
    really a "database" object is a no no. Instead
    you should be naming it "db".

    Another example, "db_id" vs. "database_id".

    So my point here is that you should not really/ideally
    be naming variables with such short un-meaningful
    names such as "as", "if", "id", "xs" or what not.

    Readability of your code becomes very important
    especially if you're working with many developers
    over time.

    1. Use sensible meaningful names.
    2. Don't use abbreviations.

    cheers
    James

    On Thu, Dec 4, 2008 at 8:43 PM, Dennis Lee Bieber <> wrote:
    > On Thu, 4 Dec 2008 01:28:56 -0800, "Warren DeLano" <>
    > declaimed the following in comp.lang.python:
    >
    >> In addition, note that my choice of a concise method identifier affects
    >> only my users. Python's introduction of a new keyword affects the
    >> entire Python world code base, so perhaps you should be directing your
    >> "choose better names" criticism in another direction?
    >>

    > Dropping in...
    >
    > If a "chosen name" mirrors a syntactic element -- whether reserved
    > or not -- I'd consider that name potentially ambiguous or conflicted.
    >
    > While "if" has been long a reserved word, I can as easily see
    > someone using "if" as a shorthand name for "interface". And if "if" were
    > not a reserved word, one might encounter code on the lines of
    >
    > if = if + 1
    >
    > which is quite obnoxious to my eyes... or maybe
    >
    > if if.connected:
    > if.close()
    >
    >
    > Since
    >
    > import x as y
    >
    > has been a syntactic capability for some time, even if not reserved, I'd
    > have avoided using "as" as anything other than that usage...
    > --
    > Wulfraed Dennis Lee Bieber KD6MOG
    >
    > HTTP://wlfraed.home.netcom.com/
    > (Bestiaria Support Staff: )
    > HTTP://www.bestiaria.com/
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >




    --
    --
    -- "Problems are solved by method"
    James Mills, Dec 4, 2008
    #2
    1. Advertising

  3. Warren DeLano

    Aaron Brady Guest

    On Dec 4, 4:43 am, Dennis Lee Bieber <> wrote:
    > On Thu, 4 Dec 2008 01:28:56 -0800, "Warren DeLano" <>
    > declaimed the following in comp.lang.python:
    >
    > > In addition, note that my choice of a concise method identifier affects
    > > only my users.  Python's introduction of a new keyword affects the
    > > entire Python world code base, so perhaps you should be directing your
    > > "choose better names" criticism in another direction?

    >
    >         Dropping in...
    >
    >         If a "chosen name" mirrors a syntactic element -- whether reserved
    > or not -- I'd consider that name potentially ambiguous or conflicted.
    >
    >         While "if" has been long a reserved word, I can as easily see
    > someone using "if" as a shorthand name for "interface". And if "if" were
    > not a reserved word, one might encounter code on the lines of
    >
    >         if = if + 1
    >
    > which is quite obnoxious to my eyes... or maybe
    >
    >         if if.connected:
    >                 if.close()


    Does the OP hold the following should be legal?

    if if or or:
    and( for )
    if not:
    while( def )

    If not, it's an exception to Python's trend of not handcuffing
    programmers.
    Aaron Brady, Dec 4, 2008
    #3
  4. Warren DeLano

    Aaron Brady Guest

    On Dec 4, 3:28 am, "Warren DeLano" <> wrote:
    > > Have you
    > > even looked at multiprocessing?


    > Multiprocessing solves some problems, but it is unsuitable for
    > high-frequency handoffs of large (in memory) objects between many
    > independent threads/processes -- the HPC object/data flow
    > parallelization model in a nutshell.  


    I think 'mmap' combined with 'ctypes.Structure' is an underrated
    approach to such use cases. There is also POSH, Python Object Sharing.
    Aaron Brady, Dec 4, 2008
    #4
  5. Warren DeLano

    James Mills Guest

    On Thu, Dec 4, 2008 at 9:04 PM, Aaron Brady <> wrote:
    [... snip ...]

    > Does the OP hold the following should be legal?
    >
    > if if or or:
    > and( for )
    > if not:
    > while( def )


    I most certainly hope not! :)

    --JamesMills

    --
    --
    -- "Problems are solved by method"
    James Mills, Dec 4, 2008
    #5
  6. Warren DeLano

    alex23 Guest

    On Dec 4, 7:28 pm, "Warren DeLano" <> wrote:
    > But who's leaving who exactly?  Surely a language as beautiful as Python
    > will easily transcend the limitations of its flagship implementation (if
    > or to the extent that such an implementation cannot keep pace with the
    > times).  That's all well and good -- it may even end up being the next
    > great leap forward for the language.  I believe Guido has even said as
    > much himself.


    Warren, thank you for a far more reasonable response than my post
    warranted. There seems a trend on this group for frustration to turn
    into ultimatums, which is what really triggered my outburst. Well,
    that and a crappy day at work.

    As for your above comment, I totally agree. It's probably the main
    outcome I'd like to see arise from the PyPy project: faster and easier
    experimentation with implementations. Nothing like some additional
    evolutionary pressure to make Python more fit.

    Good luck with resolving your current issue.
    alex23, Dec 4, 2008
    #6
  7. On Thu, 04 Dec 2008 20:53:38 +1000, James Mills wrote:

    > Readability of your code becomes very important especially if you're
    > working with many developers over time.
    >
    > 1. Use sensible meaningful names.
    > 2. Don't use abbreviations.


    This is excellent advice, but remember, what is a sensible meaningful
    name is domain-specific. In a maths library, this would be sensible:

    def poly(x):
    return 4*x**3 -2*x**2 +3*x -7

    and this ridiculous:

    def poly(real_number):
    return 4*real_number**3 -2*real_number**2 +3*real_number -7


    Sometimes there are name clashes between keywords and sensible names in
    your problem space. I'm sure every regular Python developer has found
    themselves writing something like:

    prnt print_ print2
    cls klass class_

    or similar. In the standard library, the random module uses an argument
    "lambd" because lambda is a keyword.



    --
    Steven
    Steven D'Aprano, Dec 4, 2008
    #7
  8. Warren DeLano

    Chris Mellon Guest

    On Thu, Dec 4, 2008 at 8:45 AM, Steven D'Aprano
    <> wrote:
    > On Thu, 04 Dec 2008 20:53:38 +1000, James Mills wrote:
    >
    >> Readability of your code becomes very important especially if you're
    >> working with many developers over time.
    >>
    >> 1. Use sensible meaningful names.
    >> 2. Don't use abbreviations.

    >
    > This is excellent advice, but remember, what is a sensible meaningful
    > name is domain-specific. In a maths library, this would be sensible:
    >
    > def poly(x):
    > return 4*x**3 -2*x**2 +3*x -7
    >
    > and this ridiculous:
    >
    > def poly(real_number):
    > return 4*real_number**3 -2*real_number**2 +3*real_number -7
    >
    >


    I actually wonder. The former is "sensible" in a math context because
    there's a very long tradition in mathematics of using terse,
    inscrutable placeholders for terms. I'm not a mathematician and I
    don't know anything about the history of mathematical notation, but
    I'd guess this has something to do with the fact that maths has
    historically been done with a pencil and paper, and that terseness is
    an important quality when you have a limited canvas and lots of stuff
    to write.

    Aside from the cultural indoctrination, though (and that may be a real
    and strong force when dealing with math software, and I don't want to
    discount it in general, just for purposes of this discussion) why is
    it more sensible to use "x" here instead of "number" or "real" or
    "real_number" or something else?
    Chris Mellon, Dec 4, 2008
    #8
  9. On Thu, 4 Dec 2008 10:44:33 -0600 "Chris Mellon" <>
    wrote:

    > Aside from the cultural indoctrination, though (and that may be a real
    > and strong force when dealing with math software, and I don't want to
    > discount it in general, just for purposes of this discussion) why is
    > it more sensible to use "x" here instead of "number" or "real" or
    > "real_number" or something else?


    I think "aside from" doesn't really apply. It is habitual to write
    mathematics in shorthand. That is a, if not *the* factor to consider.

    Also: Variable names in programs tend to describe what those things
    *do* not what they are. If I call a variable "number", the reader will
    usually none the wiser, because you deal with numbers a lot anyway.
    You'd call your numbers "counter", "height", "pressure" and the like.

    If however you do lots of numerical computations, your numbers tend to
    be just that, numbers. You'll gain nothing but confusion by calling them
    "number1", "number2", "number3". They are then much easier to discern
    by calling them x, y and z.

    I think.
    /W

    --
    My real email address is constructed by swapping the domain with the
    recipient (local part).
    Andreas Waldenburger, Dec 4, 2008
    #9
  10. On Thu, 04 Dec 2008 10:44:33 -0600, Chris Mellon wrote:

    > On Thu, Dec 4, 2008 at 8:45 AM, Steven D'Aprano
    > <> wrote:
    >> On Thu, 04 Dec 2008 20:53:38 +1000, James Mills wrote:
    >>
    >>> Readability of your code becomes very important especially if you're
    >>> working with many developers over time.
    >>>
    >>> 1. Use sensible meaningful names.
    >>> 2. Don't use abbreviations.

    >>
    >> This is excellent advice, but remember, what is a sensible meaningful
    >> name is domain-specific. In a maths library, this would be sensible:
    >>
    >> def poly(x):
    >> return 4*x**3 -2*x**2 +3*x -7
    >>
    >> and this ridiculous:
    >>
    >> def poly(real_number):
    >> return 4*real_number**3 -2*real_number**2 +3*real_number -7
    >>
    >>
    >>

    > I actually wonder. The former is "sensible" in a math context because
    > there's a very long tradition in mathematics of using terse, inscrutable
    > placeholders for terms.


    It's only inscrutable to those who don't speak the language, in the same
    way that those who don't read English would find "The cat sat on the mat"
    to be inscrutable, or those with no programming experience at all would
    find:

    if myList is not None: return [item.method() for item in myList.process()]

    fairly mystifying. It almost looks like English, but what's with the
    weird punctuation and non-standard use of capitals?



    > I'm not a mathematician and I don't know
    > anything about the history of mathematical notation, but I'd guess this
    > has something to do with the fact that maths has historically been done
    > with a pencil and paper, and that terseness is an important quality when
    > you have a limited canvas and lots of stuff to write.


    I don't believe "limited canvas" is a major factor, because the
    availability of paper is only rarely a limiting factor. (However, there
    have been periods where paper or its equivalent was a rare and precious
    commodity.) Having lots of stuff to write by hand is a real factor
    though, especially since in a typical proof each line is very similar to
    the previous line.


    > Aside from the cultural indoctrination, though (and that may be a real
    > and strong force when dealing with math software, and I don't want to
    > discount it in general, just for purposes of this discussion) why is it
    > more sensible to use "x" here instead of "number" or "real" or
    > "real_number" or something else?


    Because the long names actually distract from the essential semantics of
    the problem being worked on. Consider my example:

    return 4*x**3 -2*x**2 +3*x -7

    Translated into English, this would mean:

    Think of a number and call it x, and by convention it is a real number;
    cube it and multiply by four;
    subtract two times the square of it;
    add three times it;
    subtract 7


    Compare this:

    return 4*real_number**3 -2*real_number**2 +3*real_number -7

    As a mathematician, I would read that as:

    Think of a number and call it real_number;
    cube it and multiply by four, and don't forget the number needs to be a
    real number;
    subtract two times the square of it, and remember the number is a real
    number;
    add three times it, and did I mention that it has to be a real number?;
    subtract 7

    Explicit is not *always* better than implicit, and terseness *is* a
    virtue (up to a point!) which is why we don't do this:

    Define a function called myFunc which takes one argument called foo. The
    instructions to be executed when calling myFunc start here:
    if the value of the argument foo is identical to the value of the
    keyword None then:
    change the value of the argument foo to the result returned by
    the function calc_foo, passing no arguments to it
    otherwise do nothing
    ...

    but prefer the (slightly) terse and (moderately) implicit:

    def myFunc(foo, bar):
    if foo is None:
    foo = calc_foo()
    ...

    Thank goodness we don't have to program in verbose, explicit English!

    In general, most mathematical expressions will involve a small number of
    variables, and what they represent are obvious from context, at least for
    those familiar with the problem domain. Those who aren't familiar with
    the problem domain aren't expected to work on either developing the
    expression in the first place, or maintaining it, in whatever sense
    mathematics is expected to be maintained. Although the problem domain
    naively seems narrow ("huh, who needs to understand complex numbers?") it
    is actually very abstract and hence can in principle be applied to many
    different problems.

    Contrast this with some arbitrary non-mathematical program. It might
    involve many variables rather than a few, and those variables might be
    rich objects with many attributes instead of simple numbers. The problem
    domain is often very concrete: *this* one specific business process,
    meaningful to only this department of that organisation, or at least to
    those just like them. Because concrete is more narrow than abstract, and
    because people who don't understand the problem domain are expected to
    maintain the software, you can't rely on implicit knowledge: you have to
    be explicit, and hence verbose, self-explanatory names are a virtue.


    --
    Steven
    Steven D'Aprano, Dec 4, 2008
    #10
  11. On 04 Dec 2008 22:29:41 GMT Steven D'Aprano
    <> wrote:

    > Thank goodness we don't have to program in verbose, explicit English!

    Then you'll HATE Inform 7:

    http://en.wikipedia.org/wiki/Inform_7#Example_game_2

    :)
    /W

    --
    My real email address is constructed by swapping the domain with the
    recipient (local part).
    Andreas Waldenburger, Dec 5, 2008
    #11
  12. 2008/12/4 Chris Mellon <>:
    > Aside from the cultural indoctrination, though (and that may be a real
    > and strong force when dealing with math software, and I don't want to
    > discount it in general, just for purposes of this discussion) why is
    > it more sensible to use "x" here instead of "number" or "real" or
    > "real_number" or something else?


    Because long variable names in complicated math expressions lead to
    lines longer than 80 characters which hurts readability. You don't
    need to be a mathematician to see that.


    --
    mvh Björn
    BJörn Lindqvist, Dec 9, 2008
    #12
    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. Warren DeLano

    "as" keyword woes

    Warren DeLano, Dec 3, 2008, in forum: Python
    Replies:
    21
    Views:
    624
    Mensanator
    Dec 7, 2008
  2. Warren DeLano

    "as" keyword woes

    Warren DeLano, Dec 4, 2008, in forum: Python
    Replies:
    6
    Views:
    323
    Carl Banks
    Dec 4, 2008
  3. Chris Mellon

    Re: "as" keyword woes

    Chris Mellon, Dec 4, 2008, in forum: Python
    Replies:
    22
    Views:
    578
    Patrick Mullen
    Dec 10, 2008
  4. Warren DeLano

    "as" keyword woes

    Warren DeLano, Dec 4, 2008, in forum: Python
    Replies:
    0
    Views:
    206
    Warren DeLano
    Dec 4, 2008
  5. Warren DeLano

    "as" keyword woes

    Warren DeLano, Dec 4, 2008, in forum: Python
    Replies:
    0
    Views:
    232
    Warren DeLano
    Dec 4, 2008
Loading...

Share This Page