Some more notes

Discussion in 'Python' started by bearophile, Oct 21, 2004.

  1. bearophile

    bearophile Guest

    Ville Vainio:
    >It's highly typical for the newbies to suggest improvements to the
    >language. They will usually learn that they are wrong, but the
    >discussion that ensues can be fruitfull anyway :).


    Few more notes on the language. I don't know if I can really suggest
    improvements to the language... but I hope to learn something :)

    I think some things are better in Delphi/Pascal (like the := for
    assignments instead of = and = for equality, that I suggested in the
    my precedent notes):

    1) The "print" and "printf" pair without automatically added spaces
    between arguments, and with or without automatic newline, instead of
    the current "print" command. Because adding lots of "+str()+" isn't
    good for me (there's sys.stdout.write, but it's not built-in).
    2) Adding "case var of:" can be useful.
    3) "do while" (or "repeat until") can also be added, it's useful.
    4) Maybe really raw strings RR"" can be added to avoid problems with
    file paths on Win :-]

    5) Inside function definitions, assignments of mutable types like this
    can be forbidden and seen as errors by the interpreter:
    def func(a=[1,2]):
    ...

    6) Given:
    a = [1]
    a += [2]
    a = a + [3]
    The first assignment extends the list, and second creates a new list
    and rebinds it. Why such difference for operations that look the same?
    Isn't a kind of "error" to do different things with quite similar
    looking commands?

    7) There's something that I don't understand. I'm not a OOP purist,
    but finding functions like this beside normal methods seems odd to me:
    len(s) length of s
    min(s) smallest item of s
    max(s) largest item of s
    For uniformity they can be:
    s.len()
    s.min()
    s.max()
    etc.

    Thank you,
    bear hugs,
    Bearophile
    bearophile, Oct 21, 2004
    #1
    1. Advertising

  2. bearophile wrote:

    > I don't know if I can really suggest improvements to the language...


    No you can't. Your suggestions are driven by nothing else
    but your desire to make Python resemble Pascal since
    that is the language that you are accustomed to.

    Istvan.
    Istvan Albert, Oct 22, 2004
    #2
    1. Advertising

  3. bearophile

    Cliff Wells Guest

    On Thu, 2004-10-21 at 15:16 -0700, bearophile wrote:

    > I think some things are better in Delphi/Pascal (like the := for
    > assignments instead of = and = for equality, that I suggested in the
    > my precedent notes):


    Actually, since the assignment operator is used far more often than the
    equality operator, making it require three keystroke rather than just
    one is a bad idea.

    > 1) The "print" and "printf" pair without automatically added spaces
    > between arguments, and with or without automatic newline, instead of
    > the current "print" command. Because adding lots of "+str()+" isn't
    > good for me (there's sys.stdout.write, but it's not built-in).


    Use string interpolation. However, I agree having print as a statement
    rather than a function is a (very small) wart. Luckily it's easily
    circumvented (and I've heard rumor that this is, in fact, slated to be
    changed in Python 3000).

    > 2) Adding "case var of:" can be useful.


    Not familiar with this construct. If you mean "switch/case" as in C (or
    some variation of same), then I absolutely agree.

    > 3) "do while" (or "repeat until") can also be added, it's useful.


    Occasionally useful. Not enough to put it high on my list of things I'd
    like to see in Python, but I can see its utility for making *slightly*
    more logical code (versus the "while True: if x: break" idiom).

    > 4) Maybe really raw strings RR"" can be added to avoid problems with
    > file paths on Win :-]


    Not sure what problems you are referring to since I rarely use that
    platform and the times I have used it I haven't had any issues. Do you
    mean issues with "\"? Why not just use "/"?

    > 5) Inside function definitions, assignments of mutable types like this
    > can be forbidden and seen as errors by the interpreter:
    > def func(a=[1,2]):


    I don't see why valid Python syntax should be an error. Admittedly this
    quite often bites new users of Python, but there are plenty of things to
    confuse newbies, so I don't know why this particular construct should be
    singled out, especially when there is a perfectly valid explanation of
    the resulting behavior.

    > 6) Given:
    > a = [1]
    > a += [2]
    > a = a + [3]
    > The first assignment extends the list, and second creates a new list
    > and rebinds it. Why such difference for operations that look the same?
    > Isn't a kind of "error" to do different things with quite similar
    > looking commands?


    I'd agree this can be confusing. However, like the mutable arguments
    you mention previously, there is a logical explanation that suffices in
    place of breaking tons of Python code.

    > 7) There's something that I don't understand. I'm not a OOP purist,
    > but finding functions like this beside normal methods seems odd to me:
    > len(s) length of s
    > min(s) smallest item of s
    > max(s) largest item of s
    > For uniformity they can be:
    > s.len()
    > s.min()
    > s.max()
    > etc.


    I don't have a good answer for this. At least some of this is probably
    pure history (len() worked on both strings and lists, and strings didn't
    used to support methods, so I'm guessing it was a consistency issue back
    then and it's a compatibility issue now, why it wasn't added as a method
    is a good question). As far as min() and max() <shrug>. Perhaps to
    avoid a plethora of methods on such commonly used constructs? At what
    point do you stop adding new methods to classes? Perhaps the decision
    was as simple as that.

    > Thank you,
    > bear hugs,
    > Bearophile


    That disturbs me every time I see it.


    Regards,
    Cliff

    --
    Cliff Wells <>
    Cliff Wells, Oct 22, 2004
    #3
  4. bearophile

    Jeff Shannon Guest

    bearophile wrote:

    >I think some things are better in Delphi/Pascal
    >


    They may well be better _in_ Delphi/Pascal. That doesn't mean that
    adding them into Python will make Python a better language. (I love
    garlic. I love chocolate. I do not want to eat chocolate-covered
    garlic cloves, nor garlic-flavored chocolate bars.)

    >1) The "print" and "printf" pair without automatically added spaces
    >between arguments, and with or without automatic newline, instead of
    >the current "print" command. Because adding lots of "+str()+" isn't
    >good for me (there's sys.stdout.write, but it's not built-in).
    >
    >


    But Python *does* already have string interpolation: print "%s%s%s" %
    ('one', 'two', 'three')

    This is more flexible than printf() would be, because it can be used to
    generate strings even without printing. C had to resort to creating a
    sprintf() function that did printf()-like formatting without actually
    printing; Python made that a built-in operation on strings. I find that
    I use this all the time, and never worry about print statements adding a
    space after a comma because I don't need to use commas.

    >2) Adding "case var of:" can be useful.
    >
    >


    Not sure exactly what this is, but if you're referring to a case/switch
    construct: using a dict of functions is (IMO) a better and cleaner way
    of implementing the same idea.

    >3) "do while" (or "repeat until") can also be added, it's useful.
    >
    >


    Somewhat useful, sure, but it's not hard to achieve the same thing with
    'while 1: if cond: break' . Python's designer made a deliberate
    decision to minimize number of different types of loop structures to
    use, since they tend to be very easy to convert between and fewer types
    means less to learn. So we have two -- one that loops based on the
    status of a condition, and one that iterates over each object in a
    sequence. Minor variations on these themes are (according to Python
    philosophy) better done by explicitly stating the rules, rather than by
    creating new syntax for each variation.

    >4) Maybe really raw strings RR"" can be added to avoid problems with
    >file paths on Win :-]
    >
    >


    Not really, because Python doesn't know what's supposed to be a file
    path and what isn't. Unless, of course, you are explicit about it,
    which means using os.path. In which case, you have already avoided
    those problems using standard strings and don't need to worry about
    whether a string is raw or not, let alone inventing a new "extra-raw"
    string.

    >5) Inside function definitions, assignments of mutable types like this
    >can be forbidden and seen as errors by the interpreter:
    >def func(a=[1,2]):
    >
    >


    Except that having mutable types be shared this way can be a useful
    feature. It's approximately the same thing as (in C/Java) declaring a
    local variable to be static.

    >6) Given:
    >a = [1]
    >a += [2]
    >a = a + [3]
    >The first assignment extends the list, and second creates a new list
    >and rebinds it. Why such difference for operations that look the same?
    >Isn't a kind of "error" to do different things with quite similar
    >looking commands?
    >
    >


    The idea of using += is that it modifies in-place. In-place
    modification isn't meaningful for immutable types, but it can be very
    useful for mutable types. Having a += x mean in-place modification
    while a = a + x creates a new object allows both options to be easily
    accessible without function-call syntax. Having both of them create a
    new object means that one must call a.extend(x) in order to get in-place
    modification. And I'd guess that the vast majority of cases where += is
    used, in-place modification is the preferable behavior anyhow.

    >7) There's something that I don't understand. I'm not a OOP purist,
    >but finding functions like this beside normal methods seems odd to me:
    >len(s) length of s
    >min(s) smallest item of s
    >max(s) largest item of s
    >For uniformity they can be:
    >s.len()
    >s.min()
    >s.max()
    >etc.
    >
    >


    You're apparently more of an OOP purist than Python is... Having these
    as functions instead of methods is much simpler for Python's dynamic
    type system. For example, new sequence types don't need to define min()
    and max() methods -- the existing builtins just work. It also means
    that implementation details of the function can be improved without
    requiring a rewrite of every class that has ever defined a len() method,
    and that Python can split the work of the function between the function
    itself and one or more helper methods that might (or might not) be
    implemented on any given class.

    Remember, there's a lot more to good language design than just "Ooh,
    this piece might be useful!" You also have to consider how all the
    pieces fit together, and how certain constellations of pieces interact
    with other constellations of pieces. Bulldozer blades, furrowers, and
    manure-spreaders are all very useful devices when attached to the right
    vehicle, but you wouldn't want them on your commuter car, right? Much
    better to stick with a small subset of "useful devices" which fit
    together in a consistent and (most importantly) practical way.

    Jeff Shannon
    Technician/Programmer
    Credit International
    Jeff Shannon, Oct 22, 2004
    #4
  5. (bearophile) writes:

    > Ville Vainio:
    >>It's highly typical for the newbies to suggest improvements to the
    >>language. They will usually learn that they are wrong, but the
    >>discussion that ensues can be fruitfull anyway :).

    >
    > Few more notes on the language. I don't know if I can really suggest
    > improvements to the language... but I hope to learn something :)
    >
    > I think some things are better in Delphi/Pascal (like the := for
    > assignments instead of = and = for equality, that I suggested in the
    > my precedent notes):
    >
    > 1) The "print" and "printf" pair without automatically added spaces
    > between arguments, and with or without automatic newline, instead of
    > the current "print" command. Because adding lots of "+str()+" isn't
    > good for me (there's sys.stdout.write, but it's not built-in).


    Use string formatting:
    >>> a = "Hello"
    >>> b = 5
    >>> c = 4.52
    >>> print "%s, %d is greater than %g" % (a, b, c)

    Hello, 5 is greater than 4.52

    Also, adding a , to the end of the print statement will suppress the
    newline (although, not the space between the two calls).

    > 2) Adding "case var of:" can be useful.


    "can be" is the operative phrase here. It's not necessary. Chained
    if/elif/elif works fine for small cases; for larger, you should
    probably use a dict, or rewrite to use a class.

    > 3) "do while" (or "repeat until") can also be added, it's useful.


    Really, while loops and repeat until loops are special cases of the
    much more useful loop-and-a-half:

    while True:
    ... some stuff ...
    if condition_true:
    break
    ... more stuff ...

    The above is a common enough Python idiom (also seen with while 1:,
    which runs slightly faster due to absence of the lookup for True).

    > 4) Maybe really raw strings RR"" can be added to avoid problems with
    > file paths on Win :-]


    I'm confused; how does r"..." not help? The only thing that gets
    interpreted in a raw string is a backslash at the end of a string:
    r"\" is not allowed. (I don't do Windows :)

    > 5) Inside function definitions, assignments of mutable types like this
    > can be forbidden and seen as errors by the interpreter:
    > def func(a=[1,2]):
    > ...


    But then you have to determine what objects are mutable, and sometimes
    this _is_ what you want (using the argument as a cache, or you're sure
    that you don't mutate the argument).

    > 6) Given:
    > a = [1]
    > a += [2]
    > a = a + [3]
    > The first assignment extends the list, and second creates a new list
    > and rebinds it. Why such difference for operations that look the same?
    > Isn't a kind of "error" to do different things with quite similar
    > looking commands?


    To me, a += [2] and a = a + [3] look different. You're applying idioms
    you've learned in other languages (C?) to Python. += _can_ mutate the
    argument, but it doesn't have to: it's very useful when used with
    large mutable objects, such as Numeric arrays.

    > 7) There's something that I don't understand. I'm not a OOP purist,
    > but finding functions like this beside normal methods seems odd to me:
    > len(s) length of s
    > min(s) smallest item of s
    > max(s) largest item of s
    > For uniformity they can be:
    > s.len()
    > s.min()
    > s.max()


    Alex Martelli has answered this throughly in another thread, where the
    context is why have __len__, etc. methods.

    Another argument is that most objects, these methods would be useless:
    what should s.min() be when s is, for instance, a database object?
    Should numbers also have them? These methods only make sense when s is
    some type of sequence (len() also works for a collection like a dict
    or set, also).

    Also, one Python tenet is "practicality beats purity". Making a new
    sequence type is _easy_. Add __getitem__ and __len__ methods, and
    *poof*. I don't have to inherit from a 'sequence' object, or implement
    the methods above: the algorithms in min() and max() work right away.

    --
    |>|\/|<
    /--------------------------------------------------------------------------\
    |David M. Cooke
    |cookedm(at)physics(dot)mcmaster(dot)ca
    David M. Cooke, Oct 22, 2004
    #5
  6. bearophile

    Cliff Wells Guest

    On Thu, 2004-10-21 at 18:07 -0700, Jeff Shannon wrote:
    > bearophile wrote:
    >
    > >I think some things are better in Delphi/Pascal
    > >

    >
    > They may well be better _in_ Delphi/Pascal. That doesn't mean that
    > adding them into Python will make Python a better language. (I love
    > garlic. I love chocolate. I do not want to eat chocolate-covered
    > garlic cloves, nor garlic-flavored chocolate bars.)


    Well, that's a matter of personal taste. Garlic is good on
    *everything*.

    > >2) Adding "case var of:" can be useful.


    > Not sure exactly what this is, but if you're referring to a case/switch
    > construct: using a dict of functions is (IMO) a better and cleaner way
    > of implementing the same idea.


    For many things this is true (and I use function lookup tables
    frequently). However it doesn't as conveniently cover all use cases
    that switch/case does (as it requires a function definition for each
    item). While it's also true that if/elif/else can be used instead for
    these other cases, I personally find switch/case far cleaner looking
    (when there are more than five or six conditions to test).

    Also, I'd be reluctant to claim that the dictionary lookup is cleaner
    (it looks more cluttered to my eye), but rather, more flexible (items
    can be dynamically added to the list).

    Regards,
    Cliff

    --
    Cliff Wells <>
    Cliff Wells, Oct 22, 2004
    #6
  7. On Thu, 2004-10-21 at 18:43 -0700, Cliff Wells wrote:
    > Well, that's a matter of personal taste. Garlic is good on
    > *everything*.


    Mmm... roasted garlic smoothies.



    --
    /***************************************
    * Robby Russell | Owner.Developer.Geek
    * PLANET ARGON | www.planetargon.com
    * Portland, OR |
    * 503.351.4730 | blog.planetargon.com
    * PHP/PostgreSQL Hosting & Development
    ****************************************/


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.6 (GNU/Linux)

    iD8DBQBBeGiS0QaQZBaqXgwRAqTGAKCux0K7b/tkMuLXcfriT7vtFbAwQQCglRJi
    Ni1b5lmCwGnQzhCwfZjuMkk=
    =Gg43
    -----END PGP SIGNATURE-----
    Robby Russell, Oct 22, 2004
    #7
  8. On Thu, 21 Oct 2004 17:59:41 -0700, Cliff Wells wrote:
    >> 7) There's something that I don't understand. I'm not a OOP purist
    >> but finding functions like this beside normal methods seems odd to me:
    >> len(s) length of s
    >> min(s) smallest item of s
    >> max(s) largest item of s
    >> For uniformity they can be:
    >> s.len()
    >> s.min()
    >> s.max()
    >> etc.

    >
    > I don't have a good answer for this.


    See the current thread "Python and generic programming". Those are
    probably best though of as generic algorithms that can work even when
    "max" isn't implemented.

    Python 2.3.4 (#1, Sep 28 2004, 20:15:25)
    [GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> def somenumbers():

    .... yield 1
    .... yield 5
    .... yield 2
    ....
    >>> max(somenumbers())

    5
    >>>



    "max" isn't a method in any sense of the term that I am aware of, so it
    would be wrong to put it there. In some sense, then, this is *more* pure
    OO than, say, Java's "Everything is a method of some object and to hell
    with the consequences!" approach.

    (It seems like the more mature I get as a programmer, the more Java
    disgusts me. I'm beginning to have to stretch for reasons to like it at
    all; one after another they keep falling down for me. But I digress...)
    Jeremy Bowers, Oct 22, 2004
    #8
  9. bearophile

    bearophile Guest

    Istvan Albert:

    >No you can't. Your suggestions are driven by nothing else
    >but your desire to make Python resemble Pascal since
    >that is the language that you are accustomed to.


    You are right, I'm just a newbie in Python, and there are other
    languages than I know a bit better, like Delphi.
    Like natural languages, computer languages have a personal "soul"
    (grammar core, etc), but they also keep copying other languages, to
    improve, etc.
    -----------

    Cliff Wells:

    >Actually, since the assignment operator is used far more often than

    the
    >equality operator, making it require three keystroke rather than just
    >one is a bad idea.


    Right, still, from a mathematical/formal point of view, Pascal syntax
    is better here :-]


    >Use string interpolation.


    Okay, I'll learn to use it more often.


    >>2) Adding "case var of:" can be useful.

    >Not familiar with this construct. If you mean "switch/case" as in C

    (or
    >some variation of same), then I absolutely agree.


    Yes, it's the Delphi/Pascal version of it.


    >Occasionally useful. Not enough to put it high on my list of things

    I'd
    >like to see in Python, but I can see its utility for making

    *slightly*
    >more logical code (versus the "while True: if x: break" idiom).


    I agree, it's not essential, but it can be useful :)


    >Why not just use "/"?


    Okay, I'll use os.path.normcase to convert them.


    >but there are plenty of things to confuse newbies,


    Reducing non-obvious, magic or not-standard behaviours is quite
    necessary inside a language, it helps non-newbies too, making the
    language more conceptually transparent. Sometimes such non-standard
    behaviours can be useful to improve language speed or other things,
    but they have to reduced to the minimum possible. Python often prefers
    transparency, even when there are many (worse and more opaque, but
    maybe faster) ways to do things. This is positive for a hi-level
    language. So making a hi-level language like Python more transparent
    can be a way to improve it :)
    Mathematica is more transparent than Python (its hashes can process
    everything, it has just a mutable list type and not tuples, assignment
    copies the object, and it's more functional so there are much less
    problems with globals and side effects, etc. but it can still be used
    with imperaive programming) and often it's also faster, but it's far
    from free (and its can be worse to do "real" programming, etc) :-]
    Note: Mathematica can be used with a quite powerful "pattern matching
    programming", I don't know if such thing (or a subset of it) can be
    useful to add to Python.


    >there is a logical explanation that suffices in
    >place of breaking tons of Python code.


    There are logical explanations for everything (because everything must
    be executed by the processor), but for humans some things are more
    logical than others :)
    Python 3.0 already breaks lots of things, even division operators, so
    that's the best occasion to improve/change/fix things.
    -----------

    Jeff Shannon:

    >using a dict of functions is (IMO) a better and cleaner
    >way of implementing the same idea.


    I don't know... The Case syntax can be something like:

    Case <name>:
    1: DoSomething1
    range(2,23): DoSomething2
    else: DoSomething3

    (Etc. There are many other possibilities, like the Switch, etc).


    >it's not hard to achieve the same thing with
    >'while 1: if cond: break' . Python's designer made a deliberate
    >decision to minimize number of different types of loop structures to
    >use, since they tend to be very easy to convert between and fewer

    types
    >means less to learn. So we have two -- one that loops based on the
    >status of a condition, and one that iterates over each object in a
    >sequence. Minor variations on these themes are (according to Python
    >philosophy) better done by explicitly stating the rules, rather than

    by
    >creating new syntax for each variation.


    Okay... I'll use the 'while 1: if cond: break'


    >Except that having mutable types be shared this way can be a useful

    feature.<

    It looks more dangerous than useful. And assignments of non-mutable
    types can still be accepted.


    >Having a += x mean in-place modification
    >while a = a + x creates a new object allows both options to be
    >easily accessible without function-call syntax.


    Okay, the manual I've read wasn't clear enough about this :)


    >Having these
    >as functions instead of methods is much simpler for Python's dynamic
    >type system. For example,
    >new sequence types don't need to define min()
    >and max() methods -- the existing builtins just work. It also means
    >that implementation details of the function can be improved without
    >requiring a rewrite of every class that has ever defined a len()

    method,

    Okay. Thank you for the info. I still prefer Python to Ruby (a more
    pure OO language, I think).


    >Remember, there's a lot more to good language design than just "Ooh,
    >this piece might be useful!" You also have to consider how all the
    >pieces fit together,


    I agree, sometimes adding things is positive, and sometimes it's not
    good.
    Things have to be discussed by people expert on the language (and I'm
    a newbie), but I am here to learn too :)
    ("pattern matching programming" can be one of such things.)
    -----------

    Cliff Wells:

    >While it's also true that if/elif/else can be used instead for
    >these other cases, I personally find switch/case far cleaner looking
    >(when there are more than five or six conditions to test).
    >[...]
    >Also, I'd be reluctant to claim that the dictionary lookup is cleaner
    >(it looks more cluttered to my eye), but rather, more flexible (items
    >can be dynamically added to the list).


    I agree.
    -----------

    David M. Cooke:

    >Also, adding a , to the end of the print statement will suppress the
    >newline (although, not the space between the two calls).


    Right, I've forgot it :)


    >"can be" is the operative phrase here. It's not necessary.<


    Well, OOP and lots of other things (inside Python too) aren't
    necessary. I was discussing mostly about things that can be useful.


    >Chained if/elif/elif works fine for small cases; for larger,
    >you should probably use a dict, or rewrite to use a class.


    Uhm... I'll try with the dictionary.


    >Really, while loops and repeat until loops are special cases of the
    >much more useful loop-and-a-half:
    >while True:
    > ... some stuff ...
    > if condition_true:
    > break
    > ... more stuff ...


    I'll use it, but I think it's really ugly. It looks like the old
    spaghetti code with GOTOs :-]

    Thank you for the answers and explanations,
    a handshake to Cliff and bear hugs to everybody else,
    bearophile
    (remove HUGS if you want to mail me directly)
    bearophile, Oct 23, 2004
    #9
  10. bearophile

    Peter Hansen Guest

    bearophile wrote:
    > Cliff Wells:
    >>Why not just use "/"?

    >
    > Okay, I'll use os.path.normcase to convert them.


    That's not necessary in almost all cases. Windows happily(*)
    accepts forward slashes in all system calls. The only place
    it does not is in the *shell* (aka command.com and cmd.exe).
    That means paths passed as arguments to os.system or the
    Popen gang need to be normcased, but for things like open()
    you don't need to bother.

    -Peter

    (*) There are theories that although Windows does accept
    forward slashes, it does so only grudgingly.
    Peter Hansen, Oct 23, 2004
    #10
  11. bearophile

    Steve Holden Guest

    Peter Hansen wrote:

    > bearophile wrote:
    >
    >> Cliff Wells:
    >>
    >>> Why not just use "/"?

    >>
    >>
    >> Okay, I'll use os.path.normcase to convert them.

    >
    >
    > That's not necessary in almost all cases. Windows happily(*)
    > accepts forward slashes in all system calls. The only place
    > it does not is in the *shell* (aka command.com and cmd.exe).
    > That means paths passed as arguments to os.system or the
    > Popen gang need to be normcased, but for things like open()
    > you don't need to bother.
    >

    Having said which it's still good practice to use os.path functions to
    manipulate paths for forward compatibility with Windows 2007, which will
    change the separator to "^" :)

    regards
    Steve
    --
    http://www.holdenweb.com
    http://pydish.holdenweb.com
    Holden Web LLC +1 800 494 3119
    Steve Holden, Oct 23, 2004
    #11
  12. (bearophile) wrote:
    > Cliff Wells:
    >
    > >Actually, since the assignment operator is used far more often than

    > the
    > >equality operator, making it require three keystroke rather than just
    > >one is a bad idea.

    >
    > Right, still, from a mathematical/formal point of view, Pascal syntax
    > is better here :-]


    Based on Python's use of '=' rather than ':=', I believe Guido has
    already made his decision, and there has been no discussion on changing
    the behavior for Python 3.0, so argument over it is a moot point.


    > >Occasionally useful. Not enough to put it high on my list of things

    > I'd
    > >like to see in Python, but I can see its utility for making

    > *slightly*
    > >more logical code (versus the "while True: if x: break" idiom).

    >
    > I agree, it's not essential, but it can be useful :)


    As it stands, there has been more than one attempt to get case
    statements into the Python language. All have been mostly fruitless
    thusfar. There is a PEP: http://python.org/peps/pep-0275.html , but it
    is certainly not going to make it into Python 2.4, and there has been
    little discussion about its inclusion in any later versions on
    python-dev.

    In my opinion, the syntax-less case statement described in the PEP is
    pure. That is, no new syntax is needed, but if your if/elif/else
    statements are of a certain format, you gain the speed of dictionary
    dispatch. I believe that any case-statement-like behavior in Python
    will likely be of this sort.


    > >Why not just use "/"?

    >
    > Okay, I'll use os.path.normcase to convert them.


    Not necessary. You can mix '/' and '\\' freely on Windows when opening
    files.


    > >but there are plenty of things to confuse newbies,

    >
    > Reducing non-obvious, magic or not-standard behaviours is quite
    > necessary inside a language, it helps non-newbies too, making the
    > language more conceptually transparent. Sometimes such non-standard
    > behaviours can be useful to improve language speed or other things,
    > but they have to reduced to the minimum possible. Python often prefers
    > transparency, even when there are many (worse and more opaque, but
    > maybe faster) ways to do things. This is positive for a hi-level
    > language. So making a hi-level language like Python more transparent
    > can be a way to improve it :)


    What you just said was that Python is transparent, but making it more
    transparent is better. What would be more transparent? Understand that
    Python is not likely to do anything that would make it more difficult to
    learn or use, just for the sake of speed.


    > Mathematica is more transparent than Python (its hashes can process
    > everything, it has just a mutable list type and not tuples, assignment
    > copies the object, and it's more functional so there are much less
    > problems with globals and side effects, etc. but it can still be used
    > with imperaive programming) and often it's also faster, but it's far
    > from free (and its can be worse to do "real" programming, etc) :-]


    It would seem that copy-on-write for lists was a work-around for being
    able to hash sequences, a result of only having mutable lists (no
    immutable lists/tuples).

    I don't remember copy-on-write with Mathematica, though it has been a
    few years, I could have sworn that either append or prepend was fast
    (which necessitates non-copy-on-write semantics).


    "problems with globals and side effects"
    The only problem is education. Once one becomes educated about the
    side-effects of append/extend/etc., one rarely has problems of this kind,
    as one either uses them to their advantage, or programs around what they
    conceive to be a limitation. Feel free to program around them; I'm going
    to stick with using mutables wherever I see fit. Please stop advocating
    the removal of useful features.

    "often it's also faster"
    Honestly, I (and likely many others) don't care that Mathematica can be
    faster. C can be faster, Java can be faster, Perl can be faster. We
    use Python for varying reasons and for varying purposes.

    In my case, the only thing I find Mathematica useful for is helping with
    certain difficult bits of math that I have forgotten over the years.
    For general programming, there are other better languages (in my opinion,
    which I imagine is shared), nearly all of which are free.


    > Note: Mathematica can be used with a quite powerful "pattern matching
    > programming", I don't know if such thing (or a subset of it) can be
    > useful to add to Python.


    If you mean things like (I can't remember the exact syntax, perhaps this
    is it)...

    fib[a_] := If[a<3, Return[1], b=fib[a-1]+fib[a-2];fib[a]=b;Return]

    That does what is called memoization in computer science. Python can do
    that, but you need to do so explicitly:

    def fib(a, cache={}):
    if a < 3:
    return 1
    if a not in cache:
    cache[a] = fib(a-1)+fib(a-2)
    return cache[a]


    Ahh, dictionaries save the day. With a 'memoization decorator', it gets
    easier in the general case

    def memoize_single_arg(f)
    cache = {}
    def memoizer(arg):
    if arg in cache:
    return cache[arg]
    return f(arg)
    return memoizer

    @memoize_single_arg
    def fib_r(a):
    if a < 3:
    return 1
    return fib_r(a-1)+fib(a-2)


    If you are talking about something else, perhaps you should describe it.

    > >there is a logical explanation that suffices in
    > >place of breaking tons of Python code.

    >
    > There are logical explanations for everything (because everything must
    > be executed by the processor), but for humans some things are more
    > logical than others :)
    > Python 3.0 already breaks lots of things, even division operators, so
    > that's the best occasion to improve/change/fix things.


    Funny, I found no mention of division operator breaking on the Python
    3.0 wiki: http://www.python.org/cgi-bin/moinmoin/PythonThreeDotOh

    Python 3.0 doesn't even exist yet, and likely won't for at least 6 years.
    Virtually none of the suggestions you have offered thus far are even
    remotely what Guido and others on python-dev have been talking about
    changing for Python 3.0



    > Jeff Shannon:
    >
    > >using a dict of functions is (IMO) a better and cleaner
    > >way of implementing the same idea.

    >
    > I don't know... The Case syntax can be something like:
    >
    > Case <name>:
    > 1: DoSomething1
    > range(2,23): DoSomething2
    > else: DoSomething3


    That is the worst syntax for case statements I have ever seen.


    > >Except that having mutable types be shared this way can be a useful

    > feature.<
    >
    > It looks more dangerous than useful. And assignments of non-mutable
    > types can still be accepted.


    Understand that 'obj.attr = val' implies that obj is mutable. Do you
    also want to remove object oriented programming in Python? Likely not,
    but understand the implications for what you say.

    Mutables aren't going away in Python. Stop complaining about them.


    > >Having a += x mean in-place modification
    > >while a = a + x creates a new object allows both options to be
    > >easily accessible without function-call syntax.

    >
    > Okay, the manual I've read wasn't clear enough about this :)


    It is in the language reference:
    http://docs.python.org/ref/augassign.html

    "An augmented assignment expression like x += 1 can be rewritten as x =
    x + 1 to achieve a similar, but not exactly equal effect. In the
    augmented version, x is only evaluated once. Also, when possible, the
    actual operation is performed in-place, meaning that rather than
    creating a new object and assigning that to the target, the old object
    is modified instead."


    - Josiah
    Josiah Carlson, Oct 23, 2004
    #12
  13. bearophile

    David Bolen Guest

    Peter Hansen <> writes:

    > That's not necessary in almost all cases. Windows happily(*)
    > accepts forward slashes in all system calls. The only place
    > it does not is in the *shell* (aka command.com and cmd.exe). (...)


    Actually, almost all system calls. I don't have the precise list
    handy, but there are some related to networking that use UNC names
    that expect to see a machine name supplied as a string as "\\machine"
    and will not accept "//machine".

    -- David
    David Bolen, Oct 23, 2004
    #13
  14. bearophile

    Peter Hansen Guest

    David Bolen wrote:
    > Peter Hansen <> writes:
    >
    >>That's not necessary in almost all cases. Windows happily(*)
    >>accepts forward slashes in all system calls. The only place
    >>it does not is in the *shell* (aka command.com and cmd.exe). (...)

    >
    > Actually, almost all system calls. I don't have the precise list
    > handy, but there are some related to networking that use UNC names
    > that expect to see a machine name supplied as a string as "\\machine"
    > and will not accept "//machine".


    Have you verified that those calls would *not* accept
    something like "\\machine/share/path/file"?

    If they accept this, then I would simply argue that the \\machine
    part has nothing to do with a path, other than the accident
    of sharing (but doubling) the backslash that we're used to
    in Windows paths. It's a machine name, not a path, similar to
    how C: is a drive name, not a path, and therefore needs special
    handling.

    After all, you don't expect to be able to use C/ instead of C:,
    and I don't think one should necessarily expect //machine to
    work instead of \\machine.

    This is mostly supposition/theory/wild hand-waving, however.
    I don't know the reality. If you post a few of the APIs that
    you mention, I can try to disprove my theory.

    -Peter
    Peter Hansen, Oct 24, 2004
    #14
  15. bearophile

    Jorgen Grahn Guest

    On Sat, 23 Oct 2004 10:01:00 -0400, Peter Hansen <> wrote:
    > bearophile wrote:
    >> Cliff Wells:
    >>>Why not just use "/"?

    >>
    >> Okay, I'll use os.path.normcase to convert them.

    >
    > That's not necessary in almost all cases. Windows happily(*)
    > accepts forward slashes in all system calls. The only place
    > it does not is in the *shell* (aka command.com and cmd.exe).

    ....
    > (*) There are theories that although Windows does accept
    > forward slashes, it does so only grudgingly.


    IIRC, forward slashes have been acceptable since way back in early MS-DOS --
    although someone somewhere on Usenet suggested that Microsoft have never
    commited to keeping it that way.

    Personally, I tend to use them -- but I accept full responsibility when/if
    it breaks.

    /Jorgen

    --
    // Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ algonet.se> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, Oct 24, 2004
    #15
  16. bearophile

    Peter Hansen Guest

    Jorgen Grahn wrote:
    > On Sat, 23 Oct 2004 10:01:00 -0400, Peter Hansen <> wrote:
    >>That's not necessary in almost all cases. Windows happily(*)
    >>accepts forward slashes in all system calls. The only place
    >>it does not is in the *shell* (aka command.com and cmd.exe).

    >
    > IIRC, forward slashes have been acceptable since way back in early MS-DOS --
    > although someone somewhere on Usenet suggested that Microsoft have never
    > commited to keeping it that way.


    I know that there was an un(der)documented control somewhere that
    allowed one to change even DOS to accept hyphens in place of
    forward slashes as the "switch" indicator for command line options,
    but this is the first time I've heard it suggested that even
    the DOS "APIs" (I use the term loosely... the interrupt routines
    barely qualify for that title :) ) would allow forward slashes
    as the Windows APIs (always?) have.

    Does anyone have a reference for that?

    -Peter
    Peter Hansen, Oct 24, 2004
    #16
  17. On Sun, 24 Oct 2004 18:58:06 -0400, Peter Hansen <> wrote:

    > but this is the first time I've heard it suggested that even
    > the DOS "APIs" (I use the term loosely... the interrupt routines
    > barely qualify for that title :) ) would allow forward slashes
    > as the Windows APIs (always?) have.
    >
    > Does anyone have a reference for that?


    Googling coincidentally brings up a c.l.py/python-list reference on
    the first page, so that thread might be a good starting point:

    http://mail.python.org/pipermail/python-list/2003-September/185211.html
    Andrew Durdin, Oct 25, 2004
    #17
  18. bearophile

    Jorgen Grahn Guest

    On Sun, 24 Oct 2004 18:58:06 -0400, Peter Hansen <> wrote:
    > Jorgen Grahn wrote:
    >> On Sat, 23 Oct 2004 10:01:00 -0400, Peter Hansen <> wrote:
    >>>That's not necessary in almost all cases. Windows happily(*)
    >>>accepts forward slashes in all system calls. The only place
    >>>it does not is in the *shell* (aka command.com and cmd.exe).

    >>
    >> IIRC, forward slashes have been acceptable since way back in early MS-DOS --
    >> although someone somewhere on Usenet suggested that Microsoft have never
    >> commited to keeping it that way.

    >
    > I know that there was an un(der)documented control somewhere that
    > allowed one to change even DOS to accept hyphens in place of
    > forward slashes as the "switch" indicator for command line options,
    > but this is the first time I've heard it suggested that even
    > the DOS "APIs" (I use the term loosely... the interrupt routines
    > barely qualify for that title :) ) would allow forward slashes
    > as the Windows APIs (always?) have.
    >
    > Does anyone have a reference for that?


    [ greps his ~/News/* ]

    Newsgroups: comp.lang.c++.moderated
    Message-ID: <>

    MS-DOS operating system requests (e.g. open), and those of Windows, have
    always, from the very first, accepted either '\' or '/' as a directory
    separator, and still do today. There is really not the slightest need to
    use '\' for this in a string constant.

    .... followed by a lot of other interesting stuff.

    /Jorgen

    --
    // Jorgen Grahn <jgrahn@ Ph'nglui mglw'nafh Cthulhu
    \X/ algonet.se> R'lyeh wgah'nagl fhtagn!
    Jorgen Grahn, Oct 25, 2004
    #18
  19. bearophile

    Peter Hansen Guest

    Andrew Durdin wrote:
    > On Sun, 24 Oct 2004 18:58:06 -0400, Peter Hansen <> wrote:
    >>[about even DOS system calls accepting forward slash]
    >>Does anyone have a reference for that?

    >
    > Googling coincidentally brings up a c.l.py/python-list reference on
    > the first page, so that thread might be a good starting point:
    >
    > http://mail.python.org/pipermail/python-list/2003-September/185211.html


    Thanks! I even participated in that thread, so I must have read it
    at the time. Shows how great my memory is. :-(

    The summary is that ever since DOS added subdirectories (in DOS 2.0)
    it has allowed either slash in the system calls. Still, this was
    problematic at the command line because the default "switch" character
    was "/" and not "-", and because some programs hardcoded support for
    only the backslash form.

    Peter
    Peter Hansen, Oct 25, 2004
    #19
  20. bearophile

    David Bolen Guest

    Peter Hansen <> writes:

    > Have you verified that those calls would *not* accept
    > something like "\\machine/share/path/file"?


    Nope. Actually, I don't think that was even applicable since the call
    I'm recalling took a UNC machine name but not a full path, so the only
    thing in the parameter was the machine portion. Although maybe it did
    include the share level.

    > If they accept this, then I would simply argue that the \\machine
    > part has nothing to do with a path, other than the accident
    > of sharing (but doubling) the backslash that we're used to
    > in Windows paths. It's a machine name, not a path, similar to
    > how C: is a drive name, not a path, and therefore needs special
    > handling.


    I suppose, but I certainly saw UNC as a logical extension of path
    semantics to cross the network boundary (and imagine that the choice
    of \\ was logically consistent with that approach). It was a way to
    layer a level "above the root" of the filesystem into a path naming
    convention.

    > After all, you don't expect to be able to use C/ instead of C:,
    > and I don't think one should necessarily expect //machine to
    > work instead of \\machine.


    Well, we clearly expect different things, which is fine, and shows the
    variety in the universe :)

    At least for me, knowing that the API permitted me to use
    "/path/to/file.ext" instead of "\path\to\file.ext" made it seem
    logical it would permit "//machine/share/path/file.ext" for
    "\\machine\share\path\file.ext". Or at least desirable.

    > This is mostly supposition/theory/wild hand-waving, however.
    > I don't know the reality. If you post a few of the APIs that
    > you mention, I can try to disprove my theory.


    I'll see if I can find at least one again and forward it over. I seem
    to recall it was while using some of the win32net wrapped APIs to
    interrogate things on a remote server.

    But I'm also willing to just agree that it only impacts the machine
    spec and that you could consider that distinct from any path
    operation. I was really just qualifying the general comment about
    Win32 accepting forward slashes in all system calls.

    -- David
    David Bolen, Oct 25, 2004
    #20
    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. Bjorn Jensen
    Replies:
    0
    Views:
    1,171
    Bjorn Jensen
    Mar 22, 2005
  2. bearophile

    Some notes

    bearophile, Oct 12, 2004, in forum: Python
    Replies:
    19
    Views:
    639
    Bengt Richter
    Oct 17, 2004
  3. SteveM
    Replies:
    5
    Views:
    1,550
    Mark Rae [MVP]
    Aug 28, 2007
  4. John Nagle
    Replies:
    9
    Views:
    1,534
    Paul Boddie
    Jan 19, 2008
  5. John Nagle
    Replies:
    4
    Views:
    297
    John Nagle
    Mar 27, 2008
Loading...

Share This Page