RE: [Python-Dev] Re: new syntax for wrapping (PEP 318)

From: Jewett, Jim J
Agreed. And why limit it to lists - why not any expression that evaluates to a list? Or maybe any sequence? Which is one reason that a bare "[...]" doesn't seem sufficient.
Overgeneralisation without good use cases. Leave it as simple lists. Bob Ippolito just posted a pseq function which will do this for the (extremely rare) cases when it might be needed.
They don't need to, in general. The specific functions that they do need (like __init__) are in the index. Though to be honest, this was a concern at first, when I thought that creating a class would require me to define a large number of methods. If I had been more deeply object-oriented, that might have put me off. Instead, I just started with functions instead of classes.
Exactly. As a beginner, classes were more advanced than you needed. So the (relative) difficulty of finding the relevant details wasn't an issue - you just didn't use the feature for a while. By the time you needed classes, you were familiar enough with Python to know where to look. Heck, by the time most people will need the full power of the wrapping feature [1], they will probably know enough to understand the C code of the patch itself! It's pretty advanced usage, remember... [1] Except for extremely stylised cases like [classmethod], which will be for particular use cases - and you can look that one up under "classmethod"... Paul.

Moore, Paul wrote:
[1] Except for extremely stylised cases like [classmethod], which will be for particular use cases - and you can look that one up under "classmethod"...
I find this an interesting point - almost certainly, the introduction process for this syntax is going to be via one of the decorators in the standard library (classmethod, staticmethod, ?), which can be looked up directly. The write-ups for these would include a link to what a function decorator _is_, so that people can then learn that Python function decorators don't restrict you to whatever modifiers the language designers felt like providing (ala C, C++, Java etc). (Odd thought for the evening: def myFunc (arg) [private]: pass where 'private' wraps a function in some code that does some introspection to give you a _real_ private function, that refuses to be called from outside its defining context. Slow as hell, and the psuedo-privacy of name-mangling is generally enough, but just something that occured to me) Regards, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan@email.com | Mobile: +61 409 573 268

On Thu, 2004-02-26 at 04:20, Moore, Paul wrote:
Heck, by the time most people will need the full power of the wrapping feature [1], they will probably know enough to understand the C code of the patch itself! It's pretty advanced usage, remember...
[1] Except for extremely stylised cases like [classmethod], which will be for particular use cases - and you can look that one up under "classmethod"...
Nothing in PEP 318 is going to make the current way of wrapping illegal, so I would think that a beginning class might make life simpler by first teaching the post-method wrapping idiom. They might then explain how there's this neat (more advanced) decorator syntax for making things more succinct. -Barry
participants (3)
-
Barry Warsaw
-
Moore, Paul
-
Nick Coghlan