Python-Dev June 2007

python-dev@python.org

66 participants
76 discussions

by Eyal Lotem

Hi. It seems that cProfile does not support throwing exceptions into generators properly, when an external timer routine is used. The problem is that _lsprof.c: ptrace_enter_call assumes that there are no exceptions set when it is called, which is not true when the generator frame is being gen_send_ex'd to send an exception into it (Maybe you could say that only CallExternalTimer assumes this, but I am not sure). This assumption causes its eventual call to CallExternalTimer to discover that an error is set and assume that it was caused by its own work (which it wasn't). I am not sure what the right way to fix this is, so I cannot send a patch. Here is a minimalist example to reproduce the bug: >>> import cProfile >>> import time >>> p=cProfile.Profile(time.clock) >>> def f(): ... yield 1 ... >>> p.run("f().throw(Exception())") Exception exceptions.Exception: Exception() in <cProfile.Profile object at 0xb7f5a304> ignored Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.5/cProfile.py", line 135, in run return self.runctx(cmd, dict, dict) File "/usr/lib/python2.5/cProfile.py", line 140, in runctx exec cmd in globals, locals File "<string>", line 1, in <module> File "<stdin>", line 1, in f SystemError: error return without exception set

13 years, 10 months

Re: [Python-Dev] [Python-checkins] buildbot failure in x86 W2k trunk

by Brett Cannon

For removing extension modules from the build process on Windows, do you just delete the File entry from PCbuild/pythoncore.vcproj? -Brett On 5/20/07, buildbot(a)python.org <buildbot(a)python.org> wrote: > > The Buildbot has detected a new failure of x86 W2k trunk. > Full details are available at: > http://www.python.org/dev/buildbot/all/x86%2520W2k%2520trunk/builds/290 > > Buildbot URL: http://www.python.org/dev/buildbot/all/ > > Build Reason: > Build Source Stamp: [branch trunk] HEAD > Blamelist: brett.cannon > > BUILD FAILED: failed compile > > sincerely, > -The Buildbot > > _______________________________________________ > Python-checkins mailing list > Python-checkins(a)python.org > http://mail.python.org/mailman/listinfo/python-checkins >

13 years, 10 months

Representation of 'nan'

by Pete Shinners

The repr() for a float of 'inf' or 'nan' is generated as a string (not a string literal). Perhaps this is only important in how one defines repr(). I've filed a bug, but am not sure if there is a clear solution. https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1732212&group_… # Repr with a tuple of floats >>> repr((1.0, 2.0, 3.0)) '(1.0, 2.0, 3.0)' >>> eval(_) (1.0, 2.0, 3.0) # Repr with a tuple of floats, plus nan >>> repr((1.0, float('nan'), 3.0)) '(1.0, nan, 3.0)' >>> eval(_) NameError: name 'nan' is not defined There are a few alternatives I can think are fairly clean. I think I'd prefer any of these over the current 'nan' implementation. I don't think it is worth adding a nan literal into the language. But something could be changed so that repr of nan meant something. Best option in my opinion would be adding attributes to float, so that float.nan, float.inf, and float.ninf are accessable. This could also help with the odd situations of checking for these out of range values. With that in place, repr could return 'float.nan' instead of 'nan'. This would make the repr string evaluatable again. (In contexts where __builtins__ has not been molested) Another option could be for repr to return 'float("nan")' for these, which would also evaluate correctly. But this doesn't seem a clean use for repr. Is this worth even changing? It's just an irregularity that has come up and surprised a few of us developers.

13 years, 10 months

NaN / Infinity in Python

by Armin Ronacher

Hi, It's one of those "non issues" but there are still some situations where you have to deal with Infinity and NaN, even in Python. Basically one the problems is that the repr of floating point numbers is platform depending and sometimes yields "nan" which is not evaluable. It's true that eval() is probably a bad thing but there are some libraries that use repr/%r for code generation and it could happen that they produce erroneous code because of that. Also there is no way to get the Infinity and NaN values and also no way to test if they exist. Maybe changing the repr of `nan` to `math.NaN` and `inf` to `math.Infinity` as well as `-inf` to `(-math.Infinity)` and add that code to the math module (of course as a C implementation, there are even macros for testing for NaN values):: Infinity = 1e10000 NaN = Infinity / Infinity def is_nan(x): return type(x) is float and x != x def is_finite(x): return x != Infinity Bugs related to this issue: - http://bugs.python.org/1732212 [repr of 'nan' floats not parseable] - http://bugs.python.org/1481296 [long(float('nan'))!=0L] Regards, Armin

13 years, 10 months

Timeout in urllib2.urlopen

by Facundo Batista

facundo@expiron:~/devel/reps/python/trunk$ ./python Python 2.6a0 (trunk, Jun 6 2007, 12:32:23) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib2 >>> u = urllib2.urlopen("http://www.taniquetil.com.ar/plog") >>> u.headers.items() [..., ('content-type', 'text/html;charset=iso-8859-1'), ...] >>> >>> u = urllib2.urlopen("http://www.taniquetil.com.ar/plog", timeout=3) Traceback (most recent call last): ... urllib2.URLError: <urlopen error timed out> >>> Ok, my blog is a bit slow, but the timeout is working ok, :D Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

13 years, 10 months

minimal configuration for python on a DSP (C64xx family of TI)

by Roland Geibel

Dear all. We want to make python run on DSP processors (C64xx family of TI). Which would be a minimal configuration (of modules, C-files, ... ) to make it start running (without all of the things useful to add, once it runs). Any hints welcome Roland Geibel Geibel(a)vision-comp.com Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail

13 years, 10 months

Patch reviews

by BJörn Lindqvist

Here is a review of some patches: * [ 1673759 ] '%G' string formatting doesn't catch same errors as '%g' This patch is done, has been reviewed and works as advertised. Just needs someone to commit it I think. * [ 1100942 ] datetime.strptime constructor added Doesn't apply cleanly, emits compiler warnings, but works as expected. Lacks tests. * [ 968063 ] Add fileinput.islastline() Good and useful patch (see the pup.py program) but lacks unit tests and documentation. * [ 1501979 ] syntax errors on continuation lines Doesn't apply cleanly, but that is easy to fix. Needs someone to fix a few minor flaws in it, but the patch works really well. * [ 1375011 ] Improper handling of duplicate cookies Fixes a fairly exotic bug in which Pythons cookie handling deviates in an obscure way from Netscapes cookie specification. See the bug about it at 1372650. As far as I can understand, the patch fixes the problem. If someone still does the 5 for 1 deal, my patch is [ 1676135 ]. -- mvh Björn

13 years, 10 months

popen test case inquiry in r55735 using PCBuild8

by Joseph Armbruster

All, I wanted to pass this one around before opening an issue on it. When running the unit test for popen via rt.bat (in PCBuild8), I received the following error: === BEGIN ERROR === C:\Documents and Settings\joe\Desktop\Development\Python\trunk\PCbuild8>rt test_popen Deleting .pyc/.pyo files ... 43 .pyc deleted, 0 .pyo deleted C:\Documents and Settings\joe\Desktop\Development\Python\trunk\PCbuild8>win32Release\python.exe -E -tt ../lib/test/regrtest.py te st_popen test_popen test test_popen failed -- Traceback (most recent call last): File "C:\Documents and Settings\joe\Desktop\Development\Python\trunk\lib\test\test_popen.py", line 31, in test_popen ["foo", "bar"] File "C:\Documents and Settings\joe\Desktop\Development\Python\trunk\lib\test\test_popen.py", line 24, in _do_test_commandline got = eval(data)[1:] # strip off argv[0] File "<string>", line 0 ^ SyntaxError: unexpected EOF while parsing 1 test failed: test_popen === END ERROR === Only naturally, I looked into what was causing it and noticed the following: Line 23 of the test_popen.py appears to be returning '' and assigning this to data. data = os.popen(cmd).read() The problem with is, the next line (24) assumes the previous line will work and goes on to perform the following strip and assert: got = eval(data)[1:] # strip off argv[0] self.assertEqual(got, expected) So, in a perfect world, ['-c','foo','bar']\n is what data Should be. I put some quick debug statements after line 23 in test_popen.py to verify this and I observed the following: data= cmd= "C:\Documents and Settings\joe\Desktop\Development\Python\trunk\PCbuild8\win32Release\python.exe" -c "import sys;print sys.argv" foo bar Now, on to the 'interesting' part. From the command line, observe the following: C:\Documents and Settings\joe\Desktop\Development\Python\trunk\PCbuild8\win32release>python -c "import sys; print sys.argv" foo bar ['-c', 'foo', 'bar'] Outside of the popen call failing. I am wondering if an appropriate assert should be performed on the data object, prior to line 24. In addition, if you debug into the posixmodule, this is the scoop: 1. breakpoint set in posixmodule at the start of posix_popen 2. i run in debug 3. run the following: import os tmp = os.popen('"C:/Documents and Settings/joe/Desktop/Development/Python/trunk/PCbuild8/win32Release/python.exe" -c "import sys;print sys.argv" foo bar') 3. call enters posixmodule posix_popen and follows path: f = _PyPopen(cmdstring, tm | _O_TEXT, POPEN_1); 4. enters posixmodule: _PyPopen 5. enters posixmodule: _PyPopenCreateProcess 6. enters posixmodule linen 4920 where the CreateProcess is... s2 checks out as: "C:\WINDOWS\system32\cmd.exe /c "C:/Documents and Settings/joe/Desktop/Development/Python/trunk/PCbuild8/win32Release/python.exe" -c "import sys;print sys.argv" foo bar" this call returns nonzero, which means it "succeeded". see: [ http://msdn2.microsoft.com/en-us/library/ms682425.aspx ] On another note, I ran across CreateProcessW and am interested in questioning whether or not this has a place in posixmodule? Any on yet another note, when I ran test_popen.py straight from /lib (using my std::Python25 install, I obtained the following debug output in the same statement of interest) data=['-c', 'foo', 'bar'] cmd=c:\python25\python.exe -c "import sys;print sys.argv" foo bar Your thoughts ? Joseph Armbruster

13 years, 10 months

Patch #1731330 - pysqlite_cache_display - missing Py_DECREF

by Tim Delaney

I've added patch #1731330 to fix a missing Py_DECREF in pysqlite_cache_display. I've attached the diff to this email. I haven't actually been able to test this - haven't been able to get pysqlite compiled here on cygwin yet. I just noticed it when taking an example of using PyObject_Print ... Cheers, Tim Delaney

13 years, 10 months

vs2005 Project Patch and Configuration Inquiry

by Joseph Armbruster

All, As per the removal of the rgbimgmodule due to deprecation in the trunk: http://svn.python.org/projects/python/trunk ---Begin SVN log--- r55458 | brett.cannon | 2007-05-20 03:09:50 -0400 (Sun, 20 May 2007) | 2 lines Remove the rgbimg module. It has been deprecated since Python 2.5. ---End SVN log--- The PCbuild8 solution needs to be corrected. A patch is attached. In addition, I noticed that under C++/Advanced Properties, all the configurations appear to be set to "Compile as C++ Code" with the /TP argument. Should these be set to "Compile as C Code" with the /TC argument? Joseph Armbruster Index: PCbuild8/pythoncore/pythoncore.vcproj =================================================================== --- PCbuild8/pythoncore/pythoncore.vcproj (revision 55600) +++ PCbuild8/pythoncore/pythoncore.vcproj (working copy) @@ -1518,10 +1518,6 @@ > </File> <File - RelativePath="..\..\Modules\rgbimgmodule.c" - > - </File> - <File RelativePath="..\..\Modules\rotatingtree.c" > </File>

13 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev June 2007