> > do:
> >
> > until
> >
> > Written like this it is not very obvious that the 'unil' is part of
> > the do-until suite. I also imagine it to be difficult to parse and it
> > breaks the rule that suites end when there is a dedentation. So, IMHO
> > using an indented 'until' is the least evil
> > >>do:
> > >>
> > >>until
> > >>
> > >>But I'm sure that has problems too.
> > >
> [Raymond Hettinger]
> > > That looks nice to me.
>
> [Nick Coghlan]
> > And this could easily be extended to allow code both before and after
> > the 'until', giving a fully general loop:
> >
> >do:
> > Guido> How many try/finally statements have you written inside a loop?
> > Guido> In my experience this is extrmely rare. I found no
> > Guido> occurrences in the standard library.
>
> [Skip again]
> > How'd we start talking about try/finally?
>
> Because it provides by far th
> RSMotD (random stupid musing of the day): so I wonder if the decorator
> syntax couldn't be extended for this kind of thing.
>
> @acquire(myLock):
> code
> code
> code
Would it be useful for anything other than mutex-locking? And wouldn't
it be better to make a function of the block
Not sure this is pertinent but anyway: "any" and "all" are often used
as variable names. "all" especially often and then almost always as a
list of something. It would not be good to add "all" to the list of
words to watch out for. Also, "all" is usually thought of as a list of
(all) things. In my
I would LOVE for **kwargs to be an ordered dict. It would allow me to
write code like this:
.class MyTuple:
.def __init__(self, **kwargs):
.self.__dict__ = ordereddict(kwargs)
.
.def __iter__(self):
.for k, v in self.__dict__.items():
.yield v
.
.t = MyTuple(r =
