[ python-Bugs-455694 ] bug in list append, or list multiply?
Bugs item #455694, was opened at 2001-08-27 03:15 Message generated for change (Comment added) made by hamptonio You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&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: Documentation Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bug in list append, or list multiply? Initial Comment: Python 2.1.1 (Windows NT 4) >>> x=6*[[]] >>> x [[], [], [], [], [], []] >>> x[3].append(7) >>> x [[7], [7], [7], [7], [7], [7]] But, I was expecting: [[], [], [], [7], [], []] So I then tried this: >>> x=[[],[],[],[],[],[]] # instead of x=6*[[]] >>> x[3].append(7) >>> x [[], [], [], [7], [], []] And it worked. I imagine what is happening is that 6*[[]] creates 6 pointers to the same empty list? But, if so, the python docs (http://www.python.org/doc/current/lib/typesseq.html) imply otherwise: s * n , n * s yields n _copies_ of s concatenated Anyway, I'm confused. -- Comment By: M.Hampton (hamptonio) Date: 2007-02-09 05:43 Message: Logged In: YES user_id=1373289 Originator: NO This really messed me recently, and I consider it a definite bug. It is still present in python 2.5 on multiple platforms. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-28 09:56 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libstdtypes.tex revision 1.68. -- Comment By: Tim Peters (tim_one) Date: 2001-08-27 16:25 Message: Logged In: YES user_id=31435 Changed to Doc and reassigned to Fred. The docs may be clearer if they said "n shallow copies" instead of "n copies". >>> s = [[]] >>> from copy import copy >>> x = copy(s) + copy(s) + copy(s) >>> x [[], [], []] >>> x[1].append(7) >>> x [[7], [7], [7]] >>> That is, "s*n is n copies of s concatenated" is correct, but only if you have shallow copies in mind. Anonymous, the effect you *want* can be gotten via x = [] for i in range(6): x.append([]) or, in Python 2.0+ via x = [[] for i in range(6)] Doing [O] * n creates a list with n repetitions of O, i.e. exactly the same object n times, the same as [O, O, O, ...]. In [[], []] you create two distinct empty lists, but in temp = [] [temp, temp] you get a single empty list twice. Same thing for [[]] * n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.
Bugs item #1653736, was opened at 2007-02-07 02:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&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 Private: No Submitted By: ked-tao (ked-tao) Assigned to: Nobody/Anonymous (nobody) Summary: Problems in datetime.c and typeobject.c. Initial Comment: This is related to [python-Bugs-1648268], but I think these problems might be important enough to consider fixing prior to any patch being produced for that item. Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling it with args and kwargs doesn't raise any exception, but it doesn't accept them). Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() macro. I'm not sure I entirely grok what's going on here (not enough to supply a python-level failure case), but it seems to me that it should be declared with the SLOT2() macro (it's a ternary op). FWIW, I changed it from: SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O") to: SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO") ... and that ran the failing tests OK. Hopefully someone familiar with this code can determine if this is correct or not. Thanks, Kev. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-09 13:20 Message: Logged In: YES user_id=21627 Originator: NO The second bug should now be fixed in r53689 and r53690. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-08 10:18 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the report. I have fixed the first bug, in r53671 and r53672. As for the second bug: I think your suggested change is wrong. __ipow__ is supposed to take only two arguments. I'm unsure why nb_inplace_power is defined with three arguments; the third argument is set to Py_None in all places I could find. So it is, at a minimum, ok if slot_nb_inplace_power discards its third argument; I wonder whether the API should be changed to drop this argument entirely. This is for python-dev to discuss. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.
Bugs item #1653736, was opened at 2007-02-07 02:15 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: ked-tao (ked-tao) Assigned to: Nobody/Anonymous (nobody) Summary: Problems in datetime.c and typeobject.c. Initial Comment: This is related to [python-Bugs-1648268], but I think these problems might be important enough to consider fixing prior to any patch being produced for that item. Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling it with args and kwargs doesn't raise any exception, but it doesn't accept them). Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() macro. I'm not sure I entirely grok what's going on here (not enough to supply a python-level failure case), but it seems to me that it should be declared with the SLOT2() macro (it's a ternary op). FWIW, I changed it from: SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O") to: SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO") ... and that ran the failing tests OK. Hopefully someone familiar with this code can determine if this is correct or not. Thanks, Kev. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-09 13:20 Message: Logged In: YES user_id=21627 Originator: NO The second bug should now be fixed in r53689 and r53690. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-08 10:18 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the report. I have fixed the first bug, in r53671 and r53672. As for the second bug: I think your suggested change is wrong. __ipow__ is supposed to take only two arguments. I'm unsure why nb_inplace_power is defined with three arguments; the third argument is set to Py_None in all places I could find. So it is, at a minimum, ok if slot_nb_inplace_power discards its third argument; I wonder whether the API should be changed to drop this argument entirely. This is for python-dev to discuss. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically
Bugs item #1600860, was opened at 2006-11-22 01:29
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: --enable-shared links extensions to libpython statically
Initial Comment:
python 2.5 tries to link extension modules to libpython2.5 if python is
compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do
this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command
line. -lpython2.5 is fine, however the "config" directory it adds contains a
static libpython2.5.a library. The libpython2.5.so I think it should be linking
to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly)
all of that library, so you get an extension that is over a megabyte in size
where older pythons produce one of a few kilobytes.
There is a comment on the referenced bug saying
"""
You can probably rely on libpythonxy.so ending up in
$(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can
retrieve from the installed Makefile (i.e. through
distutils.config).
"""
so I think the patch that got applied does not do what was intended.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-09 13:38
Message:
Logged In: YES
user_id=21627
Originator: NO
Thanks for the patch. Committed as r53691 and r53692.
--
Comment By: Marien Zwart (marienz)
Date: 2006-11-27 02:01
Message:
Logged In: YES
user_id=857292
Originator: YES
Yes, that seems to fix it, thanks!
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-11-25 14:42
Message:
Logged In: YES
user_id=21627
Originator: NO
gustavo: you can only attach a patch if you are team member or creator of
the bug report. I'm attaching your patch.
marienz: can you please confirm whether this patch solves this problem?
--
Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-11-25 14:10
Message:
Logged In: YES
user_id=908
Originator: NO
*sigh* why doesn't SF let me attach patches? :(
You can find a patch to fix this here:
http://www.gnome.org/~gjc/linux-shlib.diff
--
Comment By: Gustavo J. A. M. Carneiro (gustavo)
Date: 2006-11-23 21:47
Message:
Logged In: YES
user_id=908
Originator: NO
Hmm.. I think I wrongfully assumed $prefix/lib/pythonX.Y/config contained
a shared python library in addition to the static one. It seems that was
an Ubuntu specific thing :|
I'll take a good look and fix this within a couple of days...
--
Comment By: Marien Zwart (marienz)
Date: 2006-11-22 14:02
Message:
Logged In: YES
user_id=857292
Originator: YES
I can reproduce this by using either gentoo's python 2.5 or one I
installed temporarily with ./configure --enable-shared --prefix
$HOME/tmp/pytem, using a trivial distutils extension (I used
http://dev.gentooexperimental.org/~marienz/ext.c and
http://dev.gentooexperimental.org/~marienz/setup.py for testing). The
relevant command that is run is:
gcc -pthread -shared build/temp.linux-i686-2.5/ext.o
-L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o
build/lib.linux-i686-2.5/ext.so
for the manually-configured python and something similar for gentoo's
python. The code doing the adding was added by r45232 in svn. From the diff
(svn di -r45231:45232
http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py)
with some extra context added:
-if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos':
+if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos'
or \
+ (sys.platform.startswith('linux') and
+sysconfig.get_config_var('Py_ENABLE_SHARED')):
if string.find(sys.executable, sys.exec_prefix) != -1:
# building third party extensions
self.library_dirs.append(os.path.join(sys.prefix, "lib",
"python" +
get_python_version(),
"config"))
(that is around line 188 of Lib/distutils/command/build_ext.py)
sys.platform on this host is linux2 and as far as I can tell
Py_ENABLE_SHARED is true if --enable-shared is passed to configure.
If you need any more information please ask.
---
[ python-Bugs-1655392 ] thirdparty extensions, --enable-shared, static linking
Bugs item #1655392, was opened at 2007-02-08 18:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655392&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marien Zwart (marienz) >Assigned to: Georg Brandl (gbrandl) Summary: thirdparty extensions, --enable-shared, static linking Initial Comment: (I'm filing this under the "Build" category which may not be entirely accurate, but couldn't find a closer match. Is there a description of what the categories mean somewhere?). Python 2.5 built with --enable-shared on linux produces a shared libpython2.5.so in the "normal" libdir and only a static libpython2.5.a in /usr/lib/python2.5/config. Normally when you build extensions you want them to link to the dynamic one. However python-config --ldflags has -L/usr/lib/python2.5/config in its output, causing build processes using it to prefer the static library over the dynamic one. This is somewhat similar to bug 1600860: distutils does the same thing when compiling extensions in an --enable-shared python 2.5. I think either python-config should be modified to not mention that "config" dir on an --enable-shared build or the build process should be modified to put a .so file next to the .a file in that directory. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-09 13:46 Message: Logged In: YES user_id=21627 Originator: NO The categories aren't described anywhere. python-config should describe the installed code; we shouldn't change what gets installed how for 2.5.1. Georg, with python-config being your code, can you take a look? If not, please unassign (in which case I'd ask marienz whether he would like to contribute a patch). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655392&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1655683 ] 3.4.1 comparison methods content
Bugs item #1655683, was opened at 2007-02-09 02:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655683&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: Documentation Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jeffrey Miller (jsmgoogle) Assigned to: Nobody/Anonymous (nobody) Summary: 3.4.1 comparison methods content Initial Comment: From: Jeffrey Miller <[EMAIL PROTECTED]> At this URL and this section of the reference: http://docs.python.org/ref/customization.html 3.4.1 Basic Customization The existing text reads, in part: """ There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection. """ but is incorrect. Although __le__ and __ge__ are symmetric, as are __lt__ and __gt__, they are not boolean inverse operations if the arguments are swapped. Instead the text should pair __lt__ with __ge__, __le__ with __gt__ . Correcting the given text, it should read: """ There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __ge__() are each other's reflection, __le__() and __gt__() are each other's reflection, and __eq__() and __ne__() are their own reflection. """ -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-09 13:54 Message: Logged In: YES user_id=21627 Originator: NO I cannot see a bug there. The text doesn't talk about boolean inverse operations, it talks about reflected operations, and defines that term as "to be used when the left argument does not support the operation but the right argument does") Consider this code: >>> class A: ... pass ... >>> class B: ... def __gt__(self, other): ... print "gt" ... return True ... def __ge__(self, other): ... print "ge" ... return True ... >>> A()x. Closing the report as invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655683&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1655800 ] email.Generator docs contain a bad off-site link
Bugs item #1655800, was opened at 2007-02-09 08:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655800&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: Documentation Group: Python 2.6 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Forest Wilkinson (forest) Assigned to: Nobody/Anonymous (nobody) Summary: email.Generator docs contain a bad off-site link Initial Comment: The email.Generator module documentation contains this off-site link, entitled "WHY THE CONTENT-LENGTH FORMAT IS BAD": http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/content-length.html That page no longer exists, and hasn't for quite a while, according to archive.org. Perhaps the python docs should refer to another source for that informative rant from jwz. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-09 14:00 Message: Logged In: YES user_id=21627 Originator: NO Thanks for the report. I updated it to http://www.jwz.org/doc/content-length.html in r53693 and r53694. This will hopefully be a bit more permanent. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655800&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656078 ] Typo in Docs
Bugs item #1656078, was opened at 2007-02-09 14:03 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=1656078&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in Docs Initial Comment: http://docs.python.org/dev/lib/module-profile.html """ This function takes a single argument that has can be passed to the exec statement,""" I think the "has" should be deleted. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656078&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-900092 ] hotshot.stats.load
Bugs item #900092, was opened at 2004-02-19 00:05
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&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
Private: No
Submitted By: Simon Dahlbacka (sdahlbac)
>Assigned to: Nobody/Anonymous (nobody)
Summary: hotshot.stats.load
Initial Comment:
trying to do a
hotshot.stats.load("myprofiling_file.prof")
fails with assertionerror
assert not self._stack
python 2.3.2 on WinXP
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-02-09 10:15
Message:
Logged In: YES
user_id=357491
Originator: NO
I think only OPs and project members can upload. Email it to me, George
(brett at python.org), mention the bug # and I will upload it.
--
Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 16:08
Message:
Logged In: YES
user_id=1065136
Originator: NO
Ok, I reduced the prof file to 38K. Can I upload an attachment here ? I
don't see how.
--
Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 15:37
Message:
Logged In: YES
user_id=1065136
Originator: NO
Has this ever been reported again since it was closed ? I just got it
today (python 2.5). The prof file is 11MB, I'll see if I can reproduce the
bug with a smaller one.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-08-15 11:14
Message:
Logged In: YES
user_id=12800
Patches applied for Python 2.4.2 and 2.5a1
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-08 08:02
Message:
Logged In: YES
user_id=12800
900092-patch-2.txt fixes the test suite for the extra return
event.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 16:26
Message:
Logged In: YES
user_id=12800
See 900092-patch.txt for a candidate patch against Python
2.4.1. Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).
This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:54
Message:
Logged In: YES
user_id=86307
Well, the superficial fix doesn't work (sorry for posting
too soon). It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit.
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs. Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").
By the way, I'm testing with 2.4b1.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:32
Message:
Logged In: YES
user_id=86307
I ran into this today, so I decided to look into it. It
looks to me like the problem only happens if you profile
with lineevents enabled. In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events. This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).
It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns. This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 07:41
Message:
Logged In: YES
user_id=12800
Could this be related to 1019882?
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 15:00
Message:
Logged In: YES
user_id=469548
Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 14:58
Message:
Logged In: YES
user_id=469548
While the original report isn't very useful, I've ran into
this pro
[ python-Bugs-1655683 ] 3.4.1 comparison methods content
Bugs item #1655683, was opened at 2007-02-09 01:48 Message generated for change (Comment added) made by jsmgoogle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655683&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: Documentation Group: Python 2.5 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Jeffrey Miller (jsmgoogle) Assigned to: Nobody/Anonymous (nobody) Summary: 3.4.1 comparison methods content Initial Comment: From: Jeffrey Miller <[EMAIL PROTECTED]> At this URL and this section of the reference: http://docs.python.org/ref/customization.html 3.4.1 Basic Customization The existing text reads, in part: """ There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other's reflection, __le__() and __ge__() are each other's reflection, and __eq__() and __ne__() are their own reflection. """ but is incorrect. Although __le__ and __ge__ are symmetric, as are __lt__ and __gt__, they are not boolean inverse operations if the arguments are swapped. Instead the text should pair __lt__ with __ge__, __le__ with __gt__ . Correcting the given text, it should read: """ There are no reflected (swapped-argument) versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __ge__() are each other's reflection, __le__() and __gt__() are each other's reflection, and __eq__() and __ne__() are their own reflection. """ -- >Comment By: Jeffrey Miller (jsmgoogle) Date: 2007-02-09 18:35 Message: Logged In: YES user_id=1714526 Originator: YES I stand corrected. Thank you for taking the time to elucidate. (A <= B is equivalent to the swapped operation B >= A) -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-09 12:54 Message: Logged In: YES user_id=21627 Originator: NO I cannot see a bug there. The text doesn't talk about boolean inverse operations, it talks about reflected operations, and defines that term as "to be used when the left argument does not support the operation but the right argument does") Consider this code: >>> class A: ... pass ... >>> class B: ... def __gt__(self, other): ... print "gt" ... return True ... def __ge__(self, other): ... print "ge" ... return True ... >>> A()x. Closing the report as invalid. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1655683&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656078 ] Typo in Docs
Bugs item #1656078, was opened at 2007-02-09 14:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656078&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: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in Docs Initial Comment: http://docs.python.org/dev/lib/module-profile.html """ This function takes a single argument that has can be passed to the exec statement,""" I think the "has" should be deleted. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-09 18:49 Message: Logged In: YES user_id=849994 Originator: NO Thanks for reporting, fixed in rev. 53697, 53698 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656078&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-455694 ] bug in list append, or list multiply?
Bugs item #455694, was opened at 2001-08-27 08:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&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: Documentation Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: bug in list append, or list multiply? Initial Comment: Python 2.1.1 (Windows NT 4) >>> x=6*[[]] >>> x [[], [], [], [], [], []] >>> x[3].append(7) >>> x [[7], [7], [7], [7], [7], [7]] But, I was expecting: [[], [], [], [7], [], []] So I then tried this: >>> x=[[],[],[],[],[],[]] # instead of x=6*[[]] >>> x[3].append(7) >>> x [[], [], [], [7], [], []] And it worked. I imagine what is happening is that 6*[[]] creates 6 pointers to the same empty list? But, if so, the python docs (http://www.python.org/doc/current/lib/typesseq.html) imply otherwise: s * n , n * s yields n _copies_ of s concatenated Anyway, I'm confused. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-09 18:50 Message: Logged In: YES user_id=849994 Originator: NO This behavior is not a bug, it is how objects in Python and the '*' operator for lists work. -- Comment By: M.Hampton (hamptonio) Date: 2007-02-09 11:43 Message: Logged In: YES user_id=1373289 Originator: NO This really messed me recently, and I consider it a definite bug. It is still present in python 2.5 on multiple platforms. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-08-28 14:56 Message: Logged In: YES user_id=3066 Fixed in Doc/lib/libstdtypes.tex revision 1.68. -- Comment By: Tim Peters (tim_one) Date: 2001-08-27 21:25 Message: Logged In: YES user_id=31435 Changed to Doc and reassigned to Fred. The docs may be clearer if they said "n shallow copies" instead of "n copies". >>> s = [[]] >>> from copy import copy >>> x = copy(s) + copy(s) + copy(s) >>> x [[], [], []] >>> x[1].append(7) >>> x [[7], [7], [7]] >>> That is, "s*n is n copies of s concatenated" is correct, but only if you have shallow copies in mind. Anonymous, the effect you *want* can be gotten via x = [] for i in range(6): x.append([]) or, in Python 2.0+ via x = [[] for i in range(6)] Doing [O] * n creates a list with n repetitions of O, i.e. exactly the same object n times, the same as [O, O, O, ...]. In [[], []] you create two distinct empty lists, but in temp = [] [temp, temp] you get a single empty list twice. Same thing for [[]] * n -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653940 ] popen - docs - wrong order on fileobjects in tuple returned
Bugs item #1653940, was opened at 2007-02-07 09:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653940&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: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Emil Lind (noflux) Assigned to: Nobody/Anonymous (nobody) Summary: popen - docs - wrong order on fileobjects in tuple returned Initial Comment: http://docs.python.org/lib/module-popen2.html (child_stdout, child_stdin, child_stderr) should probably be (child_stdin, child_stdout, child_stderr) and so on. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-02-09 18:54 Message: Logged In: YES user_id=849994 Originator: NO No, the current version is correct. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653940&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1653416 ] print >> f, "Hello" produces no error: normal?
Bugs item #1653416, was opened at 2007-02-06 17:23
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653416&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
Private: No
Submitted By: E.-O. Le Bigot (eolebigot)
Assigned to: Nobody/Anonymous (nobody)
Summary: print >> f, "Hello" produces no error: normal?
Initial Comment:
When using
print >> f, "Hello"
on a file f opened for reading, no exception is raised. Is this normal?
This situation has to be contrasted with
f.write("Hello")
which raises an exception.
Details with Python 2.5 (r25:51908, Sep 24 206) on OS X 10.4.8 / darwin 8.8.0:
In [1]: f=open("start.01")
In [2]: f.write("Hello")
: [Errno 9] Bad file descriptor
In [3]: print >> f, "Hello"
In [4]: f.close()
NB: file f is not modified, despite the "print" statement yielding no error,
above.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-10 00:14
Message:
Logged In: YES
user_id=21627
Originator: NO
There seem to be multiple problems here. AFAICT,
print >>f, 3
fails on both Linux and OSX. This is because this uses fprintf to put out
the number, which, in turn, returns -1. This result is ignored; instead
Python expects ferror() to be set. However, ferror doesn't get set.
For printing strings, fwrite is used. On both Linux and OSX, fwrite will
return 0. On Linux, in addition, ferror gets set; on OSX, it doesn't.
Reading C99, I can't figure out which of these systems is behaving
correctly in what cases. The definition of ferror is that it returns the
"error indicator" of the stream, and only fseek, fputc (+putc), and fflush
are explicitly documented to set the error indicator. However, the error
indicator is also documented to be set that it "records whether a
read/write error has occurred", and write is documented to return a
number smaller than the requested only if an error occurred. Likewise,
fprintf is document to return an negative value "if an output or
encoding error occurred."
Putting these all together, ISTM that both Linux and OSX implement fprintf
incorrectly. To work around, Python could check the result of fprintf and
fwrite in all places; this might become a large change.
--
Comment By: Skip Montanaro (montanaro)
Date: 2007-02-06 19:49
Message:
Logged In: YES
user_id=44345
Originator: NO
I verified this behavior on my Mac with /usr/bin/python, Python 2.5 and
Python 2.6a0, both built from SVN.
Skip
--
Comment By: E.-O. Le Bigot (eolebigot)
Date: 2007-02-06 18:45
Message:
Logged In: YES
user_id=1440667
Originator: YES
Interesting point, about Linux. The incorrect behavior is even seen in
the default python 2.3 that ships with Mac OS X!
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-02-06 18:31
Message:
Logged In: YES
user_id=849994
Originator: NO
If this happens, it's a bug. Though it doesn't seem to occur under Linux
here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653416&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-900092 ] hotshot.stats.load
Bugs item #900092, was opened at 2004-02-19 00:05
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900092&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
Private: No
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Nobody/Anonymous (nobody)
Summary: hotshot.stats.load
Initial Comment:
trying to do a
hotshot.stats.load("myprofiling_file.prof")
fails with assertionerror
assert not self._stack
python 2.3.2 on WinXP
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-02-09 17:48
Message:
Logged In: YES
user_id=357491
Originator: NO
Attaching the file George made.
File Added: bug.prof
--
Comment By: Brett Cannon (bcannon)
Date: 2007-02-09 10:15
Message:
Logged In: YES
user_id=357491
Originator: NO
I think only OPs and project members can upload. Email it to me, George
(brett at python.org), mention the bug # and I will upload it.
--
Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 16:08
Message:
Logged In: YES
user_id=1065136
Originator: NO
Ok, I reduced the prof file to 38K. Can I upload an attachment here ? I
don't see how.
--
Comment By: George Sakkis (gsakkis)
Date: 2007-02-08 15:37
Message:
Logged In: YES
user_id=1065136
Originator: NO
Has this ever been reported again since it was closed ? I just got it
today (python 2.5). The prof file is 11MB, I'll see if I can reproduce the
bug with a smaller one.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-08-15 11:14
Message:
Logged In: YES
user_id=12800
Patches applied for Python 2.4.2 and 2.5a1
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-08 08:02
Message:
Logged In: YES
user_id=12800
900092-patch-2.txt fixes the test suite for the extra return
event.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-07-07 16:26
Message:
Logged In: YES
user_id=12800
See 900092-patch.txt for a candidate patch against Python
2.4.1. Props to Justin Campbell for most of the heavily
lifting (but you can blame me for any problems ;).
This fix restore the tracing of a 'return' event for
exceptions that cause a function to exit.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:54
Message:
Logged In: YES
user_id=86307
Well, the superficial fix doesn't work (sorry for posting
too soon). It turns out that PyTrace_EXCEPTION is sent for
any exception, not just one causing the function to exit.
So I guess the best fix may be to have hotshot always
install its profiler_callback to handle CALLS and RETURNS,
and then optionally install the tracer_callback to handle
only LINEs. Anyway, that works for the one test case I've
been using (a runcall of a function which simply does
"import pickle").
By the way, I'm testing with 2.4b1.
--
Comment By: Greg Chapman (glchapman)
Date: 2004-11-08 15:32
Message:
Logged In: YES
user_id=86307
I ran into this today, so I decided to look into it. It
looks to me like the problem only happens if you profile
with lineevents enabled. In that case, hotshot uses the
tracer_callback function (in _hotshot.c) to dispatch trace
events. This function explicitly ignores exception returns
(PyTrace_EXCEPTION), which can lead to an unbalanced stack
of calls/returns when the log is loaded (if an profiled
function exits with an exception).
It seems on the surface that tracer_callback ought to handle
exceptions the same way as normal returns. This would be
consistent with what happens when profiler_callback is used,
since PyEval_EvalFrame dispatches sends a Py_RETURN to
c_profilefunc when exiting because of an exception.
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-09-27 07:41
Message:
Logged In: YES
user_id=12800
Could this be related to 1019882?
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 15:00
Message:
Logged In: YES
user_id=469548
Hmm, the file was too big, even though it was compressed.
I've uploaded it to
http://home.student.uva.nl/johannes.gijsbers/roundup.prof.bz2
now.
--
[ python-Feature Requests-1656538 ] dict(key,values) initializer
Feature Requests item #1656538, was opened at 2007-02-10 02:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656538&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: George Sakkis (gsakkis) Assigned to: Nobody/Anonymous (nobody) Summary: dict(key,values) initializer Initial Comment: Far too often I use the idiom dict(zip(keys,values)), or the same with izip. How does letting dict take two positional arguments sound ? Pros: - Pretty obvious semantics, no mental overhead to learn and remember it. - More concise (especially if one imports itertools just to use izip). - At least as efficient (and probably more) as the current alternatives. - Backwards compatible. George -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1656538&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656559 ] I think, I have found this bug on time.mktime()
Bugs item #1656559, was opened at 2007-02-10 03:41 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=1656559&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 Private: No Submitted By: Sérgio Monteiro Basto (sergiomb) Assigned to: Nobody/Anonymous (nobody) Summary: I think, I have found this bug on time.mktime() Initial Comment: well, I think, I have found this bug on time.mktime() for dates less than 1976-09-26 when I do stringtotime of 1976-09-25 print "timeint %d" % time.mktime(__extract_date(m) + __extract_time(m) + (0, 0, 0)) extract date = 1976 9 25 extract time = 0 0 0 timeint 212454000 and timetostring(212454000) = 1976-09-24T23:00:00Z !? To be honest the date that kept me the action was the 1-1-1970 that appears 31-12-1969. After timetostring(stringtotime(date))) I made the test and time.mktime got a bug when date is less than 1976-09-26 see: for 1976-09-27T00:00:00Z time.mktime gives 212630400 for 1976-09-26T00:00:00Z time.mktime gives 212544000 for 1976-09-25T00:00:00Z time.mktime gives 212454000 212630400 - 212544000 = 86400 (seconds) , one day correct ! but 212544000 - 212454000 = 9 (seconds), one day more 3600 (seconds), more one hour ?!? -- Sérgio M. B. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656578 ] shutil.copyfileobj description is incomplete
Bugs item #1656578, was opened at 2007-02-10 00: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=1656578&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.copyfileobj description is incomplete Initial Comment: shutil.copyfileobj reads the source's data starting from the source's current file position. Thus, a user must issue seek(0) in order to have all of the source file object's contents read. This needs to be documented. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656578&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs clarification
Bugs item #1656581, was opened at 2007-02-10 00:45 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=1656581&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.TarFile fileobject use needs clarification Initial Comment: The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs clarification
Bugs item #1656581, was opened at 2007-02-10 00:45 Message generated for change (Comment added) made by herrwitten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Witten (herrwitten) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile.TarFile fileobject use needs clarification Initial Comment: The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented. -- >Comment By: Witten (herrwitten) Date: 2007-02-10 00:47 Message: Logged In: YES user_id=1595909 Originator: YES A clarification: When an existing file object is used to create a TarFile object, the TarFile object expects the existing file object to have its file position at 0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1656581 ] tarfile.TarFile fileobject use needs clarification
Bugs item #1656581, was opened at 2007-02-10 05:45 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Witten (herrwitten) >Assigned to: Lars Gustäbel (gustaebel) Summary: tarfile.TarFile fileobject use needs clarification Initial Comment: The constructor of a TarFile object expects an existing file object to have its file position at 0. This is not documented. -- Comment By: Witten (herrwitten) Date: 2007-02-10 05:47 Message: Logged In: YES user_id=1595909 Originator: YES A clarification: When an existing file object is used to create a TarFile object, the TarFile object expects the existing file object to have its file position at 0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1656581&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
