Mailman 3 August 2004 - Python-Dev

RE: [Python-Dev] decimal.Context.copy() shallow or deep?
by Batista, Facundo Aug. 9, 2004

Aug. 9, 2004

[Raymond Hettinger] #- > > Do you guys think it should be left alone (shallow) or #- changed (made #- > > deep)? #- > #- > A user-visible copy certainly should not share mutable #- state with the #- > original. #- #- I was afraid of that. What a PITA. My opinion is that the important step here is to fix the behaviour before alpha-3 or beta (whatever cames first). So, it's nice your idea to rename context.copy() to context._shallow_copy(), make context.copy() deep, and then, in all the tests that fail, change copy for the shallow one. Later, we'll have time to maybe fix that and don't depend of a shallow copy (work around that WorkRep would be nice also). . Facundo

1 0

new failing test -- test_compiler
by Jeremy Hylton Aug. 9, 2004

Aug. 9, 2004

I added a test for the compiler package, because I realized it would easily fall out of date if the language changed (say, decorators were added) and the compiler package wasn't updated. I added a test with a resource, so it would only fail if you run regrtest.py -u all. I think that's a little lame, but better than letting us get into beta without getting the compiler package fixed. At any rate, the test become somewhat more interesting than I expected because it fails in an unexpected way: Fatal Python error: deletion of interned string failed Aborted (core dumped) My best guess is that this is a stack overflow. In particular, gdb shows that the failure is 388 stack levels deep. The compiler package has very deep function calls, because it uses recursion to traverse abstract syntax trees. (I know, I know, we should just rewrite the compiler to use iterator instead of recursion <wink>.) Inside one of those deeply nested calls, it triggers GC which attempts to free a deeply nested tree that is now garbage. I think that's where it blows up. If anyone has suggestions for debugging, I'm all ears. Jeremy

5 12

Density of pie-decorator syntax
by Josh Hoyt Aug. 9, 2004

Aug. 9, 2004

One problem I have with the pie-decorator syntax is that it is very typographically dense. The @ character runs in with the following function name. If there are multiple lines of decorators, the problem is worsened. For clarity, the decorators will have no whitespace lines between them, creating a dense block. After experimenting, I have found that readability is increased if there is one space required after the @. Don't take my word for it: Current Python 2.4a2 syntax: @framework_stuff(lots, of, args) class Quux(object): @check_args(int, str) @counted @staticmethod def frobnicate(foo, bar): pass Proposed change requiring a space: @ framework_stuff(lots of args) class Quux(object): @ check_args(int, str) @ counted @ staticmethod def frobnicate(foo, bar): pass

3 2

capturing RETURN_VALUE
by Christian Tismer Aug. 9, 2004

Aug. 9, 2004

Dear list, just by chance, I discovered a probably very unknown feature of the block stack machinery of Python's frames: -- It is possible to abandon a return statement. -- My question: Is this an artifact, or can I rely on this feature to persist for a while (while while >= 1 year) ? Example code: I have a code body which either computes and returns a value, or it raises an exception. Surrounding it, I have a while true loop, embracing a try..finally block. In case of an exception, it simply lets the exception pass. In case of a return value, it intercepts it and can do anything (in the example, it just decorates the value and returns). def return_capture(n, do_raise=False): _have_value = False # outer while loop, just there to get cancelled while True: try: # function body, returning a value or raising if do_raise: raise ValueError, "was told to raise" # signal valid value _have_value = True retval = n*n return finally: if _have_value: break # here we end after a captured return, and can do postprocessing retval = ("here the captured return value", retval) return retval Sample output: >>> return_capture(5) ('here the captured return value', 25) >>> return_capture(5, True) Traceback (most recent call last): File "<interactive input>", line 1, in ? File "<interactive input>", line 8, in return_capture ValueError: was told to raise >>> Again the question: Artifact, or a reliable feature? ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

2 4

The date in the generated documentation
by Jeff Epler Aug. 9, 2004

Aug. 9, 2004

This is probably the strangest question I've ever asked python-dev. For the Python bug day I updated my CVS, and later on typed "make" in the Doc directory. I'm now viewing the generated html/lib/lib.html file, and it's displayed in that weird font that Japanese web pages always use, and the top of the document says Release 2.4a2 平成16年8月7日 which is, as nearly as I can tell, a (correct?) Japanese "Emperor Date". http://www.i18nguy.com/l10n/emperor-date.html gives a little explanation for us westerners, the first two characters match the Kanji he gives for the current era (beginning in 1989), and the Western calendar year is now 1989 + 16 - 1. Also, the strings "Context", "Index", and "About this document" are written in Japanese characters. This appears to affect the other documents (ref/ref.html, etc) generated as well. Nothing on my system should be particularly Japanese (my locale is en_US.UTF-8, for example). While I installed a lot of fonts with this system, I haven't done anything else that would lead me to expect this. The OS is Fedora Core 2 upgraded from FC1 if that helps ring anybody's bell. The paper-letter/*.pdf files that "make pdf" generates have the proper "August 8, 2004" date in them. Jeff

2 2

RELEASED Python 2.4, alpha 2
by Anthony Baxter Aug. 9, 2004

Aug. 9, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team and the Python community, I'm happy to announce the second alpha of Python 2.4. Python 2.4a2 is an alpha release. We'd greatly appreciate it if you could download it, kick the tires and let us know of any problems you find, but it is not suitable for production usage. ~ http://www.python.org/2.4 In this release we have new syntax for function decorators, a fix for failing imports so that they don't leave a broken module in sys.modules, a host of updated modules in the standard library (including optparse and doctest) and a large number of other bug fixes and improvements. See either the highlights, the What's New in Python 2.4, or the detailed NEWS file -- all available from the Python 2.4 webpage. There will probably be one more alpha in a few weeks before the first beta a few weeks after that. Please log any problems you have with this release in the SourceForge bug tracker (noting that you're using 2.4a2): ~ http://sourceforge.net/bugs/?group_id=5470 Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBEjHFDt3F8mpFyBYRAhgXAKCful63a7kAUcHnxFzCZSzq0bmZ7QCfZIqy t/PqaaLcdRL6IVUKPAWiytA= =pQNU -----END PGP SIGNATURE-----

3 6

Suggesting '.' decorators (PEP318)
by Kevin J. Butler Aug. 9, 2004

Aug. 9, 2004

Many people wrote: > Lots of options I haven't seen this mentioned, so I'm going to throw in my suggestion. The following makes sense to me, uses previously invalid syntax, and uses the '.' punctuation in a way similar to existing/proposed usage: def longMethodNameForEffect(longArgumentOne=None, longArgumentTwo=42): .staticmethod .funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]", status="experimental", author="BDFL") """ asdfasdf """ raise NotYetImplemented If we want to allow one-liner decorators (questionable to me): def myMethod(self): .staticmethod raise NotYetImplemented Advantages/disadvantages of positioning at start of block: + Unambiguous "target" for decorators, matches Python's precedents for indentation and modify-what-came-before + Decorators won't get lost in long argument lists (they are indented differently in Guido's preferred formatting, and are separated by the smiley in the all-args-on-individual-lines formatting) + Separate from def syntax (to keep def the same avoiding breakage) 0 Perhaps decorators should be allowed before or after the docstring. If you have to choose, I'd choose making it before the docstring. + No extra cut-and-paste issues, no extra indentation level. + No smileys. (Does that get a :) or a ]: ?) Advantages/disadvantages of .decorators: + Will not be silently ignored (doesn't use currently legal syntax) + Simple for simple decorators, supports complex decorators as cleanly as possible + Less ugly (YMMV). Doesn't feel like executable line noise (to 1 out of 1 pythonistas polled...) + No new punctuation or keywords (avoids breaking Leo/IPython/existing code) + Really nice syntax for assigning attributes, if desired (Not sure I like this overloading, but it /looks/ good) def func(): .author = "Kevin Butler" pass +/0 Syntax obvious visually (Someone will complain that the leading period gets lost - that person should switch to a fixed-width font, as used when coding. <.5 wink>) Easy to highlight. 0 Although it is a punctuation-based syntax, it is compatible with existing/proposed '.' usage ('.' can mean subordination to a containing construct like 'with', and passing the implicit "func" argument is analogous to passing "self") 0 Compatible with some future "with ...:" syntax, as decorators must immediately follow a 'def ...:' (or possibly a 'class ...:'), so if there is a 'with ...:' what follows cannot be a decorator. - Minor extension to use of '.' - Some people may have too much dust on their monitors Misc items from the PEP applied to .decorators: + One decorator per line + Could use ".doc()" or ".doc = " as a docstring alternative ?+ Compile time (? as much as the @ syntax is?) + Works in interactive mode Public or private feedback appreciated, I will summarize private feedback to the list. kb

7 7

@decorators, the PEP and the "options" out there?
by IxokaI Aug. 9, 2004

Aug. 9, 2004

So, I have been following Python-dev fairly closely ever since my company decided to rewrite everything in Python, and are now very interested in the future. Keeping track of the decorator debate has been a bit of a pain, and with the outcry against @decorators now and everyone throwing out the current proposals-- well, I thought maybe I could help, since I was keeping notes anyways. Someone said the PEP is out of date, and asked it to be updated with Pro's and Cons of the various ideas out there. So I added what I have to the Python Wiki; personally I think it'd be a good place for people to edit in their pro-con thoughts. I left out all the proposals on the PEP because they appear to all be rejected, although I don't remember why. I just got through devouring the hundred or so messages on @decorators made in the last week or so to find the various information I appended. http://www.python.org/moin/PythonDecorators I added "with", although I havn't seen it. "using" would work too. I personally do not like punctuation syntax-- I'd really like to see something english, even with the hated addition of a keyword. I understand Guido's disapproval for "as" so wanted to think of an alternate. --Stephen

14 25

re: Attribute Strings
by Edward K. Ream Aug. 8, 2004

Aug. 8, 2004

> The second is not a valid string literal now -- That's why I suggested it. ""@" would be a new token, so the statement about '@' in the delims section would remain essentially unchanged. > doesn't that cause the same problems for Leo as @decorators? No. At most leading whitespace may precede Leo's directives. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

3 2

Optimized string concatenation
by Armin Rigo Aug. 8, 2004

Aug. 8, 2004

Hello, The SF patch http://www.python.org/sf/980695 about making repeated string concatenations efficient has been reviewed and is acceptable on technical grounds. This is about avoiding the quadratic behavior of s = '' for x in y: s += some_string(x) This leaves open the policy questions: * first, is that an implementation detail or a published feature? The question is important because the difference in performance is enormous -- we are not talking about 2x or even 10x faster but roughly Nx faster where N is the size of the input data set. * if it is a published feature, what about Jython? * The patch would encourage a coding style that gives program that essentially don't scale with Jython -- nor, for that matter, with 2.3 or older -- and worse, the programs would *appear* to work on Jython or 2.3 when tested with small or medium-sized data sets, but just appear to hang when run on larger data sets. Obviously, this is problem that has always been here, but if we fix it in 2.4 we can be sure that people will develop and test with 2.4, and less thoroughly on 2.3, and when they deploy on 2.3 platforms it will unexpectedly not scale. * discussed on SF too is whether we should remove the 'a=a+b' acceleration from the patch, keeping only 'a+=b'; see the SF tracker. This seems overkill, but should the acceleration be there but disabled by default? from __future__ import string_concatenate? A bientôt, Armin.

6 6