I'm using the regular expression from http://effbot.org/zone/re-common-log-format.htm. I have a problem with it, though: I have some lines in my Apache log which contain something of the form "GET /\" HTTP/1.1". So they have a " which is kind of 'escaped' by a \. I was trying to change the regex to take this into account, but I've come up dry... Here are some things I tried:

' "((?:(?:[^"])|(?:\\"))*)" ' (matching w/ non-matching groups)
' "([^"(?:\\")]*)" ' (non-matching group inside character class)
' "([^"]*)(?<!\\\)" ' (negative lookbehind assertion)

Some friends proposed this:

' "([^"]*(?<!\\\\)(\\\\(\\\\\\\\)*"[^"]*)*)" '

But it's both monstrous and fails in the case of more \"\" things...

I was wondering if you have any suggestions? (And kind of reporting a 'bug', I guess.)

For the switch statement, how about:

given foo as bar:
when baz:
    do_1(bar)
when qux, quux: #checks if bar == either qux or quux
    do_2(bar)

I think this is one time perl got it right, at least in the naming.

I really like you idea for 'static'.

For the switch statement, instead of only "in" as a case operator I'd like to see that generalized to allow any comp_operator., with a default of '==':

switch my_number:
    case < 5:
        foo()
    case > 10:
        bar()
    else:
        baz()

In particular, this would also allow "is" which is slightly different than "==".

I skimmed the python-dev thread and see that requiring an operator was suggested but considered aesthetically unpleasing. I was suggesting it be optional by defaulting to '=='. I don't have the bandwidth to add to a thread of that size, though ;)

Consider:
switch x :
case in static DIGITS :
    <block>
case in static ALPHABETS :
    <block>

Would this get optimized to a single table/dict lookup based dispatch? If it does, then what are the restrictions on DIGITS/ALPHABETS for optimizability?

"Would this get optimized to a single table/dict lookup based dispatch?"

Yes, as long as DIGITS and ALPHABETS are tuples (or any other "frozen" container type known by the optimizer), and all their members are strings (or any other hashable type known by the optimizer).

For example,

    case in static tuple(string.digits):
        ...

would be possible to optimize, but

    case in static string.digits:
        ...

wouldn't. In case of overlaps, the first matching case (in lexical order) wins.

I would like a real switch statement. Even Bertrand Meyer finally gave in and added on to Eiffel years ago. Switch statements allow me to quickly understand one expression controls the block. if...elif... blocks require me to read each and every expression to see if someone has added/subtracted variable names, etc.

if a < 5 ... elif A > 5 (whoops or maybe correct) ... elif c != d ...
is not a switch statement but

if a < 5 ... elif a == 5 else ...
is but one has to read all the expressions to determine the difference.
A switch add so much visual information like if, while and for added even though gotos got the job done in the early days.

I like the "as var" option on the switch statement!

While you are proposing PEPs (and since you are a bot with clout) why not add that same option to if, elif (?), and while? It will make converted C programmers happier as they miss assigning to a variable in a flow control expression evaluation.

An example:

mob = re.search(...)
if mob:
   a = mob.groups(1)
   ...

would become
if re.search(...) as mob:
   a = mob.groups(1)
   ...

Isn't running eval() on some random piece of data from the net a bit of a security risk?