Re: buggy python interpretter or am I missing something here?

Discussion in 'Python' started by Ethan Furman, Jan 27, 2014.

  1. Ethan Furman

    Ethan Furman Guest

    On 01/26/2014 10:46 PM, me wrote:
    >
    > [...] I'm satisfied that the except: syntax yields
    > undefined behavior, and in my mind it shouldn't be
    > syntactically allowed then.


    Two points:

    1) Python is not C++

    2) You asked for help; you received it. Coming back
    with an attitude of "Python must be broken, I'll
    work around it" is going to quickly lose you the
    support of those willing to help again.
     
    Ethan Furman, Jan 27, 2014
    #1
    1. Advertising

  2. On Mon, Jan 27, 2014 at 6:44 PM, me <> wrote:
    > On Sun, 26 Jan 2014 23:17:29 -0800, Ethan Furman wrote:
    >
    >> On 01/26/2014 10:46 PM, me wrote:
    >>>
    >>> [...] I'm satisfied that the except: syntax yields undefined behavior,
    >>> and in my mind it shouldn't be
    >>> syntactically allowed then.

    >>
    >> Two points:
    >>
    >> 1) Python is not C++
    >>
    >> 2) You asked for help; you received it. Coming back
    >> with an attitude of "Python must be broken, I'll work around it"
    >> is going to quickly lose you the support of those willing to help
    >> again.

    >
    >
    > Whatever...lighten up dude!


    When you use a language, you should be working with it, not fighting
    against it. It doesn't do to complain that REXX ought to have IEEE
    floating-point semantics, or that 8086 assembly language really would
    benefit from a native hashtable type. Python works a certain way, and
    part of that is its use of exceptions - which are integral to the
    language, rather than being (as in C++) somewhat tacked-on. Assuming
    that anything that isn't the way you expect it is inherently broken,
    and saying so on a mailing list, is a good way to alienate those who
    are offering you help for no reimbursement... and "lighten up dude"
    doesn't help.

    ChrisA
     
    Chris Angelico, Jan 27, 2014
    #2
    1. Advertising

  3. Ethan Furman

    Neil Cerutti Guest

    On 2014-01-27, me <> wrote:
    > The thread is done so lets give it a rest. The condescending
    > attitude about proper USENET tech help is just as annoying as
    > perhaps my "opinions" seem. If someone is so sensitive as to
    > not be able to discuss a technical matter without making it
    > personal or seeing it as an attack against their religion then
    > I neither want nor need their input. There are plenty of
    > technical resources in the world that don't require idol
    > worship.


    Oh, it's all right. I'm sure that we can handle this situation
    maturely, just like the responsible adults that we are. Isn't
    that right, Mr... Poopy-Pants?

    --
    Neil Cerutti
     
    Neil Cerutti, Jan 27, 2014
    #3
  4. On Mon, 27 Jan 2014 09:32:43 +0000, some guy who calls himself "me" wrote:

    > On Mon, 27 Jan 2014 20:01:33 +1100, Chris Angelico wrote:
    >
    >> On Mon, Jan 27, 2014 at 6:44 PM, me <> wrote:
    >>> On Sun, 26 Jan 2014 23:17:29 -0800, Ethan Furman wrote:
    >>>
    >>>> On 01/26/2014 10:46 PM, me wrote:
    >>>>>
    >>>>> [...] I'm satisfied that the except: syntax yields undefined
    >>>>> behavior,
    >>>>> and in my mind it shouldn't be
    >>>>> syntactically allowed then.
    >>>>
    >>>> Two points:
    >>>>
    >>>> 1) Python is not C++
    >>>>
    >>>> 2) You asked for help; you received it. Coming back
    >>>> with an attitude of "Python must be broken, I'll work around
    >>>> it" is going to quickly lose you the support of those willing
    >>>> to help again.
    >>>
    >>>
    >>> Whatever...lighten up dude!

    >>
    >> When you use a language, you should be working with it, not fighting
    >> against it. It doesn't do to complain that REXX ought to have IEEE
    >> floating-point semantics, or that 8086 assembly language really would
    >> benefit from a native hashtable type. Python works a certain way, and
    >> part of that is its use of exceptions - which are integral to the
    >> language, rather than being (as in C++) somewhat tacked-on. Assuming
    >> that anything that isn't the way you expect it is inherently broken,
    >> and saying so on a mailing list, is a good way to alienate those who
    >> are offering you help for no reimbursement... and "lighten up dude"
    >> doesn't help.
    >>
    >> ChrisA

    >
    > You feel better now that you too have vented? I had a productive
    > discussion with a couple of top level posters who helped me solve my
    > problem and they receive appropriate kuddos. Now it seems that some
    > lonely individuals who maybe just want some attention are coming out of
    > the woodwork.


    A word to the wise: Chris is one of the most frequent and helpful posters
    here. So is Ethan. Both of them know what they're talking about, so when
    they give you advice, you could do a lot worse than to listen.

    Some examples of "a lot worse": you could arrogantly dismiss them by
    saying "whatever". Or you could make assumptions about their personal
    lives ("lonely individuals").

    [Aside: you seem to be making a habit of jumping to wrong conclusions
    based on incorrect and illogical interpretations of minimal evidence.
    That's a poor habit to get into, and especially poor for a programmer.]


    > The thread is done so lets give it a rest. The condescending attitude
    > about proper USENET tech help is just as annoying as perhaps my
    > "opinions" seem. If someone is so sensitive as to not be able to
    > discuss a technical matter without making it personal or seeing it as an
    > attack against their religion then I neither want nor need their input.
    > There are plenty of technical resources in the world that don't require
    > idol worship.


    What does idol worship have to do with anything? Oh wait, do you think
    Ethan and Chris are pissed off because you're not genuflecting at
    Python's awesomeness? That's another comically wrong conclusion.


    --
    Steven
     
    Steven D'Aprano, Jan 27, 2014
    #4
  5. Ethan Furman

    Rick Johnson Guest

    On Monday, January 27, 2014 3:32:43 AM UTC-6, me wrote:
    > On Mon, 27 Jan 2014 20:01:33 +1100, Chris Angelico wrote:
    >
    > [snip chris reply]
    >
    > You feel better now that you too have vented? I had a
    > productive discussion with a couple of top level posters
    > who helped me solve my problem and they receive
    > appropriate kuddos. Now it seems that some lonely
    > individuals who maybe just want some attention are coming
    > out of the woodwork.


    You can kindly ignore Chris, he is just one of our well
    known *resident* "lonely individuals", seeking attention yet
    again! And his constant blabbing about and idol worship of REXX is
    more annoying than all of xah lee post combined, however, i
    do just enjoy watching him "casually" weaving in those
    examples as though he does not have an agenda to push.

    @Chris: Two can play at this game!
     
    Rick Johnson, Jan 27, 2014
    #5
  6. On Tue, Jan 28, 2014 at 2:33 AM, Rick Johnson
    <> wrote:
    > You can kindly ignore Chris, he is just one of our well
    > known *resident* "lonely individuals", seeking attention yet
    > again! And his constant blabbing about and idol worship of REXX is
    > more annoying than all of xah lee post combined, however, i
    > do just enjoy watching him "casually" weaving in those
    > examples as though he does not have an agenda to push.
    >
    > @Chris: Two can play at this game!


    Heh. If you'd said Pike instead of REXX, I might have believed you :)
    I've said more about Pike than is perhaps appropriate, but of late,
    I've actually not been the one to most often quote REXX code.
    Actually, REXX as a language has been majorly left behind. Back in the
    early 1990s it was blessed with support for non-English text in the
    form of DBCS (at least, the OS/2 REXX implementation was - don't know
    how standard that was), but then nobody ever went in and made it all
    Unicode instead, so now we have a bytes-only language. Has its
    coolnesses, but far too much of it is done with language magic (eg the
    PARSE statement - there's no way to interact with that, no way to make
    anything dynamic, so even though it is, in many ways, much cleaner
    than C's sscanf or Perl's regular expressions, it's just plain
    impossible to extend). Still, it was my first taste of
    arbitrary-precision arithmetic, and for that (and plenty more) I am
    well appreciative.

    Frankly, I don't "idol worship" *any* language. There is not a single
    language that I've ever used which has no flaws. And I can't think of
    any language with which I have no fundamental disagreements on major
    design points. (Note that there's a difference between those two.
    Flaws are objective (and I'm not talking about bugs, I'm talking about
    stuff where the author agrees that it's wrong but it's too late to
    change now), design disagreements are personal. For instance, I
    personally believe that disallowing assignment-as-expression cuts out
    more value than it gains by preventing bugs (as we've seen lately,
    people can just get it wrong the other way, comparing as a statement),
    but I respect Guido's decision on that and don't see it as a problem
    to be fought. A lot of Python's worst flaws were fixed in 3.x (input()
    -> eval(), print as a statement, etc), but there are still a few
    oddities that can't easily be fixed. They don't stop the language from
    being useful and awesome.

    ChrisA
     
    Chris Angelico, Jan 27, 2014
    #6
  7. On 27/01/2014 15:53, Chris Angelico wrote:
    > Frankly, I don't "idol worship" *any* language.


    I worship English because it's so easy to learn. Ducks and runs :)

    --
    My fellow Pythonistas, ask not what our language can do for you, ask
    what you can do for our language.

    Mark Lawrence
     
    Mark Lawrence, Jan 27, 2014
    #7
  8. On 01/27/2014 02:32 AM, me wrote:
    > You feel better now that you too have vented?


    Sorry but the emotional intent you're reading in to Chris's post is
    completely misplaced. I don't know why you chose to be offended by it.
    Chris's comments about C++ are accurate, but not intended to be a
    personal affront to you. They are just statements of fact.
     
    Michael Torrie, Jan 27, 2014
    #8
  9. Ethan Furman

    Rick Johnson Guest

    On Monday, January 27, 2014 9:53:37 AM UTC-6, Chris Angelico wrote:
    > Heh. If you'd said Pike instead of REXX, I might have
    > believed you :) I've said more about Pike than is perhaps
    > appropriate, but of late, I've actually not been the one
    > to most often quote REXX code.


    Yes in my haste to inject a jab at you i pulled the
    trigger before fully retracting the gun from my holster...
    OUCH!

    It was indeed "Pike" that i meant. But, although you
    *do* mention it quite a lot, i don't think mentioning any
    language should be off topic because heck, someone could
    learn something new.

    > [snip]
    > For instance, I personally believe that disallowing
    > assignment-as-expression cuts out more value than it gains
    > by preventing bugs (as we've seen lately, people can just
    > get it wrong the other way, comparing as a statement),


    I myself wish for such a Python feature -- but alas, we are but
    slaves to whims of the dutch!

    > but I respect Guido's decision on that and don't see it as
    > a problem to be fought. A lot of Python's worst flaws were
    > fixed in 3.x (input() -> eval(), print as a statement,
    > etc),


    I agree that those are flaws, but not enough of a flaw to
    break code. "input" is only used by neophytes, so who cares
    about breaking that one, but "print" is almost everywhere!

    But let's go back to "input" for a bit...

    Why do we even need an "input" function anyway if all
    it is going to do is read from stdin? Would not $stdin.read
    have been better choice? Or simply "read" if you're a global
    namespace pollution fanboy!

    Heck, if you're going to have a function for writing
    strings to $stdout, and also, you're going to have a
    function for reading strings from $stdin, then you need to
    recognize the diametric relation between these functions,
    and as such, your first design consideration should be to
    maintain a consistency between them

    input (reads a string from stdin)
    print (writes a string to stdout)

    It is my strong believe that defining an "input" method that
    "magically" evals the input string is just plain evil. Why
    you ask? Because doing so injects superfluous magic whist
    simultaneously blinding the noob to the fact that strings
    are the mutually inclusive love interest of both "Mrs.Input"
    and "Mr.Output".
     
    Rick Johnson, Jan 27, 2014
    #9
  10. On Tue, Jan 28, 2014 at 7:22 AM, Rick Johnson
    <> wrote:
    > maintain a consistency between them
    >
    > input (reads a string from stdin)
    > print (writes a string to stdout)
    >
    > It is my strong believe that defining an "input" method that
    > "magically" evals the input string is just plain evil.


    Fortunately, as of Python 3, that parallel is maintained.

    ChrisA
     
    Chris Angelico, Jan 27, 2014
    #10
  11. On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:

    > "input" is only used by neophytes, so who cares about breaking that one,
    > but "print" is almost everywhere!


    Heh heh heh, how very "Ranting Rick" to think that a function for
    listening to input is unimportant, while a function for spraying output
    all over the place is vital.


    > But let's go back to "input" for a bit...
    >
    > Why do we even need an "input" function anyway if all it is going to do
    > is read from stdin?


    That's not all it does.

    For example, it handles backspacing, so that typing H E L O O BACKSPACE
    BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".

    Of course, somebody as awesome as Rick will have never made a mistake in
    his life, but for the rest of us mere mortals, that feature alone makes a
    dedicated input function worthwhile. But there's more!

    On systems with readline, not only does input handle backspacing, but it
    handles all sorts of editing functionality, such as arrow keys and
    various editing commands. So typing A LEFT-ARROW B gives "BA" rather than
    "A\x1b[DB". input also provides visual feedback while you type, an
    optional prompt, handling of newlines, buffering, and possibly more.


    --
    Steven
     
    Steven D'Aprano, Jan 27, 2014
    #11
  12. Steven D'Aprano wrote:
    > On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
    >
    >>Why do we even need an "input" function anyway if all it is going to do
    >>is read from stdin?

    >
    > That's not all it does.
    >
    > For example, it handles backspacing, so that typing H E L O O BACKSPACE
    > BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".


    No, it doesn't -- that's handled at a lower level.
    Any other method of reading from stdin, as long
    as it hasn't been redirected away from the console,
    has the same behaviour.

    I typed some backspaces in the input to each of the
    following experiments, and they didn't end up in the
    data:

    >>> import sys
    >>> x = sys.stdin.readline()

    HELLO
    >>> x

    'HELLO\n'
    >>> import os
    >>> f = os.fdopen(0)
    >>> y = f.readline()

    adsxx
    >>> y

    'adsxx\n'

    So input() really is a pure convenience function.
    (That doesn't mean it's not worth having, though!)

    --
    Greg
     
    Gregory Ewing, Jan 30, 2014
    #12
  13. Ethan Furman

    Terry Reedy Guest

    On 1/30/2014 12:13 AM, Gregory Ewing wrote:
    > Steven D'Aprano wrote:
    >> On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
    >>
    >>> Why do we even need an "input" function anyway if all it is going to do
    >>> is read from stdin?

    >>
    >> That's not all it does.


    What else it does is print a prompt before reading and to strip off the
    trailing newline.

    >> For example, it handles backspacing, so that typing H E L O O
    >> BACKSPACE BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".

    >
    > No, it doesn't -- that's handled at a lower level.
    > Any other method of reading from stdin, as long
    > as it hasn't been redirected away from the console,
    > has the same behaviour.
    >
    > I typed some backspaces in the input to each of the
    > following experiments, and they didn't end up in the
    > data:
    >
    > >>> import sys
    > >>> x = sys.stdin.readline()

    > HELLO
    > >>> x

    > 'HELLO\n'
    > >>> import os
    > >>> f = os.fdopen(0)
    > >>> y = f.readline()

    > adsxx
    > >>> y

    > 'adsxx\n'
    >
    > So input() really is a pure convenience function.
    > (That doesn't mean it's not worth having, though!)


    It is equivalent to

    def input(prompt):
    sys.stdout.write(prompt)
    return sys.stdin.read(<one line>)[:-1]

    There was once an eval around the return, but that was determined to be
    a bad idea.

    --
    Terry Jan Reedy
     
    Terry Reedy, Jan 30, 2014
    #13
  14. On Thu, 30 Jan 2014 18:13:54 +1300, Gregory Ewing wrote:

    > Steven D'Aprano wrote:
    >> On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
    >>
    >>>Why do we even need an "input" function anyway if all it is going to do
    >>>is read from stdin?

    >>
    >> That's not all it does.
    >>
    >> For example, it handles backspacing, so that typing H E L O O BACKSPACE
    >> BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".

    >
    > No, it doesn't -- that's handled at a lower level. Any other method of
    > reading from stdin, as long as it hasn't been redirected away from the
    > console, has the same behaviour.
    >
    > I typed some backspaces in the input to each of the following
    > experiments, and they didn't end up in the data:
    >
    > >>> import sys
    > >>> x = sys.stdin.readline()

    > HELLO
    > >>> x

    > 'HELLO\n'
    > >>> import os
    > >>> f = os.fdopen(0)
    > >>> y = f.readline()

    > adsxx
    > >>> y

    > 'adsxx\n'



    Very interesting. I admit I don't actually understand the way stdin
    works. Can you explain what's going on here then?

    import sys, os
    import tty, termios, fcntl

    def getch():
    """Get a single character from standard input.

    Does not echo to the screen. This will block waiting for a keypress.
    """
    fd = sys.stdin.fileno()
    old_settings = termios.tcgetattr(fd)
    try:
    tty.setraw(fd)
    ch = sys.stdin.read(1)
    finally:
    termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
    return ch


    And in use:

    >>> [getch() for i in range(14)]

    ['H', 'e', 'l', 'l', 'l', '\x7f', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!']


    where I type "Helll BACKSPACE o SPACE World!"


    At what point do the arrow keys and other readline or readline-like
    features get handled?



    --
    Steven
     
    Steven D'Aprano, Jan 31, 2014
    #14
  15. Steven D'Aprano <> writes:

    > On Thu, 30 Jan 2014 18:13:54 +1300, Gregory Ewing wrote:
    >
    >> Steven D'Aprano wrote:
    >>> On Mon, 27 Jan 2014 12:22:22 -0800, Rick Johnson wrote:
    >>>
    >>>>Why do we even need an "input" function anyway if all it is going to do
    >>>>is read from stdin?
    >>>
    >>> That's not all it does.
    >>>
    >>> For example, it handles backspacing, so that typing H E L O O BACKSPACE
    >>> BACKSPACE L O gives "HELLO" rather than "HELOO\x7f\x7fO".

    >>
    >> No, it doesn't -- that's handled at a lower level. Any other method of
    >> reading from stdin, as long as it hasn't been redirected away from the
    >> console, has the same behaviour.
    >>
    >> I typed some backspaces in the input to each of the following
    >> experiments, and they didn't end up in the data:
    >>
    >> >>> import sys
    >> >>> x = sys.stdin.readline()

    >> HELLO
    >> >>> x

    >> 'HELLO\n'
    >> >>> import os
    >> >>> f = os.fdopen(0)
    >> >>> y = f.readline()

    >> adsxx
    >> >>> y

    >> 'adsxx\n'

    >
    >
    > Very interesting. I admit I don't actually understand the way stdin
    > works. Can you explain what's going on here then?
    >
    > import sys, os
    > import tty, termios, fcntl
    >
    > def getch():
    > """Get a single character from standard input.
    >
    > Does not echo to the screen. This will block waiting for a keypress.
    > """
    > fd = sys.stdin.fileno()
    > old_settings = termios.tcgetattr(fd)
    > try:
    > tty.setraw(fd)
    > ch = sys.stdin.read(1)
    > finally:
    > termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
    > return ch
    >
    >
    > And in use:
    >
    >>>> [getch() for i in range(14)]

    > ['H', 'e', 'l', 'l', 'l', '\x7f', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!']
    >
    >
    > where I type "Helll BACKSPACE o SPACE World!"
    >
    >
    > At what point do the arrow keys and other readline or readline-like
    > features get handled?
    >


    They can be handled by the in-kernel tty driver, when you're using a tty
    set in "cooked" mode. This driver can be configured by the termios
    functions, which invoke various ioctls on the terminal devices. Or you
    can set the tty to "raw" mode, and the keystrokes are passed on to the
    application, which can do all sorts of interpretation (for example if
    you're using the readline library, or a curses app).

    W. Richard Stevens covers this in much detail in APUE, but you can
    preserve your sanity by being ignorant of the details of tty handling.

    --
    regards,
    kushal

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

    iQEcBAEBAgAGBQJS6y+dAAoJEKolkdITDqLt6fQH/1xxAdiAJAWaq/zupTmGCSNu
    n/vnexajRihcK2OUaF/aWwD8hdTdg2zeh+z+4uN9KE3l7Er+RoN1YLD747NWPS1p
    R6n7ucrbR9dEGdR0OQY9+Ggqk8M46fqkC4A0Rj9YzY8SHafy176a2UUPGnoHhTH0
    CCNEtuvE541WjjM4oHZOtNeFfqbphfNH4rpmjEA3eOWg/4IA7HZXCbT6yS5onRNW
    pi6p6apOctxmIdKLfqNP9rVQ01sp0y8iXqfHHujKUBvUAmTktjn0UNf6kf5gbjwF
    iQJahEtPGtEEBeVRZ4fAQN+7uagrCF+ryIfk9On7eASp0DtOgrTp4gsu9UXV5/E=
    =mt2y
    -----END PGP SIGNATURE-----
     
    Kushal Kumaran, Jan 31, 2014
    #15
  16. Steven D'Aprano wrote:
    > Can you explain what's going on here then?
    >
    > import sys, os
    > import tty, termios, fcntl
    >
    > def getch():
    > """Get a single character from standard input.
    >
    > Does not echo to the screen. This will block waiting for a keypress.
    > """
    > fd = sys.stdin.fileno()
    > old_settings = termios.tcgetattr(fd)
    > try:
    > tty.setraw(fd)
    > ch = sys.stdin.read(1)
    > finally:
    > termios.tcsetattr(fd, termios.TCSADRAIN, old_settings)
    > return ch


    In Unix, normally line editing of terminal input is done
    by the tty device driver in the kernel. (In the old days
    it would have been talking to a real device connected by
    a serial line; nowadays it's more likely to be a "pseudo
    tty", which is a kind of funky pipe that looks like a
    tty from one end.)

    The tty driver can operate in a number of modes. In
    "cooked" mode it buffers up a line of input, handles
    backspacing and other editing, and a few other things
    like turning ctrl-C into an interrupt signal. In "raw"
    mode, it doesn't buffer anything and passes all characters
    straight on to the user process.

    The above code is temporarily putting the tty driver into
    raw mode, reading one character, and then putting it back
    the way it was.

    I'm not sure exactly what happens when Python is configured
    to use the readline library; probably something in the
    file object detects when it's being attached to a tty
    and interposes readline, which then puts the tty into raw
    mode and does its own thing.

    I have even less idea what happens on Windows. The console
    there seems to have an API all of its own. (The Unix
    philosophy is "everything is a file"; on Windows it
    seems to be "only files are files, everything else is
    some other weird thing of its own.")

    --
    Greg
     
    Gregory Ewing, Jan 31, 2014
    #16
    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. Gary Herron
    Replies:
    1
    Views:
    58
    Gary Herron
    Jan 27, 2014
  2. Dave Angel
    Replies:
    4
    Views:
    65
    Mark Lawrence
    Jan 27, 2014
  3. Terry Reedy
    Replies:
    1
    Views:
    57
    Ethan Furman
    Jan 27, 2014
  4. Zachary Ware
    Replies:
    0
    Views:
    50
    Zachary Ware
    Jan 27, 2014
  5. Peter Otten
    Replies:
    0
    Views:
    64
    Peter Otten
    Jan 27, 2014
Loading...

Share This Page