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
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
>
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.
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
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/
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
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
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
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
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>