Re: [Python-Dev] A new JIT compiler for a faster CPython?
On 20 Jul 2012, at 17:50, Maciej Fijalkowski wrote: > On Fri, Jul 20, 2012 at 2:55 PM, Michael Foord > wrote: > > On 17 Jul 2012, at 23:04, [email protected] wrote: > > >> [snip...] > > > >> I would like to use a JIT to generate specialized functions for a > >> combinaison of arguments types. > > > > I think history has moved past specializing JITs. Tracing JITs are the > > status quo; they provide specialization as a side effect. > > > > Mozilla implemented a method-JIT (compile whole methods) on top of their > tracing JIT because a tracing JIT only optimises part of your code (only in > loops and only if executed more times than the threshold) and there are > further performance improvements to be had. So tracing JITs are not the > *whole* of the state of the art. > > Michael > > I'm sorry michael but you're like a 100th person I have to explain this to. > The pure reason that mozilla did not make a tracing JIT work does not mean > the entire approach is horribly doomed as many people would like to assume. > The reasons are multiple, but a lot of them are connected to poor engineering > (for example the part inherited from adobe is notoriously bad, have a look if > you want). Well, that isn't how they describe it. If it is the case, it's *still* interesting that rather than putting their efforts into improving the tracing JIT they put them into adding a method-JIT *as well*. Also note that where I said "tracing JITs are not the whole of the state of the art" you somehow managed to translate this into "the entire approach is horribly doomed". That seems an ungenerous reading of what I wrote... :-) Michael > > Cheers, > fijal > > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new JIT compiler for a faster CPython?
On Sat, 21 Jul 2012 11:45:21 +0100 Michael Foord wrote: > > On 20 Jul 2012, at 17:50, Maciej Fijalkowski wrote: > > > On Fri, Jul 20, 2012 at 2:55 PM, Michael Foord > > wrote: > > > > On 17 Jul 2012, at 23:04, [email protected] wrote: > > > > >> [snip...] > > > > > >> I would like to use a JIT to generate specialized functions for a > > >> combinaison of arguments types. > > > > > > I think history has moved past specializing JITs. Tracing JITs are the > > > status quo; they provide specialization as a side effect. > > > > > > > Mozilla implemented a method-JIT (compile whole methods) on top of their > > tracing JIT because a tracing JIT only optimises part of your code (only in > > loops and only if executed more times than the threshold) and there are > > further performance improvements to be had. So tracing JITs are not the > > *whole* of the state of the art. > > > > Michael > > > > I'm sorry michael but you're like a 100th person I have to explain this to. > > The pure reason that mozilla did not make a tracing JIT work does not mean > > the entire approach is horribly doomed as many people would like to assume. > > The reasons are multiple, but a lot of them are connected to poor > > engineering (for example the part inherited from adobe is notoriously bad, > > have a look if you want). > > > Well, that isn't how they describe it. If it is the case, it's *still* > interesting > that rather than putting their efforts into improving the tracing JIT they > put them > into adding a method-JIT *as well*. Honestly I'm not sure that's a very interesting discussion. First, Javascript performance is not based on the same prorities as Python performance: for the former, startup time is key. Second, whether method-based or tracing-based, a well-written JIT would certainly bring significant performance improvements over a bytecode interpreter anyway. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list [email protected] 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: Issue #15168: Move importlb.test to test.test_importlib.
On Fri, Jul 20, 2012 at 4:12 PM, Antoine Pitrou wrote: > On Fri, 20 Jul 2012 20:49:03 +0200 (CEST) > brett.cannon wrote: > > diff --git a/Lib/importlib/test/__init__.py > b/Lib/test/test_importlib/__init__.py > > rename from Lib/importlib/test/__init__.py > > rename to Lib/test/test_importlib/__init__.py > > --- a/Lib/importlib/test/__init__.py > > +++ b/Lib/test/test_importlib/__init__.py > > @@ -1,5 +1,6 @@ > > import os > > import sys > > +from .. import support > > I don't know if I'm only speaking for myself, but I really have trouble > parsing non-trivial relative imports, I obviously don't, but then again I would hope I of all people could comprehend them after all this time. =) > and I personally prefer when > people use absolute imports (e.g. "from test import support"). > > So I changed the import above, but I'm not going to go through and change every other relative import that stays within test.test_importlib. I'm fine if someone else wants to change them, but I leave that as an exercise for the reader. -Brett > cheers > > Antoine. > > > -- > Software development and contracting: http://pro.pitrou.net > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] 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): ISsue #14988: restore Python 2's behavior of raising ImportError when unable to
This looks like it will give an "error return without exception set" if the "if (expat_capi)" directly before the change is true, and expat_capi is then set to NULL in the branch. Georg On 07/17/2012 01:25 PM, eli.bendersky wrote: > http://hg.python.org/cpython/rev/d896fd0a8ba7 > changeset: 78152:d896fd0a8ba7 > branch: 3.2 > parent: 78142:71537aba3a0a > user:Eli Bendersky > date:Tue Jul 17 14:20:38 2012 +0300 > summary: > ISsue #14988: restore Python 2's behavior of raising ImportError when > unable to load pyexpat, instead of a SystemError/RuntimeError > > files: > Modules/_elementtree.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > > diff --git a/Modules/_elementtree.c b/Modules/_elementtree.c > --- a/Modules/_elementtree.c > +++ b/Modules/_elementtree.c > @@ -3117,6 +3117,8 @@ > expat_capi->MICRO_VERSION != XML_MICRO_VERSION) > expat_capi = NULL; > } > +if (!expat_capi) > +return NULL; > #endif > > elementtree_parseerror_obj = PyErr_NewException( > > > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > ___ Python-Dev mailing list [email protected] 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: Optimize tostringlist by taking the stream class outside the function. It's now
Uh, optimizations are not exactly what I want to see during feature freeze. Georg On 07/17/2012 02:10 PM, eli.bendersky wrote: > http://hg.python.org/cpython/rev/51978f89e5ed > changeset: 78156:51978f89e5ed > user:Eli Bendersky > date:Tue Jul 17 15:09:12 2012 +0300 > summary: > Optimize tostringlist by taking the stream class outside the function. It's > now 2x faster on short calls. Related to #1767933 > > files: > Lib/xml/etree/ElementTree.py | 38 +-- > 1 files changed, 22 insertions(+), 16 deletions(-) > > > diff --git a/Lib/xml/etree/ElementTree.py b/Lib/xml/etree/ElementTree.py > --- a/Lib/xml/etree/ElementTree.py > +++ b/Lib/xml/etree/ElementTree.py > @@ -1184,23 +1184,29 @@ > # @defreturn sequence > # @since 1.3 > > +class _ListDataStream(io.BufferedIOBase): > +""" An auxiliary stream accumulating into a list reference > +""" > +def __init__(self, lst): > +self.lst = lst > + > +def writable(self): > +return True > + > +def seekable(self): > +return True > + > +def write(self, b): > +self.lst.append(b) > + > +def tell(self): > +return len(self.lst) > + > def tostringlist(element, encoding=None, method=None): > -data = [] > -class DataStream(io.BufferedIOBase): > -def writable(self): > -return True > - > -def seekable(self): > -return True > - > -def write(self, b): > -data.append(b) > - > -def tell(self): > -return len(data) > - > -ElementTree(element).write(DataStream(), encoding, method=method) > -return data > +lst = [] > +stream = _ListDataStream(lst) > +ElementTree(element).write(stream, encoding, method=method) > +return lst > > ## > # Writes an element tree or element structure to sys.stdout. This > > > > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > ___ Python-Dev mailing list [email protected] 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: Optimize tostringlist by taking the stream class outside the function. It's now
On Sat, Jul 21, 2012 at 5:43 PM, Georg Brandl wrote: > Uh, optimizations are not exactly what I want to see during feature freeze. > This is not a new optimization. It fixes a performance regression introduced by an earlier bugfix changeset (for http://bugs.python.org/issue1767933). Eli ___ Python-Dev mailing list [email protected] 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): ISsue #14988: restore Python 2's behavior of raising ImportError when unable to
On Sat, Jul 21, 2012 at 5:41 PM, Georg Brandl wrote: > This looks like it will give an "error return without exception set" > if the "if (expat_capi)" directly before the change is true, and > expat_capi is then set to NULL in the branch. > > Georg > Good catch! I'll fix it soon. Eli > On 07/17/2012 01:25 PM, eli.bendersky wrote: >> http://hg.python.org/cpython/rev/d896fd0a8ba7 >> changeset: 78152:d896fd0a8ba7 >> branch: 3.2 >> parent: 78142:71537aba3a0a >> user:Eli Bendersky >> date:Tue Jul 17 14:20:38 2012 +0300 >> summary: >> ISsue #14988: restore Python 2's behavior of raising ImportError when >> unable to load pyexpat, instead of a SystemError/RuntimeError >> >> files: >> Modules/_elementtree.c | 2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> >> diff --git a/Modules/_elementtree.c b/Modules/_elementtree.c >> --- a/Modules/_elementtree.c >> +++ b/Modules/_elementtree.c >> @@ -3117,6 +3117,8 @@ >> expat_capi->MICRO_VERSION != XML_MICRO_VERSION) >> expat_capi = NULL; >> } >> +if (!expat_capi) >> +return NULL; >> #endif >> >> elementtree_parseerror_obj = PyErr_NewException( >> >> >> >> ___ >> Python-checkins mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-checkins >> > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/eliben%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] four easy documentation patches
I was wondering if someone could review the following minor documentation patches: Document that filecmp.dircmp comparisons are "shallow" (7/5/2012): http://bugs.python.org/issue15250 Document dircmp.left and dircmp.right (7/6/2012): http://bugs.python.org/issue15269 Update "PyPI package display" documentation re: rst2html.py (7/5/2012): http://bugs.python.org/issue15231 [Dev Guide] Update documentation around Dev Guide process (7/10/2012): http://bugs.python.org/issue15311 Thanks, --Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_hashlib
I was hit by this today.
in test_hashlib.py there is this:
def test_unknown_hash(self):
self.assertRaises(ValueError, hashlib.new, 'spam spam spam spam spam')
self.assertRaises(TypeError, hashlib.new, 1)
but in hashlib.py, there is this code:
except ImportError:
pass # no extension module, this hash is unsupported.
raise ValueError('unsupported hash type %s' % name)
The code will raise ValueError when int(1) is passed in, but the unittests
expect a TypeError.
So, which is correct?
K
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_hashlib
On Sat, 21 Jul 2012 21:29:50 + Kristján Valur Jónsson wrote: > > The code will raise ValueError when int(1) is passed in, but the > unittests expect a TypeError. Well, if test_hashlib passes, surely your analysis is wrong, no? -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_hashlib
2012/7/21 Antoine Pitrou : > Kristján Valur Jónsson wrote: >> >> The code will raise ValueError when int(1) is passed in, but the >> unittests expect a TypeError. > > Well, if test_hashlib passes, surely your analysis is wrong, no? In the normal case, yes: >>> import hashlib >>> hashlib.new(1) TypeError: name must be a string But if the _hashlib extension module is not available, the python version is used and ValueError is raised: >>> import sys >>> sys.modules['_hashlib'] = None >>> import hashlib >>> hashlib.new(1) ValueError: unsupported hash type 1 -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_hashlib
I think I see Kristján's point: the pure Python implementation handles errors differently than the C implementation, so the unittest fails if the pure Python version is enabled. I imagine this is a general problem that often occurs when a pure Python version is normally shadowed by a C extension, unless the unittest is rigged so that it tests the pure Python version as well as the C version. But it still remains a matter of judgment whether in a particular case the unittest is overspecified or the Python version is incorrect. I think that in this case Kristján's hunch is correct, and the pure Python version needs to be adjusted to pass the test. I also think this is a low priority issue since it only affects behavior of error cases. --Guido On Sat, Jul 21, 2012 at 3:56 PM, Amaury Forgeot d'Arc wrote: > 2012/7/21 Antoine Pitrou : >> Kristján Valur Jónsson wrote: >>> >>> The code will raise ValueError when int(1) is passed in, but the >>> unittests expect a TypeError. >> >> Well, if test_hashlib passes, surely your analysis is wrong, no? > > In the normal case, yes: > import hashlib hashlib.new(1) > TypeError: name must be a string > > But if the _hashlib extension module is not available, the python > version is used and ValueError is raised: > import sys sys.modules['_hashlib'] = None import hashlib hashlib.new(1) > ValueError: unsupported hash type 1 > > -- > Amaury Forgeot d'Arc > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] venv scripts for fish and csh shells
I created http://bugs.python.org/issue15417 with required activation scripts. If there are no objections I like to commit it after, say, three days. On Thu, Jul 19, 2012 at 7:31 PM, Carl Meyer wrote: > On 07/19/2012 10:26 AM, Andrew Svetlov wrote: >> virtualenv has virtualenv.csh and virtualenv.fish files. >> Is there any reason for restricting venv to bash/zsh only? > > No. As far as I'm concerned, a patch to port the virtualenv csh and fish > activate scripts to pyvenv would be welcome (though I can't commit said > patch, so it might be good to hear if Vinay has a different opinion). > > Carl > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_hashlib
Indeed, shame on me for not mentioning this. I rarely have the full complement of externals available when I'm doing python work, and it struck me that this unitest was failing. I suppose it should be possible to write unittests that test more than one particular implementation. K Frá: [email protected] [[email protected]] fyrir hönd Amaury Forgeot d'Arc [[email protected]] Sent: 21. júlí 2012 22:56 To: Antoine Pitrou Cc: [email protected] Efni: Re: [Python-Dev] test_hashlib 2012/7/21 Antoine Pitrou : > Kristján Valur Jónsson wrote: >> >> The code will raise ValueError when int(1) is passed in, but the >> unittests expect a TypeError. > > Well, if test_hashlib passes, surely your analysis is wrong, no? In the normal case, yes: >>> import hashlib >>> hashlib.new(1) TypeError: name must be a string But if the _hashlib extension module is not available, the python version is used and ValueError is raised: >>> import sys >>> sys.modules['_hashlib'] = None >>> import hashlib >>> hashlib.new(1) ValueError: unsupported hash type 1 -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_hashlib
On Sun, 22 Jul 2012 01:05:35 -, =?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?= wrote: > Indeed, shame on me for not mentioning this. > I rarely have the full complement of externals available when I'm doing > python work, and it struck me that this unitest was failing. > I suppose it should be possible to write unittests that test more than one > particular implementation. It is indeed, and we have been moving the unit tests to do exactly that for the cases where there is a Python implementation as well as a C implementation. It seems like it would be appropriate to open an issue for doing that for hashlib, in addition to one for fixing this particular issue with the Python version. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_hashlib
Fixed. The TypeError in this nonsense never gonna work use case is now consistent in 2.7, 3.2 and 3.3. On Sat, Jul 21, 2012 at 7:10 PM, R. David Murray wrote: > On Sun, 22 Jul 2012 01:05:35 -, > =?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?= wrote: > > Indeed, shame on me for not mentioning this. > > I rarely have the full complement of externals available when I'm doing > python work, and it struck me that this unitest was failing. > > I suppose it should be possible to write unittests that test more than > one particular implementation. > > It is indeed, and we have been moving the unit tests to do exactly > that for the cases where there is a Python implementation as well as > a C implementation. It seems like it would be appropriate to open an > issue for doing that for hashlib, in addition to one for fixing this > particular issue with the Python version. > > --David > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
