Mailman 3 August 2004 - Python-Dev

status of statistics.py?
by Michael Hudson Aug. 11, 2004

Aug. 11, 2004

I see statistics.py is still in nondist/sandbox/. Is there any deep reason for this? I see the file ends with XXX = """ Other possible functions include data groupers for binning, counting, and splitting into equivalence classes. """ but that hardly seems a blocker. I'd like to see the module in 2.4. Cheers, mwh -- Important data should not be entrusted to Pinstripe, as it may eat it and make loud belching noises. -- from the announcement of the beta of "Pinstripe" aka. Redhat 7.0

2 1

Semantics of decorators?
by Edward C. Jones Aug. 11, 2004

Aug. 11, 2004

In the development docs, Python Reference Manual, 7.5, it says: A function definition may be wrapped by one or more decorator expressions. Decorator expressions are evaluated when the function is defined, in the scope that contains the function definition. The result must be a callable, which is invoked with the function object as the only argument. The returned value is bound to the function name instead of the function object. If there are multiple decorators, they are applied in reverse order. Does this completely describe the semantics of decorators?

4 3

Re: Decorators after 'def' should be reconsidered
by barnesc＠engr.orst.edu Aug. 11, 2004

Aug. 11, 2004

>> ----------------------------------------------- >> Option A >> ----------------------------------------------- >> >> """ >> Hi, >> >> Performs a binary operation. >> >> Docstring. >> """ >> @staticmethod >> @synchronized(lockvar) >> def f(a, b): >> return a + b >> >> """ >> Now, >> >> Performs a simple operation. >> """ >> @classmethod >> def g(a): >> return a >> >> ----------------------------------------------- >> Option B >> ----------------------------------------------- >> >> def f(a, b): >> @staticmethod >> @synchronized(lockvar) >> """ >> Hi, >> >> Performs a binary operation. >> >> Docstring. >> """ >> return a + b >> >> def g(a): >> @classmethod >> """ >> Now, >> >> Performs a simple operation. >> """ >> return a >> >> >> Now, forget everything you've learned about Python. >> Forget that @ symbols are ugly. >> >> - For which method is it visually easier to find the function def? > >None of them. A good syntax coloring would even make it easier in fact. On >the second hand, the Option B makes it much harder to find the function >code once you've found the function def. Option B makes it easier to find the function def, because the def is the only line that is not indented. I can scan straight down the page and instantly find the two function 'def's. For Option A, I have to scan line by line. >> - For which method is the code in the most logical order? > >Option A of course. Since the decorator can be seen as a function that takes >the defined function as it's first parameter, it's logical to place the >decorator before the definition. I consider the function def to be the most important line of the entire function. Thus it follows that it should be the first line. Thinking further, it makes sense to define a function, then define various properties of the function in indented blocks, since the properties are 'contained' in the function. I do agree with your assessment for decorators. However, you have to weigh the 'priority' of the decorator against the priority of the def line. In my mind, the def line wins, and so should be first. Again, of course, there's the advantage of being able to skim down the left column (which is mostly whitespace) and locate function entrance points quickly. For me, this increases the perceived organization of the code, much like labelled boxes help organize the papers in my room (locate the box quickly, then sort through it). See: http://oregonstate.edu/~barnesc/temp/option/optiona.html http://oregonstate.edu/~barnesc/temp/option/optionb.html Consider the difficulty of scanning such code, when there is a long module, with nested functions inside a class. >I don't understand how grep can be "confused" by the decorators before the >def. Are we talking about the same program ??? I refer to searching done by the eye. - Connelly

1 0

RE: [Python-Dev] Re: Re: Update PEP 292
by Michael Chermside Aug. 11, 2004

Aug. 11, 2004

Fredrik writes: > - Consider changing the ${} to accept arbitrary patterns, instead of > just Python-style identifiers. \${([^}]+)} should do the trick. +1 And hey, I'd be +1 on releasing a less-simple template that allowed arbitrary Python expressions (but no '}' characters) instead of just identifiers. But that's another issue -- and my liking it doesn't detract from my liking SIMPLE templates too. As Barry said elsewhere... even if all it does is to replace '%()s' with '${}' it's still an improvement. -- Michael Chermside

1 0

Decorator keyword possibility?
by Nick Coghlan Aug. 11, 2004

Aug. 11, 2004

Someone recently suggested 'remake' as a possible replacement for '@' I don't like that name because Python doesn't use the word 'make' for anything. However, it immediately prompted the thought of 'redef' After all, decorator's effectively 'redefine' the original 'define' block, to mean something else. And the old decorator syntax is *definitely* a 'redefinition' syntax. However, the problem with that word is that you would expect it to come _after_ the definition (like the old syntax does). Which leads to the actual suggestion of a 'predefinition'. That is, we're going to tell you about the definition before we actually get to it. And so, on with the examples: class demo(object): predef classmethod def foo(cls): pass predef staticmethod def bar(): pass predef accepts(int, int) predef returns(bool) predef someOtherDecorator(anarg, anotherarg, yetanotherarg) def foobar(self, apples, oranges): """Compares apples and oranges""" return apples < oranges Regards, Nick. -- Nick Coghlan | Eugene, Oregon Email: ncoghlan(a)email.com | USA

1 0

RE: [Python-Dev] Unifying Long Integers and Integers: baseint
by Michael Chermside Aug. 11, 2004

Aug. 11, 2004

I previously wrote: > I envision an eventual Python which has just one type, called 'int'. Oops, didn't mean to let the cat out of the bag about my evil plan to make Python fast by turning it into a simple machine langauge. Hmm... let's pretend I said "...just one integral numeric type..." instead. That way the PSU won't be able to figure out that

1 0

Re: [Python-Dev] pre-PEP: Complete, Structured Regular Expression Group Matching
by Edward Loper Aug. 11, 2004

Aug. 11, 2004

Michael Hudson wrote: >> Generally, it strikes me as mildly useful. An implementation would >> surely help :-) Mike wrote: > If yours is the most positive review, there probably won't be one. :-) I wouldn't lose heart over the lack of response -- the current flood of decorator messages tends to drown out everything else. I like your idea in the abstract, but I have trouble following many of the examples in your pre-pep (and as a result, I'm not sure if I *really* understand what you're proposing). E.g., you have: | >>> m1 = re.match(r'("([A-Z]|[a-z])*"\s*)*', '"Xx" "yy" "ZzZ"') | >>> m1.group(2) | [['X', 'x'], ['yy'], ['ZzZ']] But it seems to me like the output should instead be: | [['X', 'x'], ['y', 'y'], ['Z', 'z', 'Z']] In particular, group two is "([A-Z]|[a-z])", which matches a single character; so it seems like the value of m1.group(2) should be a tree with leaves that are single characters. (Looking at it from another angle, I can't see any difference between "Xx" and "ZzZ" that would cause one to be decomposed and the other to be left as a string.) Similar comments apply for many of your other examples. So either: - Your examples are incorrect - My understanding of your proposed algorithm is incorrect If it's the former, then please fix the examples. If not, then perhaps we can talk about your algorithm some more off-list, so I can try to see where my misunderstanding is coming from. -Edward

5 9

request: add keywords for static and class methods only [related to decorators discussion]
by Doug Holton Aug. 11, 2004

Aug. 11, 2004

After reading some posts here and the wiki page discussing the decorators: http://www.python.org/moin/PythonDecorators One idea that some people have suggested is to separate out standard uses for decorators like function metadata, vs. built-in features of python, like static methods and class methods. So I'm suggesting, don't use decorators for static and class methods. Perhaps for 2.5 or whenever, we should add keyword support for built-in features, just like java: These two keywords at least: def static mymethod (arg1, arg2): .... def classmethod mymethod( cls, arg1, arg2 ): .... And then you have to decide if you want to support other java built-in features and keywords like private, protected, public, synchronized. See the bottom of the wiki page for ideas for the long term future that combine these keywords with decorators and other possible features.

3 2

RE: [Python-Dev] Re: Re: Decimal type question [Prothon]
by Michael Chermside Aug. 11, 2004

Aug. 11, 2004

> What do you think of the newer idea of using the IBM floating > decimal for > all numerics? Tim Peters and others pushed this on me. [...] > I am thinking of having all current constant formats default to the > "Decimal" type (0, 123, 123.456, 123e3) and have a new > constant type using > the letter 'f' for the binary "Float" type (0f0, 123f0, > 123.456f0, 123.f3). +1 -- Michael Chermside

1 0

Another approach to decorators.
by Martin Zarate Aug. 11, 2004

Aug. 11, 2004

Hello. I've already thrown a few cents into this debate, and have read every post on it. I've used Ruby, so I love being able to make blocks for whatever I want - which is why Python's decorator syntax interests me. Its not as powerful as Ruby blocks, but its a close approach for some things. I can see the problems are legion. I think the fundamental difficulty is that Python is line-oriented, and decorators break this - they either make a gigantic line that the coder remakes as they see fit (very unpython) or a multi-line mess, which Python does not have for any statements. Second is that Python is an extremely legible language, and most decorator syntaxes are not. @ means nothing to an uninformed eye. This violates the most important feature of Python (imho) which is that it is "runnable pseudocode". A coder will see what "def" or "class" or "import" means just by looking at it. @ is meaningless. I submit that a reserved keyword would fit much better in the @ place. Second, that comma-based delimiting (like the global statement) would also be nicer, to avoid line-after-line of decoration. For example, lets say our keyword is "remake" - a bad word, a better one should be used, but I'm tired of thinking of one. remake functor(foo, bar) remake staticmethod def baz(): pass or, alternately, remake functor(foo,bar), staticmethod def baz(): pass but either way, the system doesn't look very Python, as you've a multi-line statement. I submit that the most Python solution, that would also be legible (but not necessarily very pretty) would be to actually make the decorator a bona-fide block that you nest your class or function into. remake functor(foo, bar), staticmethod: def baz(): pass This concretely shows the relationship of the original define statement to its wrapper objects. The principle is simple - the remake block will close with only one object in its immediate namespace, and that object will be wrapped by each of its argument objects in turn, and place it in its surrounding namespace with the same name. Thus, more general-purpose oddball approaches could be used, such as, lambdas or even rewrapping an external object. For example, in order to import a C-based extension module as a member method in a class... class foo(number): remake instancemethod: sin = math.sin bar = foo() num = bar.sin or something like that. other good keywords that could be used instead of remake: wrap, decorate, as, etc. I'm sure you can all think of something better than @.

2 1