[ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Feature Requests item #1649329, was opened at 2007-02-01 03:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.py incompatible with eggs Initial Comment: If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg. That's because gettext.py only knows how to find the translation catalogs in the actual filesystem. This wouldn't be so bad if the "find" function didn't serve double duty. On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks. On the other hand, it actually resolves the files in the filesystem. It would be nice if these were separate. It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem. Perhaps gettext can be updated to know about eggs. Perhaps setting localedir to something like "egg://..." would enable this functionality. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-08 09:27 Message: Logged In: YES user_id=21627 Originator: NO Ok, I see how this fixes find(). What about translation() (which calls find, then also performs open())? Wouldn't this need to be fixed as well? Also, what about os.path.join? It might depend on the structure of the storage, as well (suppose you have the .mo data stored in a relational database)? In principle, I'm willing to fix this. I just want to avoid adding a hack. For example, it might be sensible to come up with a MOOpener interface, that has an .exists method, taking a list of strings, a .join method, taking a list of strings and returning something that can be passed to the .open method, which would take something that .join returned and returning a file-like object. It might be possible to extend the meaning of the localedir parameter to be either a string (understood as a directory name), or a MOOpener object. In any case, people *will* have to duplicate find for the moment, as any changes we discuss will only appear in 2.6. -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-08 01:52 Message: Logged In: YES user_id=30164 Originator: YES Ok, I've uploaded a patch with a possible way to refactor the code. I'm okay if you mark this bug as WONTFIX. I'm raising it as a concern because I know there are a lot of people out there using Web frameworks such as Pylons, Turbo Gears, etc. that are going to have to duplicate the code in "find" in order to use eggs. I hate to have see them do that. :-/ -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-08 01:49 Message: Logged In: YES user_id=30164 Originator: YES File Added: gettext.patch -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-07 07:45 Message: Logged In: YES user_id=21627 Originator: NO Do you have a proposal on how to do the refactoring? It would be fine to split find into two parts; it would not be acceptable (to me) to teach it egg: URLs. -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-06 23:28 Message: Logged In: YES user_id=30164 Originator: YES Sorry, yes, this is a feature request. The most important thing that I'm requesting is to refactor the code. That "find" function implements a certain algorithm that has nothing to do with the filesystem. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-06 20:43 Message: Logged In: YES user_id=21627 Originator: NO I fail to see the bug. gettext.find behaves as specified; if you want something else, don't use that function. If you want to load a .mo file from a zip file, you should be able to create a GNUTranslation object directly, from a file-like object. I don't think that gettext should support eggs directly. If you want it to do things other than loading from file systems, you should generalize that appropriately. One appropriate generalization could be the introduction of a directory-like object, where you can do .exists(relpath), and .open(relpath). However, introduction of directory-like objets is PEP material. Reclassifying this as a feature request. -- You can resp
[ python-Feature Requests-1654367 ] [PATCH] Debuggers need a way to change the locals of a frame
Feature Requests item #1654367, was opened at 2007-02-07 18:12
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabio Zadrozny (fabioz)
Assigned to: Nobody/Anonymous (nobody)
Summary: [PATCH] Debuggers need a way to change the locals of a frame
Initial Comment:
Debuggers need a way to change the local variables in a given frame...
currently, this works only if this change is done in the topmost frame (and
under certain circumstances), but it should work for any frame.
Initial discussion at:
http://mail.python.org/pipermail/python-dev/2007-February/070884.html
Apparently, the problem is the order in which PyFrame_LocalsToFast /
PyFrame_FastToLocals is called.
The proposed solution to this is having a savelocals() method in the frame
object and have it reflect the changes in its returned dict into its locals. It
will simply enable users to call PyFrame_LocalsToFast externally after a
change, to be sure that it will not be changed (and it must be done before
another call to PyFrame_LocalsToFast -- which I don't see as a large problem,
because it is of restrict use -- mainly for debuggers).
- frameobject.c Patch part 1: -
static PyObject *
PyFrame_SaveLocals(PyFrameObject *f)
{
PyFrame_LocalsToFast(f, 0);
Py_INCREF(Py_None);
return Py_None;
}
static PyMethodDef frame_methodlist[] = {
{"savelocals", (PyCFunction)PyFrame_SaveLocals, METH_NOARGS,
"After a change in f_locals, this method should be called to save the
changes internally."
},
{NULL} /* Sentinel */
};
-- frameobject.c Patch part 2: ---
Add to PyTypeObject PyFrame_Type:
frame_methodlist,/* tp_methods */
-- end patch -
I'm sorry that this is not in an actual patch format... but as I didn't get it
from the cvs, it is easier for me to explain it (as it is a rather small patch).
Attached is a test-case for this patch.
Thanks,
Fabio
--
>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-08 09:38
Message:
Logged In: YES
user_id=21627
Originator: NO
Why don't you set the clear parameter to 1?
Please do submit a patch, you can use 'diff -ur' to create a recursive
unified diff between source trees. Please also try to come up with a patch
to the documentation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654367&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-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-Feature Requests-1654408 ] Installer should split tcl/tk and tkinter install options.
Feature Requests item #1654408, was opened at 2007-02-07 18:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654408&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: Tkinter >Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ron Adam (ron_adam) Assigned to: Martin v. Löwis (loewis) Summary: Installer should split tcl/tk and tkinter install options. Initial Comment: On Windows, installing tcl/tk separately without removing tcl/tk from python can cause tkinter to be very unstable. These bugs happen even if the versions differ by only a minor release number from the version shipped with python. Selecting to not install tcl/tk with the installer also removes tkinter, and idle. Which is what you don't want in this case. To be able to use tkinter and idle and a full installation of tcl/tk you need to manually remove the following: - python/tcl directory - python/dlls/tcl84.dll - python/dlls/tk84.dll - python/dlls/tclpip84.dll (or the corresponding versions) And then make sure tcl's bin directory is in the path. This also avoids problems resulting from attempting to install tcl extensions into the python tcl directory (or tcl into pythons tcl directory) which tends to not work. Separating the tcl/tk and tkinter/idle in the installer along with adding advise on using a separate tcl installation with python would be helpful to some people. -- >Comment By: Martin v. Löwis (loewis) Date: 2007-02-08 10:21 Message: Logged In: YES user_id=21627 Originator: NO Moving it to the feature-requests tracker. -- Comment By: Ron Adam (ron_adam) Date: 2007-02-08 02:19 Message: Logged In: YES user_id=1687923 Originator: YES I think part of my problem was because of having python/dlls directory in windows file path. So that does explain some of it. Probably due to following instructions like this. http://mail.python.org/pipermail/python-win32/2002-September/000497.html It still would be nice to have the option to not install tcl/tk (but keep tkinter) and use the newest update of tcl with python. I use BLT to do graphs, and it installs fine if you remove tcl from python, install tcl and BLT together. Keeping tcl in python results in the errors reported in th e above link. And following the advice and adding python/dlls to the path can result in conflicts. Is that clearer. I know this isn't a common occurrence and not a problem with python directly. That's why I listed it as a feature request and not as a bug. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-07 22:14 Message: Logged In: YES user_id=21627 Originator: NO I cannot understand why Python's Tkinter becomes unstable when Tcl is installed, or vice versa. Are you setting any environment variables (like TCL_HOME)? You should not do that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1654408&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1655392 ] thirdparty extensions, --enable-shared, static linking
Bugs item #1655392, was opened at 2007-02-08 18:16 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=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: Nobody/Anonymous (nobody) 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. -- 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-Feature Requests-1649329 ] gettext.py incompatible with eggs
Feature Requests item #1649329, was opened at 2007-01-31 18:20 Message generated for change (Comment added) made by jjinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.py incompatible with eggs Initial Comment: If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg. That's because gettext.py only knows how to find the translation catalogs in the actual filesystem. This wouldn't be so bad if the "find" function didn't serve double duty. On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks. On the other hand, it actually resolves the files in the filesystem. It would be nice if these were separate. It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem. Perhaps gettext can be updated to know about eggs. Perhaps setting localedir to something like "egg://..." would enable this functionality. -- >Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-08 11:09 Message: Logged In: YES user_id=30164 Originator: YES > What about translation() (which calls find, then also performs open())? Wouldn't this need to be fixed as well? Perhaps, but it's probably not as critical. I.e. if the code gets duplicated to deal with eggs, it's not as big a loss. I really wish the distutils guys would weigh in on this one. > Also, what about os.path.join? I think it's relatively harmless. One can work around that. One can't work around os.path.exists. > In principle, I'm willing to fix this. I just want to avoid adding a hack. I agree. The patch isn't smelling too pretty. Neither of us wants to commit to a virtual filesystem layer which is how I've handled problems like this in the past. However, doing nothing results in a ton of code being duplicated in any project that uses gettext and zipped eggs. Should we see if Phillip Eby has any ideas since he's Mr. Eggs? > For example, it might be sensible to come up with a MOOpener interface, that has an .exists method, taking a list of strings, a .join method, taking a list of strings and returning something that can be passed to the .open method, which would take something that .join returned and returning a file-like object. It might be possible to extend the meaning of the localedir parameter to be either a string (understood as a directory name), or a MOOpener object. That's a light virtual filesystem layer ;) If you want that, I have code for that. > In any case, people *will* have to duplicate find for the moment, as any changes we discuss will only appear in 2.6. True. Alas, this may be a moot point. Thanks for your time. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-08 00:27 Message: Logged In: YES user_id=21627 Originator: NO Ok, I see how this fixes find(). What about translation() (which calls find, then also performs open())? Wouldn't this need to be fixed as well? Also, what about os.path.join? It might depend on the structure of the storage, as well (suppose you have the .mo data stored in a relational database)? In principle, I'm willing to fix this. I just want to avoid adding a hack. For example, it might be sensible to come up with a MOOpener interface, that has an .exists method, taking a list of strings, a .join method, taking a list of strings and returning something that can be passed to the .open method, which would take something that .join returned and returning a file-like object. It might be possible to extend the meaning of the localedir parameter to be either a string (understood as a directory name), or a MOOpener object. In any case, people *will* have to duplicate find for the moment, as any changes we discuss will only appear in 2.6. -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-07 16:52 Message: Logged In: YES user_id=30164 Originator: YES Ok, I've uploaded a patch with a possible way to refactor the code. I'm okay if you mark this bug as WONTFIX. I'm raising it as a concern because I know there are a lot of people out there using Web frameworks such as Pylons, Turbo Gears, etc. that are going to have to duplicate the code in "find" in order to use eggs. I hate to have see them do that. :-/ -- Comment By: Shannon -jj Behrens (jjinux) Date
[ python-Feature Requests-1649329 ] gettext.py incompatible with eggs
Feature Requests item #1649329, was opened at 2007-01-31 18:20 Message generated for change (Comment added) made by jjinux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1649329&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shannon -jj Behrens (jjinux) Assigned to: Nobody/Anonymous (nobody) Summary: gettext.py incompatible with eggs Initial Comment: If you distribute your code in a zipped egg, you can't use translation catalogs stored in that egg. That's because gettext.py only knows how to find the translation catalogs in the actual filesystem. This wouldn't be so bad if the "find" function didn't serve double duty. On the one hand, it implements the "find" algorithm to pick the right languages and fallbacks. On the other hand, it actually resolves the files in the filesystem. It would be nice if these were separate. It seems like people in projects like Pylons are stuck copying code from the find function in order to work around this problem. Perhaps gettext can be updated to know about eggs. Perhaps setting localedir to something like "egg://..." would enable this functionality. -- >Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-08 11:11 Message: Logged In: YES user_id=30164 Originator: YES Perhaps instead of committing to a special virtual filesystem layer, perhaps we should just take something that matches some subset of the posix interface. We can document the functions we need. -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-08 11:09 Message: Logged In: YES user_id=30164 Originator: YES > What about translation() (which calls find, then also performs open())? Wouldn't this need to be fixed as well? Perhaps, but it's probably not as critical. I.e. if the code gets duplicated to deal with eggs, it's not as big a loss. I really wish the distutils guys would weigh in on this one. > Also, what about os.path.join? I think it's relatively harmless. One can work around that. One can't work around os.path.exists. > In principle, I'm willing to fix this. I just want to avoid adding a hack. I agree. The patch isn't smelling too pretty. Neither of us wants to commit to a virtual filesystem layer which is how I've handled problems like this in the past. However, doing nothing results in a ton of code being duplicated in any project that uses gettext and zipped eggs. Should we see if Phillip Eby has any ideas since he's Mr. Eggs? > For example, it might be sensible to come up with a MOOpener interface, that has an .exists method, taking a list of strings, a .join method, taking a list of strings and returning something that can be passed to the .open method, which would take something that .join returned and returning a file-like object. It might be possible to extend the meaning of the localedir parameter to be either a string (understood as a directory name), or a MOOpener object. That's a light virtual filesystem layer ;) If you want that, I have code for that. > In any case, people *will* have to duplicate find for the moment, as any changes we discuss will only appear in 2.6. True. Alas, this may be a moot point. Thanks for your time. -- Comment By: Martin v. Löwis (loewis) Date: 2007-02-08 00:27 Message: Logged In: YES user_id=21627 Originator: NO Ok, I see how this fixes find(). What about translation() (which calls find, then also performs open())? Wouldn't this need to be fixed as well? Also, what about os.path.join? It might depend on the structure of the storage, as well (suppose you have the .mo data stored in a relational database)? In principle, I'm willing to fix this. I just want to avoid adding a hack. For example, it might be sensible to come up with a MOOpener interface, that has an .exists method, taking a list of strings, a .join method, taking a list of strings and returning something that can be passed to the .open method, which would take something that .join returned and returning a file-like object. It might be possible to extend the meaning of the localedir parameter to be either a string (understood as a directory name), or a MOOpener object. In any case, people *will* have to duplicate find for the moment, as any changes we discuss will only appear in 2.6. -- Comment By: Shannon -jj Behrens (jjinux) Date: 2007-02-07 16:52 Message: Logged In: YES user_id=30164 Originator: YES Ok, I've uploaded a patch with a possible way to refactor the code. I'm okay if you mark
[ python-Bugs-900092 ] hotshot.stats.load
Bugs item #900092, was opened at 2004-02-19 08:05
Message generated for change (Comment added) made by gsakkis
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.4
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Brett Cannon (bcannon)
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: George Sakkis (gsakkis)
Date: 2007-02-08 23: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 18: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 15: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 23: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 23: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 23: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 14:41
Message:
Logged In: YES
user_id=12800
Could this be related to 1019882?
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 22: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 21:58
Message:
Logged In: YES
user_id=469548
While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:
Python 2.3.4 (#2, Jul 5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.stats
>>> stats = hotshot.stats.load('roundup.prof')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/hotshot/stats.py", line 12, in load
return StatsLoader(filename).load()
File "/usr/lib/python2.3/hotshot/stats.py", line 51, in load
[ python-Bugs-900092 ] hotshot.stats.load
Bugs item #900092, was opened at 2004-02-19 08:05
Message generated for change (Comment added) made by gsakkis
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.4
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Brett Cannon (bcannon)
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: George Sakkis (gsakkis)
Date: 2007-02-09 00: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 23: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 18: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 15: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 23: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 23: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 23: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 14:41
Message:
Logged In: YES
user_id=12800
Could this be related to 1019882?
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2004-09-24 22: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 21:58
Message:
Logged In: YES
user_id=469548
While the original report isn't very useful, I've ran into
this problem multiple times as well. I can reproduce it
using the attached profile file (compressed because of the
large size) and the following console session:
Python 2.3.4 (#2, Jul 5 2004, 09:15:05)
[GCC 3.3.4 (Debian 1:3.3.4-2)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import hotshot.st
[ python-Bugs-1655683 ] 3.4.1 comparison methods content
Bugs item #1655683, was opened at 2007-02-09 01:48 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=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: Open Resolution: None 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. """ -- 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-08 23:54 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=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: Open Resolution: None 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. -- 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
