Re: buggy python interpretter or am I missing something here?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 pgp_vFN2YRuSu.pgp Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
me wrote: Not me, you ;) Since this code is for a personal research project I'm not as concerned about code quality as I would be if I was getting paid to write production code...and if it was production code I'd only prototype a proof-of-concept in python and then rewrite in c++. Another way to improve code quality is to write less code yourself and instead to rely on well-tested libraries: import argparse parser = argparse.ArgumentParser() parser.add_argument(-d, --basedir, default=/process) parser.add_argument(-i, --inpipe, default=/tmp/TCdaemonIN) parser.add_argument(-#, --maxjobs, type=int, default=8) parser.add_argument(-o, --outpipe, default=/tmp/TCdaemonOUT) print parser.parse_args() Seriously, code quality doesn't magically improve by a switch of language. You may make fewer newbie errors in C++, but once you get over the instinctive Ducktype and unit tests? I'll do it with these three undebuggable templates and get type checks for free from the compiler. the simpler and often more concise Python solutions will start to pay off. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, Jan 27, 2014 at 6:44 PM, me no...@all.net 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 20:01:33 +1100, Chris Angelico wrote: On Mon, Jan 27, 2014 at 6:44 PM, me no...@all.net 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. 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. Regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
O My python stuff is all rapid application development for personal projects. If I need to do anything serious I take the time to do it in C+ +. Many people Prototype in python then re-factor into a compiled language later if needed (often it turns out there is not really any need :-) ) It's the intendation specific requirements that throw me. I haven't seen such a hork since RPG. ;^) But i bet you almost certainly indent your C++ cod in a similar manor on a voluntary basis, don't worry you will soon get used to it quite probably start to like it. -- Hempstone's Question: If you have to travel on the Titanic, why not go first class? -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 2014-01-27, me no...@all.net 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 27/01/2014 07:17, me wrote: My python stuff is all rapid application development for personal projects. If I need to do anything serious I take the time to do it in C+ +. For me at least you'll fit in extremely well here with a sense of humour like that. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 09:32:43 +, 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 no...@all.net 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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! -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Tue, Jan 28, 2014 at 2:33 AM, Rick Johnson rantingrickjohn...@gmail.com 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, Jan 27, 2014 at 1:17 AM, me no...@all.net wrote:
It's the intendation specific requirements that throw me. I haven't seen
such a hork since RPG. ;^)
Best I can tell, the only thing RPG and Python have in common is the
fact that they're programming languages, though I'm being a little
generous to RPG there. I'll note that RPG (IV) is the only language
I've ever been formally trained in, unfortunately. I've mostly
forgotten it though, so that's a plus :)
Python's significant indentation is really quite nice and intuitive.
The basic rule of thumb is if a line ends in a colon, the next line
needs to be indented one more level. If you're continuing the same
logical block, keep the same indention level. When a logical block is
finished (whether by a raise, continue, break, or return statement, or
just by falling off the end of the block), indent the next line one
level less. Parentheses () (and brackets [] and braces {}) create
what amounts to a 'virtual line', \n characters are basically ignored
until the closing parenthesis is found (as long as they aren't in a
non-triple-quoted string literal).
As long as you don't try to mix tabs and spaces for your indentation
(either is fine on its own, but spaces are generally preferred), it's
very straightforward and allows you to better see the flow of the
program with no question as to whether there is anything hidden within
a block. I've been using C more in the past two weeks than I really
expected to all this year, and have been bitten more than once by
missing braces. Indenting intentionally is just a much cleaner,
clearer way to do things (in my opinion, of course).
Also, you can iterate over a (sys.argv) in a for
loop, replacing 'l', 'idx', and the while loop; something like
for arg in a:
if arg == '-h':
print help # help being defined elsewhere...
elif arg == '-hh':
# no really, print help
print 'help'
Understood, except that some parameters take multiple elements...thus why
I manually reference the indexes.
Try this on for size, then:
a_iter = iter(a)
for arg in a_iter:
print('current', arg)
if arg == '-#':
print('next', next(a_iter))
Yup. Every language and platform has multiple arg parsing libraries.
Didn't feel like taking the time to research any since most of my python
ramblings are usually pyQT4 bindings to QT4 gui and postgresql apps.
As with most modules in the standard library, I would bet you can get
started using argparse in probably 15 minutes or less. The online
documentation of the language and standard library is already quite
good, and there is constant effort going into improving it. You might
also want to play around with the 'help()' function in the interactive
interpreter, it may have answered your original question without ever
having had to ask here:
help(sys.exit)
Help on built-in function exit in module sys:
exit(...)
exit([status])
Exit the interpreter by raising SystemExit(status).
If the status is omitted or None, it defaults to zero (i.e., success).
If the status is numeric, it will be used as the system exit status.
If it is another kind of object, it will be printed and the system
exit status will be one (i.e., failure).
Pointing out that sys.exit() raises a low level exception was the point I
was missing. Thx!
You're welcome, I'm glad I could help :)
As a general reply to the 'attitude' portion of this thread: mutual
respect is the name of the game here. If you show respect (whether
you've already received it or not), you're likely to receive respect.
If not, don't be surprised by heated responses. This applies equally
to everyone, I'm not pointing fingers at anyone in particular.
Regards,
--
Zach
--
https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 10:23:49 -0600, Zachary Ware wrote:
Understood, except that some parameters take multiple elements...thus
why I manually reference the indexes.
Try this on for size, then:
a_iter = iter(a)
for arg in a_iter:
print('current', arg)
if arg == '-#':
print('next', next(a_iter))
And check out add_argument's nargs option:
http://docs.python.org/3/library/argparse.html#nargs
HTH,
Dan
--
https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 27/01/2014 07:17, me wrote: It's the intendation specific requirements that throw me. I haven't seen such a hork since RPG. ;^) Programming with a rocket propelled grenade is vastly superior to programming in C++. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Tue, Jan 28, 2014 at 7:22 AM, Rick Johnson rantingrickjohn...@gmail.com 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 -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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 -- https://mail.python.org/mailman/listinfo/python-list
buggy python interpretter or am I missing something here?
I'm writing a linux daemon in python 2.x to process batches of GPS/GIS
data and I'm running into something that seems to break the expected
program flow in a REALLY BAD WAY.
Consider the attached template script and execute it with the -h option.
It is falling through to the except: clause even though try to manually
exit with sys.exit(0). However, if I insert a raise into the except
clause then the sys.exit(0) executes properly.
See the attached code and output from when I run it.
Not interested in work-arounds. I want to understand why it doesn't work
as expected.
Thanks!
TCdaemon.py
#! /usr/bin/python
import sys
#
--
defaultparams={ \
basedir: /process, \
inpipe: /tmp/TCdaemonIN, \
maxjobs:8, \
outpipe: /tmp/TCdaemonOUT, \
ZZZ: 0
}
#
--
def parse_args(a,d):
l=len(a)
idx=1
try:
while (idxl):
if (a[idx]==-#):
idx=idx+1
d[maxjobs]=int(a[idx])
elif (a[idx]==-d):
idx=idx+1
d[basedir]=a[idx]
elif (a[idx]==-h):
print help goes here
sys.exit(0)
elif (a[idx]==-i):
idx=idx+1
d[inpipe]=a[idx]
elif (a[idx]==-o):
idx=idx+1
d[outpipe]=a[idx]
idx=idx+1
except:
# raise # -- WTF!!!??? required for -h to not fall through to
here?
print %s: error in command line - %s%(a[0],a[idx:])
sys.exit(1)
#
--
#
--
#
--
if (__name__==__main__):
print defaultparams
parse_args(sys.argv,defaultparams)
print defaultparams
output.txt ---
[@blackbox new]$ ./TCdaemon.py -h
{'ZZZ': 0, 'basedir': '/process', 'outpipe': '/tmp/TCdaemonOUT',
'maxjobs': 8, 'inpipe': '/tmp/TCdaemonIN'}
help goes here
./TCdaemon.py: error in command line - ['-h']
[@blackbox new]$ echo $?
1
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$ # editing to add raise at line 40
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$ ./TCdaemon.py -h
{'ZZZ': 0, 'basedir': '/process', 'outpipe': '/tmp/TCdaemonOUT',
'maxjobs': 8, 'inpipe': '/tmp/TCdaemonIN'}
help goes here
[@blackbox new]$ echo $?
0
[@blackbox new]$
--
https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 07:42 PM, me wrote:
I'm writing a linux daemon in python 2.x to process batches of GPS/GIS
data and I'm running into something that seems to break the expected
program flow in a REALLY BAD WAY.
Consider the attached template script and execute it with the -h option.
It is falling through to the except: clause even though try to manually
exit with sys.exit(0). However, if I insert a raise into the except
clause then the sys.exit(0) executes properly.
See the attached code and output from when I run it.
Not interested in work-arounds. I want to understand why it doesn't work
as expected.
Thanks!
TCdaemon.py
#! /usr/bin/python
import sys
#
--
defaultparams={ \
basedir: /process, \
inpipe: /tmp/TCdaemonIN, \
maxjobs:8, \
outpipe: /tmp/TCdaemonOUT, \
ZZZ: 0
}
#
--
def parse_args(a,d):
l=len(a)
idx=1
try:
while (idxl):
if (a[idx]==-#):
idx=idx+1
d[maxjobs]=int(a[idx])
elif (a[idx]==-d):
idx=idx+1
d[basedir]=a[idx]
elif (a[idx]==-h):
print help goes here
sys.exit(0)
elif (a[idx]==-i):
idx=idx+1
d[inpipe]=a[idx]
elif (a[idx]==-o):
idx=idx+1
d[outpipe]=a[idx]
idx=idx+1
except:
# raise # -- WTF!!!??? required for -h to not fall through to
here?
print %s: error in command line - %s%(a[0],a[idx:])
sys.exit(1)
Never *ever* have a bare except like that. If it gets invoked, you have
no idea why. A simple typo like ixd instead of idx or a(idx) instead
of a[idx] would raise an exception but give you no idea why.
Do
try:
...
except Exception,e:
print e
at the absolute minimum.
(Python 3 syntax would differ slightly, but the advice is the same.)
Perhaps printing a traceback along with the exception would help. Add
traceback.print_exc()
Gary Herron
#
--
#
--
#
--
if (__name__==__main__):
print defaultparams
parse_args(sys.argv,defaultparams)
print defaultparams
output.txt ---
[@blackbox new]$ ./TCdaemon.py -h
{'ZZZ': 0, 'basedir': '/process', 'outpipe': '/tmp/TCdaemonOUT',
'maxjobs': 8, 'inpipe': '/tmp/TCdaemonIN'}
help goes here
./TCdaemon.py: error in command line - ['-h']
[@blackbox new]$ echo $?
1
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$ # editing to add raise at line 40
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$
[@blackbox new]$ ./TCdaemon.py -h
{'ZZZ': 0, 'basedir': '/process', 'outpipe': '/tmp/TCdaemonOUT',
'maxjobs': 8, 'inpipe': '/tmp/TCdaemonIN'}
help goes here
[@blackbox new]$ echo $?
0
[@blackbox new]$
--
https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Sun, 26 Jan 2014 21:04:57 -0800, Gary Herron wrote: Never *ever* have a bare except like that. If it gets invoked, you have no idea why. A simple typo like ixd instead of idx or a(idx) instead of a[idx] would raise an exception but give you no idea why. Do try: ... except Exception,e: print e at the absolute minimum. (Python 3 syntax would differ slightly, but the advice is the same.) Perhaps printing a traceback along with the exception would help. Add traceback.print_exc() So here's the clencher without debating the merits bare except: since a bare catch(...) is totally acceptable in the c++ world. When I have except: by itself the program fails...but simply adding the except Exception,e: causes the program to work correctly. To me that signifies an undefined behavior of the python specification, or at least bad behavior of the python interpreter I'm using. If you can syntactically use a bare except: without generating an invalid syntax error then it should have a well defined and predictable outcome. If in fact the except Exception, e: is what's required then a bare except shouldn't be considered valid syntax at all, right? kind regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 1/27/2014 12:04 AM, Gary Herron wrote: Do try: ... except Exception,e: print e at the absolute minimum. (Python 3 syntax would differ slightly, but the advice is the same.) The 'python 3' syntax except Exception as e: works in 2.7 and perhaps 2.6. So use it unless you need compatibility with even earlier versions. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 01:21:41 -0500, Terry Reedy wrote: On 1/27/2014 12:04 AM, Gary Herron wrote: Do try: ... except Exception,e: print e at the absolute minimum. (Python 3 syntax would differ slightly, but the advice is the same.) The 'python 3' syntax except Exception as e: works in 2.7 and perhaps 2.6. So use it unless you need compatibility with even earlier versions. My point of contention isn't so much about what specific syntax I should be using as much as it is about being allowed to use a syntax that gives erroneous results without triggering a syntax violation. If the bare except: clause is syntactically legal then it should yield deterministic results based on a well defined language specification, right? It's looking very much like except: is undefined behaviour. kind regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, Jan 27, 2014 at 12:02 AM, me no...@all.net wrote: On Mon, 27 Jan 2014 00:36:20 -0500, Dave Angel wrote: sys.exit() raises an exception, and you're deliberately eating that exception. I can buy that sys.exit (may) be throwing an exception...My point of contention isn't that I may be throwing one, but why would a subsequent raise in the except: clause cause the point of program execution to jump back up to the sys.exit(0) and then function correctly. You've missed the point here. sys.exit() *does* raise an exception: SystemExit, a subclass of BaseException. In fact, you can implement sys.exit in pure Python like so: def exit(status): raise SystemExit(status) Your bare 'except:' catches that SystemExit along with any other possible exception; the bare 'raise' in the except clause just re-raises the same SystemExit, which then does what you meant for it to do in the first place. Exception classes form a hierarchy, with BaseException being the base (obviously :)), except: is really just shorthand for except BaseException:, and is very rarely a good idea. Deriving from BaseException are SystemExit, KeyboardInterrupt, and Exception. SystemExit is the exception raised by sys.exit(), which if left unhandled, the interpreter takes as a sign to shut down gracefully. KeyboardInterrupt is raised by Ctrl+C, or (more accurately, if I'm not mistaken) by sending SIGINT to the process. Exception is the base class for all other exceptions, such as TypeError, ValueError, OSError, etc., and is what you actually want to catch if you really don't care what exception is raised but want to handle it (though in most cases, you either should care, or should at least report what the exception was, preferably with a traceback...which is easiest to do by not trying to catch the exception at all). I would suggest skimming through the Python tutorial and/or language reference if you haven't before, there's a lot of good information in there that will make your life with Python much easier. And, please take this positively, but from your posted code it's fairly apparent that Python is not your native tongue :). For instance, you don't need the backslashes in your defaultparams assignment; the parser knows it needs to keep looking on subsequent lines when it hasn't found the closing '}' yet. Also, you can iterate over a (sys.argv) in a for loop, replacing 'l', 'idx', and the while loop; something like for arg in a: if arg == '-h': print help # help being defined elsewhere... elif arg == '-hh': # no really, print help print 'help' And the big one, argument parsing is a solved problem in Python. Check out the argparse module in the standard library (or if you're using an older version of Python, try either optparse or getopt. It's really a thrice-solved problem ;)). I hope I've been of some help, -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
In any case, thanks for the answers guys. I'm satisfied that the except: syntax yields undefined behavior, and in my mind it shouldn't be syntactically allowed then. Updating to Exception,e or Exception as e fixes the problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, Jan 27, 2014 at 12:46 AM, me no...@all.net wrote: In any case, thanks for the answers guys. I'm satisfied that the except: syntax yields undefined behavior, and in my mind it shouldn't be syntactically allowed then. It's not undefined, though; it is explicitly defined. See my other message, and here are a couple other places to skim through: http://docs.python.org/2/tutorial/errors.html and http://docs.python.org/2/library/exceptions.html -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 10:17 PM, me wrote: On Sun, 26 Jan 2014 21:04:57 -0800, Gary Herron wrote: Never *ever* have a bare except like that. If it gets invoked, you have no idea why. A simple typo like ixd instead of idx or a(idx) instead of a[idx] would raise an exception but give you no idea why. Do try: ... except Exception,e: print e at the absolute minimum. (Python 3 syntax would differ slightly, but the advice is the same.) Perhaps printing a traceback along with the exception would help. Add traceback.print_exc() So here's the clencher without debating the merits bare except: since a bare catch(...) is totally acceptable in the c++ world. When I have except: by itself the program fails...but simply adding the except Exception,e: causes the program to work correctly. Doubtful. We've been doing this kind of stuff for decades without hitting your supposed bug. Much more likely is that you've misinterpreted the results. Ii don't know how, but I'm quite confident that you have. Your contention that the raise goes back to the sys.exit() is certainly a mis-interpretation also. The re-raise of the original exception is now an uncaught exception, and the interpreter's response to an uncaught exception is to kill the program. Nearly the same result as the sys.exit(), but via a different pathway. To me that signifies an undefined behavior of the python specification, or at least bad behavior of the python interpreter I'm using. If you can syntactically use a bare except: without generating an invalid syntax error then it should have a well defined and predictable outcome. It is well defined. Slow down a bit, rerun your two tests, show is the code *and* the results, and we'll get to the bottom of this. If in fact the except Exception, e: is what's required then a bare except shouldn't be considered valid syntax at all, right? Bare excepts are perfectly legal valid syntax and have their uses, however it's just extremely dangerous programming to allow a simple typo (or any of an infinite number of possible errors) in your try section to masquerade as a error in command line (to quote your print at that point).Python's dynamic typing makes bare except extremely dangerous. In Python, unlike C, any number of typos can be syntactically correct, but meaningless, exception-raising actions at run time. Things like misspelling a variable/function name, substituting a comma for a decimal point, indexing something that is not indexable, applying a function to the wrong parameters or wrong number of parameters, ... All these are *not* syntax errors (as they would be in C), but will cause a run-time exception -- and you'd never know why with that bare except blindly catching them all and claiming command line error. Gary Herron kind regards -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 10:46 PM, me wrote: In any case, thanks for the answers guys. I'm satisfied that the except: syntax yields undefined behavior, and in my mind it shouldn't be syntactically allowed then. Updating to Exception,e or Exception as e fixes the problem. That's an irksome habit you have there, this jumping to (incorrect) conclusions so quickly. We'd like to get to the bottom of this. (And correct your mis-interpretations while we're at it :-)But we need to see your test *and* the results. Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Mon, 27 Jan 2014 00:47:13 -0600, Zachary Ware wrote: You've missed the point here. sys.exit() *does* raise an exception: SystemExit, a subclass of BaseException. In fact, you can implement sys.exit in pure Python like so: def exit(status): raise SystemExit(status) Your bare 'except:' catches that SystemExit along with any other possible exception; the bare 'raise' in the except clause just re-raises the same SystemExit, which then does what you meant for it to do in the first place. Well that does change things a bit and makes perfect sense now. Thx! And, please take this positively, but from your posted code it's fairly apparent that Python is not your native tongue :). Correct. The barbarians invaded my homeland and forced me to speak their wicked incantations. I'm a c/c++ guy through and through with a sprinkling of the ancient tongues like algol, LSI-11 and Z80 assembler, fortran-4, etc. My python stuff is all rapid application development for personal projects. If I need to do anything serious I take the time to do it in C+ +. For instance, you don't need the backslashes in your defaultparams assignment; the parser knows it needs to keep looking on subsequent lines when it hasn't found the closing '}' yet. It's the intendation specific requirements that throw me. I haven't seen such a hork since RPG. ;^) Also, you can iterate over a (sys.argv) in a for loop, replacing 'l', 'idx', and the while loop; something like for arg in a: if arg == '-h': print help # help being defined elsewhere... elif arg == '-hh': # no really, print help print 'help' Understood, except that some parameters take multiple elements...thus why I manually reference the indexes. And the big one, argument parsing is a solved problem in Python. Check out the argparse module in the standard library (or if you're using an older version of Python, try either optparse or getopt. It's really a thrice-solved problem ;)). Yup. Every language and platform has multiple arg parsing libraries. Didn't feel like taking the time to research any since most of my python ramblings are usually pyQT4 bindings to QT4 gui and postgresql apps. I hope I've been of some help, Pointing out that sys.exit() raises a low level exception was the point I was missing. Thx! -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Sun, 26 Jan 2014 23:03:51 -0800, Gary Herron wrote: found the part I was missing based on another response. Didn't realize that sys.exit() triggered an instance of BaseException and that explains the weird behavior. thx! -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On 01/26/2014 10:42 PM, me wrote: My point of contention isn't so much about what specific syntax I should be using as much as it is about being allowed to use a syntax that gives erroneous results without triggering a syntax violation. If the bare except: clause is syntactically legal then it should yield deterministic results based on a well defined language specification, right? It's looking very much like except: is undefined behaviour. There is nothing undefined about it. `except:` catches everything. Occasionally there is a good reason to do it that way, but under typical circumstances you tell 'except' which exceptions you are prepared to deal with. -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
On Sun, 26 Jan 2014 23:12:18 -0800, Gary Herron wrote: On 01/26/2014 10:46 PM, me wrote: In any case, thanks for the answers guys. I'm satisfied that the except: syntax yields undefined behavior, and in my mind it shouldn't be syntactically allowed then. Updating to Exception,e or Exception as e fixes the problem. That's an irksome habit you have there, this jumping to (incorrect) conclusions so quickly. We'd like to get to the bottom of this. (And correct your mis-interpretations while we're at it :-)But we need to see your test *and* the results. Gary Herron Problem solved. I understand what was happening now with the raise following the bare except: Since this code is for a personal research project I'm not as concerned about code quality as I would be if I was getting paid to write production code...and if it was production code I'd only prototype a proof-of-concept in python and then rewrite in c++. The project is to take advantage of all 16 CPU cores to process A LOT of GPS data for a 3d map-making and visualization project. Now my bottleneck may end up being the python global lock when doing concurrent processing...but we'll see. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: buggy python interpretter or am I missing something here?
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! -- https://mail.python.org/mailman/listinfo/python-list
