Mailman 3 November 2005 - Python-Dev

Fwd: [Python-checkins] commit of r41497 - python/trunk/Lib/test
by Neal Norwitz Dec. 18, 2005

Dec. 18, 2005

I just checked in the modification below. I'm not sure if this behaviour is on purpose or by accident. Do we want to support hex values in floats? Do we want to support p, similar to e in floats? Here are the lines from the test: + self.assertEqual(float(" 0x3.1 "), 3.0625) + self.assertEqual(float(" -0x3.p-1 "), -1.5) n ---------- Forwarded message ---------- From: neal.norwitz(a)python.org <neal.norwitz(a)python.org> Date: Nov 21, 2005 9:17 PM Subject: [Python-checkins] commit of r41497 - python/trunk/Lib/test To: python-checkins(a)python.org Author: neal.norwitz Date: Tue Nov 22 06:17:40 2005 New Revision: 41497 Modified: python/trunk/Lib/test/test_builtin.py Log: improve test coverage in Python/pystrtod.c and Python/mystrtoul.c. Modified: python/trunk/Lib/test/test_builtin.py ============================================================================== --- python/trunk/Lib/test/test_builtin.py (original) +++ python/trunk/Lib/test/test_builtin.py Tue Nov 22 06:17:40 2005 @@ -545,6 +545,34 @@ self.assertEqual(float(unicode(" 3.14 ")), 3.14) self.assertEqual(float(unicode(" \u0663.\u0661\u0664 ",'raw-unicode-escape')), 3.14) + def test_float_with_comma(self): + # set locale to something that doesn't use '.' for the decimal point + try: + import locale + orig_locale = locale.setlocale(locale.LC_NUMERIC, '') + locale.setlocale(locale.LC_NUMERIC, 'fr_FR') + except: + # if we can't set the locale, just ignore this test + return + + try: + self.assertEqual(locale.localeconv()['decimal_point'], ',') + except: + # this test is worthless, just skip it and reset the locale + locale.setlocale(locale.LC_NUMERIC, orig_locale) + return + + try: + self.assertEqual(float(" 3,14 "), 3.14) + self.assertEqual(float(" +3,14 "), 3.14) + self.assertEqual(float(" -3,14 "), -3.14) + self.assertEqual(float(" 0x3.1 "), 3.0625) + self.assertEqual(float(" -0x3.p-1 "), -1.5) + self.assertEqual(float(" 25.e-1 "), 2.5) + self.assertEqual(fcmp(float(" .25e-1 "), .025), 0) + finally: + locale.setlocale(locale.LC_NUMERIC, orig_locale) + def test_floatconversion(self): # Make sure that calls to __float__() work properly class Foo0: @@ -682,6 +710,7 @@ self.assertRaises(TypeError, int, 1, 12) self.assertEqual(int('0123', 0), 83) + self.assertEqual(int('0x123', 16), 291) def test_intconversion(self): # Test __int__() _______________________________________________ Python-checkins mailing list Python-checkins(a)python.org http://mail.python.org/mailman/listinfo/python-checkins

2 2

Bug bz2.BZ2File(...).seek(0,2) + patch
by Victor STINNER Dec. 9, 2005

Dec. 9, 2005

Hi, I found a bug in bz2 python module. Example: import bz2 bz2.BZ2File("test.bz2","r") bz2.seek(0,2) assert bz2.tell() != 0 Details and *patch* at: http://sourceforge.net/tracker/index.php?func=detail&aid=1366000&group_id=5… Please CC-me for all your answers. Bye, Victor -- Victor Stinner - student at the UTBM (Belfort, France) http://www.haypocalc.com/wiki/Accueil

3 2

Re: [Python-Dev] Short-circuiting iterators
by Edward Loper Dec. 8, 2005

Dec. 8, 2005

> I had an idea this morning for a simple extension to Python's iterator > protocol that would allow the user to force an iterator to raise > StopIteration on the next call to next(). My thought was to add a new > method to iterators called stop(). There's no need to change the iterator protocol for your example use case; you could just define a simple iterator-wrapper: class InterruptableIterator: stopped = False def __init__(self, iter): self.iter = iter() def next(self): if stopped: raise StopIteration('iterator stopped.') return self.iter.next() def stop(self): self.stopped = True And then just replace: > generator = some_generator_function() with: generator = InterruptableIterator(some_generator_function()) -Edward

4 7

ast-objects branch created
by "Martin v. Löwis" Dec. 7, 2005

Dec. 7, 2005

I created http://svn.python.org/projects/python/branches/ast-objects/ You can convert your repository to that branch with svn switch svn+ssh://pythondev@svn.python.org/python/branches/ast-objects in the toplevel directory. In particular, this features http://svn.python.org/projects/python/branches/ast-objects/Parser/asdl_c.py http://svn.python.org/projects/python/branches/ast-objects/Include/Python-a… http://svn.python.org/projects/python/branches/ast-objects/Python/Python-as… The status is currently this: - asdl_c generates a type hierarchy: "Sum" productions have one type per constructor, inheriting from a type for the sum; plain products only have a type for the product. - attributes are in the base type, accessible through o->_base.attr; projections of the product types are accessible directly through member names. - all projections must be non-NULL. Sequences are represented through potentially empty lists; optional types are potentially represented through Py_None. bool is gone; use Py_True/Py_False. The only primitive type remaining is int (which only occurs in lineno) - the types currently have only a constructor, a dealloc function, and an _Check macro. - Naming is this: for cross-object-file visible symbols (functions and global variables), a Py_ prefix is used. Otherwise, I use the type name or constructor name directly. There is a #define for the Py_<type>_New function, so you can also write <type>(params). Parameter order for the types is: projections first, then attributes. - For compatibility with the current code, the Sum base types also have the _kind enumeration (although that appears not to get initialized right now). For asdl_c, I see the following things as TODOs: - add support for traversing the types from C, through tp_members (read-only). Optionally add support for pickling. - add support for garbage collection. I don't expect this to be necessary right now, but will be if the API is exposed, and it doesn't cost much. The bigger chunk of necessary changes is in using these, starting with ast.c. Feel free to commit any changes to that branch that you consider helpful. To avoid duplicated work, posting a note here might also help. Regards, Martin

6 14

Proposed additional keyword argument in logging calls
by Vinay Sajip Dec. 5, 2005

Dec. 5, 2005

On numerous occasions, requests have been made for the ability to easily add user-defined data to logging events. For example, a multi-threaded server application may want to output specific information to a particular server thread (e.g. the identity of the client, specific protocol options for the client connection, etc.) This is currently possible, but you have to subclass the Logger class and override its makeRecord method to put custom attributes in the LogRecord. These can then be output using a customised format string containing e.g. "%(foo)s %(bar)d". The approach is usable but requires more work than necessary. I'd like to propose a simpler way of achieving the same result, which requires use of an additional optional keyword argument in logging calls. The signature of the (internal) Logger._log method would change from def _log(self, level, msg, args, exc_info=None) to def _log(self, level, msg, args, exc_info=None, extra_info=None) The extra_info argument will be passed to Logger.makeRecord, whose signature will change from def makeRecord(self, name, level, fn, lno, msg, args, exc_info): to def makeRecord(self, name, level, fn, lno, msg, args, exc_info, extra_info) makeRecord will, after doing what it does now, use the extra_info argument as follows: If type(extra_info) != types.DictType, it will be ignored. Otherwise, any entries in extra_info whose keys are not already in the LogRecord's __dict__ will be added to the LogRecord's __dict__. Can anyone see any problems with this approach? If not, I propose to post the approach on python-list and then if there are no strong objections, check it in to the trunk. (Since it could break existing code, I'm assuming (please correct me if I'm wrong) that it shouldn't go into the release24-maint branch.) Of course, if anyone can suggest a better way of doing it, I'm all ears :-) Regards, Vinay Sajip

9 13

Proposed additional keyword argument in logging calls
by Jim Jewett Dec. 3, 2005

Dec. 3, 2005

> I couldn't think of a good reason why it should be possible to overwrite these > values with values from a user-supplied dictionary, other than to spoof log > entries in some way. The intention is to stop a user accidentally overwriting > one of the above attributes. This makes sense, but is it worth the time to check on each logging call? -jJ

2 1

Memory management in the AST parser & compiler
by Nick Coghlan Dec. 1, 2005

Dec. 1, 2005

Transferring part of the discussion of Thomas Lee's PEP 341 patch to python-dev. . . Neal Norwitz wrote in the SF patch tracker: > Thomas, I hope you will write up this experience in coding > this patch. IMO it clearly demonstrates a problem with the > new AST code that needs to be addressed. ie, Memory > management is not possible to get right. I've got a 700+ > line patch to ast.c to correct many more memory issues > (hopefully that won't cause conflicts with this patch). I > would like to hear ideas of how the AST code can be improved > to make it much easier to not leak memory and be safe at the > same time. As Neal pointed out, it's tricky to write code for the AST parser and compiler without accidentally letting memory leak when the parser or compiler runs into a problem and has to bail out on whatever it was doing. Thomas's patch got to v5 (based on Neal's review comments) with memory leaks still in it, my review got rid of some of them, and we think Neal's last review of v6 of the patch got rid of the last of them. I am particularly concerned about the returns hidden inside macros in the AST compiler's symbol table generation and bytecode generation steps. At the moment, every function in compile.c which allocates code blocks (or anything else for that matter) and then calls one of the VISIT_* macros is a memory leak waiting to happen. Something I've seen used successfully (and used myself) to deal with similar resource-management problems in C code is to use a switch statement, rather than getting goto-happy. Specifically, the body of the entire function is written inside a switch statement, with 'break' then used as the equivalent of "raise Exception". For example: PyObject* switchAsTry() { switch(0) { default: /* Real function body goes here */ return result; } /* Error cleanup code goes here */ return NULL; } It avoids the potential for labelling problems that arises when goto's are used for resource cleanup. It's a far cry from real exception handling, but it's the best solution I've seen within the limits of C. A particular benefit comes when macros which may abort function execution are used inside the function - if those macros are rewritten to use break instead of return, then the function gets a chance to clean up after an error. Cheers, Nick. P.S. Getting rid of the flow control macros entirely is another option, of course, but it would make compile.c and symtable.c a LOT harder to follow. Raymond Chen's articles notwithstanding, a preprocessor-based mini-language does make sense in some situations, and I think this is one of them. Particularly since the flow control macros are private to the relevant implementation files. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

18 67

Python bug day this Sunday
by A.M. Kuchling Dec. 1, 2005

Dec. 1, 2005

Let's have a Python bug day this Sunday. One goal might be to assess bugs and patches, and make a list of ones we can work on at the Python core sprint at PyCon <http://wiki.python.org/moin/PyCon2006/Sprints/PythonCore>. Meeting on IRC: #python-dev on irc.freenode.net Date: Sunday, December 4th Time: roughly 9AM to 3PM Eastern (2PM to 8PM UTC). People on the US West Coast may want to show up from 9AM to 3PM Pacific time (12PM to 6PM Eastern), because it'll be more convenient. --amk

1 0

Standalone email package in the sandbox
by Barry Warsaw Dec. 1, 2005

Dec. 1, 2005

Unless there are any objections, I'd like to create a space in the sandbox for the standalone email package miscellany. This currently lives in the mimelib project's hidden CVS on SF, but that seems pretty silly. Basically I'm just going to add the test script, setup.py, generated html docs and a few additional unit tests, along with svn:external refs to pull in Lib/email from the appropriate Python svn tree. This way, I'll be able to create standalone email packages from the sandbox (which I need to do because I plan on fixing a few outstanding email bugs). -Barry

1 0

something is wrong with test___all__
by Reinhold Birkenfeld Dec. 1, 2005

Dec. 1, 2005

Hi, on my machine, "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. I can only suspect some AST bug here. Reinhold -- Mail address is perfectly valid!

2 2