Re: [Python-Dev] Volunteer
On 05/02/2012 21:42, Ben Finney wrote: Blockheads Oi Oibreamore...@yahoo.co.uk writes: I would like to give it another go. Welcome back. Your signature shows the name “Mark Lawrence”. It would help with initial impressions if your ‘From’ field, instead of the pseudonym currently shown, shows your name. Could you please change it to that? Done :) -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] distutils 'depends' management
On Fri, Feb 3, 2012 at 5:52 PM, Éric Araujo mer...@netwok.org wrote:
Hi Matteo,
Now setup.py will rebuild all every time, this is because the policy of
newer_group in build_extension is to consider 'newer' any missing file.
Here you certainly mean “older”.
No, and this is the problem: newer_group(depends, ext_path, 'newer'))
if (some dep is newer than the target): rebuild
[...] Can someone suggest me the reason of this choice
distutils’ notion of dependencies directly comes from make. A missing
(not existing) target is perfectly normal: it’s usually a generated file
that make needs to create (i.e. compile from source files). In this
world, you want to (re-)compile when the target is older than the
sources, or when the target is missing.
Here is a simple Makefile that has the behavior I was expecting from
distutils too:
$ cat Makefile
all: missing.dep
echo Done!
$ make
make: *** No rule to make target `missing.dep', needed by `all'. Stop.
So here your extension module is a target that needs to be created, and
when distutils does not find a file with the name you give in depends, it
just thinks it’s another thing that will be generated.
So, if I understand correctly, starting today a better name could be
'generates' instead of 'depends'?
This model is inherently prone to typos; I’m not sure how we can improve
it to let people catch possible typos.
Yes, perhaps the name of the list and the explanation in the docs are both
a bit confusing:
http://docs.python.org/distutils/apiref.html#distutils.ccompiler.CCompiler.compile
*depends*, if given, is a list of filenames that all targets depend on. If
a source file is older than any file in depends, then the source file will
be recompiled.
Can this be a better explanation? If a source file is older than any file
in depends {+or if some depend is missing+}
Cheers
--
Matteo Bertini
http://www.slug.it/naufraghi
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On Fri, Dec 9, 2011 at 10:02, Stefan Behnel stefan...@behnel.de wrote: Hi everyone, I think Py3.3 would be a good milestone for cleaning up the stdlib support for XML. Note upfront: you may or may not know me as the maintainer of lxml, the de-facto non-stdlib standard Python XML tool. This (lengthy) post was triggered by the following kind of conversation that I keep having with new XML users in Python (mostly on c.l.py), which hints at some serious flaw in the stdlib. snip AFAIU nothing really happened with this. The discussion started with a lot of +1s but then got derailed. The related Issue 11379 also got stuck nearly two months ago. It would be great if some sort of consensus could be reached here, since this is an important issue :-) Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On Dec 9, 2011 3:04 AM, Stefan Behnel stefan...@behnel.de wrote: Hi everyone, I think Py3.3 would be a good milestone for cleaning up the stdlib support for XML. Note upfront: you may or may not know me as the maintainer of lxml, the de-facto non-stdlib standard Python XML tool. This (lengthy) post was triggered by the following kind of conversation that I keep having with new XML users in Python (mostly on c.l.py), which hints at some serious flaw in the stdlib. User: I'm trying to do XML stuff XYZ in Python and have problem ABC. Me: What library are you using? Could you show us some code? User: My code looks like this snippet: ... Me: You are using minidom which is known to be hard to use, slow and uses lots of memory. Use the xml.etree.ElementTree package instead, or rather its C implementation cElementTree, also in the stdlib. User (coming back after a while): thanks, that was exactly what [I didn't know] I was looking for. What does this tell us? 1) MiniDOM is what new users find first. It's highly visible because there are still lots of ancient Python and XML web pages out there that date back from the time before Python 2.5 (or rather something like 2.2), when it was the only XML tree library in the stdlib. It's also the first hit from the top when you search for XML on the stdlib docs page and contains the (to some people) familiar word DOM, which lets users stop their search and start writing code, not expecting to find a separate alternative in the same stdlib, way further down. And the description as mini, simple and lightweight suggests to users that it's going to be easy to use and efficient. 2) MiniDOM is not what users want. It leads to complicated, unpythonic code and lots of problems. It is neither easy to use, nor efficient, nor lightweight, simple or mini, not in absolute numbers (see http://bugs.python.org/issue11379#msg148584 and following for a recent discussion). It's also badly maintained in the sense that its performance characteristics could likely be improved, but no-one is seriously interested in doing that, because it would not lead to something that actually *is* fast or memory friendly compared to any of the 'real' alternatives that are available right now. 3) ElementTree is what users should use, MiniDOM is not. ElementTree was added to the stdlib in Py2.5 on popular demand, exactly because it is very easy to use, very fast, and very memory friendly. And because users did not want to use MiniDOM any more. Today, ElementTree has a rather straight upgrade path towards lxml.etree if more XML features like validation or XSLT are needed. MiniDOM has nothing like that to offer. It's a dead end. 4) In the stdlib, cElementTree is independent of ElementTree, but totally hidden in the documentation. In conversations like the above, it's unnecessarily complex to explain to users that there is ElementTree (which is documented in the stdlib), but that what they want to use is really cElementTree, which has the same API but does not have a stdlib documentation page that I can send them to. Note that the other Python implementations simply provide cElementTree as an alias for ElementTree. That leaves CPython as the only Python implementation that really has these two separate modules. So, there are many problems here. And I think they make it unnecessarily complicated for users to process XML in Python and that the current situation helps in turning away new users from Python as a language for XML processing. Python does have impressively great tools for working with XML. It's just that the stdlib and its documentation do not reflect or even appreciate that. What should change? a) The stdlib documentation should help users to choose the right tool right from the start. Instead of using the totally misleading wording that it uses now, it should be honest about the performance characteristics of MiniDOM and should actively suggest that those who don't know what to choose (or even *that* they can choose) should not use MiniDOM in the first place. I created a ticket (issue11379) for a minor step in this direction, but given the responses, I'm rather convinced that there's a lot more that can be done and should be done, and that it should be done now, right for the next release. b) cElementTree should finally loose it's special status as a separate library and disappear as an accelerator module behind ElementTree. This has been suggested a couple of times already, and AFAIR, there was some opposition because 1) ET was maintained outside of the stdlib and 2) the APIs of both were not identical. However, getting ET 1.3 into Py2.7 and 3.2 was a U-turn. Today, ET is *only* being maintained in the stdlib by Florent Xicluna (who is doing a good job with it), and ET 1.3 has basically made the APIs of both implementations compatible again. So, 3.3 would be the right milestone for fixing the two libs for one quirk. Given that this is the third time during the last couple
Re: [Python-Dev] Fixing the XML batteries
What should change? a) The stdlib documentation should help users to choose the right tool right from the start. Instead of using the totally misleading wording that it uses now, it should be honest about the performance characteristics of MiniDOM and should actively suggest that those who don't know what to choose (or even *that* they can choose) should not use MiniDOM in the first place. I created a ticket (issue11379) for a minor step in this direction, but given the responses, I'm rather convinced that there's a lot more that can be done and should be done, and that it should be done now, right for the next release. On one hand I agree that ET should be emphasized since it's the better API with a much faster implementation. But I also understand Martin's point of view that minidom has its place, so IMHO some sort of compromise should be reached. Perhaps we can recommend using ET for those not specifically interested in the DOM interface, but for those who *are*, minidom is still a good stdlib option (?). Tying this doc clarification with an optimization in minidom is not something that makes sense. This is just delaying a much needed change forever. b) cElementTree should finally loose it's special status as a separate library and disappear as an accelerator module behind ElementTree. This has been suggested a couple of times already, and AFAIR, there was some opposition because 1) ET was maintained outside of the stdlib and 2) the APIs of both were not identical. However, getting ET 1.3 into Py2.7 and 3.2 was a U-turn. Today, ET is *only* being maintained in the stdlib by Florent Xicluna (who is doing a good job with it), and ET 1.3 has basically made the APIs of both implementations compatible again. So, 3.3 would be the right milestone for fixing the two libs for one quirk. This, at least in my view, is the more important point which unfortunately got much less attention in the thread. I was a bit shocked to see that in 3.3 trunk we still have both the Python and C versions exposed and only formally document ElementTree (the Python version), The only reference to cElementTree is an un-emphasized note: A C implementation of this API is available as xml.etree.cElementTree. Is there anything that *really* blocks providing cElementTree on import ElementTree and removing the explicit cElementTree for 3.3 (or at least leaving it with a deprecation warning)? Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] need help with frozen module/marshal/gc issue involving sub-interpreters for importlib bootstrapping
So my grand quest for bootstrapping importlib into CPython is damn close to coming to fruition; I have one nasty bug blocking my way and I can't figure out what could be causing it. I'm hoping someone here will either know the solution off the top of their head or will have the time to have a quick look to see if they can figure it out as my brain is mush at this point. First, the bug tracking all of this is http://bugs.python.org/issue2377 and the repo where I have been doing my work is ssh:// h...@hg.python.org/sandbox/bcannon/#bootstrap_importlib (change as needed if you want an HTTPS checkout). Everything works fine as long as you don't use sub-interpreters via test_capi (sans some test failures based on some assumptions which can easily be fixed; the bug I'm talking about is the only real showstopper at this point). Here is the issue: if you run test_capi the code triggers an assertion of ``test_subinterps (__main__.TestPendingCalls) ... Assertion failed: (gc-gc.gc_refs != 0), function visit_decref, file Modules/gcmodule.c, line 327.``. If you run the test under gdb you will discover that the assertion is related to ref counts when collecting for a generation (basically the ref updating is hitting 0 when it shouldn't). Now the odd thing is that this is happening while importing frozen module code (something I didn't touch) which is calling marshal (something else I didn't touch) and while it is in the middle of unmarshaling the frozen module code it is triggering the assertion. Does anyone have any idea what is going on? Am I possibly doing something stupid with refcounts which is only manifesting when using sub-interpreters? All relevant code for bootstrapping is contained in Python/pythonrun.c:import_init() (with a little tweaking in the _io module to delay importing the os module and making import.c always use __import__ instead of using the C code). I'm storing the __import__ function in the PyInterpreterState to keep separate state from the other interpreters (i.e. separate sys modules so as to use the proper sys.modules, etc.). But as I said, this all works in a single interpreter view of the world (the entire test suite doesn't trigger a nasty error like this). Thanks for any help people can provide me on this now 5 year quest to get this work finished. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] peps: Update with bugfix releases.
On Feb 06, 2012, at 07:11 AM, Georg Brandl wrote: Well, one way to do it would be to release a rc now-ish, giving the community time to test it, and to already use it productively in critical cases, and release the final with the OSX fixes after/at PyCon. That could work well. I'd be happy to release a 2.6.8 rc next week. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need help with frozen module/marshal/gc issue involving sub-interpreters for importlib bootstrapping
Usually this means that you're not doing an INCREF in a place where you should, and the object is kept alive by something else. Do you know which object it is? That might really help... Possibly deleting the last subinterpreter makes the refcount of that object go to zero. Of course it could also be that you're doing a DECREF you shouldn't be doing... But the identity of the object seems key in any case. --Guido On Mon, Feb 6, 2012 at 6:57 AM, Brett Cannon br...@python.org wrote: So my grand quest for bootstrapping importlib into CPython is damn close to coming to fruition; I have one nasty bug blocking my way and I can't figure out what could be causing it. I'm hoping someone here will either know the solution off the top of their head or will have the time to have a quick look to see if they can figure it out as my brain is mush at this point. First, the bug tracking all of this is http://bugs.python.org/issue2377and the repo where I have been doing my work is ssh:// h...@hg.python.org/sandbox/bcannon/#bootstrap_importlib (change as needed if you want an HTTPS checkout). Everything works fine as long as you don't use sub-interpreters via test_capi (sans some test failures based on some assumptions which can easily be fixed; the bug I'm talking about is the only real showstopper at this point). Here is the issue: if you run test_capi the code triggers an assertion of ``test_subinterps (__main__.TestPendingCalls) ... Assertion failed: (gc-gc.gc_refs != 0), function visit_decref, file Modules/gcmodule.c, line 327.``. If you run the test under gdb you will discover that the assertion is related to ref counts when collecting for a generation (basically the ref updating is hitting 0 when it shouldn't). Now the odd thing is that this is happening while importing frozen module code (something I didn't touch) which is calling marshal (something else I didn't touch) and while it is in the middle of unmarshaling the frozen module code it is triggering the assertion. Does anyone have any idea what is going on? Am I possibly doing something stupid with refcounts which is only manifesting when using sub-interpreters? All relevant code for bootstrapping is contained in Python/pythonrun.c:import_init() (with a little tweaking in the _io module to delay importing the os module and making import.c always use __import__ instead of using the C code). I'm storing the __import__ function in the PyInterpreterState to keep separate state from the other interpreters (i.e. separate sys modules so as to use the proper sys.modules, etc.). But as I said, this all works in a single interpreter view of the world (the entire test suite doesn't trigger a nasty error like this). Thanks for any help people can provide me on this now 5 year quest to get this work finished. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is this safe enough? Re: [Python-checkins] cpython: _Py_Identifier are always ASCII strings
I realize that _Py_Identifier is a private name, and that PEP 3131
requires anything (except test cases) in the standard library to stick
with ASCII ... but somehow, that feels like too long of a chain.
I would prefer to see _Py_Identifier renamed to _Py_ASCII_Identifier,
or at least a comment stating that Identifiers will (per PEP 3131)
always be ASCII -- preferably with an assert to back that up.
-jJ
On Sat, Feb 4, 2012 at 7:46 PM, victor.stinner
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d2c1521ad0a1
changeset: 74772:d2c1521ad0a1
user: Victor Stinner victor.stin...@haypocalc.com
date: Sun Feb 05 01:45:45 2012 +0100
summary:
_Py_Identifier are always ASCII strings
files:
Objects/unicodeobject.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
--- a/Objects/unicodeobject.c
+++ b/Objects/unicodeobject.c
@@ -1744,9 +1744,8 @@
_PyUnicode_FromId(_Py_Identifier *id)
{
if (!id-object) {
- id-object = PyUnicode_DecodeUTF8Stateful(id-string,
- strlen(id-string),
- NULL, NULL);
+ id-object = unicode_fromascii((unsigned char*)id-string,
+ strlen(id-string));
if (!id-object)
return NULL;
PyUnicode_InternInPlace(id-object);
--
Repository URL: http://hg.python.org/cpython
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need help with frozen module/marshal/gc issue involving sub-interpreters for importlib bootstrapping
2012/2/6 Brett Cannon br...@python.org: Thanks for any help people can provide me on this now 5 year quest to get this work finished. Fixed. (_PyExc_Init was behaving badly.) -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is this safe enough? Re: [Python-checkins] cpython: _Py_Identifier are always ASCII strings
I would prefer to see _Py_Identifier renamed to _Py_ASCII_Identifier, or at least a comment stating that Identifiers will (per PEP 3131) always be ASCII -- preferably with an assert to back that up. Please ... no. This is a *convenience* interface, whose sole purpose is to make something more convenient. Adding naming clutter destroys this objective. I'd rather restore support for allowing UTF-8 source here (I don't think that requiring ASCII really improves much), than rename the macro. The ASCII requirement is actually more in the C compiler than in Python. Since not all of the C compilers that we compile Python with support non-ASCII identifiers, failure to comply to the ASCII requirement will trigger a C compilation failure. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): remove unused import
On Sun, Feb 5, 2012 at 19:53, Christian Heimes li...@cheimes.de wrote: Am 06.02.2012 01:39, schrieb Brett Cannon: I'm going to assume pylint or pyflakes would throw too many warnings on the stdlib, but would it be worth someone's time to write a simple unused import checker to run over the stdlib on occasion? I bet even one that did nothing more than a regex search for matched import statements would be good enough. Zope 3 has an import checker that uses the compiler package and AST tree to check for unused imports. It seems like a better approach than a simple regex search. http://svn.zope.org/Zope3/trunk/utilities/importchecker.py?rev=25177view=auto The importorder tool uses the tokenizer module to order import statements. http://svn.zope.org/Zope3/trunk/utilities/importorder.py?rev=25177view=auto Both are written by Jim Fulton. Ah, but does it run against Python 3? If so then this is something to suggest on python-mentor for someone to get their feet wet for contributing. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): remove unused import
Am 06.02.2012 18:57, schrieb Brett Cannon: Ah, but does it run against Python 3? If so then this is something to suggest on python-mentor for someone to get their feet wet for contributing. Probably not, the code was last modified seven years ago. The compiler package has been removed from Python 3, too. A similar approach should yield better results than a simple regexp search. The 2to3 / 3to2 infrastructure could be reused to parse the AST and search for imports and used names. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): remove unused import
On Mon, Feb 6, 2012 at 13:07, Christian Heimes li...@cheimes.de wrote: Am 06.02.2012 18:57, schrieb Brett Cannon: Ah, but does it run against Python 3? If so then this is something to suggest on python-mentor for someone to get their feet wet for contributing. Probably not, the code was last modified seven years ago. The compiler package has been removed from Python 3, too. A similar approach should yield better results than a simple regexp search. The 2to3 / 3to2 infrastructure could be reused to parse the AST and search for imports and used names. If that's the case I might as well add it as part of my mnfy project's verification run I do over the stdlib if someone doesn't beat me to it. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): remove unused import
Hi Brett, If that's the case I might as well add it as part of my mnfy project's verification run I do over the stdlib if someone doesn't beat me to it. Is that devinabox ? Thanks in advance ! francis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 2/6/2012 8:01 AM, Eli Bendersky wrote: On one hand I agree that ET should be emphasized since it's the better API with a much faster implementation. But I also understand Martin's point of view that minidom has its place, so IMHO some sort of compromise should be reached. Perhaps we can recommend using ET for those not specifically interested in the DOM interface, but for those who *are*, minidom is still a good stdlib option (?). If you can, go ahead and write a patch saying something like that. It should not be hard to come up with something that is a definite improvement. Create a tracker issue for comment. but don't let it sit forever. Tying this doc clarification with an optimization in minidom is not something that makes sense. This is just delaying a much needed change forever. Right. This, at least in my view, is the more important point which unfortunately got much less attention in the thread. I was a bit shocked to see that in 3.3 trunk we still have both the Python and C versions exposed and only formally document ElementTree (the Python version), The only reference to cElementTree is an un-emphasized note: A C implementation of this API is available as xml.etree.cElementTree. Since the current policy seems to be to hide C behind Python when there is both, I assume that finishing the transition here is something just not gotten around to yet. Open another issue if there is not one. Is there anything that *really* blocks providing cElementTree on import ElementTree and removing the explicit cElementTree for 3.3 (or at least leaving it with a deprecation warning)? If cElementTree were renamed _ElementTree for import from ElementTree, then a new cElementTree.py could raise the warning and then import _ElementTree also. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] importlib quest
On Mon, 6 Feb 2012 09:57:56 -0500 Brett Cannon br...@python.org wrote: Thanks for any help people can provide me on this now 5 year quest to get this work finished. Do you have any plan to solve the performance issue? $ ./python -m timeit -s import sys; mod='struct' \ __import__(mod); del sys.modules[mod] 1 loops, best of 3: 75.3 usec per loop $ ./python -m timeit -s import sys; mod='struct'; from importlib import __import__ \ __import__(mod); del sys.modules[mod] 1000 loops, best of 3: 421 usec per loop Startup time is already much worse in 3.3 than in 2.7. With such a slowdown in importing fresh modules, applications using many batteries (third-party or not) will be heavily impacted. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib quest
On Mon, 6 Feb 2012 20:49:48 +0100
Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 6 Feb 2012 09:57:56 -0500
Brett Cannon br...@python.org wrote:
Thanks for any help people can provide me on this now 5 year quest to get
this work finished.
Do you have any plan to solve the performance issue?
$ ./python -m timeit -s import sys; mod='struct' \
__import__(mod); del sys.modules[mod]
1 loops, best of 3: 75.3 usec per loop
$ ./python -m timeit -s import sys; mod='struct'; from importlib import
__import__ \
__import__(mod); del sys.modules[mod]
1000 loops, best of 3: 421 usec per loop
The culprit for the overhead is likely to be PathFinder.find_module:
$ ./python -m timeit -s import sys; mod='struct'; from importlib._bootstrap
import _DefaultPathFinder; finder=_DefaultPathFinder
finder.find_module('struct')
1000 loops, best of 3: 355 usec per loop
$ ./python -S -m timeit -s import sys; mod='struct'; from importlib._bootstrap
import _DefaultPathFinder; finder=_DefaultPathFinder
finder.find_module('struct')
1 loops, best of 3: 176 usec per loop
Note how it's dependent on sys.path length. On an installed Python with
many additional sys.path entries (e.g. because of distribute-based
module installs), import times will be much worse.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] need help with frozen module/marshal/gc issue involving sub-interpreters for importlib bootstrapping
On Mon, Feb 6, 2012 at 11:32, Benjamin Peterson benja...@python.org wrote: 2012/2/6 Brett Cannon br...@python.org: Thanks for any help people can provide me on this now 5 year quest to get this work finished. Fixed. (_PyExc_Init was behaving badly.) That did it! Thanks, Benjamin! Doing one more -uall test run before I declare the bootstrap working. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): remove unused import
On Tue, Feb 7, 2012 at 4:52 AM, francis franci...@email.de wrote: Hi Brett, If that's the case I might as well add it as part of my mnfy project's verification run I do over the stdlib if someone doesn't beat me to it. Is that devinabox ? No, it's Brett's Python minifier: http://pypi.python.org/pypi/mnfy devinabox is the everything you need to get started with contributing to CPython and Python standard library development Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is this safe enough? Re: [Python-checkins] cpython: _Py_Identifier are always ASCII strings
2012/2/6 Jim Jewett jimjjew...@gmail.com: I realize that _Py_Identifier is a private name, and that PEP 3131 requires anything (except test cases) in the standard library to stick with ASCII ... but somehow, that feels like too long of a chain. I would prefer to see _Py_Identifier renamed to _Py_ASCII_Identifier, or at least a comment stating that Identifiers will (per PEP 3131) always be ASCII -- preferably with an assert to back that up. _Py_IDENTIFIER(xxx) defines a variable called PyId_xxx, so xxx can only be ASCII: the C language doesn't accept non-ASCII identifiers. I thaugh that _Py_IDENTIFIER() macro was the only way to create a identifier and so ASCII was enough... but there is also _Py_static_string. _Py_static_string(name, value) allows to specify an arbitrary string, so you may pass a non-ASCII value. I don't see any usecase where you need a non-ASCII value in Python core. - id-object = PyUnicode_DecodeUTF8Stateful(id-string, - strlen(id-string), - NULL, NULL); + id-object = unicode_fromascii((unsigned char*)id-string, + strlen(id-string)); This is just an optimization. If you think that _Py_static_string() is useful, I can revert my change. Otherwise, _Py_static_string() should be removed. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Is this safe enough? Re: [Python-checkins] cpython: _Py_Identifier are always ASCII strings
On Mon, 6 Feb 2012 22:57:46 +0100 Victor Stinner victor.stin...@haypocalc.com wrote: - id-object = PyUnicode_DecodeUTF8Stateful(id-string, - strlen(id-string), - NULL, NULL); + id-object = unicode_fromascii((unsigned char*)id-string, + strlen(id-string)); This is just an optimization. Is the optimization even worthwhile? This code is typically called once for every static string. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
