Re: [Python-Dev] Problem between deallocation of modules and func_globals
On 2007-01-18 20:53, Brett Cannon wrote: > I have discovered an issue relating to func_globals for functions and > the deallocation of the module it is contained within. Let's say you > store a reference to the function encodings.search_function from the > 'encodings' module (this came up in C code, but I don't see why it > couldn't happen in Python code). Then you delete the one reference to > the module that is stored in sys.modules, leading to its deallocation. > That triggers the setting of None to every value in > encodings.__dict__. > > Oops, now the global namespace for that module has everything valued > at None. The dict doesn't get deallocated since a reference is held > by encodings.search_function.func_globals and there is still a > reference to that (technically held in the interpreter's > codec_search_path field). So the function can still execute, but > throws exceptions like AttributeError because a module variable that > once held a dict now has None and thus doesn't have the 'get' method. That's a typical error situation you get in __del__ methods at the time the interpreter is shut down. The main reason for setting everything to None first is to break circular references and make sure that at least some of the object destructors can run. > My question is whether this is at all worth trying to rectify. Since > Google didn't turn anything up I am going to guess this is not exactly > a common thing. =) That would lead me to believe some (probably > most) of you will say, "just leave it alone and work around it". If you can come up with a better way, sure :-) > The other option I can think of is to store a reference to the module > instead of just to its __dict__ in the function. The problem with > that is we end up with a circular dependency of the functions in > modules having a reference to the module but then the module having a > reference to the functions. I tried not having the values in the > module's __dict__ set to None if the reference count was above 1 and > that solved this issue, but that leads to dangling references on > anything in that dict that does not have a reference stored away > somewhere else like encodings.search_function. > > Anybody have any ideas on how to deal with this short of rewriting > some codecs stuff so that they don't depend on global state in the > module or just telling me to just live with it? I'm not exactly sure which global state you are referring to. The aliase map, the cache used by the search function ? Note that the search function registry is a global managed in the thread state (it's not stored in any module). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 19 2007) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deletion order when leaving a scope?
Neil Toronto wrote: > I imagine this would be important to someone expecting system resources > to be cleaned up, closed, deallocated, or returned inside of __del__ > methods. Someone coming from C++ might expect LIFO behavior because > common idioms like RAII (Resource Allocation Is Instantiation) don't > work otherwise. A Java programmer wouldn't care, being used to cleaning > up resources manually with a try...catch...finally. > > I'm just putting a possible motivation on the concern. It happens that > the Pythonic Way is also the Java Way in this area: don't expect any > specific deletion order (don't even expect a guaranteed call to > __del__), and manually clean up after yourself. As a warning, this has > been the subject of a great many flame wars between C++ and Java > programmers... We know. Python 2.5 added a new statement (with) and a new standard library module (contextlib) to allow resource deallocation to be dealt with cleanly without requiring assumptions about the interpreter's memory model. While RAII isn't mentioned explicitly in the corresponding PEP (PEP 343), it was certainly a factor in the python-dev discussions. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] BangPycon 2007 - First Indian Python Conference : Call for Participation
Hi, The BangPypers (Bangalore Python Users Group) invite you to submit a proposal to present a technical paper or tutorial, or to host a meeting or BOF session at the first Indian Python conference here at St Josephs PG College Auditorium in Bangalore,India on March 3rd,2007. There are no fixed guidelines except for the below. 1) The talk has to be on a Pythonic Topic 2) It will be restricted to 45 mts with buffer for Q& A -10 mts 3) Though not mandatory, preference will be given to relevance of the topic with the agenda of the conference being "to promote Python" Though currently the plans of having a separate tutorial section is not on, we still want to hear from you, and we can see whether something can be fitted in... There might be just 10 talks split into 2 tracks. So please hurry up and send in your proposals. Your Proposal should be mailed conference AT bangpypers DOT org BangPycon First Indian Python Conference, March 3rd 2007, St Josephs PG College, Bangalore, India. Email: [EMAIL PROTECTED] http://groups.yahoo.com/group/bangpypers http://bangpypers.org -- Cheers. Anush Shetty ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deletion order when leaving a scope?
Nick Coghlan <[EMAIL PROTECTED]> writes: > Neil Toronto wrote: >> I imagine this would be important to someone expecting system resources >> to be cleaned up, closed, deallocated, or returned inside of __del__ >> methods. Someone coming from C++ might expect LIFO behavior because >> common idioms like RAII (Resource Allocation Is Instantiation) don't >> work otherwise. A Java programmer wouldn't care, being used to cleaning >> up resources manually with a try...catch...finally. >> >> I'm just putting a possible motivation on the concern. It happens that >> the Pythonic Way is also the Java Way in this area: don't expect any >> specific deletion order (don't even expect a guaranteed call to >> __del__), and manually clean up after yourself. As a warning, this has >> been the subject of a great many flame wars between C++ and Java >> programmers... > > We know. Python 2.5 added a new statement (with) and a new standard > library module (contextlib) to allow resource deallocation to be dealt > with cleanly without requiring assumptions about the interpreter's > memory model. > > While RAII isn't mentioned explicitly in the corresponding PEP (PEP > 343), it was certainly a factor in the python-dev discussions. It's mentioned in PEP 310, the predecessor to PEP 343. Cheers, mwh -- "I lacked the courage to investigate the weaknesses of the wicked, because I discovered they are the same as the weaknesses of the saintly." -- The Name Of The Rose, Umberto Eco ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem between deallocation of modules and func_globals
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Josiah Carlson schrieb: > > Seems to me like a bug, but the bug could be fixed if the module's > > dictionary kept a (circular) reference to the module object. Who else > > has been waiting for a __module__ attribute? > > This is the time machine at work: > > py> import encodings > py> encodings.search_function.__module__ > 'encodings' > > It's a string, rather than the module object, precisely to avoid cyclic > references. I was saying that it would be nice if the following were true: >>> encodings.__module__ That would make it easier for functions inside a module to pass around references to the module namespace (I've had the need to do so before, and have ended up using sys.modules[__name__], but that doesn't always work). So what if it is a circular reference (module references dict which references module), we've got a GC which handles cycles just fine (when users try not to be too smart). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem between deallocation of modules and func_globals
On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2007-01-18 20:53, Brett Cannon wrote: > > I have discovered an issue relating to func_globals for functions and > > the deallocation of the module it is contained within. Let's say you > > store a reference to the function encodings.search_function from the > > 'encodings' module (this came up in C code, but I don't see why it > > couldn't happen in Python code). Then you delete the one reference to > > the module that is stored in sys.modules, leading to its deallocation. > > That triggers the setting of None to every value in > > encodings.__dict__. > > > > Oops, now the global namespace for that module has everything valued > > at None. The dict doesn't get deallocated since a reference is held > > by encodings.search_function.func_globals and there is still a > > reference to that (technically held in the interpreter's > > codec_search_path field). So the function can still execute, but > > throws exceptions like AttributeError because a module variable that > > once held a dict now has None and thus doesn't have the 'get' method. > > That's a typical error situation you get in __del__ methods at > the time the interpreter is shut down. > Yeah, but in this case this is at the end of Py_Initialize() for the stuff I am doing to the interpreter. =) > The main reason for setting everything to None first is to > break circular references and make sure that at least some > of the object destructors can run. > I know the reason, it just happens to occur at a bad time for me. > > My question is whether this is at all worth trying to rectify. Since > > Google didn't turn anything up I am going to guess this is not exactly > > a common thing. =) That would lead me to believe some (probably > > most) of you will say, "just leave it alone and work around it". > > If you can come up with a better way, sure :-) > > > The other option I can think of is to store a reference to the module > > instead of just to its __dict__ in the function. The problem with > > that is we end up with a circular dependency of the functions in > > modules having a reference to the module but then the module having a > > reference to the functions. I tried not having the values in the > > module's __dict__ set to None if the reference count was above 1 and > > that solved this issue, but that leads to dangling references on > > anything in that dict that does not have a reference stored away > > somewhere else like encodings.search_function. > > > > Anybody have any ideas on how to deal with this short of rewriting > > some codecs stuff so that they don't depend on global state in the > > module or just telling me to just live with it? > > I'm not exactly sure which global state you are referring to. The > aliase map, the cache used by the search function ? > encodings._cache . > Note that the search function registry is a global managed > in the thread state (it's not stored in any module). > Right, but that is not the issue. If you have deleted the reference to the encodings module from sys.modules it then sets encodings._cache to None. After the deletion, if you try to encode/decode a unicode string you can an AttributeError about how encodings._cache does not have a 'get' method since it is now None instead of a dict. The function is fine and still runs, it's just that the global state it depends on is no longer the way it assume it should be. -Brett > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Jan 19 2007) > >>> Python/Zope Consulting and Support ...http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ > > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem between deallocation of modules and func_globals
On 1/18/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Brett Cannon schrieb: > > Anybody have any ideas on how to deal with this short of rewriting > > some codecs stuff so that they don't depend on global state in the > > module or just telling me to just live with it? > > There is an old patch by Armin Rigo ( python.org/sf/812369 ), which > attempts to implement shutdown based on gc, rather than the explicit > clearing of modules. It would be good if that could be put to work; > I don't know what undesirable side effects doing so would cause. > I will have a look. > Short of that, I don't think Python needs to support explicit deletion > of the encodings module from sys.modules when somebody still has a > reference to the search function. Don't do that, then. =) Yeah. As of this moment I am leaving __builtin__, exceptions, encodings, codecs, encodings.utf_8, warnings, and sys. I am deleting all other modules after Py_Initialize finishes its thing. I need to do a security audit on all of those modules before I permanently let them stick around (which is what I was hoping to avoid). I am also hoping make the sys module not be required to stay since it is only there because of the amount of stuff that is put into the module before its __dict__ is cached by the import machinery. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem between deallocation of modules and func_globals
On 2007-01-19 22:33, Brett Cannon wrote: >> That's a typical error situation you get in __del__ methods at >> the time the interpreter is shut down. >> > > Yeah, but in this case this is at the end of Py_Initialize() for the > stuff I am doing to the interpreter. =) Is that in some error branch of Py_Initialize() ? Otherwise I don't see how the modules could get garbage-collected. >> I'm not exactly sure which global state you are referring to. The >> aliase map, the cache used by the search function ? >> > > encodings._cache . > >> Note that the search function registry is a global managed >> in the thread state (it's not stored in any module). >> > > Right, but that is not the issue. If you have deleted the reference > to the encodings module from sys.modules it then sets encodings._cache > to None. After the deletion, if you try to encode/decode a unicode > string you can an AttributeError about how encodings._cache does not > have a 'get' method since it is now None instead of a dict. The > function is fine and still runs, it's just that the global state it > depends on is no longer the way it assume it should be. While I could add some tricks to have the cache dictionary stay alive even after the globals were set to None, I doubt that this will really fix the problem. The encoding package relies on the import mechanism, the codecs module and the _codecs builtin module. Any of these could fail to work depending on the order in which the modules get GCed. There's a reason why things in Py_Finalize() are as carefully ordered :-) Perhaps we need to apply some reordering to the steps in Py_Initialize() ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 19 2007) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem between deallocation of modules and func_globals
On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2007-01-19 22:33, Brett Cannon wrote: > >> That's a typical error situation you get in __del__ methods at > >> the time the interpreter is shut down. > >> > > > > Yeah, but in this case this is at the end of Py_Initialize() for the > > stuff I am doing to the interpreter. =) > > Is that in some error branch of Py_Initialize() ? Otherwise > I don't see how the modules could get garbage-collected. > Nope, it's code I am adding to clean out sys.modules of stuff the user didn't import themselves; it's for security reasons. > >> I'm not exactly sure which global state you are referring to. The > >> aliase map, the cache used by the search function ? > >> > > > > encodings._cache . > > > >> Note that the search function registry is a global managed > >> in the thread state (it's not stored in any module). > >> > > > > Right, but that is not the issue. If you have deleted the reference > > to the encodings module from sys.modules it then sets encodings._cache > > to None. After the deletion, if you try to encode/decode a unicode > > string you can an AttributeError about how encodings._cache does not > > have a 'get' method since it is now None instead of a dict. The > > function is fine and still runs, it's just that the global state it > > depends on is no longer the way it assume it should be. > > While I could add some tricks to have the cache dictionary stay > alive even after the globals were set to None, I doubt that this > will really fix the problem. > > The encoding package relies on the import mechanism, the codecs > module and the _codecs builtin module. Any of these could fail > to work depending on the order in which the modules get > GCed. > > There's a reason why things in Py_Finalize() are as carefully > ordered :-) Perhaps we need to apply some reordering to the > steps in Py_Initialize() ?! > Nah, I just need to not delete the modules. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem between deallocation of modules and func_globals
Josiah Carlson schrieb: > I was saying that it would be nice if the following were true: > > >>> encodings.__module__ > Ah, ok. It would be somewhat confusing, though, that __module__ is sometimes a module object, and sometimes a string (it certainly confused me). > So what if it is a circular reference (module references dict which > references module), we've got a GC which handles cycles just fine (when > users try not to be too smart). That remains to be seen in practice. Currently, modules are explicitly cleared at shutdown. I think any cycle with an object implementing __del__ will keep loads of modules alive, noncollectable for GC. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Floor division
I bumped into an oddity today: 6.0 // 0.001 != math.floor(6.0 / 0.001) In looking at Objects/floatobject.c, I was surprised to find that float_floor_division() is implemented in terms of float_divmod(). Does anyone know why it takes such a circuitous path? I had expected something simpler and faster: return PyFloat_FromDouble(floor(a/b)); Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
Probably because I tend not to know what I'm doing when numerics are concerned. :-( On 1/19/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I bumped into an oddity today: > > 6.0 // 0.001 != math.floor(6.0 / 0.001) > > In looking at Objects/floatobject.c, I was surprised to find that > float_floor_division() is implemented in terms of float_divmod(). Does anyone > know why it takes such a circuitous path? I had expected something simpler > and > faster: > > return PyFloat_FromDouble(floor(a/b)); > > > Raymond > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
[Raymond Hettinger]
> I bumped into an oddity today:
>
> 6.0 // 0.001 != math.floor(6.0 / 0.001)
>
> In looking at Objects/floatobject.c, I was surprised to find that
> float_floor_division() is implemented in terms of float_divmod(). Does anyone
> know why it takes such a circuitous path? I had expected something simpler
> and
> faster:
>
> return PyFloat_FromDouble(floor(a/b));
To preserve, so far as is possible with floats, that
(*)a == (a//b)*b + a%b
In this case the binary double closest to decimal 0.001 is
0.00120816681711721685132943093776702880859375
which is a little bit larger than 1/1000. Therefore the mathematical
value of a/b is a little bit smaller than 6/(1/1000) = 6000, and the
true floor of the mathematically correct result is 5999.
a % b is always computed exactly (mathematical result == machine
result) under Python's definition whenever a and b have the same sign
(under C99's and the `decimal` module's definition it's always exact
regardless of signs), and getting the exact value for a%b implies the
exact value for a//b must also be returned (when possible) in order to
preserve identity (*) above.
IOW, since
>>> 6.0 % 0.001
0.00087512
it would be inconsistent to return 6000 for 6.0 // 0.001:
>>> 6.0 - 6000 * 0.001 # this isn't close to the value of a%b
0.0
>>> 6.0 - 5999 * 0.001 # but this is close
0.00044578
Note that two rounding errors occur in computing a - N*b via binary
doubles. If there were no rounding errors, we'd have
6 % b == 6.0 - 5999 * b
exactly where
b =
0.00120816681711721685132943093776702880859375
is the value actually stored in the machine for 0.001:
>>> import decimal
>>> decimal.getcontext().prec = 1000 # way more than needed
>>> import math
>>> # Set b to exact decimal value of binary double closest to 0.001.
>>> m, e = math.frexp(0.001)
>>> b = decimal.Decimal(int(m*2**53)) / decimal.Decimal(1 << (53-e))
>>> # Then 6%b is exactly equal to 6 - 5999*b
>>> 6 % b == 6 - 5999*b
True
>>> # Confirm that all decimal calculations were exact.
>>> decimal.getcontext().flags[decimal.Inexact]
False
>>> # Confirm that floor(6/b) is 5999.
>>> int(6/b)
5999
>>> print 6/b
5999.87509990972966989180234686226...
All that said, (*) doesn't make a lot of sense for floats to begin
with (for that matter, Python's definition of mod alone doesn't make
much sense for floats when the signs differ -- e.g.,
>>> -1 % 1e100
1e+100
>>> decimal.Decimal(-1) % decimal.Decimal("1e100")
Decimal("-1")
).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 423 open ( +2) / 3539 closed ( +9) / 3962 total (+11)
Bugs: 960 open ( -3) / 6446 closed (+20) / 7406 total (+17)
RFE : 258 open ( +3) / 249 closed ( +3) / 507 total ( +6)
New / Reopened Patches
__
Add aliases for latin7/9/10 charsets (2007-01-13)
http://python.org/sf/1634778 opened by Christoph Zwerschke
htonl et al accept negative ints (2007-01-14)
CLOSED http://python.org/sf/1635058 opened by Mark Roberts
Logging Module - followfile patch (2006-11-17)
CLOSED http://python.org/sf/1598415 reopened by cjschr
CSV DictWriter Errors (2007-01-14)
http://python.org/sf/1635454 opened by Mark Roberts
strptime %F and %T directives (2007-01-14)
CLOSED http://python.org/sf/1635473 opened by Mark Roberts
File Read/Write Flushing Patch (2007-01-16)
http://python.org/sf/1636874 opened by jurojin
urllib: change email.Utils -> email.utils (2007-01-16)
http://python.org/sf/1637157 opened by Russell Owen
urllib2: email.Utils->email.utils (2007-01-16)
http://python.org/sf/1637159 opened by Russell Owen
smtplib email renames (2007-01-16)
http://python.org/sf/1637162 opened by Russell Owen
Add httponly to Cookie module (2007-01-17)
http://python.org/sf/1638033 opened by Arvin Schnell
compiler.pycodegen causes crashes when compiling 'with' (2007-01-17)
http://python.org/sf/1638243 opened by kirat
Fix to the long("123\0", 10) problem (2007-01-18)
http://python.org/sf/1638879 opened by Calvin Spealman
email.utils.parsedate documentation (2007-01-19)
http://python.org/sf/1639973 opened by Mark Roberts
Patches Closed
__
platform.py support for IronPython (2006-09-23)
http://python.org/sf/1563842 closed by lemburg
Small upgrades to platform.platform() (2005-11-10)
http://python.org/sf/1352731 closed by lemburg
pybench support for IronPython (2006-09-23)
http://python.org/sf/1563844 closed by lemburg
Py3k: Fix pybench so it runs (2007-01-12)
http://python.org/sf/1634499 closed by gvanrossum
Bug fixes for int unification branch (2006-12-20)
http://python.org/sf/1619846 closed by gvanrossum
htonl et al accept negative ints (2007-01-14)
http://python.org/sf/1635058 closed by gvanrossum
Logging Module - followfile patch (2006-11-17)
http://python.org/sf/1598415 closed by vsajip
strptime %F and %T directives (2007-01-14)
http://python.org/sf/1635473 closed by bcannon
BSD version of ctypes.util.find_library (2006-12-07)
http://python.org/sf/1610795 closed by theller
New / Reopened Bugs
___
Problem running a subprocess (2007-01-13)
http://python.org/sf/1634739 opened by Florent Rougon
locale 1251 does not convert to upper case properly (2007-01-13)
http://python.org/sf/1634774 opened by Ivan Dobrokotov
Little mistake in docs (2007-01-14)
http://python.org/sf/1635217 opened by anatoly techtonik
Add registry functions to windows postinstall (2007-01-14)
http://python.org/sf/1635335 opened by anatoly techtonik
expanduser tests in test_posixpath fail if $HOME ends in a / (2007-01-14)
CLOSED http://python.org/sf/1635353 opened by Marien Zwart
Add command line help to windows unistall binary (2007-01-14)
http://python.org/sf/1635363 opened by anatoly techtonik
ConfigParser does not quote % (2007-01-15)
http://python.org/sf/1635639 opened by Mark Roberts
Interpreter seems to leak references after finalization (2007-01-15)
http://python.org/sf/1635741 opened by B Sizer
description of the beta distribution is incorrect (2007-01-15)
CLOSED http://python.org/sf/1635892 opened by elgordo
Newline skipped in "for line in file" (2007-01-16)
http://python.org/sf/1636950 opened by Andy Monthei
Python-2.5 segfault with tktreectrl (2007-01-16)
CLOSED http://python.org/sf/1637022 opened by klappnase
Python 2.5 fails to build on AIX 5.3 (xlc_r compiler) (2007-01-16)
http://python.org/sf/1637120 opened by Orlando Irrazabal
mailbox.py uses old email names (2007-01-16)
http://python.org/sf/1637167 opened by Russell Owen
make_table in difflib does not work with unicode (2007-01-18)
http://python.org/sf/1637850 opened by y-unno
Problem packaging wx application with py2exe. (2007-01-17)
CLOSED http://python.org/sf/1637943 opened by Indy
typohttp://www.python.org/doc/current/tut/node10.html (2007-01-17)
CLOSED http://python.org/sf/1637952 opened by jim pruett
langref: missing item in numeric op list (2007-01-17)
CLOSED http://python.org/sf/1637967 opened by paul rubin
Incorrect documentation for random.betavariate() (2007-01-18)
CLOSED http://python.org/sf/1638627 opened by Troels Walsted Hansen
Bugs Closed
___
class derived from float evaporates under += (2007-01-11)
