|
Hot Bard posted:After spending the past two weeks attempting to learn python which is supposedly the most newbie friendly language out there, my mind is blown by how people manage to program computer games and rocket ships with this. Okay I'll bite. With keywords like "supposedly" and "with this" it seems you're disenchanted. Do we have to play 20 questions?
|
# ? Nov 10, 2008 06:56 |
|
|
# ? May 14, 2024 01:15 |
|
Beats the hell out of me man, how anyone can take this so-called "programming language" seriously is anybody's guess.
|
# ? Nov 10, 2008 10:57 |
|
Ragg posted:Beats the hell out of me man, how anyone can take this so-called "programming language" seriously is anybody's guess.
|
# ? Nov 10, 2008 15:13 |
|
BigRedDot posted:Probably because they (unlike you?) do lots of productive work with it. I think he was being sarcastic (given that he's not the person Habnabit was responding to)? Hope so, anyway.
|
# ? Nov 10, 2008 15:53 |
|
I am not insulting computer.
|
# ? Nov 10, 2008 18:50 |
|
tbradshaw posted:You mean try it as a string rather than a list? I finally got a working solution. After giving up and doing it with an AutoIt script, which failed in my demo with my co-worker as an IM alert popped up which ruined it. I grabbed Paramiko but I would have had to do some compiling to get pycrypto working. Found a compiled version here http://commandline.org.uk/python/2008/may/29/sftp-python-really-simple-ssh/ Then I found a ssh file that simplified paramiko http://commandline.org.uk/python/2008/may/29/sftp-python-really-simple-ssh/ Now I have something that works and I hope this helps someone else out in the future code:
chemosh6969 fucked around with this message at 00:39 on Nov 11, 2008 |
# ? Nov 11, 2008 00:36 |
|
deimos posted:You should really try to do the exercise without using string.find, it's kind of cheating. That being said: Hey, thanks. I haven't had time to try it out, but I didn't want to forget to say thanks. I'll probably end up chiming in again once I'm able to try some more exercises. An interesting side note: At work, I got a chance to hover over some of our dev's shoulders, and for the first time in 3 years at my job, I was able to identify and understand chunks of the code that would have looked like gobledegook a month ago. It's in Java, but I could identify various methods, statements, variables, etc. So I guess this poo poo is rewarding me with more than frustration. Go Python!
|
# ? Nov 11, 2008 09:48 |
|
Hey everyone, I'm using python to convert our company's log in script from a few hundred batch scripts to a single script. I've got much of the script completed but I was thinking about something earlier and wanted to see what my options were. When this script executes it maps a number of drives, some users plug in usb thumb drives that might steal a drive letter. When this happens the script will silently fail and not continue mapping printers and what not. The script is a large if statement (if username = whatever map these drives etc) is there a way to tell python to just continue going through the script instead of stopping if it can't map a single drive?
|
# ? Nov 11, 2008 23:24 |
|
Twlight posted:Hey everyone, code:
|
# ? Nov 11, 2008 23:45 |
|
Slightly on topic: anyone else going to PyWorks this week in atlanta?
|
# ? Nov 12, 2008 16:13 |
|
m0nk3yz posted:Slightly on topic: anyone else going to PyWorks this week in atlanta? I'm not! Hope it's a good con though. Speaking of cons, I'm starting to think I may not be able to make it to PyCon next year either. Was hoping to attend, especially since I've got some pressure to help push the book, but I really doubt I can spare the money for the travel/board/fees (my wife is chronically unemployed due to the poor animation market, so that makes our financial situation not the greatest). Almost makes me miss my last job; they paid for yearly training, including conferences and such. vvv Reeeeallly....I'll have to look into that. Thanks for the tip, I had no idea they'd actually help people go to the cons, given that your average tech worker is usually well off. EDIT v2: and, also, if I'm lucky I might make a little money off the book by then, we'll have to see bitprophet fucked around with this message at 19:00 on Nov 12, 2008 |
# ? Nov 12, 2008 16:41 |
|
bitprophet posted:I'm not! Hope it's a good con though. When pycon gets closer, you could apply for PSF aid to go - I know they have a fund for just this.
|
# ? Nov 12, 2008 18:25 |
|
chemosh6969 posted:
For the love of god don't do this! There's still an argument going on in another thread that started with why this was a terrible idea. If you really, really don't care about errors, LOG THEM. This way, if there's any problems, you'll have no idea why and thus no way to correct it. code:
|
# ? Nov 13, 2008 00:18 |
|
Also, pretty much never do a catch-all except statement. It catches exceptions like the KeyboardInterrupt exception, which you probably want to leave alone. It's good practice to always specify the exceptions that you're catching.
|
# ? Nov 13, 2008 00:56 |
|
What's the best way of creating a numpy array of 16-bit values from packed 12-bit data (originating from a file on disk)? Everything I start doing seems too convoluted to fit in with the rest of my python code.
|
# ? Nov 13, 2008 23:17 |
|
Habnabit posted:except: pass is just about the stupidest thing you can do in python. I do it when I expect an error to happen but don't care about logging it because I know what it is, or don't care, and want to program to do whatever it's doing. If I need to know what the error is, then I don't need to use it. It has it's uses and there's nothing wrong with using it if you know what you're doing.
|
# ? Nov 13, 2008 23:39 |
|
chemosh6969 posted:I do it when I expect an error to happen but don't care about logging it because I know what it is, or don't care, and want to program to do whatever it's doing. It turns out Python is special, and whereas other languages use exceptions as a scoped error handling mechanism giving you structured control over errors, Python also uses them for:
|
# ? Nov 13, 2008 23:57 |
|
chemosh6969 posted:I do it when I expect an error to happen but don't care about logging it because I know what it is, or don't care, and want to program to do whatever it's doing. Even if you don't care about logging it do something like except OSError: pass so you can be like wtf TypeError? in the rare case that something truly, you know, exceptional happens.
|
# ? Nov 14, 2008 01:05 |
|
Lord Uffenham posted:Even if you don't care about logging it do something like except OSError: pass so you can be like wtf TypeError? in the rare case that something truly, you know, exceptional happens. Then in that rare case where I don't know the error, I can take out pass and read the error. edit: If it's something that I care about, I do logs. For simple poo poo I do to speed things up, I don't care about logs. chemosh6969 fucked around with this message at 01:13 on Nov 14, 2008 |
# ? Nov 14, 2008 01:09 |
|
Right, why have a computer do something automatically that you can do manually
|
# ? Nov 14, 2008 01:13 |
|
Lord Uffenham posted:Right, why have a computer do something automatically that you can do manually See above edit. Some things just aren't some complex that I need a log to tell me of any errors and it works just fine if it hits any. It ignores it and continues. Also, see what Zombywuf posted.
|
# ? Nov 14, 2008 01:19 |
|
chemosh6969 posted:I do it when I expect an error to happen but don't care about logging it because I know what it is, or don't care, and want to program to do whatever it's doing. Can you be any more specific? I can't think of any times where I ever thought that would be useful.
|
# ? Nov 14, 2008 01:34 |
|
I don't think we're disagreeing as much as you think we are. I'm okay with ignoring exceptions, even not logging them. (In very simple shell script like programs, of course). I'm just saying only ignore the exceptions that you know will happen and don't care about so that when something subtle or uncommon happens your script terminates with a stack trace saying hey I'm broken, broken right here, and broken in this way. It beats what the gently caress why isn't this piece of poo poo working?
|
# ? Nov 14, 2008 01:36 |
|
Lord Uffenham posted:I don't think we're disagreeing as much as you think we are. I'm okay with ignoring exceptions, even not logging them. (In very simple shell script like programs, of course). My poo poo's just so good that when it breaks I know why or just don't care. System works as designed. I don't use it that much but the first example I found was code:
|
# ? Nov 14, 2008 01:49 |
|
And if logfile.close() goes into an infinite loop (maybe because it's on a crappy network share that's not responding), and you can't kill it because Ctrl-C gets silently thrown away, you're fine with that? EDIT: actually in this case I guess Ctrl-C would magically resolve the infinite loop and jolt the program awake, so you'd be pleasantly surprised when you hit it and everything starts working again. But that's not the point.
|
# ? Nov 14, 2008 02:42 |
|
chemosh6969 posted:My poo poo's just so good that when it breaks I know why or just don't care. System works as designed. You know what would work just fine? code:
Habnabit fucked around with this message at 08:16 on Nov 14, 2008 |
# ? Nov 14, 2008 08:14 |
|
alternatively:code:
|
# ? Nov 14, 2008 09:21 |
|
Habnabit posted:You know what would work just fine? It at would last until the screen closes down at the end of the job which means I wouldn't see it anyway.
|
# ? Nov 14, 2008 18:37 |
|
chemosh6969 posted:It at would last until the screen closes down at the end of the job which means I wouldn't see it anyway. We don't care about your particular use case here. We're just trying to point out that what you're doing is the Python equivalent of e.g. PHP's mysql_query("UPDATE table SET field='" . $_GET['raw_user_input'] . "'");. Yea, sure, "it works for now", but it's dumb to the point of retardation, and is an absolutely horrible habit to get into. You don't (or won't forever, if you do now) work in total isolation, so learning best practices and conventions is the best way to ensure you won't run into problems working with other folks, using other peoples' code, and so forth. Or, say, trying to help out other programmers on a coding forum on the Internet, where you're passing on this really bad habit to newbies. That's why the PHP ecosystem is such poo poo -- this sort of thing, people passing bad information around until it becomes conventional wisdom.
|
# ? Nov 14, 2008 19:32 |
|
chemosh6969 posted:It at would last until the screen closes down at the end of the job which means I wouldn't see it anyway. Log to a file
|
# ? Nov 14, 2008 20:21 |
|
chemosh6969 posted:It at would last until the screen closes down at the end of the job which means I wouldn't see it anyway. Okay, so maybe logging isn't useful to you. That's fine, logging isn't always useful. I can think of one use of Python where I was scripting "logon scripts" for a fleet of workstations, and without a robust logging solution, I would have just ended up with a bunch of logs scattered all over a university, not much use. You also seem to be set in your ways, and no matter how many people tell you that you're doing a "worst practice" and you're a lovely coder, because of your attitude about it, you're not going to change. However, for all the "new guys" reading this, there is an important lesson. It comes in two parts: 1) Logging is great, use it liberally. It's especially great for *users* to troubleshooting without having to code dive. 2) Catch exactly the exceptions you expect, no others. If logging doesn't make any sense to you in your particular application, that's fine, there's no one size-fits all solution. BUT that same rule means that a "naked except" clause is stupid. Only catch the exceptions you know can happen and you're ready to catch. Don't catch everything and assume you know everything about the world and it's methods. Catching only the exceptions you expect is not only great for troubleshooting, it's also fantastic for code reuse. If the code you write today gets integrated into something larger, perhaps it's more appropriate for something "farther up the stack" to handle a particular exception. Exception handling in Python is very robust and extremely effective. A "naked except" clause takes all of the elegance out of the solution and makes it a kludge.
|
# ? Nov 14, 2008 22:07 |
|
tbradshaw posted:Okay, so maybe logging isn't useful to you. That's fine, logging isn't always useful. I can think of one use of Python where I was scripting "logon scripts" for a fleet of workstations, and without a robust logging solution, I would have just ended up with a bunch of logs scattered all over a university, not much use. Yes, logging isn't useful to me logfile.close() clearly means nothing. Janin posted:Log to a file Like another log file in addition to the one that couldn't close because of an error? Then if I can't close that open a third log file and repeat as necessary? Holy poo poo, was all this really necessary? If everyone wants to make a log file for something as simple as 3 lines of code, go ahead. I've only used pass a couple of times in the years I've been doing python. There's no reason to limit oneself to not using something when it can be useful.
|
# ? Nov 15, 2008 00:09 |
|
chemosh6969 posted:Yes, logging isn't useful to me logfile.close() clearly means nothing. If you're opening log files manually you're doing it wrong, use a logging.FileHandler. chemosh6969 posted:Like another log file in addition to the one that couldn't close because of an error? Then if I can't close that open a third log file and repeat as necessary? Why do you want to preserve error output from closing a log file? If you don't, just use warnings.warn() or logging.error(). chemosh6969 posted:Holy poo poo, was all this really necessary? If everyone wants to make a log file for something as simple as 3 lines of code, go ahead. Or just use the built-in, debugged, working logging module and stop poorly re-implementing standard library features. chemosh6969 posted:I've only used pass a couple of times in the years I've been doing python. There's no reason to limit oneself to not using something when it can be useful. except: pass is not useful.
|
# ? Nov 15, 2008 01:57 |
|
The whole logging thing seems to be leading to tangents so here's the core summation: except: pass is always troublesome, even if not immediately so or if not apparently so. However, ignoring exceptions that you want to safely ignore is fine, just use except IgnorableException: pass instead, so that you are in fact always safely ignoring them. That said, feel free to ignore the above advice and any exceptions if you realize that it is a bad practice and a potential source of bugs but you guage the likelihood of such bugs to be close enough to never to not give a drat.
|
# ? Nov 15, 2008 02:38 |
|
Janin posted:If you're opening log files manually you're doing it wrong, use a logging.FileHandler. No, that doesn't work. You have to use except: pass. Since I use it, it's useful and that makes you wrong. quote:Why do you want to preserve error output from closing a log file? Read the post. That's what she said. edit: Here's my favorite use of pass. This is the first thing I show people new to python code:
chemosh6969 fucked around with this message at 02:44 on Nov 15, 2008 |
# ? Nov 15, 2008 02:42 |
|
Why would you show them that?
|
# ? Nov 15, 2008 03:32 |
|
Well, I'm glad he showed us that, since it means we can discount his opinions and arguments wholesale and move on with our lives.
Lonely Wolf fucked around with this message at 03:55 on Nov 15, 2008 |
# ? Nov 15, 2008 03:52 |
|
my stepdads beer posted:Why would you show them that? Because no matter how many people tell me it's wrong, I'm still going to use it once every couple years. Nothing changes. edit: I don't really show anyone that. Clearly the answer is log files
|
# ? Nov 15, 2008 03:56 |
|
Guys, this: http://github.com/alex/pyelection/tree/master/models.py#L57 is why you shouldn't be using except: pass, because i don't have a loving clue what my own code does, or what the logic is.
|
# ? Nov 15, 2008 08:40 |
|
|
# ? May 14, 2024 01:15 |
|
king_kilr posted:i don't have a loving clue what my own code does A python application for following the US primaries edit: According to the Zen of Python, I'm right. "Errors should never pass silently. Unless explicitly silenced." -- Tim Peters' Zen of Python chemosh6969 fucked around with this message at 18:08 on Nov 15, 2008 |
# ? Nov 15, 2008 18:01 |