Python information and short questions megathread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Python information and short questions megathread.

«‹›484 »

Habnabit: Dec 30, 2007; lift your skinny fists like
antennas in germany.

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. :v:

With keywords like "supposedly" and "with this" it seems you're disenchanted. Do we have to play 20 questions?

# ? Nov 10, 2008 06:56

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 17:16

Ragg: Apr 27, 2003; <The Honorable Badgers>

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

BigRedDot: Mar 6, 2008

Ragg posted:

Beats the hell out of me man, how anyone can take this so-called "programming language" seriously is anybody's guess.

Probably because they (unlike you?) do lots of productive work with it.

# ? Nov 10, 2008 15:13

bitprophet: Jul 22, 2004; Taco Defender

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

Thats so Brad!: Jul 5, 2008; by Ozma

I am not insulting computer.

# ? Nov 10, 2008 18:50

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

tbradshaw posted:

You mean try it as a string rather than a list?

That would be equivalent to:
code:
p = subprocess.Popen(['ls -l'], shell=True)
Which would be the other direction to the same solution as what our friend Habnabit stated here. He removed the "shell=True", you instead removed the arguments (instead passing a single string as a single argument).

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:

s = ssh.Connection(host = 'example.com', username = 'username', password = 'password')
s.execute('rename poo.txt pee.txt')
s.close()

I get errors if I try s.get(file) but not when I s.put(file). Guessing it's a path thing I'm messing up but I only need put() to work so I'm happy.

chemosh6969 fucked around with this message at 00:39 on Nov 11, 2008

# ? Nov 11, 2008 00:36

Bunson_Honeydew: May 12, 2001

deimos posted:

You should really try to do the exercise without using string.find, it's kind of cheating. That being said:
...

That's not very useful if he's trying to learn to code. (albeit my code is un-pythonic, but I think it's illustrating what Bunson is trying to learn.

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

Twlight: Feb 18, 2005; I brag about getting free drinks from my boss to make myself feel superior; Fun Shoe

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

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

Twlight posted:

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?

code:

try:
   #try to map drive
except:
   pass
else:
   #it worked so do something

If there's an exception, it'll just keep on trucking(but not do the else if the mapping failed of course)

# ? Nov 11, 2008 23:45

m0nk3yz: Mar 13, 2002; Behold the power of cheese!

Slightly on topic: anyone else going to PyWorks this week in atlanta?

# ? Nov 12, 2008 16:13

bitprophet: Jul 22, 2004; Taco Defender

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 :ninja:

bitprophet fucked around with this message at 19:00 on Nov 12, 2008

# ? Nov 12, 2008 16:41

m0nk3yz: Mar 13, 2002; Behold the power of cheese!

bitprophet posted:

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.

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

Habnabit: Dec 30, 2007; lift your skinny fists like
antennas in germany.

chemosh6969 posted:

code:
try:
   #try to map drive
except:
   pass
else:
   #it worked so do something
If there's an exception, it'll just keep on trucking(but not do the else if the mapping failed of course)

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:

try:
   #try to map drive
except:
   traceback.print_exc()
else:
   #it worked so do something

except: pass is just about the stupidest thing you can do in python. I've seen people come into #python with no idea why their code isn't working and not understanding why half of their debug prints don't print because they put a 'try: ... except: pass' around everything, assuming that silencing the traceback stops problems.

# ? Nov 13, 2008 00:18

hey mom its 420: May 12, 2007

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

yippee cahier: Mar 28, 2005

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

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

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

Zombywuf: Mar 29, 2008

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.

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.

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:

Informing the program that a keyboard interrupt has occurred. This only happens for this kind of external message, because this message is special somehow.
Providing a stack-trace when you run out of memory. It would be easy to mistake this for Python allowing you to recover from memory errors, but instead it is explicitly documented as not guaranteeing and uncorrupted heap after a failed allocation.
Signaling that a generator has nothing more to generate/should stop generating.
Informing functions further up the stack that sys.exit() has been called, and allowing them to trap it.

# ? Nov 13, 2008 23:57

Lonely Wolf: Jan 20, 2003; Will hawk false idols for heaps and heaps of dough.

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.

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.

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

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

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

Lonely Wolf: Jan 20, 2003; Will hawk false idols for heaps and heaps of dough.

Right, why have a computer do something automatically that you can do manually :confused:

# ? Nov 14, 2008 01:13

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

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

Habnabit: Dec 30, 2007; lift your skinny fists like
antennas in germany.

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.

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.

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

Lonely Wolf: Jan 20, 2003; Will hawk false idols for heaps and heaps of dough.

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

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

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).

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?

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:

try:
    logfile.close()
except:
    pass

If it doesn't want to close, I'm not going to sweet talk it.

# ? Nov 14, 2008 01:49

JoeNotCharles: Mar 3, 2005; Yet beyond each tree there are only more trees.

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

Habnabit: Dec 30, 2007; lift your skinny fists like
antennas in germany.

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.

I don't use it that much but the first example I found was
code:
try:
    logfile.close()
except:
    pass
If it doesn't want to close, I'm not going to sweet talk it.

You know what would work just fine?

code:

try:
    logfile.close()
except:
    warnings.warn('tried to close file: \n' + traceback.format_exc(), stacklevel=2)

e: Slight clarification. Warnings will only be shown once per line, and you can pass a flag to python to treat them as errors or suppress them entirely. Problem solved, and in a configurable way!

Habnabit fucked around with this message at 08:16 on Nov 14, 2008

# ? Nov 14, 2008 08:14

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

alternatively:

code:

try:
    logfile.close ()
except:
    logging.error ("Couldn't close log file", exc_info = True)

# ? Nov 14, 2008 09:21

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

Habnabit posted:

You know what would work just fine?
code:
try:
    logfile.close()
except:
    warnings.warn('tried to close file: \n' + traceback.format_exc(), stacklevel=2)
e: Slight clarification. Warnings will only be shown once per line, and you can pass a flag to python to treat them as errors or suppress them entirely. Problem solved, and in a configurable way!

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

bitprophet: Jul 22, 2004; Taco Defender

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

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

tbradshaw: Jan 15, 2008; First one must nail at least two overdrive phrases and activate the tilt sensor to ROCK OUT!

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

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

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.

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.

Yes, logging isn't useful to me :rolleyes:

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

TOO SCSI FOR MY CAT: Oct 12, 2008; this is what happens when you take UI design away from engineers and give it to a bunch of hipster art student "designers"

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

Lonely Wolf: Jan 20, 2003; Will hawk false idols for heaps and heaps of dough.

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

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

Janin posted:

If you're opening log files manually you're doing it wrong, use a logging.FileHandler.

except: pass is not useful.

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:

try:
    print 'Hello World'
except:
    pass

chemosh6969 fucked around with this message at 02:44 on Nov 15, 2008

# ? Nov 15, 2008 02:42

cowboy beepboop: Feb 24, 2001

Why would you show them that?

# ? Nov 15, 2008 03:32

Lonely Wolf: Jan 20, 2003; Will hawk false idols for heaps and heaps of dough.

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

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

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

king_kilr: May 25, 2007

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

Adbot: ADBOT LOVES YOU

# ? May 14, 2024 17:16

chemosh6969

Jul 3, 2004

code:
cat /dev/null > /etc/professionalism

_{_{I am in fact a massive asswagon.

Do not let me touch computer.}}

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

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Python information and short questions megathread.

«‹›484 »