[Python-Dev] Re: Re: anonymous blocks
Shane Hathaway wrote: Brian's suggestion makes the code read more like an outline. In Brian's example, the high-level intent stands out from the details that assumes that when you call a library function, the high-level intent of *your* code is obvious from the function name in the library, and to some extent, by the argument names chosen by the library implementor. I'm not so sure that's always a valid assumption. while in your example, there is no visual cue that distinguishes the details from the intent. carefully chosen function names (that you chose yourself) plus blank lines can help with that. Of course, lambdas are even better, when it's possible to use them: doFoo((lambda a, b: a + b), (lambda c, d: c + d)) that only tells you that you're calling "doFoo", with no clues whatsoever to what the code in the lambdas are doing. keyword arguments are a step up from that, as long as your intent matches the library writers intent. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: anonymous blocks
Josiah Carlson wrote: See the previous two discussions on thunks here on python-dev, and notice how the only problem that seem bettered via blocks/thunks /in Python/ are those which are of the form... #setup try: block finally: #finalization ... and depending on the syntax, properties. I once asked "Any other use cases for one of the most powerful features of Ruby, in Python?" I have yet to hear any sort of reasonable response. Why am I getting no response to my question? Either it is because I am being ignored, or no one has taken the time to translate one of these 'killer features' from Smalltalk or Ruby, or perhaps such translations show that there is a better way in Python already. for my purposes, I've found that the #1 callback killer in contemporary Python is for-in:s support for the iterator protocol: instead of def callback(x): code dosomething(callback) or with the "high-level intent"-oriented syntax: dosomething(**): def libraryspecifiedargumentname(x): code I simply write for x in dosomething(): code and get shorter code that runs faster. (see cElementTree's iterparse for an excellent example. for typical use cases, it's nearly three times faster than pyexpat, which is the fastest callback-based XML parser we have) unfortunately, def do(): print "setup" try: yield None finally: print "tear down" doesn't quite work (if it did, all you would need is syntactic sugar for "for dummy in"). PS. a side effect of the for-in pattern is that I'm beginning to feel that Python might need a nice "switch" statement based on dictionary lookups, so I can replace multiple callbacks with a single loop body, without writing too many if/elif clauses. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proper place to put extra args for building
Brett C. wrote: > I am currently adding some code for a Py_COMPILER_DEBUG build for use on the > AST branch. I thought that OPT was the proper variable to put stuff like this > into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall > -Wstrict-prototypes``. Obviously I could just tack all of that into my own > thing, but that seems like an unneeded step. Actually, this step is needed. >>From looking at Makefile.pre.in it seems like CFLAGSFORSHARED is meant for > extra arguments to the compiler. Is that right? No. This is the set of flags to be passed to the compiler when compiling with --enable-shared. It is set in configure.in. It might be reasonable to add a variable that will just take additional compiler flags, and never be modified in configure. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
On 4/19/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Well, one obvious use might be, say:
>
> @withfile('foo.bar', 'r'):
> content = thefile.read()
>
> but that would require the decorator and block to be able to interact
> in some way, so that inside the block 'thefile' is defined suitably.
>
> > it be better to make a function of the block wrapped in a
> > block-decorator and then use a normal decorator?
>
> From a viewpoint of namespaces, I think it would be better to have the
> block execute in the same namespace as the code surrounding it, not a
> separate one (assigning to 'content' would not work otherwise), so a
> nested function would not be all that useful. The problem might be,
> how does the _decorator_ affect that namespace. Perhaps:
>
> def withfile(filename, mode='r'):
> openfile = open(filename, mode)
> try:
> block(thefile=openfile)
> finally:
> openfile.close()
>
> i.e., let the block take keyword arguments to tweak its namespace (but
> assignments within the block should still affect its _surrounding_
> namespace, it seems to me...).
I'm not a big fan of this means of tweaking the block's namespace. It
means that if you use a "block decorator", you might find that names
have been 'magically' added to your namespace. This has a bad code
smell of too much implicitness to me...
I believe this was one of the reasons Brian Sabbey's proposal looked
something like:
do in = ():
This way you could write the block above as something like:
def withfile(filename, mode='r'):
def _(block):
openfile = open(filename, mode)
try:
block(openfile)
finally:
openfile.close()
return _
do thefile in withfile('foo.bar', 'r'):
content = thefile.read()
where 'thefile' is explicitly named in the do/in-statement's unpack
list. Personally, I found the 'do' and 'in' keywords very confusing,
but I do like the fact that the parameters passed to the thunk/block
are expanded in an explicit unpack list. Using @, I don't see an easy
way to insert such an unpack list...
Of course, even with the unpack list, you still have to know what kind
of arguments the function calls your block with. And because these
only appear within the code, e.g.
block(openfile)
you can't rely on easily accessible things like the function's
signature. It means that unlike other callables that can basically
document parameters and return type, "block decorators" would have to
document parameters, return type, and the parameters with which they
call the block...
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
*If* we're going to create syntax for anonymous blocks, I think the primary use case ought to be cleanup operations to replace try/finally blocks for locking and similar things. I'd love to have syntactical support so I can write I heartily agree! Especially when you have very similar try/finally code you use in many places, and wish to refactor it into a common area. If this is done, you are forced into a callback form like follows:: def withFile(filename, callback): aFile = open(filename, 'r') try: result = callback(aFile) finally: aFile.close() return result class Before: def readIt(self, filename): def doReading(aFile): self.readPartA(aFile) self.readPartB(aFile) self.readPartC(aFile) withFile(filename, doReading) Which is certainly functional. I actually use the idiom frequently. However, my opinion is that it does not read smoothly. This form requires that I say what I'm doing with something before I know the context of what that something is. For me, blocks are not about shortening the code, but rather clarifying *intent*. With this proposed change, the code becomes:: class After: def readIt(self, filename): withFile(filename): self.readPartA(aFile) self.readPartB(aFile) self.readPartC(aFile) In my opinion, this is much smoother to read. This particular example brings up the question of how arguments like "aFile" get passed and named into the block. I anticipate the need for a place to put an argument declaration list. ;) And no, I'm not particularly fond of Smalltalk's solution with "| aFile |", but that's just another opinion of aesthetics. Another set of question arose for me when Barry started musing over the combination of blocks and decorators. What are blocks? Well, obviously they are callable. What do they return? The local namespace they created/modified? How do blocks work with control flow statements like "break", "continue", "yield", and "return"? I think these questions have good answers, we just need to figure out what they are. Perhaps "break" and "continue" raise exceptions similar to StopIteration in this case? As to the control flow questions, I believe those answers depend on how the block is used. Perhaps a few different invocation styles are applicable. For instance, the method block.suite() could return a tuple such as (returnedValue, locals()), where block.__call__() would simply return like any other callable. It would be good to figure out what the control flow difference is between:: def readAndReturn(self, filename): withFile(filename): a = self.readPartA(aFile) b = self.readPartB(aFile) c = self.readPartC(aFile) return (a, b, c) and:: def readAndReturn(self, filename): withFile(filename): a = self.readPartA(aFile) b = self.readPartB(aFile) c = self.readPartC(aFile) return (a, b, c) Try it with yield to further vex the puzzle. ;) Thanks for your time! -Shane Holloway ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Michael Walter <[EMAIL PROTECTED]> wrote: > > On 4/19/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > > 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 wrapped in a > > block-decorator and then use a normal decorator? > > Yes. Check how blocks in Smalltalk and Ruby are used for starters. See the previous two discussions on thunks here on python-dev, and notice how the only problem that seem bettered via blocks/thunks /in Python/ are those which are of the form... #setup try: block finally: #finalization ... and depending on the syntax, properties. I once asked "Any other use cases for one of the most powerful features of Ruby, in Python?" I have yet to hear any sort of reasonable response. Why am I getting no response to my question? Either it is because I am being ignored, or no one has taken the time to translate one of these 'killer features' from Smalltalk or Ruby, or perhaps such translations show that there is a better way in Python already. Now, don't get me wrong, I have more than a few examples of the try/finally block in my code, so I would personally find it useful, but just because this one pattern is made easier, doesn't mean that it should see syntax. - Josiah P.S. If I'm sounding like a broken record to you, don't be surprised. But until my one question is satisfactorally answered, I'll keep poking at its soft underbelly. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: anonymous blocks
Fredrik Lundh wrote: > Brian Sabbey wrote: >> doFoo(**): >> def func1(a, b): >> return a + b >> def func2(c, d): >> return c + d >> >> That is, a suite can be used to define keyword arguments. > > > umm. isn't that just an incredibly obscure way to write > >def func1(a, b): >return a + b >def func2(c, d): >return c + d >doFoo(func1, func2) > > but with more indentation? Brian's suggestion makes the code read more like an outline. In Brian's example, the high-level intent stands out from the details, while in your example, there is no visual cue that distinguishes the details from the intent. Of course, lambdas are even better, when it's possible to use them: doFoo((lambda a, b: a + b), (lambda c, d: c + d)) Shane ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
On Apr 19, 2005, at 15:57, BJörn Lindqvist wrote:
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
Well, one obvious use might be, say:
@withfile('foo.bar', 'r'):
content = thefile.read()
but that would require the decorator and block to be able to interact
in some way, so that inside the block 'thefile' is defined suitably.
it be better to make a function of the block wrapped in a
block-decorator and then use a normal decorator?
From a viewpoint of namespaces, I think it would be better to have the
block execute in the same namespace as the code surrounding it, not a
separate one (assigning to 'content' would not work otherwise), so a
nested function would not be all that useful. The problem might be,
how does the _decorator_ affect that namespace. Perhaps:
def withfile(filename, mode='r'):
openfile = open(filename, mode)
try:
block(thefile=openfile)
finally:
openfile.close()
i.e., let the block take keyword arguments to tweak its namespace (but
assignments within the block should still affect its _surrounding_
namespace, it seems to me...).
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
On 4/19/05, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > > 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 wrapped in a > block-decorator and then use a normal decorator? Yes. Check how blocks in Smalltalk and Ruby are used for starters. Regards, Michael ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
On Tue, Apr 19, 2005 at 01:33:15PM -0700, Guido van Rossum wrote: > > @acquire(myLock): > > code > > code > > code > > It would certainly solve the problem of which keyword to use! :-) And > I think the syntax isn't even ambiguous -- the trailing colon > distinguishes this from the function decorator syntax. I guess it > would morph '@xxx' into "user-defined-keyword". > > How would acquire be defined? I guess it could be this, returning a > function that takes a callable as an argument just like other > decorators: [snip] > and the substitution of > > @EXPR: > CODE > > would become something like > > def __block(): > CODE > EXPR(__block) > > I'm not yet sure whether to love or hate it. :-) > I don't know what the purpose of these things is, but I do think they should be like something else to avoid learning something new. Okay, I lied, I do know what these are: "namespace decorators" Namespaces are currently modules or classes, and decorators currently apply only to functions. The dissonance is that function bodies are evaluated later and namespaces (modules and classes) are evaluated immediately. I don't know if adding a namespace that is only evaluated later makes sense. It is only an extra case but it is one extra case to remember. At best I have only channeled Guido once, and by accident[1] so I'll stay out of the specifics (for a bit). -jackdied [1] during the decorator syntax bru-ha-ha at a Boston PIG meeting I suggested Guido liked the decorator-before-function because it made more sense in Dutch. I was kidding, but someone who knows a little Dutch (Deibel?) stated this was, in fact, the case. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
I apologize for sparking such debate on this list instead of on
c.l.py. By the way, the only reason I brought this up was as a
replacement for lambdas in Py3K.
Guido, in response to your much earlier comment about supporting "{}"
for normal defs as a matter of consistency within my proposal, yes, I
agree. Just like ";", you should rarely use them.
Best Regards,
-jj
On 4/19/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:00 PM 04/19/2005 -0700, Guido van Rossum wrote:
> > > Interestingly, this syntax also works to do decoration, though it's not a
> > > syntax that was ever proposed for that. e.g.:
> > >
> > > foo = classmethod(foo) where:
> > > def foo(cls,x,y,z):
> > > # etc.
> >
> >This requires you to write foo three times, which defeats at least
> >half of the purpose of decorators.
>
> Well, you could do 'foo = classmethod(x) where: def x(...)', but that *is*
> kind of kludgy. I'm just suggesting that if 'where:' had existed before
> decorators, people might have griped about the three-time typing or kludged
> around it, but there wouldn't likely have been strong support for creating
> a syntax "just" for decorators.
>
> Indeed, if somebody had proposed this syntax during the decorator debates I
> would have supported it, but of course Bob Ippolito (whose PyObjC use cases
> involve really long function names) might have disagreed.
>
>
> > > foo = property(get_foo,set_foo) where:
> > > def get_foo(self):
> > > # ...
> > > def set_foo(self):
> > > # ...
> > >
> > > I don't mind @decorators, of course, but maybe they wouldn't be needed
> > here.
> >
> >As I said before, I'm not sure why keeping get_foo etc. out of the
> >class namespace is such a big deal.
>
> That's a relatively minor thing, compared to being able to logically group
> them with the property, which I think enhances readability, even more than
> the sometimes-proposed '@property.getter' and '@property.setter' decorators.
>
> Anyway, just to be clear, I don't personally think 'where:' is needed in
> Python 2.x; lambda and decorators suffice for all but the most Twisted use
> cases. ;) I was just viewing it as a potential alternative to lambda in
> Py3K.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jjinux%40gmail.com
>
--
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
At 01:00 PM 04/19/2005 -0700, Guido van Rossum wrote: > Interestingly, this syntax also works to do decoration, though it's not a > syntax that was ever proposed for that. e.g.: > > foo = classmethod(foo) where: > def foo(cls,x,y,z): > # etc. This requires you to write foo three times, which defeats at least half of the purpose of decorators. Well, you could do 'foo = classmethod(x) where: def x(...)', but that *is* kind of kludgy. I'm just suggesting that if 'where:' had existed before decorators, people might have griped about the three-time typing or kludged around it, but there wouldn't likely have been strong support for creating a syntax "just" for decorators. Indeed, if somebody had proposed this syntax during the decorator debates I would have supported it, but of course Bob Ippolito (whose PyObjC use cases involve really long function names) might have disagreed. > foo = property(get_foo,set_foo) where: > def get_foo(self): > # ... > def set_foo(self): > # ... > > I don't mind @decorators, of course, but maybe they wouldn't be needed here. As I said before, I'm not sure why keeping get_foo etc. out of the class namespace is such a big deal. That's a relatively minor thing, compared to being able to logically group them with the property, which I think enhances readability, even more than the sometimes-proposed '@property.getter' and '@property.setter' decorators. Anyway, just to be clear, I don't personally think 'where:' is needed in Python 2.x; lambda and decorators suffice for all but the most Twisted use cases. ;) I was just viewing it as a potential alternative to lambda in Py3K. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proper place to put extra args for building
I am currently adding some code for a Py_COMPILER_DEBUG build for use on the AST branch. I thought that OPT was the proper variable to put stuff like this into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall -Wstrict-prototypes``. Obviously I could just tack all of that into my own thing, but that seems like an unneeded step. >From looking at Makefile.pre.in it seems like CFLAGSFORSHARED is meant for extra arguments to the compiler. Is that right? And I will document this in Misc/Specialbuilds.txt to fix my initial blunderous checkin of specifying OPT (or at least clarifying it). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
> 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 wrapped in a block-decorator and then use a normal decorator? -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Re: anonymous blocks
Fredrik Lundh wrote: Brian Sabbey wrote: If suites were commonly used as above to define properties, event handlers and other callbacks, then I think most people would be able to comprehend what the first example above is doing much more quickly than the second. wonderful logic, there. good luck with your future adventures in language design. I'm just trying to help python improve. Maybe I'm not doing a very good job, I don't know. Either way, there's no need to be rude. If I've broken some sort of unspoken code of behavior for this list, then maybe it would be easier if you just 'spoke' it (perhaps in a private email or in the description of this list on python.org). I'm not sure what your point is exactly. Are you saying that any language feature that needs to be commonly used to be comprehendible will never be comprehendible because it will never be commonly used? If so, then I do not think you have a valid point. I never claimed that keyword suites *need* to be commonly used to be comprehendible. I only said that if they were commonly used they would be more comprehendible than the alternative. I happen to also believe that seeing them once or twice is enough to make them about equally as comprehendible as the alternative. -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
[Guido van Rossum] > @EXPR: > CODE > > would become something like > > def __block(): > CODE > EXPR(__block) > > I'm not yet sure whether to love or hate it. :-) Is it preferable for CODE to execute in its own namespace (the above being a literal translation of the given code), or for it to execute in the originally defined namespace? Deferring to Greg Ewing for a moment [1]: They should be lexically scoped, not dynamically scoped. Wrapped blocks in an old namespace, I believe, is the way to go, especially for things like... @synchronize(fooLock): a = foo.method() I cannot come up with any code for which CODE executing in its own namespace makes sense. Can anyone else? - Josiah [1] http://mail.python.org/pipermail/python-dev/2005-March/052239.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Guido van Rossum wrote: Why not have the block automatically be inserted into acquire's argument list? It would probably get annoying to have to define inner functions like that every time one simply wants to use arguments. But the number of *uses* would be much larger than the number of "block decorators" you'd be coding. If you find yourself writing new block decorators all the time that's probably a sign you're too much in love with the feature. :-) Ok, but in explanations of how to use such blocks, they appear about equally often. They will therefore seem more difficult to use than they have to. I don't like implicit modifications of argument lists other than by method calls. It's okay for method calls because in the x.foo(a) <==> foo(x, a) equivalence, x is really close to the beginning of the argument list. There is a rough equivalence: @foo(x): block <==> @foo(block, x) Of course, the syntax does not allow such an equivalence, but conceptually it's there. To improve the appearance of equivalence, the block could be made the last element in the argument list. And your proposal would preclude parameterless block decorators (or turn them into an ugly special case), which I think might be quite useful: @forever: infinite loop body @ignore: not executed at all @require: assertions go here and so on. (In essence, we're inventing the opposite of "barewords" in Perl here, right?) I don't understand this. Why not: @forever(): infinite loop body etc.? The same is done with methods: x.foo() (or am I missing something?). I actually prefer this because using '()' make it clear that you are making a call to 'forever'. Importantly, 'forever' can throw exceptions at you. Without the '()' one does not get this reminder. I also believe it is more difficult to read without '()'. The call to the function is implicit in the fact that it sits next to '@'. But, again, if such argument list augmentation were done, something other than '@' would need to be used so as to not conflict with function decorator behavior. -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Guido van Rossum wrote: As I said before, I'm not sure why keeping get_foo etc. out of the class namespace is such a big deal. In fact, I like having them there (sometimes they can even be handy, e.g. you might be able to pass the unbound get_foo method as a sort key). Not to mention that it's possible to override get_foo in subclasses if done right ... Two approaches are here: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/408713 Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Guido van Rossum wrote:
But what exactly are you trying to accomplish here? I think that
putting the defs *before* the call (and giving the anonymous blocks
temporary local names) actually makes the code clearer:
I'm afraid that 'block1', 'block2', and 'doFoo' aren't really making
anything clear for me - can you show a slightly more concrete example?
def block1(a, b):
return a + b
def block2(c, d):
return c + d
items.doFoo(block1, block2)
Despite being guilty of propagating this style for years myself, I have
to disagree. Consider the following network-conversation using Twisted
style (which, I might add, would be generalizable to other Twisted-like
systems if they existed ;-)):
def strawman(self):
def sayGoodbye(mingleResult):
def goAway(goodbyeResult):
self.loseConnection()
self.send("goodbye").addCallback(goAway)
def mingle(helloResult):
self.send("nice weather we're having").addCallback(sayGoodbye)
self.send("hello").addCallback(mingle)
On the wire, this would look like:
> hello
< (response) hello
> nice weather we're having
< (response) nice weather we're having
> goodbye
< (response) goodbye
FIN
Note that the temporal order of events here is _exactly backwards_ to
the order of calls in the code, because we have to name everything
before it can happen. Now, with anonymous blocks (using my own pet
favorite syntax, of course):
def tinman(self):
self.send("hello").addCallback(def (x):
self.send("nice weather we're having").addCallback(def (y):
self.send("goodbye").addCallback(def (z):
self.loseConnection(
Now, of course, this is written as network I/O because that is my
bailiwick, but you could imagine an identical example with a nested
chain of dialog boxes in a GUI, or a state machine controlling a robot.
For completeness, the same example _can_ be written in the same order as
events actually occur, but it takes twice times the number of lines and
ends up creating a silly number of extra names:
def lion(self):
d1 = self.send("hello")
def d1r(x):
d2 = self.send("nice weather we're having")
def d2r(y):
d3 = self.send("goodbye")
def d3r(z):
self.loseConnection()
d3.addCallback(d3r)
d2.addCallback(d2r)
d1.addCallback(d1r)
but this only works if you have a callback-holding object like Twisted's
Deferred. If you have to pass a callback function as an argument, as
many APIs require, you really have to define the functions before
they're called.
My point here is not that my proposed syntax is particularly great, but
that anonymous blocks are a real win in terms of both clarity and
linecount. I'm glad guido is giving them a moment in the limelight :).
Should there be a PEP about this?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
> Why not have the block automatically be inserted into acquire's argument > list? It would probably get annoying to have to define inner functions > like that every time one simply wants to use arguments. But the number of *uses* would be much larger than the number of "block decorators" you'd be coding. If you find yourself writing new block decorators all the time that's probably a sign you're too much in love with the feature. :-) > For example: > > def acquire(block, aLock): > aLock.acquire() > try: > block() > finally: > aLock.release() > > @acquire(myLock): > code > code > code > > Of course, augmenting the argument list in that way would be different > than the behavior of decorators as they are now. I don't like implicit modifications of argument lists other than by method calls. It's okay for method calls because in the x.foo(a) <==> foo(x, a) equivalence, x is really close to the beginning of the argument list. And your proposal would preclude parameterless block decorators (or turn them into an ugly special case), which I think might be quite useful: @forever: infinite loop body @ignore: not executed at all @require: assertions go here and so on. (In essence, we're inventing the opposite of "barewords" in Perl here, right?) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: anonymous blocks
Guido van Rossum wrote: This reflects a style pattern that I've come to appreciate more recently: what took you so long? ;-) Why do people care about cluttering namespaces so much? I thought thats' what namespaces were for -- to put stuff you want to remember for a bit. A function's local namespace in particular seems a perfectly fine place for temporaries. and by naming stuff, you can often eliminate a comment or three. this is python. names are cheap. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Re: anonymous blocks
Brian Sabbey wrote: If suites were commonly used as above to define properties, event handlers and other callbacks, then I think most people would be able to comprehend what the first example above is doing much more quickly than the second. wonderful logic, there. good luck with your future adventures in language design. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Guido van Rossum wrote: @acquire(myLock): code code code It would certainly solve the problem of which keyword to use! :-) And I think the syntax isn't even ambiguous -- the trailing colon distinguishes this from the function decorator syntax. I guess it would morph '@xxx' into "user-defined-keyword". How would acquire be defined? I guess it could be this, returning a function that takes a callable as an argument just like other decorators: def acquire(aLock): def acquirer(block): aLock.acquire() try: block() finally: aLock.release() return acquirer and the substitution of @EXPR: CODE would become something like def __block(): CODE EXPR(__block) Why not have the block automatically be inserted into acquire's argument list? It would probably get annoying to have to define inner functions like that every time one simply wants to use arguments. For example: def acquire(block, aLock): aLock.acquire() try: block() finally: aLock.release() @acquire(myLock): code code code Of course, augmenting the argument list in that way would be different than the behavior of decorators as they are now. -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
> @acquire(myLock): > code > code > code It would certainly solve the problem of which keyword to use! :-) And I think the syntax isn't even ambiguous -- the trailing colon distinguishes this from the function decorator syntax. I guess it would morph '@xxx' into "user-defined-keyword". How would acquire be defined? I guess it could be this, returning a function that takes a callable as an argument just like other decorators: def acquire(aLock): def acquirer(block): aLock.acquire() try: block() finally: aLock.release() return acquirer and the substitution of @EXPR: CODE would become something like def __block(): CODE EXPR(__block) I'm not yet sure whether to love or hate it. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
> > IMO this is clearer, and even shorter! > But it clutters the namespace with objects you don't need. Why do people care about cluttering namespaces so much? I thought thats' what namespaces were for -- to put stuff you want to remember for a bit. A function's local namespace in particular seems a perfectly fine place for temporaries. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Guido van Rossum wrote:
tri = self.subcalculation("The quick brown fox jumps over the lazy
dog")
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
But it clutters the namespace with objects you don't need. So the
complete equivalent would be more close to:
tri = self.subcalculation("The quick brown fox jumps over the lazy
dog")
self.disentangle(0x40, tri, self.indent+1)
del tri
which seems a bit odd to me.
If we apply this to the anonymous block problem, we may end up finding
lambda the ultimate compromise -- like a gentleman in the back of my
talk last week at baypiggies observed (unfortunately I don't know his
name).
It wasn't me ;-) It seems this keeps getting back at you. Wish I had
thought of this argument before.
--eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
On Tue, 2005-04-19 at 15:24, Guido van Rossum wrote: > *If* we're going to create syntax for anonymous blocks, I think the > primary use case ought to be cleanup operations to replace try/finally > blocks for locking and similar things. I'd love to have syntactical > support so I can write > > blahblah(myLock): > code > code > code > > instead of > > myLock.acquire() > try: > code > code > code > finally: > myLock.release() Indeed, it would be very cool to have these kind of (dare I say) block decorators for managing resources. The really nice thing about that is when I have to protect multiple resources in a safe, but clean way inside a single block. Too many nested try/finally's cause you to either get sloppy, or really ugly (or both!). 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 -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: anonymous blocks
Guido van Rossum wrote: >> What was your opinion on "where" as a lambda replacement? i.e. >> >> foo = bar(callback1, callback2) where: >> def callback1(x): >> print "hello, " >> def callback2(x): >> print "world!" > > I don't recall seeing this proposed, but I might have -- I thought of > pretty much exactly this syntax in the shower a few days ago. Gee, the time machine again! Lots of proposals on c.l.py base on the introduction of "expression suites", that is, suites embedded in arbitrary expressions. My opinion is that one will never find a suitable (;-) syntax, there's always the question of where to put the code that follows the suite (and is part of the same statement). yours, Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
From: Guido van Rossum <[EMAIL PROTECTED]> ... This reflects a style pattern that I've come to appreciate more recently: when breaking a call with a long argument list to fit on your screen, instead of trying to find the optimal break points in the argument list, take one or two of the longest arguments and put them in local variables. ... If we apply this to the anonymous block problem, we may end up finding lambda the ultimate compromise -- like a gentleman in the back of my talk last week at baypiggies observed (unfortunately I don't know his name). I like it: Lambda: The Ultimate Compromise (c.f. http://library.readscheme.org/page1.html) kb ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: anonymous blocks
Fredrik Lundh wrote: In short, if doFoo is defined like: def doFoo(func1, func2): pass You would be able to call it like: doFoo(**): def func1(a, b): return a + b def func2(c, d): return c + d That is, a suite can be used to define keyword arguments. umm. isn't that just an incredibly obscure way to write def func1(a, b): return a + b def func2(c, d): return c + d doFoo(func1, func2) but with more indentation? If suites were commonly used as above to define properties, event handlers and other callbacks, then I think most people would be able to comprehend what the first example above is doing much more quickly than the second. So, I don't find it obscure for any reason other than because no one does it. Also, the two examples above are not exactly the same since the two functions are defined in a separate namespace in the top example. -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
> What was your opinion on "where" as a lambda replacement? i.e. > > foo = bar(callback1, callback2) where: > def callback1(x): > print "hello, " > def callback2(x): > print "world!" I don't recall seeing this proposed, but I might have -- I thought of pretty much exactly this syntax in the shower a few days ago. Unfortunately it doesn't solve the lock-release use case that is more pressing in my mind. Also, if you want top-down programming (which is a fine coding style!), we already have several ways to do that. > I suspect that you like the define-first approach because of your tendency > to ask questions first and read later. That is, you want to know what > callback1 and callback2 are before you see them passed to > something. However, other people seem to like to have the context first, > then fill in the details of each callback later. I think it all depends, not so much on the personality of the reader, but on the specifics of the program. When callback1 and callback2 are large chunks of code, we probably all agree that it's better to have them out of the way, either way up or way down -- purely because of their size they deserve to be abstracted away when we're reading on how they are being used. A more interesting use case may be when callback1 and callback2 are very *small* amounts of code, since that's the main use case for lambda; there knowing what callback1 and callback2 stand for is probably important. I have to say that as long as it's only a few lines away I don't care much whether the detail is above or below its application, since it will all fit on a single screen and I can look at it all together. So then the 'where' syntax isn't particularly attractive because it doesn't solve a problem I'm experiencing. > Interestingly, this syntax also works to do decoration, though it's not a > syntax that was ever proposed for that. e.g.: > > foo = classmethod(foo) where: > def foo(cls,x,y,z): > # etc. This requires you to write foo three times, which defeats at least half of the purpose of decorators. > foo = property(get_foo,set_foo) where: > def get_foo(self): > # ... > def set_foo(self): > # ... > > I don't mind @decorators, of course, but maybe they wouldn't be needed here. As I said before, I'm not sure why keeping get_foo etc. out of the class namespace is such a big deal. In fact, I like having them there (sometimes they can even be handy, e.g. you might be able to pass the unbound get_foo method as a sort key). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Guido van Rossum wrote: See the thread "pre-PEP: Suite-Based Keywords" (shamless plug) (an earlier, similar proposal is here: http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list %40python.org ). In short, if doFoo is defined like: def doFoo(func1, func2): pass You would be able to call it like: doFoo(**): def func1(a, b): return a + b def func2(c, d): return c + d That is, a suite can be used to define keyword arguments. I'm still not sure how this is particularly solving a pressing problem that isn't solved by putting the function definitions in front of the call. I saw the first version of the proto-PEP and didn't think that the motivating example (keeping the getx/setx methods passed to a property definition out of the class namespace) was all that valuable. OK. I think most people (myself included) who would prefer to define properties (and event handlers, etc.) in this way are motivated by the perception that the current method is just ugly. I don't know that it solves any pressing problems. Two more issues: (1) It seems that *every* name introduced in the block automatically becomes a keyword argument. This looks like a problem, since you could easily need temporary variables there. (I don't see that a problem with class bodies because the typical use there is only method and property definitions and the occasional instance variable default.) Combining the suite-based keywords proposal with the earlier, 'where' proposal (linked in my above post), you would be able to name variables individually in the case that temporary variables are needed: f(x=x): x = [i**2 for i in [1,2,3]] (2) This seems to be attaching a block to a specific function call but there are more general cases: e.g. you might want to assign the return value of doFoo() to a variable, or you might want to pass it as an argument to another call. The 'where' proposal also doesn't have this problem. Any expression is allowed. *If* we're going to create syntax for anonymous blocks, I think the primary use case ought to be cleanup operations to replace try/finally blocks for locking and similar things. I'd love to have syntactical support so I can write blahblah(myLock): code code code instead of myLock.acquire() try: code code code finally: myLock.release() Well, that was my other proposal, "pre-PEP: Simple Thunks" (there is also an implementation). It didn't seem to go over all that well. I am going to try to rewrite it and give more motivation and explanation (and maybe use 'with' and 'from' instead of 'do' and 'in' as keywords). -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
On 4/19/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm still not sure how this is particularly solving a pressing problem > that isn't solved by putting the function definitions in front of the Well. As to what I've read in my short python experience, people wants to change the language *not* because they have a problem that can not be solved in a different way, but because they *like* to solve it in a different way. And you, making a stand against this, are a main Python feature. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
At 03:39 PM 04/19/2005 -0400, Phillip J. Eby wrote: I suspect that you like the define-first approach because of your tendency to ask questions first and read later. Oops; I forgot to put the smiley on that. It was supposed to be a humorous reference to a comment Guido made in private e-mail about the Dr. Dobbs article I wrote on decorators. He had said something similar about the way he reads articles, expecting the author to answer all his questions up front. Without that context, the above sentence sounds like some sort of snippy remark that I did not intend it to be. Sorry. :( ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
At 11:55 AM 04/19/2005 -0700, Guido van Rossum wrote:
I'd recommend this:
tri = self.subcalculation("The quick brown fox jumps over the lazy dog")
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
What was your opinion on "where" as a lambda replacement? i.e.
foo = bar(callback1, callback2) where:
def callback1(x):
print "hello, "
def callback2(x):
print "world!"
I suspect that you like the define-first approach because of your tendency
to ask questions first and read later. That is, you want to know what
callback1 and callback2 are before you see them passed to
something. However, other people seem to like to have the context first,
then fill in the details of each callback later.
Interestingly, this syntax also works to do decoration, though it's not a
syntax that was ever proposed for that. e.g.:
foo = classmethod(foo) where:
def foo(cls,x,y,z):
# etc.
foo = property(get_foo,set_foo) where:
def get_foo(self):
# ...
def set_foo(self):
# ...
I don't mind @decorators, of course, but maybe they wouldn't be needed here.
If we apply this to the anonymous block problem, we may end up finding
lambda the ultimate compromise -- like a gentleman in the back of my
talk last week at baypiggies observed (unfortunately I don't know his
name).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: anonymous blocks
Brian Sabbey wrote: In short, if doFoo is defined like: def doFoo(func1, func2): pass You would be able to call it like: doFoo(**): def func1(a, b): return a + b def func2(c, d): return c + d That is, a suite can be used to define keyword arguments. umm. isn't that just an incredibly obscure way to write def func1(a, b): return a + b def func2(c, d): return c + d doFoo(func1, func2) but with more indentation? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
> See the thread "pre-PEP: Suite-Based Keywords" (shamless plug) > (an earlier, similar proposal is here: > http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list > %40python.org ). > > In short, if doFoo is defined like: > > def doFoo(func1, func2): > pass > > You would be able to call it like: > > doFoo(**): > def func1(a, b): > return a + b > def func2(c, d): > return c + d > > That is, a suite can be used to define keyword arguments. I'm still not sure how this is particularly solving a pressing problem that isn't solved by putting the function definitions in front of the call. I saw the first version of the proto-PEP and didn't think that the motivating example (keeping the getx/setx methods passed to a property definition out of the class namespace) was all that valuable. Two more issues: (1) It seems that *every* name introduced in the block automatically becomes a keyword argument. This looks like a problem, since you could easily need temporary variables there. (I don't see that a problem with class bodies because the typical use there is only method and property definitions and the occasional instance variable default.) (2) This seems to be attaching a block to a specific function call but there are more general cases: e.g. you might want to assign the return value of doFoo() to a variable, or you might want to pass it as an argument to another call. *If* we're going to create syntax for anonymous blocks, I think the primary use case ought to be cleanup operations to replace try/finally blocks for locking and similar things. I'd love to have syntactical support so I can write blahblah(myLock): code code code instead of myLock.acquire() try: code code code finally: myLock.release() -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickling buffer objects.
Greg Ewing wrote: Travis Oliphant wrote: I'm proposing to pickle the buffer object so that it unpickles as a string. Wouldn't this mean you're only solving half the problem? Unpickling a Numeric array this way would still use an intermediate string. Well, actually, unpickling in the new numeric uses the intermediate string as the memory (yes, I know it's not supposed to be "mutable", but without a mutable bytes object what else are you supposed to do?). Thus, ideally we would have a mutable-bytes object with a separate pickle opcode. Without this, then we overuse the string object. But, since the string is only created by the pickle (and nobody else uses it, then what's the real harm). So, in reality the previously-mentioned patch together with modificiations to Numeric's unpickling code actually solves the whole problem. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
Shannon -jj Behrens wrote:
Have you guys considered the following syntax for anonymous blocks? I
think it's possible to parse given Python's existing syntax:
items.doFoo(
def (a, b) {
return a + b
},
def (c, d) {
return c + d
}
)
There was a proposal in the last few days on comp.lang.python that allows
you to do this in a way that requires less drastic changes to python's
syntax. See the thread "pre-PEP: Suite-Based Keywords" (shamless plug)
(an earlier, similar proposal is here:
http://groups.google.co.uk/groups?selm=mailman.403.1105274631.22381.python-list
%40python.org ).
In short, if doFoo is defined like:
def doFoo(func1, func2):
pass
You would be able to call it like:
doFoo(**):
def func1(a, b):
return a + b
def func2(c, d):
return c + d
That is, a suite can be used to define keyword arguments.
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
> (I apologize that this is my first post. Please don't flame me into
> oblivion or think I'm a quack!)
(Having met JJ I can assure he's not a quack. But don't let that stop
the flames. :-)
> Have you guys considered the following syntax for anonymous blocks? I
> think it's possible to parse given Python's existing syntax:
>
>items.doFoo(
>def (a, b) {
>return a + b
>},
>def (c, d) {
>return c + d
>}
>)
>
> Notice the trick is that there is no name between the def and the "(",
> and the ")" is followed by a "{".
>
> I understand that there is hesitance to use "{}". However, you can
> think of this as a Python special case on the same level as using ";"
> between statements on a single line. From that perspective, it's not
> inconsistent at all.
It would be a lot less inconsistent if {...} would be acceptable
alternative block syntax everywhere.
But what exactly are you trying to accomplish here? I think that
putting the defs *before* the call (and giving the anonymous blocks
temporary local names) actually makes the code clearer:
def block1(a, b):
return a + b
def block2(c, d):
return c + d
items.doFoo(block1, block2)
This reflects a style pattern that I've come to appreciate more
recently: when breaking a call with a long argument list to fit on
your screen, instead of trying to find the optimal break points in the
argument list, take one or two of the longest arguments and put them
in local variables. Thus, instead of this:
self.disentangle(0x40,
self.triangulation("The quick brown fox jumps over
the lazy dog"),
self.indent+1)
I'd recommend this:
tri = self.subcalculation("The quick brown fox jumps over the lazy dog")
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
If we apply this to the anonymous block problem, we may end up finding
lambda the ultimate compromise -- like a gentleman in the back of my
talk last week at baypiggies observed (unfortunately I don't know his
name).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: anonymous blocks
"Shannon -jj Behrens" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Have you guys considered the following syntax for anonymous blocks?
There have probably been about 10 such proposals bandied about over the
years, mostly on comp.lang.python, which is the more appropriate place for
speculative proposals such as this.
>I understand that there is hesitance to use "{}".
For some, there is more than 'hisitance'. If you understood why, as has
been discussed on c.l.p several times, I doubt you would bother proposing
such. I won't repeat them here. I should hope there is a Python FAQ entry
on this.
Terry J. Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] anonymous blocks
(I apologize that this is my first post. Please don't flame me into
oblivion or think I'm a quack!)
Have you guys considered the following syntax for anonymous blocks? I
think it's possible to parse given Python's existing syntax:
items.doFoo(
def (a, b) {
return a + b
},
def (c, d) {
return c + d
}
)
Notice the trick is that there is no name between the def and the "(",
and the ")" is followed by a "{".
I understand that there is hesitance to use "{}". However, you can
think of this as a Python special case on the same level as using ";"
between statements on a single line. From that perspective, it's not
inconsistent at all.
Best Regards,
-jj
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] os.urandom uses closed FD (sf 1177468)
We're running into the problem described in bug 1177468, where urandom tries to use a cached file descriptor that was closed by a daemonizing function. A quick fix/workaround is to have os.urandom open /dev/urandom everytime it gets called instead of using the a cached fd. Would that create any problems other that those related to the additional system call overhead? BTW, I added the traceback we're getting as comment to the bug. Thanks PS This is with Python 2.4.1 -- Luis P CaamanoAtlanta, GA USA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do you get yesterday from a time object
Hi, I believe it's not the appropriate place to ask such questions.
You should check the Python users' list (
http://python.org/community/lists.html )
Anyway, here you go :
now = time.time()
nowTuple = time.localtime(now)
yesterdayTuple = time.localtime(now-60*60*24)
Regards,
Patrick.
2005/4/19, Ralph Hilton <[EMAIL PROTECTED]>:
> i'm a beginning python programmer.
>
> I want to get the date for yesterday
>
> nowTime = time.localtime(time.time())
> print nowTime.
> oneDay = 60*60*24 # number seconds in a day
> yday = nowTime - oneDay # <-- generates an error
> print yday.strftime("%Y-%m-%d")
>
> How can I just get yesterday's day? It a simple
> concept yet it seems to be so hard to figure out.
>
> What i'm worried about is if today is say
> June 1, 2023
> what is yesterday? and how do i compute that?
>
> Ralph Hilton
>
> __
> Do you Yahoo!?
> Plan great trips with Yahoo! Travel: Now over 17,000 guides!
> http://travel.yahoo.com/p-travelguide
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/pdecat%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do you get yesterday from a time object
On 4/19/05, Ralph Hilton <[EMAIL PROTECTED]> wrote:
> i'm a beginning python programmer.
>
> I want to get the date for yesterday
>
> nowTime = time.localtime(time.time())
> print nowTime.
> oneDay = 60*60*24 # number seconds in a day
> yday = nowTime - oneDay # <-- generates an error
> print yday.strftime("%Y-%m-%d")
>
> How can I just get yesterday's day? It a simple
> concept yet it seems to be so hard to figure out.
>
> What i'm worried about is if today is say
> June 1, 2023
> what is yesterday? and how do i compute that?
You don't want the python-dev list for this type of question.
Python-dev is for development *of* Python. For usage questions such as
this, you would be better asking on python-list (or, equivalently, the
Usenet group comp.lang.python).
To assist with your question, though, I'd suggest you look at the
documentation of the datetime module, which allows you to do what you
are after (and much more).
Regards,
Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How do you get yesterday from a time object
On 4/19/05, Ralph Hilton <[EMAIL PROTECTED]> wrote: > i'm a beginning python programmer. > > I want to get the date for yesterday This is the wrong place for this question. Nip over to http://mail.python.org/mailman/listinfo/python-list, and I'd be more than happy answer it there... -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How do you get yesterday from a time object
i'm a beginning python programmer.
I want to get the date for yesterday
nowTime = time.localtime(time.time())
print nowTime.
oneDay = 60*60*24 # number seconds in a day
yday = nowTime - oneDay # <-- generates an error
print yday.strftime("%Y-%m-%d")
How can I just get yesterday's day? It a simple
concept yet it seems to be so hard to figure out.
What i'm worried about is if today is say
June 1, 2023
what is yesterday? and how do i compute that?
Ralph Hilton
__
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.1 in HP-UX
On Tue, Apr 19, 2005, Prakash A wrote: > > I using jython 2.1. For that i need of Python 2.1 ( i am sure about > this, pls clarify me if any version of Python can be used with > Jython). and i am working HP-UX platform. I need to know that, > whether Python can be Built in HP-UX, because i seeing some of the > mails saying Python 2.1 did not compile in HP-UX and Python can not > build with HP-UX. Please tell me, whether Python 2.1 can be build in > HP-UX. If yes, please give me the stpes to do that. python-dev is for development of the Python project. Please use comp.lang.python for other questions. Thank you. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.1 in HP-UX
Hello All, I using jython 2.1. For that i need of Python 2.1 ( i am sure about this, pls clarify me if any version of Python can be used with Jython). and i am working HP-UX platform. I need to know that, whether Python can be Built in HP-UX, because i seeing some of the mails saying Python 2.1 did not compile in HP-UX and Python can not build with HP-UX. Please tell me, whether Python 2.1 can be build in HP-UX. If yes, please give me the stpes to do that. Thanks in Advance, Prakash.A ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
