[ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode
Bugs item #1124295, was opened at 2005-02-16 21:34
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 8
Submitted By: Tres Seaver (tseaver)
Assigned to: Tim Peters (tim_one)
Summary: Function's __name__ no longer accessible in restricted mode
Initial Comment:
This change breaks an obscure bit of Zope's security
machinery,
which uses the __name__ of a function to construct the
synthetic
attribute name under which the roles for a method are
stored.
$ ../bin/python2.3
Python 2.3.4 (#3, Jan 27 2005, 10:46:13)
[GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> code = """... def func():
... pass
... print func.__name__
... """
>>> exec code
func
>>> globs = {'__builtins__':{}}
>>> exec code in globs
func
>>> ^D
$ ../bin/python2.4
Python 2.4 (#1, Feb 16 2005, 13:11:02)
[GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> code = """... def func():
... pass
... print func.__name__
... """
>>> exec code
func
>>> globs = {'__builtins__':{}}
>>> exec code in globs
Traceback (most recent call last):
File "", line 1, in ?
File "", line 3, in ?
RuntimeError: function attributes not accessible in
restricted mode
>>> ^D
--
>Comment By: Michael Hudson (mwh)
Date: 2005-02-17 10:32
Message:
Logged In: YES
user_id=6656
Oops. My fault, easy to fix.
--
Comment By: Tim Peters (tim_one)
Date: 2005-02-16 21:58
Message:
Logged In: YES
user_id=31435
Assigned to me, and boosted priority, since this should be
addressed for 2.4.1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode
Bugs item #1124295, was opened at 2005-02-16 21:34
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: Tres Seaver (tseaver)
>Assigned to: Michael Hudson (mwh)
Summary: Function's __name__ no longer accessible in restricted mode
Initial Comment:
This change breaks an obscure bit of Zope's security
machinery,
which uses the __name__ of a function to construct the
synthetic
attribute name under which the roles for a method are
stored.
$ ../bin/python2.3
Python 2.3.4 (#3, Jan 27 2005, 10:46:13)
[GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> code = """... def func():
... pass
... print func.__name__
... """
>>> exec code
func
>>> globs = {'__builtins__':{}}
>>> exec code in globs
func
>>> ^D
$ ../bin/python2.4
Python 2.4 (#1, Feb 16 2005, 13:11:02)
[GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> code = """... def func():
... pass
... print func.__name__
... """
>>> exec code
func
>>> globs = {'__builtins__':{}}
>>> exec code in globs
Traceback (most recent call last):
File "", line 1, in ?
File "", line 3, in ?
RuntimeError: function attributes not accessible in
restricted mode
>>> ^D
--
>Comment By: Michael Hudson (mwh)
Date: 2005-02-17 10:44
Message:
Logged In: YES
user_id=6656
Fixed on HEAD in
Objects/funcobject.c revision 2.68
Lib/test/test_funcattrs.py revision 1.17
and on 24-maint in
Objects/funcobject.c revision 2.67.2.1
Lib/test/test_funcattrs.py revision 1.16.2.1
Copy and paste are evil...
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-17 10:32
Message:
Logged In: YES
user_id=6656
Oops. My fault, easy to fix.
--
Comment By: Tim Peters (tim_one)
Date: 2005-02-16 21:58
Message:
Logged In: YES
user_id=31435
Assigned to me, and boosted priority, since this should be
addressed for 2.4.1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124637 ] test_subprocess is far too slow
Bugs item #1124637, was opened at 2005-02-17 11:10 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=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&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-1122532 ] Line Numbers
Feature Requests item #1122532, was opened at 2005-02-14 17:28 Message generated for change (Comment added) made by friedrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Egon Frerich (friedrich) Assigned to: Nobody/Anonymous (nobody) Summary: Line Numbers Initial Comment: The presentation of line numbers would be helpfull. -- >Comment By: Egon Frerich (friedrich) Date: 2005-02-17 11:18 Message: Logged In: YES user_id=37594 and I should have added: line numbers on the left side of edit sreens, not in the Shell screen -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:25 Message: Logged In: YES user_id=80475 Sorry, I saw the IDLE category sending. -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-17 01:24 Message: Logged In: YES user_id=80475 In the editor or someplace else? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122532&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124637 ] test_subprocess is far too slow
Bugs item #1124637, was opened at 2005-02-17 12:10 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. -- >Comment By: Peter Åstrand (astrand) Date: 2005-02-17 12:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124637 ] test_subprocess is far too slow
Bugs item #1124637, was opened at 2005-02-17 11:10 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. -- >Comment By: Michael Hudson (mwh) Date: 2005-02-17 12:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. -- Comment By: Peter Åstrand (astrand) Date: 2005-02-17 11:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124692 ] Math mode not well handled in \documentclass{howto}
Bugs item #1124692, was opened at 2005-02-17 13:08
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=1124692&group_id=5470
Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniele Varrazzo (dvarrazzo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Math mode not well handled in \documentclass{howto}
Initial Comment:
LaTeX loses its Math Magic (tm) when using
\documentclass{howto}: underscore operator in math
enviroment doesn't produce subscripts.
This documents shows some oddities:
\documentclass{howto}
\begin{document}
Water is $H_2O$, and subscript is missing from...
\[ V_{0,r} \]
Superscripts are instead fine, as $e^{\pi i} + 1 = 0$
shows.
Also this is completely different from what obtained by
\textbackslash documentclass\{article\}.
\[ \sum_{k=0}^\infty \int_0^k f(x) dx \]
\end{document}
The bug is removed by commenting out lines 541--549 in
python.sty, but i don't know how to *fix* them... (not a
TeXpert)
Using Python 2.3.5, Windows 2000, LaTeX2e (e-TeX
3.141592-2.2, MikTex 2.4 implementation)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124692&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124637 ] test_subprocess is far too slow
Bugs item #1124637, was opened at 2005-02-17 22:10 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-18 00:16 Message: Logged In: YES user_id=29957 I'm with mwh. This test should be enabled with an option - I'd noticed that test_subprocess took a long time, but hadn't bothered to track it down. Before releases (and at other times) I always try to make sure that I run 'make testall', but for day-to-day use, this is too slow. -- Comment By: Michael Hudson (mwh) Date: 2005-02-17 23:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. -- Comment By: Peter Åstrand (astrand) Date: 2005-02-17 22:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-881522 ] Shelve slow after 7/8000 key
Bugs item #881522, was opened at 2004-01-21 17:09
Message generated for change (Comment added) made by marcoberi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=881522&group_id=5470
Category: Python Library
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Marco Beri (marcoberi)
Assigned to: Gregory P. Smith (greg)
Summary: Shelve slow after 7/8000 key
Initial Comment:
After about 8.000 insertion shelve became really, really
slow.
This happens only with 2.3.3 #51 on Windows, not with
2.2 and with 2.3 on Linux.
I try with writeback True or False: same problem.
Help! :-))
--
>Comment By: Marco Beri (marcoberi)
Date: 2005-02-17 13:42
Message:
Logged In: YES
user_id=588604
FYI, with Python 2.4 speed is again ok.
So problem are confined to 2.3 version (also 2.3.5 has the
shelve slow problem).
--
Comment By: Tim Peters (tim_one)
Date: 2004-04-22 01:39
Message:
Logged In: YES
user_id=31435
As threatened months ago, closed as 3rd Party, Won't Fix --
there's no sign that this will ever make progress.
--
Comment By: Marco Beri (marcoberi)
Date: 2004-01-23 10:03
Message:
Logged In: YES
user_id=588604
I mean: I didn't try with python 2.3 on linux (just with python
2.2)
--
Comment By: Marco Beri (marcoberi)
Date: 2004-01-23 10:01
Message:
Logged In: YES
user_id=588604
I give a wrong info: I didn't try it on Linux so I'm not so sure
it's a windows specific problem.
Besides this, looking at 2004-01-22 18:32 greg comment, it's
seems that also Linux - alpha version has this problem.
Probably it's better to modify category to "Python library"?
--
Comment By: Marco Beri (marcoberi)
Date: 2004-01-23 00:44
Message:
Logged In: YES
user_id=588604
jkew,
also I god a bit of a headache. I was pretty sure to improve
performances with Python 2.3.3, while they get incredibly
worse.
I know perhaps this is a third-party issue, but I use a python
feature (shelve) and at least I think that it's better to remove
it or signal this problem in the documentation.
We are talking about few thousand key, not billions!
BTW I didn't post twice the previuos message.
--
Comment By: James Kew (jkew)
Date: 2004-01-23 00:16
Message:
Logged In: YES
user_id=598066
FWIW2, on skip's "miserable hack" comment below, vis-a-vis
running shelve on btree: isn't this exactly the sort of thing
shelve.Shelf is intended for?
import bsddb
import shelve
db = bsddb.btopen("temp.db")
sh = shelve.Shelf(db)
# do stuff with sh
sh.close()
# automatically calls close() on the underlying db
(Not sure why Shelf and friends are documented on
shelve's "Restrictions" subsection...)
--
Comment By: Marco Beri (marcoberi)
Date: 2004-01-23 00:08
Message:
Logged In: YES
user_id=588604
I get your same results under normal cmd: 7.07 seconds vs
0.46.
[c:\tmp]timer & \python23\python test3skip.py hashopen &
timer
Timer 1 on: 19.13.22
Timer 1 off: 19.13.29 Elapsed: 0.00.07,07
[c:\tmp]timer & \python23\python test3skip.py btopen & timer
Timer 1 on: 19.13.45
Timer 1 off: 19.13.45 Elapsed: 0.00.00,46
--
Comment By: James Kew (jkew)
Date: 2004-01-22 23:53
Message:
Logged In: YES
user_id=598066
FWIW, to throw another use case into the pot: I (used to)
run Roundup (roundup.sf.net) trackers on anydbm/Win2K and
experienced a significant drop in performance between 2.2.x
(bsddb185) and 2.3.x (dbhash).
I understand that this is a third-party issue, and that there
were significant known problems with bsddb 1.85, but it did
cause me a bit of a double-take after having heard so much
about Python 2.3 being faster...
I say "used to" because the slowdown prompted me to
migrate to Roundup's sqlite backend, solving my problem.
--
Comment By: Skip Montanaro (montanaro)
Date: 2004-01-22 21:11
Message:
Logged In: YES
user_id=44345
If we wanted speed and didn't care about corruption, my vote
would be bsddb185. ;-)
--
Comment By: Tim Peters (tim_one)
Date: 2004-01-22 20:36
Message:
Logged In: YES
user_id=31435
Greg, I didn't expect you to fix it , I just didn't want
the bug report closed based on misunderstanding what it was
about.
I've unassigned this item, and if nobody volunteers to dig into
it within a few weeks, it should indeed be closed as "3rd
Party" and "Wont Fix
Skip,
[ python-Bugs-1124637 ] test_subprocess is far too slow
Bugs item #1124637, was opened at 2005-02-17 06:10 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. -- >Comment By: Tim Peters (tim_one) Date: 2005-02-17 10:13 Message: Logged In: YES user_id=31435 Peculiar -- test_subprocess takes about 8 seconds on my WinXP box release build, about 10 seconds debug build, and Windows is notorious for slow process creation. That's a zippy 3.4 GHz P4, but clock rate alone can't account for such a large speed difference. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-17 08:16 Message: Logged In: YES user_id=29957 I'm with mwh. This test should be enabled with an option - I'd noticed that test_subprocess took a long time, but hadn't bothered to track it down. Before releases (and at other times) I always try to make sure that I run 'make testall', but for day-to-day use, this is too slow. -- Comment By: Michael Hudson (mwh) Date: 2005-02-17 07:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. -- Comment By: Peter Åstrand (astrand) Date: 2005-02-17 06:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124637 ] test_subprocess is far too slow
Bugs item #1124637, was opened at 2005-02-17 12:10 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. -- >Comment By: Peter Åstrand (astrand) Date: 2005-02-17 16:17 Message: Logged In: YES user_id=344921 tim_one: test_subprocess only creates 65 processes on Windows, compared to 1026 for UNIX. -- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:13 Message: Logged In: YES user_id=31435 Peculiar -- test_subprocess takes about 8 seconds on my WinXP box release build, about 10 seconds debug build, and Windows is notorious for slow process creation. That's a zippy 3.4 GHz P4, but clock rate alone can't account for such a large speed difference. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-17 14:16 Message: Logged In: YES user_id=29957 I'm with mwh. This test should be enabled with an option - I'd noticed that test_subprocess took a long time, but hadn't bothered to track it down. Before releases (and at other times) I always try to make sure that I run 'make testall', but for day-to-day use, this is too slow. -- Comment By: Michael Hudson (mwh) Date: 2005-02-17 13:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. -- Comment By: Peter Åstrand (astrand) Date: 2005-02-17 12:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124513 ] test_os fails on 2.4
Bugs item #1124513, was opened at 2005-02-17 00:22 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 -- >Comment By: Tim Peters (tim_one) Date: 2005-02-17 10:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124295 ] Function's __name__ no longer accessible in restricted mode
Bugs item #1124295, was opened at 2005-02-16 16:34
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: Tres Seaver (tseaver)
Assigned to: Michael Hudson (mwh)
Summary: Function's __name__ no longer accessible in restricted mode
Initial Comment:
This change breaks an obscure bit of Zope's security
machinery,
which uses the __name__ of a function to construct the
synthetic
attribute name under which the roles for a method are
stored.
$ ../bin/python2.3
Python 2.3.4 (#3, Jan 27 2005, 10:46:13)
[GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> code = """... def func():
... pass
... print func.__name__
... """
>>> exec code
func
>>> globs = {'__builtins__':{}}
>>> exec code in globs
func
>>> ^D
$ ../bin/python2.4
Python 2.4 (#1, Feb 16 2005, 13:11:02)
[GCC 3.3.4 (Debian 1:3.3.4-9ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> code = """... def func():
... pass
... print func.__name__
... """
>>> exec code
func
>>> globs = {'__builtins__':{}}
>>> exec code in globs
Traceback (most recent call last):
File "", line 1, in ?
File "", line 3, in ?
RuntimeError: function attributes not accessible in
restricted mode
>>> ^D
--
>Comment By: Tim Peters (tim_one)
Date: 2005-02-17 10:55
Message:
Logged In: YES
user_id=31435
Thanks, Michael! It _looked_ like a copy-paste glitch .
I've confirmed that the specific failing Zope test works with
current release24-maint branch.
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-17 05:44
Message:
Logged In: YES
user_id=6656
Fixed on HEAD in
Objects/funcobject.c revision 2.68
Lib/test/test_funcattrs.py revision 1.17
and on 24-maint in
Objects/funcobject.c revision 2.67.2.1
Lib/test/test_funcattrs.py revision 1.16.2.1
Copy and paste are evil...
--
Comment By: Michael Hudson (mwh)
Date: 2005-02-17 05:32
Message:
Logged In: YES
user_id=6656
Oops. My fault, easy to fix.
--
Comment By: Tim Peters (tim_one)
Date: 2005-02-16 16:58
Message:
Logged In: YES
user_id=31435
Assigned to me, and boosted priority, since this should be
addressed for 2.4.1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124295&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1123660 ] add SHA256/384/512 to lib
Bugs item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 11:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html -- Comment By: paul rubin (phr) Date: 2005-02-16 22:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, something is going wrong somewhere. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-16 21:52 Message: Logged In: YES user_id=593130 Yes, feature request = RFE. However, this somehow got into the tracker as a bug item, not an RFE item. Check the top of the page or
[ python-Bugs-1124861 ] GetStdHandle in interactive GUI
Bugs item #1124861, was opened at 2005-02-17 11:23
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=1124861&group_id=5470
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
Summary: GetStdHandle in interactive GUI
Initial Comment:
Using the suprocess module from with IDLE or PyWindows,
it appears that calls GetStdHandle (STD__HANDLE)
returns None, which causes an error. (All appears fine
on Linux, the standard Python command-line, and ipython.)
For example:
>>> import subprocess
>>> p = subprocess.Popen("dir", stdout=subprocess.PIPE)
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = subprocess.Popen("dir", stdout=subprocess.PIPE)
File "C:\Python24\lib\subprocess.py", line 545, in
__init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 605, in
_get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
The error originates in the mswindows implementation of
_get_handles. You need to set one of stdin, stdout, or
strerr because the first line in the method is:
if stdin == None and stdout == None and stderr == None:
...return (None, None, None, None, None, None)
I added "if not handle: return GetCurrentProcess()" to
_make_inheritable() as below and it worked. Of course,
I really do not know what is going on, so I am letting
go now...
def _make_inheritable(self, handle):
..."""Return a duplicate of handle, which is inheritable"""
...if not handle: return GetCurrentProcess()
...return DuplicateHandle(GetCurrentProcess(), handle,
GetCurrentProcess(),
0, 1,
DUPLICATE_SAME_ACCESS)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1123660 ] add SHA256/384/512 to lib
Bugs item #1123660, was opened at 2005-02-16 04:14 Message generated for change (Comment added) made by phr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. -- >Comment By: paul rubin (phr) Date: 2005-02-17 16:55 Message: Logged In: YES user_id=72053 Well, I don't see an obvious way to reclassify this item. If someone knows how to do it, please go ahead. I sent an email to the lawyer and haven't gotten a response yet. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 16:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 05:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html -- Comment By: paul rubin (phr) Date: 2005-02-17 03:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It is just bizarre. Is that the same lawyer? It says he also advises the OSI, so I might email him with that Bernstein cite. This tracker item clearly says "Feature request" in the "Group" pulldown when I look at it in Sourceforge. That's the way I entered it and if it's showing up differently for you, somethin
[ python-Bugs-1123660 ] add SHA256/384/512 to lib
Bugs item #1123660, was opened at 2005-02-15 23:14 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123660&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: add SHA256/384/512 to lib Initial Comment: According to http://www.schneier.com/blog/archives/2005/02/sha1_broken.html some Chinese researchers have just announced a break against SHA1. These are the same guys who broke MD5 a few months ago and the SHA1 break, while not exactly expected, is also not really shocking at this point. The break allows finding a free collision in the full SHA1 in O(2**69) operations, still an awful lot in practice. So nobody should panic. But it means that new applications probably want to use SHA256, SHA384, or SHA512, which were standardized by NIST at the same time AES was standardized, as successors to SHA1. The hash lengths are 256, 384, or 512 bits respectively, and correspond to 2x the AES key lengths of 128, 192, or 384 bits. Their design is strengthened from SHA1 to resist attacks like this. On the other hand, they are slower than SHA1. Anyway, there are various free implementations of the algorithms around (libtomcrypt.org has some public domain versions) so it should be straightforward enough to transplant the Python C API wrapper from sha.c to it. I think it's reasonable to put these all into the existing sha module, rather than make a new module. They could be called by adding an optional arg to sha.new: x = sha.new(data, 256).digest() would find the sha256 digest, etc. Note that sha512 and sha384 are the same algorithm, with different initial parameters and with 128 bits discarded for sha384. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 12:45 Message: Logged In: YES user_id=593130 Ok, next time You might want to look at https://sourceforge.net/tracker/index.php? func=detail&aid=1121611&group_id=5470&atid=305470 -- Comment By: paul rubin (phr) Date: 2005-02-17 11:55 Message: Logged In: YES user_id=72053 Well, I don't see an obvious way to reclassify this item. If someone knows how to do it, please go ahead. I sent an email to the lawyer and haven't gotten a response yet. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 11:14 Message: Logged In: YES user_id=593130 Addition to the previous: current does not necessarily mean final. I am not a party to any ongoing non-public discussion of these issues. Over and out. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-02-17 00:25 Message: Logged In: YES user_id=593130 Here is the top of this page: Project: Bugs: Trackers and here is the beginning of the email sent to me: Bugs item #1123660, was opened at 2005-02-16 04:14 I found the explanation: on https://sourceforge.net/tracker/?group_id=5470 you need to click RFE instead of Bugs on this line: Summary | Admin | Home Page | Tracker | Bugs | Patches | RFE | When you click Bugs, Feature Request shows up under Group because it was put there before there was a separate RFE list and now, I remember, it cannot be removed. (SF 'feature') But it would be if it could be. --- Yes, that is the lawyer and article. Yes, I noticed the discrepancy 'PD not real' and current PEP PD policy, but refrained from saying anything yet. I have no more to do with those and other docs than you do. Contributor agreements: your link is to a 3 1/2 year old draft, badly misleading, but first hit on 'contributor' search. I have suggested its removal. Current, I believe, is http://www.python.org/psf/contrib which links to http://www.python.org/moin/PythonSoftwareFoundationLicen seFaq and http://www.python.org/psf/contrib-form.html -- Comment By: paul rubin (phr) Date: 2005-02-16 22:33 Message: Logged In: YES user_id=72053 I couldn't find the "Contributions" section of Python.org; got a url? I did find PEP 241 says public domain is a legitimate choice of license, and also the PSF patch submission agreement near the bottom of http://www.python.org/psf/psf-contributor-agreement.html suggests releasing the patch to the PD (but only if the contributor wrote the entire patch, which wouldn't apply to wrapping some existing public domain work). Also a lot of the PEP's are released as PD. So maybe you want to revisit all those docs, if there's now some problem with PD releases. I think the Linuxjournal article you refer to might be http://www.linuxjournal.com/article/6225 . It
[ python-Bugs-1126208 ] subprocess.py Errors with IDLE
Bugs item #1126208, was opened at 2005-02-17 15:33
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=1126208&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess.py Errors with IDLE
Initial Comment:
=
From: David S. alumni.tufts.edu>
Subject: subprocess problem on Windows in IDLE and PythonWin
Newsgroups: gmane.comp.python.general
Date: Wed, 16 Feb 2005 02:05:24 +
Python 2.4 on Windows XP
In the python command-line the following works fine:
>>> from subprocess import *
>>> p = Popen('dir', stdout=PIPE)
>From within IDLE or PythonWin I get the following exception:
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = Popen('dir', stdout=PIPE)
File "c:\python24\lib\subprocess.py", line 545, in __init__
(p2cread, p2cwrite,
File "c:\python24\lib\subprocess.py", line 605, in _get_handles
p2cread = self._make_inheritable(p2cread)
File "c:\python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
Note it works fine on Linux also. I tested it with
>>> p = Popen('ls', stdout=PIPE)
... and had no trouble.
===
I (KBK) can duplicate this on W2K using 2.4. If I run IDLE with the -n
switch (no subprocess) the error doesn't occur.
Unfortunately, I can't debug it because I don't have the necessary
tools on Windows. It appears that the problem is in
_subprocess.c:sp_DuplicateHandle(), likely that PyArg_ParseTuple()
is OK but the failure occurs in the call to DuplicateHandle().
All the args to sp_DuplicateHandle() seem to be the right type.
DUPLICATE_SAME_ACCESS is an integer, value 2
To find out what's going on, it would seem necessary to attach a
windows debugger to IDLE's subprocess (not the IDLE GUI). Let
me know if I can help.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1126208&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124513 ] test_os fails on 2.4
Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 -- >Comment By: Martin v. Löwis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. -- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1119860 ] Static library incompatible with nptl
Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. -- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124513 ] test_os fails on 2.4
Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-02-17 22:30 Message: Logged In: YES user_id=89016 The new implementation of os._Environ.update() assumes that the argument dict is a mapping, if it provides a method items(), otherwise it treats it as an item sequence. Unfortunately the SimpleUserDict from mapping_tests.py provides only keys() and __getitem__(). So what is the minimal mapping interface? UserDict.DictMixin claims that keys and __getitem__ (and __setitem__ and __delitem__) is enough and adding __contains__, __iter__ and iteritems increases performance. So should update() try iteritems() or should an items() method be added to the SimpleUserDict in the test? CVS HEAD does not fail, because a test method test_update() has been added there, which hides the original method from mapping_tests.BasicTestMappingProtocol. Adding a call mapping_tests.BasicTestMappingProtocol.test_update(self) there results in the same exception as on the release24-maint branch. -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. -- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124513 ] test_os fails on 2.4
Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-02-17 22:33 Message: Logged In: YES user_id=89016 Oops, seems are comments have crossed, thanks for the fix. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-02-17 22:30 Message: Logged In: YES user_id=89016 The new implementation of os._Environ.update() assumes that the argument dict is a mapping, if it provides a method items(), otherwise it treats it as an item sequence. Unfortunately the SimpleUserDict from mapping_tests.py provides only keys() and __getitem__(). So what is the minimal mapping interface? UserDict.DictMixin claims that keys and __getitem__ (and __setitem__ and __delitem__) is enough and adding __contains__, __iter__ and iteritems increases performance. So should update() try iteritems() or should an items() method be added to the SimpleUserDict in the test? CVS HEAD does not fail, because a test method test_update() has been added there, which hides the original method from mapping_tests.BasicTestMappingProtocol. Adding a call mapping_tests.BasicTestMappingProtocol.test_update(self) there results in the same exception as on the release24-maint branch. -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. -- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124513 ] test_os fails on 2.4
Bugs item #1124513, was opened at 2005-02-17 06:22 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: test_os fails on 2.4 Initial Comment: Seems at test for os.environ that uses mapping_tests.py to make sure the object returned by os.environ has a mapping environment is failing under 2.4 (fine under 2.5) at least on OS X: test.test_support.TestFailed: Traceback (most recent call last): File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 204, in test_update d.update(SimpleUserDict()) File "/Users/drifty/Code/cvs/Trees/python24/Lib/os.py", line 467, in update for k, v in items: File "/Users/drifty/Code/cvs/Trees/python24/Lib/test/ mapping_tests.py", line 202, in __getitem__ return self.d[i] KeyError: 0 -- Comment By: Walter Dörwald (doerwalter) Date: 2005-02-17 22:33 Message: Logged In: YES user_id=89016 Oops, seems are comments have crossed, thanks for the fix. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-02-17 22:30 Message: Logged In: YES user_id=89016 The new implementation of os._Environ.update() assumes that the argument dict is a mapping, if it provides a method items(), otherwise it treats it as an item sequence. Unfortunately the SimpleUserDict from mapping_tests.py provides only keys() and __getitem__(). So what is the minimal mapping interface? UserDict.DictMixin claims that keys and __getitem__ (and __setitem__ and __delitem__) is enough and adding __contains__, __iter__ and iteritems increases performance. So should update() try iteritems() or should an items() method be added to the SimpleUserDict in the test? CVS HEAD does not fail, because a test method test_update() has been added there, which hides the original method from mapping_tests.BasicTestMappingProtocol. Adding a call mapping_tests.BasicTestMappingProtocol.test_update(self) there results in the same exception as on the release24-maint branch. -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-17 22:24 Message: Logged In: YES user_id=21627 This is now fixed in os.py 1.86 and 1.83.2.2, test_os.py 1.30. -- Comment By: Tim Peters (tim_one) Date: 2005-02-17 16:39 Message: Logged In: YES user_id=31435 Confirming that test_os fails the same way on WinXP, on current release24-maint branch. But it does not fail under the released 2.4. Brett, can you clarify whether you're talking about 2.4 or about release24-maint here? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124513&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1138653 ] subprocesss module retains older license header
Bugs item #1138653, was opened at 2005-02-17 17:46 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=1138653&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: subprocesss module retains older license header Initial Comment: The header of the file seems to imply that the module is licensed separately from the standard Python license: # subprocess - Subprocesses with accessible I/O streams # # For more information about this module, see PEP 324. # # Copyright (c) 2003-2004 by Peter Astrand <[EMAIL PROTECTED]> # # By obtaining, using, and/or copying this software and/or its # associated documentation, you agree that you have read, understood, # and will comply with the following terms and conditions: # # Permission to use, copy, modify, and distribute this software and # its associated documentation for any purpose and without fee is # hereby granted, provided that the above copyright notice appears in # all copies, and that both that copyright notice and this permission # notice appear in supporting documentation, and that the name of the # author not be used in advertising or publicity pertaining to # distribution of the software without specific, written prior # permission. # # THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS # OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, # NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION # WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1119860 ] Static library incompatible with nptl
Bugs item #1119860, was opened at 2005-02-10 08:29 Message generated for change (Comment added) made by ekloef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: daniel (ekloef) Assigned to: Nobody/Anonymous (nobody) Summary: Static library incompatible with nptl Initial Comment: When compiling on a linux system, the python lock structure contains three variables, the lock, a mutex and a condition variable. On systems where linuxthreads are used, sizeof(pthread_cond_t) == 12, but on nptl systems sizeof(pthread_cond_t) == 48. Why is this a problem? Lets say you compile the static library on an old system. Then the smaller pthread_cond_t will be used. If an application links against this library and is run on a newer system, ugly things will happen: only 12 bytes (+ the rest of the lock structure) is allocated, but the pthread functions will expect it to be 48 bytes... seg. fault. Note that this problem only occurs when using a static library, compiled on a linuxthreads system, and running on a nptl system. Attached is a simple fix; a padding buffer is inserted into the python lock structure. This ensures enough memory is allocated. -- >Comment By: daniel (ekloef) Date: 2005-02-18 08:13 Message: Logged In: YES user_id=1216071 libpythonVERSION.a which is installed in lib/pythonVERSION/config/ But like I said, this bug is only triggered if the lib and the application linking against the lib is compiled on systems with different glibc-versions. -- Comment By: Martin v. Löwis (loewis) Date: 2005-02-17 22:27 Message: Logged In: YES user_id=21627 Can you please explain what static library you are talking about? Python compiles into /usr/local/bin/python, which is an executable, not a library. -- Comment By: daniel (ekloef) Date: 2005-02-16 09:40 Message: Logged In: YES user_id=1216071 Just realized that the only time this bug can be triggered is if the static library is compiled on one (old) system and the application on another (new). If both are compiled on an old system, the versioned functions of glibc will take care of this problem. I guess it might be a stretch to call this a python bug; feel free to close. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
