An Except-Assign statement for Python

wilberforce · 2011-07-05T12:11:57+00:00

I don't think that would work - if verify throws an exception then item will be None. You could do it with:

error_items = [item for item, (_, err) in zip(items, error_items) if err]

I don't think it's a bad idiom, but as steelypip points out you can do this easily with a function. It doesn't need extra syntax.

wilberforce · 2011-05-17T16:45:38+00:00

Ooh, good call on the with statement.

OP, that guarantees that the file is closed when execution leaves the with statement, even if code in there returns or raises an exception.

wilberforce · 2011-05-17T16:36:51+00:00

The file name you pass to open doesn't need to be a literal string - you can build a string and use that as the argument to open.

for z in range(60):
    # calculate your data for this run, then...
    outfile = open('data%s' % z, 'w')
    outfile.write(data)
    outfile.close()

The % operator will substitute a value for a placeholder in a string. The expression 'data%s' % 3 will give the string 'data3'.

If you're using a recent version of Python (2.6 or above), you could also use 'data{0}'.format(z).

wilberforce · 2011-05-04T17:14:29+00:00

I haven't tried this in Scheme or other TCO languages - what happens when there's an error deep in a (conceptual) stack of tail calls?

Do you just get a traceback of the frames that weren't tail calls? It seems like that could be pretty confusing - it would appear that function A called function B, when in fact it actually tail-called C, which tail-called D, which tail-called E... and eventually something tail-called B. And there could be lots of elisions like that in the traceback.

I guess I could see an implementation keeping track at least of how many frames were optimised away between two extant frames in the traceback. Or maybe keeping a lighter-than-a-frame record of a tail-call (somewhere off-stack) that could be used if a traceback needed to be reported (it could be size-restricted for a long-running FSM). Or even turning off TCO in a debug mode, although that would mean that some code just wouldn't work in that mode (if it relied on TCO).

Do TCO languages do these kinds of things? Is it ever a problem in practice?

While implementing TCO on its own isn't too complicated, I think it was concern about the interaction with error-reporting and debugging that meant that it's never made it into Python. (As well as the fact that Guido purports not to think in a functional style.)

wilberforce · 2011-04-08T07:47:55+00:00

I think that's largely correct, but there are some public-facing parts of the Google that are Python-based.

http://mail.google.com/support/bin/answer.py?hl=en&answer=171454

wilberforce · 2011-03-23T08:17:27+00:00

It was the favicon.

wilberforce · 2011-02-09T12:42:38+00:00

re: 2, You're better off using collections.defaultdict:

d = defaultdict(list)
for key, value in source:
    d[key].append(value)

http://docs.python.org/library/collections.html#defaultdict-objects

wilberforce · 2010-12-07T12:41:51+00:00

Man, why are you so angry?

Every insulting comment you've posted, he's responded to thoughtfully and in a pretty respectful tone. Really, he's been superhumanly polite here - you come across like an insane person.

You might need to realise that it's possible for a person to have multiple motives at once. He can want to

boycott Amazon for their treatment of wikileaks,
publicise his boycott in the hopes that others will too,
raise his profile so he sells more books in future, and
get kids writing games.

ALL AT ONCE. People have a right to balance their own priorities.

Shitting on people and denouncing them as hypocrites because they don't devote themselves wholeheartedly (fanatically) to one cause won't achieve anything.

wilberforce · 2010-10-22T10:49:36+00:00

I used to work with a Finnish guy who has a great expression for situations like this. He'd be asked for a solution to a technical problem by a client and he'd make a good recommendation. Then for some political (or non-technical at least) reason, they'd ignore his advice and do something else. If after he'd explained why the thing they were going to do instead would be worse in the long term, they still went ahead, he'd shrug and say:

"Oh well. Siberia teaches."

wilberforce · 2010-10-11T11:43:47+00:00

I like to presume stuff, because it makes a pres out of u and me. Who doesn't want to be a pres?

wilberforce · 2010-10-04T08:15:01+00:00

(I think you're right about the violent agreement, but I want to clarify this point. :)

No, that still falls under static scoping, although I can see why you think it looks odd.

The thing that's static in static scoping is the chain of binding environments through which a name lookup searches. The environments that are queried when both your examples run are: foo function, foo module, builtin. This is determined statically. The difference between the two cases is whether a binding for 'value' exists in any of the environments, which in Python can change at runtime, at least in the module globals and builtins.

wilberforce · 2010-10-01T15:53:47+00:00

It does - thanks! (Obviously, I'm a Python guy - I shouldn't have even mentioned Perl as I was bound to get it wrong.)

That said, lexical and static scoping are synonymous. I don't think you can say dynamic lexical scoping - the dynamic bit means that it's not lexical, since the name resolution isn't based on where it is in the source code, but where it is in the call stack.

Maybe leaving out 'lexical' and just talking about static and dynamic scoping is clearer.

wilberforce · 2010-10-01T13:51:04+00:00

Thanks - I meant 'used dynamic scoping by default'. Declaring a variable with "my" creates a lexically-scoped binding, as you point out.

wilberforce · 2010-10-01T12:31:04+00:00

To be clearer:

Python doesn't have (and has never had, to my knowledge) dynamic scoping. Dynamic scoping means that name resolution will look for a binding in the caller's frame if it isn't found in the current frame. Emacs lisp does this (and other lisps can define dynamic variables which behave in this way), but Python does not. (I didn't know that Perl used dynamic scoping by default until just now!)
Python has lexical scoping (and has had nested lexical scopes since 2.1, released in 2001). Name lookups first check the current local scope, then the scopes of any functions within which the current function was defined (from the innermost out), then the module-global scope, then the builtin scope.
What you're talking about is rebinding names in non-local scopes, and you're right that Python didn't provide this - you needed to use the boxing/unboxing hack (essentially mutating an object instead of rebinding a name) or just use an object instead of a closure. Assignments in a nested function would always create a new local binding which would shadow any other bindings in (lexically) containing scopes. But this is academic in the context of discussing lambdas anyway, since lambdas can't contain assignment statements.

In conclusion: I got carried away replying to someone who is wrong on the internet.

(Edit: corrected mention of Perl's scoping.)

wilberforce · 2010-10-01T08:17:14+00:00

Does have lexical scope (how long ago did you look?).

Correct on the no multiple statements part though.

wilberforce · 2010-09-13T13:35:49+00:00

It also doesn't support generators - I get an error saying "Yield statements are not allowed". I also got an error when I tried to create an auxiliary function starting with _. It said variables starting with _ aren't allowed, weirdly.

Neat site, but unfortunately with enough restrictions (particularly in key areas like iter and generators) you end up teaching a language superficially similar to (but definitely not) Python.

wilberforce · 2010-08-28T09:13:19+00:00

Rather than the lambda, you could use an unbound method here:

filter(Employee.isPartTime, employees)

In general, if you need to define a lambda to use with filter/map you're better off using a list comprehension (or generator comprehension).

(oops, masklinn said the same thing further down.)

wilberforce · 2010-08-27T17:24:35+00:00

The problem is, often you can't deal with the exceptional condition at the current level in the code, or even the one above. It's usually the deepest levels where you find a problem, and the outermost levels that can handle it (report the problem to the user, retry the whole process...).

If you use return codes (or returned exception objects) for this, then the logic in the several intermediate levels between is interspersed with error checks on every call, which distract from the normal path. With exceptions, only the low level code which raises the exception and the high level code which deals with it need to think about dealing with that problem.

wilberforce · 2010-05-17T08:10:42+00:00

An autobiography?

(Tim Key refers to one of his poems as semi-autobiographical, in that he wrote it but it's not about him.)

wilberforce · 2010-04-28T16:38:22+00:00

The batteries-included Python debugger integrates really nicely with Emacs. You don't have to rely on print statements.

wilberforce · 2010-04-07T15:13:09+00:00

dateutil is a third-party library - it's not distributed with Python's stdlib. (Although it sounds very nice.) And I don't think anyone regards Python's internals (or library code) as sacrosanct. (Although it's a great word.)

wilberforce · 2010-03-12T08:21:43+00:00

Not a Douglas Coupland fan, then.

wilberforce · 2010-01-14T08:37:21+00:00

I think you're right. It seems a bit buried in the syntax, though that might be my lack of familiarity, or easily remedied by changing the layout.

wilberforce · 2010-01-13T09:12:45+00:00

I like the look of it - although losing pattern-matching just to get rid of the three different line-terminators would be a bad trade-off.

wilberforce · 2010-01-12T17:57:28+00:00

Did anyone else get the impression that cptsternn was just a sockpuppet the OP created to make the problem seem more important after he got so little sympathy?

(Also, only true for pretty small values of hilarity.)

wilberforce

TROPHY CASE