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 »

yippee cahier: Mar 28, 2005

Mr. Wynand posted:

Why not simply put it outside of the try block? Just some weird pythonism style thing?

In the example here, you could end up trying to read lines and close an unopened file, raising more exceptions.

# ? Aug 17, 2010 02:28

Adbot: ADBOT LOVES YOU

# ? May 24, 2024 14:11

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

edit: nvm, I get it

# ? Aug 17, 2010 02:57

Boblonious: Jan 14, 2007; I HATE PYTHON IT'S THE SHITTIEST LANGUAGE EVER PHP IS WAY BETTER BECAUSE IT IS MADE FOR THE WEB AND IT USES MYSQL WHICH IS ALSO USED BY GOOGLE AND THATS WHY ITS SO MUCH BETTER THAN PYTHON EVEN HTML IS A BETTER PROGRAMMING LANGUAGE THAN PYTHON

tef posted:

Especially when people catch exception instead of StandardError, and end up catching generatorexit and breaking generators.

code:

In [1]: isinstance(GeneratorExit(), Exception)
Out[1]: False

In [2]: isinstance(GeneratorExit(), StandardError)
Out[2]: False

In [3]: isinstance(GeneratorExit(), BaseException)
Out[3]: True

In [4]: try:
   ...:     raise GeneratorExit()
   ...: except Exception:
   ...:     print "Caught you!"
   ...:    
---------------------------------------------------------------------------
GeneratorExit                             Traceback (most recent call last)

Is there something I'm missing? GeneratorExit doesn't seem to inherit from Exception.

Edit: The docs say this was changed in 2.6:

quote:

Changed in version 2.6: Changed to inherit from BaseException.

# ? Aug 17, 2010 12:45

Lurchington: Jan 2, 2003; Forums Dragoon

If you actually check GeneratorExit, it does say it's changed to inherit from BaseException, but it's a little confusing if you're looking at the Built-in Exceptions documentation:

pre:

exception Exception

    All built-in, non-system-exiting exceptions are derived from this class. All
 user-defined exceptions should also be derived from this class.

    Changed in version 2.5: Changed to inherit from BaseException.

exception StandardError
    The base class for all built-in exceptions except StopIteration, GeneratorExit,
 KeyboardInterrupt and SystemExit. StandardError itself is derived from Exception.

As a bonus, StopIteration seems to inherit from Exception (not BaseException)

# ? Aug 17, 2010 13:29

Ferg: May 6, 2007; Lipstick Apathy

I know this was asked recently but later this week I have a technical phone screen for a major web company looking for a Django developer. Since this is only a phone screen I assume it will be more specific questions rather than whiteboard questions like what was asked earlier. Does anybody have example questions they've encountered or have used? I've brushed up on a lot of Django topics, some I was less familiar with than others, but this interview I've been told will be more down and dirty Python focused.

# ? Aug 17, 2010 15:00

Lurchington: Jan 2, 2003; Forums Dragoon

Here's my interview whiteboard question from the yospos thread: link

questions that stood out, not exhaustive or anything:

On the phone, I was asked:

underlying structure of a python list in C - array of pointers
difference between processes and threads - pycon presentation
what is the global interpreter lock? - link
what is a generator
what is a list comprehension
explain garbage collection

in person:

how would you make use of the with keyword - link, also link
compare and contrast eventlet/twisted/other concurrency libraries - pycon talk (pycon 09 was great for brushing up)
what do I hate most about python (struggled with this, but it was a good question)
what changes are in 3.x vs 2.x (I had difficulty going beyond syntax at the time, but removing bytestrings for unicode would be key for a Django-based group)

# ? Aug 17, 2010 15:43

wtcurtis: Jun 13, 2003

I've been learning python for a while now, but I seem to run into this kind of situation pretty often. I'm pretty sure there's a more pythonic way to do this sort of thing:

code:

def maskColumns(self):
	for i in range(9):
		doneNumbers = [a for a in [self.grid[j][i] for j in range(9)] if a > 0]
		for num in doneNumbers:
			for j in range(9):
				self.mask[num-1][j][i] = 0

This is from a sudoku solver I'm writing for no good reason. (grid is a 9x9 matrix containing the ongoing puzzle, and mask is a 9x9x9 matrix of zeros and ones, where a one means a specific number may go there in the grid, and zero means it can't. doneNumbers is just the numbers from the column in question I need to mask off.) The way I'm doing it works just fine.

But my problem is the fact that I'm iterating over range(9) so drat often. Is there a way to, in this example, set an entire column of one matrix (well, list of lists, but whatever) to zero, depending on the value in a corresponding location in another matrix?

# ? Aug 17, 2010 19:02

tef: May 30, 2004; -> some l-system crap ->

store it as a flat array instead of a nested one, and you can use array slices to describe rows and colums.

# ? Aug 17, 2010 19:21

tripwire: Nov 19, 2004; _{ghost flow}

itertools.chain would come in really handy there.

# ? Aug 17, 2010 22:59

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

Lurchington posted:

Here's my interview whiteboard question from the yospos thread: link

questions that stood out, not exhaustive or anything:
...snip...

Nice! And I'm oddly flattered you cited my talks

Have you mentioned where you were interviewing - those are pretty good questions, although if it was a web shop, I'd have not asked the GIL/process questions. Also, I would have skipped the list implementation question, but that's personal taste.

m0nk3yz fucked around with this message at 03:55 on Aug 19, 2010

# ? Aug 19, 2010 03:35

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Lurchington posted:

Here's my interview whiteboard question from the yospos thread: link

questions that stood out, not exhaustive or anything:

On the phone, I was asked:

underlying structure of a python list in C - array of pointers

As a hobbyist programmer that item kind of stood out to me. Why would an employer care if you knew that? What problems does knowing that allow you to solve?

(The link you provided is broken)

# ? Aug 19, 2010 03:39

Lurchington: Jan 2, 2003; Forums Dragoon

Sorry about the link, I had to get it google cache. The answer is that a python list in cPython is an array of pointers.

Two guesses on the purpose of that question:
1) My particular resume showed formal education in computer science and for the era I was in school, that meant a fact check on C/C++
2) An underlying understanding of the cPython implementation of a common python data structure would imply that I would be able to program/structure efficiently. An understanding of the level below the abstraction was presented in this good Pycon talk: link

Understanding that it was an array meant that you'd know that appending to the list is cheap but adding an element in the middle was going to be a relatively expensive operation

I was asked the same question on the phone and in person

edit: fixed a broken link

Lurchington fucked around with this message at 13:36 on Aug 19, 2010

# ? Aug 19, 2010 04:21

Lurchington: Jan 2, 2003; Forums Dragoon

m0nk3yz posted:

Nice! And I'm oddly flattered you cited my talks Have you mentioned where you were interviewing - those are pretty good questions, although if it was a web shop, I'd have not asked the GIL/process questions. Also, I would have skipped the list implementation question, but that's personal taste.

PM sent in the actual company, but my from what I was told (interview conducted at a high level) was that it wasn't exclusively a web shop, and there whatever they were doing certainly leveraged threading/multiprocessing (and for that I'll thank your talk).

I talked a bit about the list implementation question on my previous post, but thinking about it more, maybe the job has a lot of writing in C extensions? And an understanding of the C implementation of a list would seem like the barrier to entry for going to that level.

Lurchington fucked around with this message at 13:37 on Aug 19, 2010

# ? Aug 19, 2010 04:45

king_kilr: May 25, 2007

Thermopyle posted:

As a hobbyist programmer that item kind of stood out to me. Why would an employer care if you knew that? What problems does knowing that allow you to solve?

(The link you provided is broken)

Well, it should tell you the expected complexity of any operation on it.

# ? Aug 19, 2010 04:47

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

Lurchington posted:

PM sent in the actual company, but my from what I was told (interview conducted at a high level) was that it wasn't exclusively a web shop, and there whatever they were doing certainly leveraged threading/multiprocessing (and for that I'll thank your talk).

I talked a bit about the list implementation question on my previous post, but thinking about it more, maybe the job has a lot of writing in C extensions? And an understanding of the C implementation of a list would seem like the barrier to entry for going to that level.

If they're doing a lot of concurrency, yeah - I'd put money on them using a lot of C/C extensions as well.

# ? Aug 19, 2010 17:01

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

king_kilr posted:

By comparison
code:
my_list.append(x)
will only need to allocate once every N (for some constant N) iterations.

I know this was a while back, but I want to be slightly pedantic here: N is not constant, it's well known, but certainly not constant, it has a behavior where smaller lists (IIRC < 100 elements) will double in size but larger lists approach a constant size increase. At least this is what I gathered from some optimization lecture given by either Guido or one of the core python devs.

# ? Aug 19, 2010 20:41

king_kilr: May 25, 2007

deimos posted:

I know this was a while back, but I want to be slightly pedantic here: N is not constant, it's well known, but certainly not constant, it has a behavior where smaller lists (IIRC < 100 elements) will double in size but larger lists approach a constant size increase. At least this is what I gathered from some optimization lecture given by either Guido or one of the core python devs.

It's probably raymond hettinger's talk from pycon 2008. 2nd comment in list_resize explains the pattern: http://svn.python.org/view/python/trunk/Objects/listobject.c?view=markup. It's still linear, as opposed to the quadratic rate you get when you copy every single addition.

# ? Aug 19, 2010 21:19

xPanda: Feb 6, 2003; Was that me or the door?

Is there a way to prevent assignment to names in __builtins__ ? Style guides basically say "don't do it", but I'm curious whether it's possible to run a simple function on assignment which checks to see whether the name is in __builtins__. I can't think of a way though, it seems like something which would have to be done in the implementation.

# ? Aug 20, 2010 01:14

tripwire: Nov 19, 2004; _{ghost flow}

xPanda posted:

Is there a way to prevent assignment to names in __builtins__ ? Style guides basically say "don't do it", but I'm curious whether it's possible to run a simple function on assignment which checks to see whether the name is in __builtins__. I can't think of a way though, it seems like something which would have to be done in the implementation.

Make sure none of your variable names get turned into the color for a keyword or builtin in your ide?

# ? Aug 20, 2010 01:16

xPanda: Feb 6, 2003; Was that me or the door?

tripwire posted:

Make sure none of your variable names get turned into the color for a keyword or builtin in your ide?

Haha, well yeah that's what I do and it works. I was trying to think how you would do it in the language itself.

# ? Aug 20, 2010 01:34

tripwire: Nov 19, 2004; _{ghost flow}

Well you can use data descriptors to override the way assignment works within a class. You could use something like "if var_name in dir(__builtins__): raise Exception('uh oh')". I'm not sure how you would do that at the top level though. Descriptor howto is here: http://docs.python.org/dev/howto/descriptor.html

tripwire fucked around with this message at 02:10 on Aug 20, 2010

# ? Aug 20, 2010 02:07

king_kilr: May 25, 2007

No. It is not technically possible to do so.

# ? Aug 20, 2010 02:22

hnc: Jul 1, 2010

This post is in regards to the PyWin32 extension for python and COM dlls.

I am apart of a game community where a member wrote a dll that hijacks memory of a chat program. The dll is used to create a chat bot, using VB, to do things... well things that a chat bot would do. I, however, would like to use this dll in python. I have my own chat bot using python, but the win32api is meh at best and the dll has a lot of features that my bot is still missing.

Using Dll Export Viewer, I have a list of functions. It has 4 exported functions (DllUnregisterSesrver, DllGetClassObject, DllRegisterServer, and DllCanUnloadNow), 1 COM Property, and 26 COM Methods. I can access the exported functions very easily using ctypes which, from my understanding, doesn't help me. Calling the COM methods is proving to be difficult however. After days of googling, I come here for answers.

How can I use ctypes or win32com to access these functions? I have the GUID of the dll because at some point I thought it might help (the dll is registered).

I have no idea how people figure these things out for themselves... Thanks in advance.

# ? Aug 20, 2010 08:27

KuruMonkey: Jul 23, 2004

Alright, I'm still steadily picking up Python at my own pace.

This is not expected behaviour in any language I've encountered before:

code:

>>> def monkey(a, b=[]):
...     b.append(a)
...     return b
...
>>> monkey('see')
['see']
>>> monkey('do')
['see', 'do']
>>> monkey('trouble', ['business'])
['business', 'trouble']
>>> monkey('confused')
['see', 'do', 'confused']

Someone care to explain / debunk / clarify / link to explanation of the (to my mind) "sometimes static, sometimes not" variable I've created there?

I'm guessing here, but when you specify "an empty list" as the default parameter there, in python you're actually specifying a specific list, that just happens to begin empty? (so how is it sometimes replaced with the one I send, but returns to the previous one when I don't send anything?)

see I'm used to (deep breath):

php:

<?
function monkey($a, $b=array())
{
 // any and every call, b will be what you send or an EMPTY ARRAY
 $b[] = $a;
 return $b;
}

// or

function static_monkey($a)
{
 static $b = array();
 $b[] = $a;
 return $b;
}
?>

I should point out that I'd merrily google this, except I've no idea what this feature / idiom might be called to go look it up!

# ? Aug 20, 2010 14:21

Threep: Apr 1, 2006; It's kind of a long story.

The default list is created when the function is parsed, but b only points to it when you don't specify another value. It's the whole "b is a reference to the list, not the list itself" deal.

This is a common way to solve it:

code:

def monkey(a, b=None):
    if b is None:
        b = []
    b.append(a)
    return b

# ? Aug 20, 2010 14:31

BigRedDot: Mar 6, 2008

KuruMonkey posted:

Someone care to explain / debunk / clarify / link to explanation of the (to my mind) "sometimes static, sometimes not" variable I've created there?

I'm guessing here, but when you specify "an empty list" as the default parameter there, in python you're actually specifying a specific list, that just happens to begin empty? (so how is it sometimes replaced with the one I send, but returns to the previous one when I don't send anything?)

Default arguments are only constructed once, when the function is defined, and that same object is used for every invocation. Changing default arguments is usually not what you want.

Edit: beaten!

# ? Aug 20, 2010 14:32

KuruMonkey: Jul 23, 2004

Threep posted:

The default list is created when the function is parsed, but b only points to it when you don't specify another value. It's the whole "b is a reference to the list, not the list itself" deal.

This is a common way to solve it:
code:
def monkey(a, b=None):
    if b is None:
        b = []
    b.append(a)
    return b

Thanks; I tried this:

code:

>>> def monkey(a, b=[]):
...     b.append(a)
...     return b
...
>>> c = monkey('test')
>>> monkey('again')
['test', 'again']
>>> c
['test', 'again']
>>> c.append('oh god')
>>> monkey('welp')
['test', 'again', 'oh god', 'welp']

and whats going on is a bit clearer now. Unusual, given my experience with other languages, but no-longer unpredictable

# ? Aug 20, 2010 14:39

ATLbeer: Sep 26, 2004; Über nerd

KuruMonkey posted:

Unusual, given my experience with other languages, but no-longer unpredictable

I think everyone who's every programmed in Python has been caught by that feature. You are not alone.

# ? Aug 20, 2010 18:47

Captain Capacitor: Jan 21, 2008; The code you say?

Threep posted:

The default list is created when the function is parsed, but b only points to it when you don't specify another value. It's the whole "b is a reference to the list, not the list itself" deal.

This is a common way to solve it:
code:
def monkey(a, b=None):
    if b is None:
        b = []
    b.append(a)
    return b

code:

def monkey(a, b=None):
    b = b if b else []
    b.append(a)
    return b

Just thought I'd chip in this syntax, since I've been trying to teach myself to use it as often as I can.

Edit: Fixed, but leaving up my old version so my mistake can be seen. It's syntactically the same as what Threep wrote, just slightly more compact.

code:

def monkey(a, b=None):
    b = [] if b is None else b
    b.append(a)
    return b

Captain Capacitor fucked around with this message at 22:08 on Aug 20, 2010

# ? Aug 20, 2010 21:43

king_kilr: May 25, 2007

Captain Capacitor posted:

code:
def monkey(a, b=None):
    b = b if b else []
    b.append(a)
    return b
Just thought I'd chip in this syntax, since I've been trying to teach myself to use it as often as I can.

Please don't, this can trivially fail:

code:

m = []
monkey("foo", m)
assert m == ["foo"]

# ? Aug 20, 2010 21:44

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

KuruMonkey posted:

code:

>>> def monkey(a, b=[]):
...     b.append(a)
...     return b
...
>>> monkey('see')
['see']
>>> monkey('do')
['see', 'do']
>>> monkey('trouble', ['business'])
['business', 'trouble']
>>> monkey('confused')
['see', 'do', 'confused']

That's fuuuuucked uuuuup.

This is not excusable :mad:

# ? Aug 21, 2010 02:55

king_kilr: May 25, 2007

Mr. Wynand posted:

That's fuuuuucked uuuuup.

This is not excusable

Uhh no, it's a perfect reasonable semantic, and there's 0 precedent in Python for evaluating something multiple times, besides function bodies. To evaluate function defaults would incur a fantastic overview.

# ? Aug 21, 2010 06:32

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

It only causes problems if you mutate things and mutation is the devil anyway.

# ? Aug 21, 2010 10:25

tripwire: Nov 19, 2004; _{ghost flow}

Mr. Wynand posted:

That's fuuuuucked uuuuup.

This is not excusable

Why? If you want a mutable object to use in a function, declare it in the function. Declaring a mutable object outside of a function and expecting it to behave like its brand new everytime a function is called seems a lot weirder to me.

# ? Aug 22, 2010 14:02

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

tripwire posted:

Why? If you want a mutable object to use in a function, declare it in the function. Declaring a mutable object outside of a function and expecting it to behave like its brand new everytime a function is called seems a lot weirder to me.

I dunno it's probably because of my non-python background but i really would expect default argument expressions to essentially be moved inside the function body for me and get re-initialized each call.

I can tell you from experience that in ruby it's drat common to simply declare array or dict arguments as having empty defaults in the arg definition and simply build on them inside the function. It's certainly a much more common need then wanting early bound args...

# ? Aug 22, 2010 18:13

ShoulderDaemon: Oct 9, 2003; support goon fund; Taco Defender

Mr. Wynand posted:

I dunno it's probably because of my non-python background but i really would expect default argument expressions to essentially be moved inside the function body for me and get re-initialized each call.

I can tell you from experience that in ruby it's drat common to simply declare array or dict arguments as having empty defaults in the arg definition and simply build on them inside the function. It's certainly a much more common need then wanting early bound args...

Yeah, as a mostly-non-python-programmer it's completely nonintuitive that these two loops are different:

code:

def add( x, l=[] ):
  l.append( x )
  print( l )

print( "Explicit argument:" )

for i in [1, 2, 3, 4, 5]:
  add( i, [] )

print( "Default argument:" )

for i in [1, 2, 3, 4, 5]:
  add( i )

I would naturally expect any default parameters of the add function to be scoped to the inside of the add function. I could remotely understand them taking the calling scope of the add function instead. Taking global scope seems extremely surprising to me, and if you're doing any mutation whatsoever it seems like it only serves to reduce the utility of default parameters without any real gain.

# ? Aug 22, 2010 18:29

tef: May 30, 2004; -> some l-system crap ->

Yeah but it isn't going to change in python any time soon.

You could have a decorator that did the right thing

code:

def defaultargs(**defargs):
    def decorator(f):
        def wrapped(*args,**kwargs):
            names = f.func_code.co_varnames[:len(args)]
            for k,v in defargs.iteritems():
                if k not in kwargs and k not in names:
                    kwargs[k]=v()
                return f(*args,**kwargs)
        return wrapped
    return decorator


@defaultargs(l=list)
def add(x,l):
    l.append(x)
    print l

print( "Explicit argument:" )

for i in [1, 2, 3, 4, 5]:
  add( i, [] )

print( "Default argument:" )

for i in [1, 2, 3, 4, 5]:
  add( i )

For the record I think it's a design mistake personally :3:

tef fucked around with this message at 18:49 on Aug 22, 2010

# ? Aug 22, 2010 18:45

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Yeah I mean it's cool, once you know about it you just keep an eye out for it and know how to avoid any problems. It's easy enough to understand.

But I don't have to like it :colbert:

.

Also the fact that not all statements are value-returning expression. Is it really just to avoid writing/reading "if a = foo" instaed of "if a == foo" ? C'mon Guido, relax a little.

# ? Aug 22, 2010 18:50

tef: May 30, 2004; -> some l-system crap ->

Mr. Wynand posted:

Also the fact that not all statements are value-returning expression. Is it really just to avoid writing/reading "if a = foo" instaed of "if a == foo" ? C'mon Guido, relax a little.

Thing is, this is a bit of a grammar restriction. Python's whitespace style doesn't lead itself to easy embedding within other expressions. I.e, how would you have a multiline if statement inside a function call. or inside an if condition? It kinda goes against the grain of the language I guess.

# ? Aug 22, 2010 18:57

Adbot: ADBOT LOVES YOU

# ? May 24, 2024 14:11

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

Mr. Wynand posted:

Also the fact that not all statements are value-returning expression. Is it really just to avoid writing/reading "if a = foo" instaed of "if a == foo" ? C'mon Guido, relax a little.

If it's a common-enough mistake that if (0 == foo) is a common-enough C idiom...

# ? Aug 22, 2010 18:58

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

«‹›484 »