[ python-Bugs-1495488 ] make altinstall installs pydoc
Bugs item #1495488, was opened at 2006-05-26 12:19
Message generated for change (Comment added) made by charlesmerriam
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Heaney (theaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: make altinstall installs pydoc
Initial Comment:
I did the "make altinstall" rather than the "make
install" as suggested on
http://www.python.org/download/releases/2.5/
This worked great, creating a
/usr/local/bin/python2.5
which doesn't clash with my /usr/bin/python. However,
it also created a
/usr/local/bin/pydoc
which did clash with my /usr/bin/pydoc. I just removed
it and all is well. Should altinstall not create pydoc?
It could create pydoc2.5 rather than pydoc, but then
the shebang line would have to be changed to python2.5.
What about smtpd.py, idle, and python-config, which
were also created by altinstall? They don't currently
conflict with anything I have for Python 2.4, but the
potential is there for the same problem.
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 08:12
Message:
Logged In: YES
user_id=1581732
A bit more background; I'm starting to appreciate the
problem. The makefile plays a part, but the real problem is
down is down in Lib/distutils/command/install_scripts.py.
Makefile/altinstall builds
Makefile/sharedinstall executes
setup.py imports
distutils.core/setup() invokes indirectly
distuitls.commands/install_scripts.py
And install_scripts.py needs to be taught about the
suffixes, or be passed a new destination filename.
Note that setup() must be backward compatible back several
versions.
So it seems like the problems are:
1. Change the Makefile target sharedinstall to somehow pass
the right suffix into setup. Also make sharedinstall alter
the scripts to call the right version of python.
2. Change the Makefile target bininstall to add hard links
for the scripts, e.g., from pydoc2.5 to pydoc.
3. Somehow pick up the parameters in
Lib/distutils/commands/install_scripts.py and tack on the
right suffix when copying.
I'll whack at it tomorrow.
--
Comment By: Tim Heaney (theaney)
Date: 2006-08-23 00:39
Message:
Logged In: YES
user_id=827666
Yeah, that's what the sed command is for.
By the way, it looks like python-config is taken care of in
release candidate 1. That is, after doing the altinstall for
2.5c1, I did
# for file in pydoc idle smtpd.py; do
mv $file ${file}2.5
sed -i
's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5
done
to fix things up.
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-22 23:50
Message:
Logged In: YES
user_id=1581732
Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc
would not have worked anyway. It's first line:
#!/usr/local/bin/python
would give an error because only /usr/local/bin/python2.5
exists.
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-22 00:14
Message:
Logged In: YES
user_id=827666
Sorry, I haven't had a chance to look at this again. I just
installed Python-2.5b1 and it's still the same way. Here's
what I did to fix things up after the make altinstall...
# cd /usr/local/bin
# for file in pydoc idle smtpd.py python-config; do
mv $file ${file}2.5
sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@'
${file}2.5
done
Now, how to fix up the Makefile.pre and setup.py so this
isn't necessary...
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-06 11:19
Message:
Logged In: YES
user_id=827666
I'm not sure I know how. It looks like the downloaded files
have the following shebang lines
Tools/scripts/pydoc => #!/usr/bin/env python
Tools/scripts/idle=> #! /usr/bin/env python
Lib/smtpd.py => #! /usr/bin/env python
Misc/python-config.in => [EMAIL PROTECTED]@/python
whereas the installed files have
/usr/local/bin/pydoc => #!/usr/local/bin/python
/usr/local/bin/idle => #!/usr/local/bin/python
/usr/local/bin/smtpd.py => #!/usr/local/bin/python
/usr/local/bin/python-config => #!/usr/local/bin/python
so they're already getting rewritten somewhere. We want both
their names and their shebang lines to have the version
/usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5
/usr/local/bin/smtpd.py2.5 => #!/usr/lo
[ python-Bugs-1514428 ] NaN comparison in Decimal broken
Bugs item #1514428, was opened at 2006-06-29 16:19
Message generated for change (Comment added) made by charlesmerriam
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm)
Assigned to: Raymond Hettinger (rhettinger)
Summary: NaN comparison in Decimal broken
Initial Comment:
Methinks this is a bit off :-) True should be False.
Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46)
[GCC 4.1.0 (SUSE Linux)] on linux2
>>> import decimal
>>> d = decimal.Decimal
>>> inf = d("inf")
>>> nan = d("nan")
>>> nan > inf
True
>>> nan < inf
False
>>> inf > nan
True
>>> inf < nan
False
b
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 08:43
Message:
Logged In: YES
user_id=1581732
More specifically, any comparison with a NaN should equal
False, even inf, per IEEE 754. A good starting point to
convince oneself of this is http://en.wikipedia.org/wiki/NaN.
--
Comment By: Nick Maclaren (nmm)
Date: 2006-07-13 10:35
Message:
Logged In: YES
user_id=42444
It's still there in Beta 2.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544762 ] x!=y and [x]==[y] (!)
Bugs item #1544762, was opened at 2006-08-22 17:51 Message generated for change (Comment added) made by charlesmerriam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex ([EMAIL PROTECTED]) -- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 08:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. -- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 22:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1495488 ] make altinstall installs pydoc
Bugs item #1495488, was opened at 2006-05-26 14:19
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Heaney (theaney)
Assigned to: Nobody/Anonymous (nobody)
Summary: make altinstall installs pydoc
Initial Comment:
I did the "make altinstall" rather than the "make
install" as suggested on
http://www.python.org/download/releases/2.5/
This worked great, creating a
/usr/local/bin/python2.5
which doesn't clash with my /usr/bin/python. However,
it also created a
/usr/local/bin/pydoc
which did clash with my /usr/bin/pydoc. I just removed
it and all is well. Should altinstall not create pydoc?
It could create pydoc2.5 rather than pydoc, but then
the shebang line would have to be changed to python2.5.
What about smtpd.py, idle, and python-config, which
were also created by altinstall? They don't currently
conflict with anything I have for Python 2.4, but the
potential is there for the same problem.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-08-23 16:20
Message:
Logged In: YES
user_id=21627
I don't think you have to pass the version to setup.py. Instead, setup.py can
just
use sys.version_info (since it is being run with the "right" interpreter).
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 10:12
Message:
Logged In: YES
user_id=1581732
A bit more background; I'm starting to appreciate the
problem. The makefile plays a part, but the real problem is
down is down in Lib/distutils/command/install_scripts.py.
Makefile/altinstall builds
Makefile/sharedinstall executes
setup.py imports
distutils.core/setup() invokes indirectly
distuitls.commands/install_scripts.py
And install_scripts.py needs to be taught about the
suffixes, or be passed a new destination filename.
Note that setup() must be backward compatible back several
versions.
So it seems like the problems are:
1. Change the Makefile target sharedinstall to somehow pass
the right suffix into setup. Also make sharedinstall alter
the scripts to call the right version of python.
2. Change the Makefile target bininstall to add hard links
for the scripts, e.g., from pydoc2.5 to pydoc.
3. Somehow pick up the parameters in
Lib/distutils/commands/install_scripts.py and tack on the
right suffix when copying.
I'll whack at it tomorrow.
--
Comment By: Tim Heaney (theaney)
Date: 2006-08-23 02:39
Message:
Logged In: YES
user_id=827666
Yeah, that's what the sed command is for.
By the way, it looks like python-config is taken care of in
release candidate 1. That is, after doing the altinstall for
2.5c1, I did
# for file in pydoc idle smtpd.py; do
mv $file ${file}2.5
sed -i
's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5
done
to fix things up.
--
Comment By: CharlesMerriam (charlesmerriam)
Date: 2006-08-23 01:50
Message:
Logged In: YES
user_id=1581732
Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc
would not have worked anyway. It's first line:
#!/usr/local/bin/python
would give an error because only /usr/local/bin/python2.5
exists.
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-22 02:14
Message:
Logged In: YES
user_id=827666
Sorry, I haven't had a chance to look at this again. I just
installed Python-2.5b1 and it's still the same way. Here's
what I did to fix things up after the make altinstall...
# cd /usr/local/bin
# for file in pydoc idle smtpd.py python-config; do
mv $file ${file}2.5
sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@'
${file}2.5
done
Now, how to fix up the Makefile.pre and setup.py so this
isn't necessary...
--
Comment By: Tim Heaney (theaney)
Date: 2006-06-06 13:19
Message:
Logged In: YES
user_id=827666
I'm not sure I know how. It looks like the downloaded files
have the following shebang lines
Tools/scripts/pydoc => #!/usr/bin/env python
Tools/scripts/idle=> #! /usr/bin/env python
Lib/smtpd.py => #! /usr/bin/env python
Misc/python-config.in => [EMAIL PROTECTED]@/python
whereas the installed files have
/usr/local/bin/pydoc => #!/usr/local/bin/python
/usr/local/bin/idle => #!/usr/local/bin/python
/usr/local/bin/smtpd.py => #!/usr/local/bin/python
/usr/local/bin/python-con
[ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work with tuple)
Bugs item #1545341, was opened at 2006-08-23 16:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: STINNER Victor (haypo)
Assigned to: Nobody/Anonymous (nobody)
Summary: setup() keyword have to be list (doesn't work with tuple)
Initial Comment:
Code:
== 8< =
from distutils.core import setup
setup(..., classifier=('Intended Audience ::
Developers', 'Environment :: Console ::
Curses'), ...)
== 8< =
The query: "./setup.py register" will create HTML
request:
GHSKFJDLGDS7543FJKLFHRE75642756743254
Content-Disposition: form-data; name="classifiers"
('Intended Audience :: Developers', 'Environment ::
Console :: Curses')
Instead of a multipart part for each value.
The bug is stupid, see attached patch.
Haypo
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545497 ] inconsistent treatment of NULs in int()
Bugs item #1545497, was opened at 2006-08-23 12:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545497&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent treatment of NULs in int()
Initial Comment:
In int_new (Objects/intobject.c), embedded NUL chars
are handled differently.
We should check that the entire string is converted
like PyNumber_Int(). int('5\0') raises an exception.
int('5\0', 10) returns 5.
>>> int('5\0', 10)
5
>>> int('5\0')
Traceback (most recent call last):
File "", line 1, in
ValueError: null byte in argument for int()
The difference is the explicit vs implicit base.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545497&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
>Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
del A
Output:
creating X('new')
deleting X('new')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 18:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 22:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigger that via gc.collect).
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 22:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
del A
Output:
creating X('new')
deleting X('new')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
>Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-style class objects.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 18:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigger that via gc.collect).
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
del A
Output:
creating X('new')
deleting X('new')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 18:24
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 23:18
Message:
Logged In: YES
user_id=849994
There's also this sentence in the __del__ docs:
"""
It is not guaranteed that __del__() methods are called for
objects that still exist when the interpreter exits.
"""
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 22:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-style class objects.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 22:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigger that via gc.collect).
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 22:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
del A
Output:
creating X('new')
deleting X('new')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545463 ] New-style classes fail to cleanup attributes
Bugs item #1545463, was opened at 2006-08-23 14:24
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Belopolsky (belopolsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: New-style classes fail to cleanup attributes
Initial Comment:
> cat x.py
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
class B:
x = X('old')
> python x.py
creating X('new')
creating X('old')
deleting X('old')
Python 2.4.2 (#2, Jan 13 2006, 12:00:38)
Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11)
--
>Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 20:08
Message:
Logged In: YES
user_id=835142
I used __del__ just to illustrate the problem. In real life
application, X was a type defined in a C module and I've
noticed that it's tp_dealloc is not called on instances
assigned to class variables.
BTW, what are the circumstances when __del__() methods are
not called for objects that still exist when the interpreter
exits?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 19:18
Message:
Logged In: YES
user_id=849994
There's also this sentence in the __del__ docs:
"""
It is not guaranteed that __del__() methods are called for
objects that still exist when the interpreter exits.
"""
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:54
Message:
Logged In: YES
user_id=835142
Yes, I've found that (using gc.get_referrers!), but this
does not explain why A is not cleaned up when the program exits.
Note that if I put class A definition inside a function, it
does get cleaned up. Must be some funny interation between
module and new-style class objects.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-23 18:45
Message:
Logged In: YES
user_id=849994
Note that new-style classes are always part of a reference
cycle (you can find this out via gc.get_referrers).
Therefore, they will not be deleted instantly, but only
after gc collects them (you can trigger that via gc.collect).
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2006-08-23 18:01
Message:
Logged In: YES
user_id=835142
It looks like the class object is not deleted alltogether:
class X(object):
def __init__(self, x):
self.x = x
print 'creating X(%r)' % x
def __del__(self):
print 'deleting X(%r)' % self.x
class A(object):
x = X('new')
del A
Output:
creating X('new')
deleting X('new')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps
Feature Requests item #1006786, was opened at 2004-08-10 11:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: extend strptime to understand logging timestamps Initial Comment: The default timestamp format used by the logging module appends a comma followed by a three-digit value representing milliseconds, e.g.: 2004-08-10 08:21:20,380 DEBUG log message here It would be nice if time.strptime() grokked this specification for the seconds in a timestamp so that applications which want to analyze log files can do so more easily. One possibility is to add a %s format specifier which recognizes NN,MMM as a floating point value containing fractional seconds with a comma as the "decimal point". Attached is a simple patch. I chose %s as the format sequence since it is related to %S. -- >Comment By: Brett Cannon (bcannon) Date: 2006-08-23 18:15 Message: Logged In: YES user_id=357491 Closing as rejected since this is not going to happen within strptime itself. -- Comment By: Brett Cannon (bcannon) Date: 2004-08-11 11:17 Message: Logged In: YES user_id=357491 Jim is right; dateFormat() in the Formatter class in Lib/logging/ __init__.py seems to handle formatting of timestamps. Now looking at the code it seems to store the format in self.datefmt, but it is set to None by default. Then in dateFormat(), if self.datefmt is None it uses the default format. The problem is that the millisecond part of the timestamp is not supported by time tuples. strftime doesn't even support it (if you look at timeFormat(), it kind of cheats and passes everything *but* the millisecond time to strftime and then just tacks on the millisecond stamp) so it seems a little off to add support just in strptime. Kind of too bad since it means that there is no way to actually construct the default timestamp yourself; timeFormat, if given a value other than None just passes the format string through strftime. And look at datetime. It supports *microsecond* values in its time class and strftime can't support that either. So now we have two places in the stdlib where they use stuff that strftime (and thus strptime) can't support. And of course the logging module doesn't use datetime since it is keeping 1.5.2 compatibility, so we can't solve all our problems with just a fix for datetime or by subclassing stuff in _strptime and coming up with a custom strptime for the logging module. So honestly I don't know what a good solution would be since not having symmetry with strftime is not acceptable. I can only think of having a small wrapper function in the logging module that handles the millisecond part and passes the rest through strptime. -- Comment By: Jim Jewett (jimjjewett) Date: 2004-08-11 08:59 Message: Logged In: YES user_id=764593 The format changes; "##,###" is just the default. It is based on an ISO recommendation, including the use of "," rather than "." to indicate a decimal point. -- Comment By: Skip Montanaro (montanaro) Date: 2004-08-10 20:22 Message: Logged In: YES user_id=44345 Whatever works. I hope we don't need a PEP for this. One way or the other I think it would be great if strptime can grok the logging module's timestamp. I haven't looked carefully at it to see if its timestamp format is variable or fixed. I suppose that will have a lot to do with how the parsing problem is solved in _strptime. -- Comment By: Brett Cannon (bcannon) Date: 2004-08-10 18:43 Message: Logged In: YES user_id=357491 Is this the best solution, or would it be better to just have a specific logging module directive (either in the logging package or in strptime) that recognized the whole string? If that format *never* changes, then we could just simplify it by having a single directive to make life easier for everyone involved. If we are going to compromise on adding a special directive for the logging module might as well go all the way, right? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 ___ Python-bugs-
[ python-Bugs-1545658 ] distutils home scheme lacks python versioning
Bugs item #1545658, was opened at 2006-08-24 02:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545659 ] distutils needs vendor-packages support
Bugs item #1545659, was opened at 2006-08-24 02:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows
Bugs item #1545668, was opened at 2006-08-24 03:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jack Howarth (jwhowarth) Assigned to: Jack Jansen (jackjansen) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: //* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows
Bugs item #1545668, was opened at 2006-08-24 03:14 Message generated for change (Comment added) made by jwhowarth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jack Howarth (jwhowarth) Assigned to: Jack Jansen (jackjansen) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: //* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. -- >Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0 -0400 +++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545696 ] structmember T_LONG won't accept a python long
Bugs item #1545696, was opened at 2006-08-24 00:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: structmember T_LONG won't accept a python long Initial Comment: An attribute defined as T_LONG throws a vague error when set to a python long, even when the value is within the range of a LONG. TypeError: bad argument type for built-in operation -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1117670 ] profiler: Bad return and Bad call errors with exceptions
Bugs item #1117670, was opened at 2005-02-06 23:50
Message generated for change (Comment added) made by edloper
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Nobody/Anonymous (nobody)
Summary: profiler: Bad return and Bad call errors with exceptions
Initial Comment:
I ran into a weird error when trying to profile a test
script of mine:
AssertionError: ('Bad call', ('', 0, 'encode'))
I managed to whittle it down to some minimal test
cases, which are attached (although the errors they
generate are slightly different.)
$ python-cvs -m profile profile_badcall.py
Traceback (most recent call last):
[snipped ...]
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
exec cmd in globals, locals
File "", line 1, in ?
File "profile_badcall.py", line 10, in ?
os.path.join("C",'b')
File
"/home/donut/usr64/python/lib/python2.5/posixpath.py",
line 56, in join
def join(a, *p):
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
if self.dispatch[event](self, frame, t):
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 285, in trace_dispatch_call
assert (self.cur is None or \
AssertionError: ('Bad call', ('profile_badcall.py', 2,
'trier'))
$ python-cvs -m profile profile_badreturn.py
Traceback (most recent call last):
[snipped...]
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 444, in runctx
exec cmd in globals, locals
File "", line 1, in ?
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 228, in trace_dispatch_i
if self.dispatch[event](self, frame, t):
File
"/home/donut/usr64/python/lib/python2.5/profile.py",
line 312, in trace_dispatch_return
assert frame is self.cur[-2].f_back, ("Bad return",
self.cur[-3])
AssertionError: ('Bad return', ('profile_badreturn.py',
1, 'trier'))
The errors occur in python CVS as of 20050206 and
python 2.4, but not in python 2.3.4.
OS: debian sid (3.1)
Arch: amd64
--
>Comment By: Edward Loper (edloper)
Date: 2006-08-24 02:43
Message:
Logged In: YES
user_id=195958
This bug was fixed by the following check-in:
http://mail.python.org/pipermail/python-checkins/2005-
September/047099.html
It should be closed. A work-around for people using older
versions of 2.4 is to do:
from profile import Profile
Profile.dispatch['c_exception'] = \
Profile.trace_dispatch_return
--
Comment By: Artur de Sousa Rocha (adsr)
Date: 2006-02-04 18:47
Message:
Logged In: YES
user_id=728207
I've run into this bug too and decided to check the test
cases. Here's what I found:
1) Both test cases fail as mentioned above under Cygwin.
2) Under native Windows Python, profile_badcall.py passes OK
and profile_badreturn.py gives the following traceback:
Traceback (most recent call last):
File "c:\Python24\lib\profile.py", line 611, in ?
run('execfile(%r)' % (sys.argv[0],), options.outfile,
options.sort)
File "c:\Python24\lib\profile.py", line 72, in run
prof = prof.run(statement)
File "c:\Python24\lib\profile.py", line 448, in run
return self.runctx(cmd, dict, dict)
File "c:\Python24\lib\profile.py", line 454, in runctx
exec cmd in globals, locals
File "", line 1, in ?
File "profile_badreturn.py", line 9, in ?
sum(1,0)
TypeError: iteration over non-sequence
Python versions used:
Python 2.4.1 (#1, May 27 2005, 18:02:40)
[GCC 3.3.3 (cygwin special)] on cygwin
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit
(Intel)] on win32
--
Comment By: Andrew Bennetts (spiv)
Date: 2005-10-08 03:05
Message:
Logged In: YES
user_id=50945
I still see this in current python 2.4, but not in current
python CVS.
Also, hotshot seems to work ok in 2.4 and CVS.
OS: ubuntu breezy (5.10)
Arch: i386
--
Comment By: Gary Oberbrunner (garyoberbrunner)
Date: 2005-03-08 22:35
Message:
Logged In: YES
user_id=417980
Is there any news on this bug? It is possibly preventing
scons (http://scons.org) from being profiled on python 2.4
-- we get the same errors as above. Test case is too large
to include here, but please email me with any news if
possible! Would be glad to test a fix.
-- Gary
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470
__
