Mailman 3 August 2004 - Python-Dev

Re: [Python-checkins] python/nondist/sandbox/string/string __init__.py, 1.2, 1.3 template.py, 1.1, 1.2
by Barry Warsaw Aug. 12, 2004

Aug. 12, 2004

On Thu, 2004-08-12 at 17:20, rhettinger(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/nondist/sandbox/string/string > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7407 > > Modified Files: > __init__.py template.py > Log Message: > Capitalized the class names. > Fixed a broken example > Cleaned-up the namespace. > Added __slots__ for compactness. > Doctest the example. Thanks! pining-for-my-page-breaks-ly y'rs, -Barry :)

1 0

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

Aug. 12, 2004

>In the discussion on decorators months ago, solutions involving >special syntax inside the block were ruled out early on. Basically, >you shouldn't have to peek inside the block to find out important >external properties of the function. >--Guido van Rossum (home page: http://www.python.org/~guido/) I disagree. The most important part of a function is the first def line. If you place other stuff before the def line, you make it harder to grep for the def line. Compare: ----------------------------------------------- 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? - For which method is the code in the most logical order? Note that Option A causes you to skim all the way through the docstring and the decorators to find out which function is being defined. At this point, you have to start over at the docstring, to find out what the function actually does. Option A is especially painful when a large number of functions are thrown into a module. It is almost impossible to grep efficiently for the function names. Thus the code appears disorganized, and messy. It seems strange that Option B was "ruled out early on." Option B is clearly more readable. - Connelly

8 7

pep 318, Decorators for Functions, Methods and Classes
by Simon Percivall Aug. 12, 2004

Aug. 12, 2004

On pep 318 (like everything else here). Is it actually supposed to work for classes? like the pep title says. It doesn't seem to work, instead it issues a SyntaxError on the class keyword. Also, the discussion is completely focused on decorating functions and methods. //Simon

10 17

RE: [Python-Dev] Third Bug Day outcome
by Batista, Facundo Aug. 12, 2004

Aug. 12, 2004

[A.M. Kuchling] #- Also, 9 to 5 is a good length for the bug day; by 3 or 4 PM I'm #- starting to get frazzled, but the day is almost over so that's OK. #- The first bug day was announced as being 12 hours long, which would #- have ben deadly, but luckily SF CVS stopped working around #- 6PM on that #- first day and saved me. 9 to 5 where? Maybe for the next Bug Day should be two "IRC hosts", one in America and other in Europe. so, the'll be 6 hs each (top) and the whole day will be of 12 hours. Not-being-able-to-be-him-because-of-56.6k-modem-ly yours, . Facundo

3 2

New Subscriber
by Dave Hastings Aug. 12, 2004

Aug. 12, 2004

Hello fellow developers. My name is David Hastings and I am a new subscriber to the python-dev list. I'm also a little new to python but I can get around in it. I have been learning how to use the language for about a year now. First, some information about myself. I am a senior attending the University of Minnesota. Today was the last day of classes for the spring semester and also the last day of my college career. I am receiving a Bachelor of Science in Computer Science degree. Man it feels good to be done ! This last semester a friend (Michael Sampson) and I took an independent study class where we sign up with a Professor and decide on a project and work on it until the end of the semester. The project that was decided upon, with the advice of the Professor, was to make a CGIpm python module that reflected CGI.pm for perl. We noticed that there is a current cgi module for python and even a cgipm module. These modules are very useful, but did not include all the functions that CGI.pm for perl provides. It turns out that my Professor really likes python and would have loved to see a CGIpm python module for python that was like the CGI.pm module for perl. (I think he is a bit turned off by perl, more because it is a language that is not that easy to pick up unless you are familiar with unix, namely sed and awk.) We decided to take the oportunity and wrote CGIpm.py. I'm not going to go into a lot of details in this e-mail since it is an introductory e-mail, but the first version of CGIpm.py is complete. I feel that this e-mail is a bit long winded as is, so I think I will end it. I can not wait to start reading about all the new ideas, development, and contributions that this list will provide. Dave

8 9

Naming nit
by Raymond Hettinger Aug. 12, 2004

Aug. 12, 2004

For PEP 292, should the class be Template() or template()? Raymond

5 4

Re: Re: Decimal type question [Prothon]
by Jim J Jewett Aug. 12, 2004

Aug. 12, 2004

Mark Hahn: > 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. In theory, it is a great idea, and removes a lot of useless clutter. C often has signed and unsigned versions of char, short, int, long, and long long. Python has just int and long. The "missing" types aren't really missed. For Python itself, the unification probably shouldn't happen until 3.0, because of all the programs that use an "integer" as a bitfield, and because performance won't really be equal. For a new language -- yes, you might as well get it right from the start. -jJ __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail

1 0

Asyncore .set_reuse_addr() on Windows
by A.M. Kuchling Aug. 12, 2004

Aug. 12, 2004

A recent patch makes asyncore.py's .set_reuse_addr method work on Windows, which needs a different socket option: if sys.platform == 'win32': reuse_constant = socket.SO_EXCLUSIVEADDRUSE else: reuse_constant = socket.SO_REUSEADDR Question: should the condition be sys.platform.startswith('win') for the sake of win64, or other Windows variants? (I don't know which values sys.platform can have on Windows.) --amk

7 13

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

Aug. 12, 2004

> the only reason programmers write loops as integers is > because accumulating floats "doesn't work". With Decimal, that > is no longer the case. That is completely untrue. Binary floating point does just as good a job of handling integers as decimal floating point does. For instance: >>> accumulator = 0.0 >>> for i in range(25000): ... accumulator += 1.0 ... >>> print accumulator 25000.0 Notice, perfect accuracy. Yet people don't tend to use floating point for loops... why not? I'd argue there are at LEAST two other good reasons. Performance (floating point arithmatic is fast, but the equivalent integer arithmatic is normally faster), and clarity of intent (using an int type makes it clear that you intend only to use integers. But lots of languages make other choices. The number of languages that have a single numeric type is pretty large... perl comes to mind, but I bet I could list 10 others without too much trouble. -- Michael Chermside

3 2

Similarity of docstrings and decorators
by Andrew Durdin Aug. 12, 2004

Aug. 12, 2004

It recently struck me that both decorators and docstrings are syntactic sugar for code that would otherwise follow the function definition, vide: @staticmethod def foo(): """Frobs the baz""" pass versus def foo(): pass foo.__doc__ = """Frobs the baz""" foo = staticmethod(foo) This suggests two things to me: firstly, that the proposed decorator syntaxes which place the decorators after the def, beside the docstring, are the most consistent with existing syntax (that for docstrings); and secondly, that this suggests that it might be better to have an explicit function "header" section where both decorators and docstrings will reside. For a conceptual example (not a syntax proposal): def foo(): header: staticmethod """Frobs the baz""" pass I realise there would be some issues with this--backward compatibility with existing docstrings (which could probably be resolved by a gradual deprecation), and Guido's concern about having to "peek inside the block"--but I thought it worth mentioning this generalised conception of both features, that highlights their similarity. (As for peeking inside the function, if a separate header area existed for the "important external properties", then it, together with the signature (which is arguably the most important part of a function definition) would comprise all that you would need to know externally.)

1 0