[ python-Bugs-1537167 ] 2nd issue with need for speed patch
Bugs item #1537167, was opened at 2006-08-09 06:01
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&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: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Robin Bryce (robinbryce2)
Assigned to: Phillip J. Eby (pje)
Summary: 2nd issue with need for speed patch
Initial Comment:
This is not a duplicate of the "realease manager
pronouncement on 302 Fix needed" issue raised on pydev.
If a custom importer is present, import.c skips the
builtin import machinery if the find_module method of
that importer returns None. For python 2.4.3 if
find_module returns none the normal builtin machinery
gets a lookin. The relevent change was the addition of
a continue statement with svn commit r46372 (at around
line 1283 of import.c on the trunk).
I don't understand, in the face of this change, how pep
302 importers are expected to cascade. returning None
from find_module is the way an importer says "no I
can't load this module but I cant say for certain this
means ImportError" isnt it ?
One (unintended?) consequence of this change is the
following corner case:
As __import__ allows non dotted module names
__import__('fakemod.a/b') *will* succede on python
2.4.3 provided b is a directory under the package a
that contains an __init__.py. In python 2.5b3 this fails.
I've atatched a detailed repro case of this particular
corner case.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-08-11 07:27
Message:
Logged In: YES
user_id=849994
I've now added a note to the PEP explaining this behavior
explicitly. Closing as Won't Fix.
--
Comment By: Robin Bryce (robinbryce2)
Date: 2006-08-11 05:06
Message:
Logged In: YES
user_id=1547259
>It never was the intention of the entire machinery that such
>a fallback is implemented.
Ah. And having just reread pep 302 the wording on this is
actualy quite specifif. From: "specification part 1: the
importer protocol"
"It should return a loader object if the module was found".
Wich precludes the trickery I was thinking of anyway.
Appologies for the bandwidth this has taken up. I have no
objection to this bug being closed. Thanks for your time.
Cheers,
Robin
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-08-09 23:33
Message:
Logged In: YES
user_id=21627
The patch is originally mine; it does not have to do much
with the need-for-speed sprint. The rationale is to reduce
the number of stat/open calls when loading a module and the
directory doesn't even exist (e.g. for the first sys.path
entry, which is python25.zip). It originally put True/False
on sys.path_importer_cache.
Philipp Eby changed it to put the NullImporter on
path_importer_cache, and not fall back to the builtin import
if the path importer returns None.
It never was the intention of the entire machinery that such
a fallback is implemented. Instead, it always should have
continued with the next sys.path entry instead.
If a path import claims responsibility for a sys.path entry,
and then finds it cannot fulfill the responsibility, and
wants to fall back to the traditional file-based lookup, it
needs to implement that itself. I would advise against doing
so, though, and make the path import reject responsibility
for the sys.path entry in the first place if that entry
really is an on-disk directory.
--
Comment By: Robin Bryce (robinbryce2)
Date: 2006-08-09 15:50
Message:
Logged In: YES
user_id=1547259
I've tried the attatched test case patch against
release24-maint and it passes.
--
Comment By: Robin Bryce (robinbryce2)
Date: 2006-08-09 14:33
Message:
Logged In: YES
user_id=1547259
The 'illeagal' module name is a red herring. The problem
exists with leagal paths also::
Python 2.5b3 (trunk:51136, Aug 9 2006, 15:17:14)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from fakemod import urlpathimport
>>> urlpathimport.install()
>>> m=__import__('fakemod.a')
*** fullname='fakemod.a' initpath='fakemod' ***
Traceback (most recent call last):
File "", line 1, in
ImportError: No module named a
>>>
[EMAIL PROTECTED]:~/devel/blackmile$ python
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> from fakemod import urlpathimport
>>> urlpathimport.install()
>
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 10:05 Message generated for change (Comment added) made by ahmetbiskinler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&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: Unicode Group: Python 2.4 Status: Open Resolution: None >Priority: 6 Submitted By: Ahmet Bişkinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "Mayıs".upper() >>> MAYıS >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "Mayıs".upper() >>> MAYıS >>> print "ğüşiöçı".upper() >>> ğüşIöçı MAYıS should be MAYIS ğüşIöçı should be ĞÜŞİÖÇI but >>> "Mayıs".upper() >>> "MAYIS" is right -- >Comment By: Ahmet Bişkinler (ahmetbiskinler) Date: 2006-08-11 11:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1538556 ] PyThreadState_SetAsyncExc bug
Bugs item #1538556, was opened at 2006-08-11 12:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_SetAsyncExc bug Initial Comment: while working on a library for raising exceptions in the context of another thread, i've come across a bug in PyThreadState_SetAsyncExc. if i raise an instance, sys.exc_info() confuses the exception value for the exception type, and the exception value is set None. if i raise the type itself, the interpreter creates an instance internally, but then i can't pass arguments to the exception. see this post for more info http://mail.python.org/pipermail/python-dev/2006-August/068158.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538556&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c
Bugs item #1534630, was opened at 2006-08-04 11:29 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 08:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 00:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1538778 ] pyo's are not overwritten by different optimization levels
Bugs item #1538778, was opened at 2006-08-11 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=1538778&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: None Status: Open Resolution: None Priority: 5 Submitted By: Toshio Kuratomi (abadger1999) Assigned to: Nobody/Anonymous (nobody) Summary: pyo's are not overwritten by different optimization levels Initial Comment: If I invoke "python -OO" on a set of files, python creates a set of .pyo files. If I then realize this is an incredibly stupid thing to do because it removes the docstrings from the output and this program requires those docstrings python does not give me a method of overwriting the generated .pyos. I anticipated that running "python -O" would detect that the already generated .pyos were created in a different optimixation level and overwrite them with new .pyos. Barring that, I expected there to be a command line switch to tell python to overwrite the previously generated .pyo cache files. Finding neither, I realized that the only way to recover docstrings for people using python -O was to rm all the generated .pyo files. This seems like a bug or a missing feature. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538778&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c
Bugs item #1534630, was opened at 2006-08-04 08:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 08:30 Message: Logged In: YES user_id=33168 Yes, for all the reasons you mention. Also, I'm not sure that anyone other than /f can address this problem and I don't know when he will be able to fix it. I would very much prefer this be addressed prior to 2.5, but if it has to wait for 2.5.1 so be it. Also, I would guess this same problem is in the external version, so it's probably not a 'regression' either, even though this is a new module. Realize that there's still a month before release. So this is a non-issue if you can convince /f to fix it soon-ish. :-) -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 05:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-10 21:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c
Bugs item #1534630, was opened at 2006-08-04 17:29 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&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: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. -- >Comment By: Fredrik Lundh (effbot) Date: 2006-08-11 19:23 Message: Logged In: YES user_id=38376 I'm pretty sure this only happens if you're explicitly using the TreeBuilder class, which is a rather specialized use of ET. I'm also pretty sure that this is a cElementTree regression; I have a vague memory that I did some "optimizations" around 1.0.4 or 1.0.5 that might have caused this. I hope to find some time to look at this this weekend. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 17:30 Message: Logged In: YES user_id=33168 Yes, for all the reasons you mention. Also, I'm not sure that anyone other than /f can address this problem and I don't know when he will be able to fix it. I would very much prefer this be addressed prior to 2.5, but if it has to wait for 2.5.1 so be it. Also, I would guess this same problem is in the external version, so it's probably not a 'regression' either, even though this is a new module. Realize that there's still a month before release. So this is a non-issue if you can convince /f to fix it soon-ish. :-) -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 14:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 06:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
