without calling PyType_Ready().
Question 1: Should the interpreter register all types with PyType_Ready()?
Many types seem to avoid it.
Question 2: To reproduce the problem, run the following code:
def f():
while True:
for a in iter(range(0,1,10**20)):
pass
f()
And watch the memory used by the process.
How do we test this in a unittest?
external symbol PyObject_Unicode'.
Building _ssl than hangs the build server because starting python.exe
displayes a message box that 'Python30.dll' cannot be found.
Temporary (?) solution: Look for existance of python30.dll and fail
the _ssl build when it is missing.
Tested on Windows by Christian Heimes.
I changed the code slightly, renaming decref_socketios() to
_decref_socketios(), and moving it closer to the close() method
that it calls. Hopefully Bill can now submit his SSL port to 3.0.
After a long discussion about the problem with Windows GUI apps Guido decided that sys.stdin, stdout and stderr should be None when the C runtime library returns invalid file descriptors for the standard streams.
So far the only known cases are Windows GUI apps and scripts started with pythonw on Windows. The OS restrictions are tight enough to catch the problem on other OSes.
When an unfinished generator-iterator is garbage collected, PyEval_EvalFrameEx
is called with a GeneratorExit exception set. This leads to funny results
if the sys.settrace function itself makes use of generators.
A visible effect is that the settrace function is reset to None.
Another is that the eventual "finally" block of the generator is not called.
It is necessary to save/restore the exception around the call to the trace
function.
This happens a lot with py3k: isinstance() of an ABCMeta instance runs
def __instancecheck__(cls, instance):
"""Override for isinstance(instance, cls)."""
return any(cls.__subclasscheck__(c)
for c in {instance.__class__, type(instance)})
which lets an opened generator expression each time it returns True.
Seems a backport candidate, even if the case is less frequent in 2.5.
Added some more methods and attributes to stdprinter to ease up debugging #1415 on Windows. It also makes the object more file like. Now it can be used as a working replacement for an io instance.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r58931 | vinay.sajip | 2007-11-11 15:27:30 +0100 (Sun, 11 Nov 2007) | 1 line
Fixed a bug reported (in private email, by Robert Crida) in logging configuration whereby child loggers of a logger named in a configuration file, which are not themselves named in the configuration, are disabled when the configuration is applied.
........
r58932 | georg.brandl | 2007-11-11 16:16:16 +0100 (Sun, 11 Nov 2007) | 2 lines
Remove duplication of "this".
........
r58935 | christian.heimes | 2007-11-12 02:15:40 +0100 (Mon, 12 Nov 2007) | 2 lines
Added new decorator syntax to property.__doc__
Guido prefers _x over __x.
........
r58936 | christian.heimes | 2007-11-12 02:20:56 +0100 (Mon, 12 Nov 2007) | 2 lines
Fix for #1427: Error in standard module calendar
the prweek() method is still broken and I can't figure out how it suppose to work.
........
r58938 | andrew.kuchling | 2007-11-12 02:25:21 +0100 (Mon, 12 Nov 2007) | 1 line
Re-word sentence
........
raw string literals. I added a whole bunch of tests but am still not sure
I am testing all paths through the code. I really think the code could be
simplified quite a bit.
On Windows fileno(stdout) and fileno(stderr) can return an invalid file descriptor number (-2 on my machine). It happens only for pythonw.exe but not for python.exe.
Catch the problem ASAP in PyFile_NewStdPrinter(). I've also removed the call to PyErr_BadInternalCall(). It was causing a seg fault because the exceptions aren't available yet.
I figured out that the files may suite other developers. The files take care of most problems and makes building Python on Windows easier. Simply double click on build_env.bat to open a shell and type build.
The patch doesn't do the whole name mangling mambo jambo on purpose. MS sure does some weird things and I don't feel like reimplementing ntpath.normpath in C. If the user does deliberately something stupid he is on his own.
TODO: Backport to 2.6 (maybe 2.5?) and document that users should only do sys.path.append(os.path.normpath(somepath)) if they want to be on the safe side.
No detailed change log; just check out the change log for the py3k-pep3137
branch. The most obvious changes:
- str8 renamed to bytes (PyString at the C level);
- bytes renamed to buffer (PyBytes at the C level);
- PyString and PyUnicode are no longer compatible.
I.e. we now have an immutable bytes type and a mutable bytes type.
The behavior of PyString was modified quite a bit, to make it more
bytes-like. Some changes are still on the to-do list.