[Python-Dev] _PyImport_FindExtensionObject() does not set _Py_PackageContext

Hi, I noticed that _PyImport_FindExtensionObject() in Python/import.c does not set _Py_PackageContext when it calls the module init function for module reinitialisation. However, PyModule_Create2() still uses that variable to figure out the fully qualified module name. Was this intentionally l

[Python-Dev] how to find the file path to an extension module at init time?

Hi, in Python modules, the "__file__" attribute is provided by the runtime before executing the module body. For extension modules, it is set only after executing the init function. I wonder if there's any way to figure out where an extension module is currently being loaded from. The _PyImpo

Re: [Python-Dev] how to find the file path to an extension module at init time?

"Martin v. Löwis", 13.11.2011 21:46: I'm asking specifically because I'd like to properly implement __file__ in Cython modules at module init time. Why do you need to implement __file__? Python will set it eventually to its correct value, no? Well, yes, eventually. However, almost all real wo

Re: [Python-Dev] how to find the file path to an extension module at init time?

mark florisson, 14.11.2011 12:55: On 14 November 2011 08:18, Stefan Behnel wrote: "Martin v. Löwis", 13.11.2011 21:46: I'm asking specifically because I'd like to properly implement __file__ in Cython modules at module init time. Why do you need to implement __file__

Re: [Python-Dev] how to find the file path to an extension module at init time?

"Martin v. Löwis", 15.11.2011 01:33: Currently, for Cython? I don't think that can work. Hmm, it might work to put an empty module next to the 'real' extension and to import it to figure out the common directory of both. As long as it's still there after installation and the right one gets impo

Re: [Python-Dev] how to find the file path to an extension module at init time?

Stefan Behnel, 15.11.2011 09:01: "Martin v. Löwis", 15.11.2011 01:33: An approach similar to _Py_PackageContext should be possible. Yes, and a "_Py_ModuleImportContext" would be rather trivial to do. Could that go into 3.3? If somebody contributes a patch: sure.

Re: [Python-Dev] _PyImport_FindExtensionObject() does not set _Py_PackageContext

Stefan Behnel, 13.11.2011 19:48: I noticed that _PyImport_FindExtensionObject() in Python/import.c does not set _Py_PackageContext when it calls the module init function for module reinitialisation. However, PyModule_Create2() still uses that variable to figure out the fully qualified module

[Python-Dev] patch metadata - to use or not to use?

Hi, I recently got some patches accepted for inclusion in 3.3, and each time, the patch metadata (such as my name and my commit comment) were stripped by applying the patch manually, instead of hg importing it. This makes it clear in the history who eventually reviewed and applied the patch, b

Re: [Python-Dev] PyPy 1.7 - widening the sweet spot

Giampaolo Rodolà, 22.11.2011 10:21: 2011/11/21 Terry Reedy: I strongly recommend that where it makes a difference, the pypy python3 project target 3.3. In particular, don't reproduce the buggy narrow-build behavior of 3.2 and before (perhaps pypy avoids this already). Do include the new unicode

Re: [Python-Dev] PyPy 1.7 - widening the sweet spot

Maciej Fijalkowski, 22.11.2011 15:46: On Tue, Nov 22, 2011 at 3:15 PM, Stefan Behnel wrote: Giampaolo Rodolà, 22.11.2011 10:21: 2011/11/21 Terry Reedy: I strongly recommend that where it makes a difference, the pypy python3 project target 3.3. In particular, don't reproduce the buggy n

[Python-Dev] Fixing the XML batteries

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

Re: [Python-Dev] Fixing the XML batteries

"Martin v. Löwis", 09.12.2011 09:41: 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

Re: [Python-Dev] Fixing the XML batteries

Bill Janssen, 09.12.2011 19:15: I think another thing that might go into "refreshing the batteries" is a feature comparison of BeautifulSoup and HTML5lib against the stdlib competition, to see what needs to be added/revised. Having to switch to an outside package for parsing possibly invalid HTM

Re: [Python-Dev] Fixing the XML batteries

"Martin v. Löwis", 11.12.2011 23:39: I can't recall anyone working on any substantial improvements during the last six years or so, and the reason for that seems obvious to me. What do you think is the reason? It's not at all obvious to me. Just to repeat myself for the third time here: lack

Re: [Python-Dev] Fixing the XML batteries

"Martin v. Löwis", 11.12.2011 23:03: Am 09.12.2011 10:09, schrieb Xavier Morel: On 2011-12-09, at 09:41 , Martin v. Löwis wrote: 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 shou

Re: [Python-Dev] Fixing the XML batteries

Stefan Behnel, 12.12.2011 10:59: Just look through the xml-sig page Hmm, I meant "xml-sig mailing list archive" here ... Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscr

Re: [Python-Dev] readd u'' literal support in 3.3?

"Martin v. Löwis", 14.12.2011 18:23: overhead of running 2to3 every time 'setup.py develop' etc. runs dooms the effort. How so? Running 2to3 after every change is very fast. I never use setup.py develop, though. I think the problem starts with the fact that it needs to be run in the first pl

Re: [Python-Dev] Fixing the XML batteries

"Martin v. Löwis", 14.12.2011 19:14: Am 12.12.2011 10:04, schrieb Stefan Behnel: "Martin v. Löwis", 11.12.2011 23:39: I can't recall anyone working on any substantial improvements during the last six years or so, and the reason for that seems obvious to me. What d

Re: [Python-Dev] Fixing the XML batteries

Xavier Morel, 14.12.2011 20:54: On 2011-12-14, at 20:41 , Stefan Behnel wrote: I meant: "lack of interest in improving them". It's clear from the discussion that there are still users and that new code is still being written that uses MiniDOM. However, I would argue that this can

Re: [Python-Dev] Fixing the XML batteries

"Martin v. Löwis", 14.12.2011 22:20: Am 14.12.2011 20:41, schrieb Stefan Behnel: "Martin v. Löwis", 14.12.2011 19:14: Am 12.12.2011 10:04, schrieb Stefan Behnel: "Martin v. Löwis", 11.12.2011 23:39: I can't recall anyone working on any substantial improveme

Re: [Python-Dev] Fixing the XML batteries

Stefan Behnel, 09.12.2011 09:02: I think Py3.3 would be a good milestone for cleaning up the stdlib support for XML. [...] I still think it is, so let me sum up the current discussion here. What should change? a) The stdlib documentation should help users to choose the right tool right

Re: [Python-Dev] Fixing the XML batteries

Stefan Behnel, 14.12.2011 20:41: It's clear from the discussion that there are still users and that new code is still being written that uses MiniDOM. However, I would argue that this cannot possibly be performance critical code and that it only deals with somewhat small documents. I say

Re: [Python-Dev] Anyone still using Python 2.5?

Antoine Pitrou, 22.12.2011 10:56: On Thu, 22 Dec 2011 09:44:32 + Tim Wintle wrote: 2.5 apps are the speed-critical ones. Our tests showed the performance was different enough between 2.5 and 2.6 for me to not update. Really? Where's the regression? That's not unexpected at least, and ma

Re: [Python-Dev] A new dict for Xmas?

Mark Shannon, 23.12.2011 12:21: Martin v. Löwis wrote: - it would be useful to have a specialized representation for all-keys-are-strings. In that case, me_hash could be dropped from the representation. You would get savings compared to the status quo even in the non-shared case. It might trick

Re: [Python-Dev] Hash collision security issue (now public)

Christian Heimes, 31.12.2011 04:59: > Am 31.12.2011 03:22, schrieb Victor Stinner: > The unique structure of CPython's dict implementation makes it harder to > get the number of values with equal hash. The academic hash map (the one > I learnt about at university) uses a bucket to store all element

Re: [Python-Dev] Hash collision security issue (now public)

Jim Jewett, 08.01.2012 23:33: > Stefan Behnel wrote: >> Admittedly, this may require some adaptation for the PEP393 unicode memory >> layout in order to produce identical hashes for all three representations >> if they represent the same content. > > They SHOULD NOT

Re: [Python-Dev] Python C API: Problem sending tuple to a method of a python Class

Hi, sorry for hooking into this off-topic thread. Amaury Forgeot d'Arc, 09.01.2012 19:09: > 2012/1/9 >> I am trying to send a tuple to a method of a python class and I got a Run >> failed from netbeans compiler >> when I want to send a tuple to a simple method in a module it works,when I >> want

Re: [Python-Dev] Python C API: Problem sending tuple to a method of a python Class

Matt Joiner, 10.01.2012 09:40: > Perhaps the python-dev mailing list should be renamed to python-core. Well, there *is* a rather visible warning on the list subscription page that tells people that it's most likely not the list they actually want to use. If they manage to ignore that, I doubt that

Re: [Python-Dev] Status of the fix for the hash collision vulnerability

Terry Reedy, 14.01.2012 06:43: > On 1/13/2012 8:58 PM, Gregory P. Smith wrote: > >> It is perfectly okay to break existing users who had anything depending >> on ordering of internal hash tables. Their code was already broken. > > Given that the doc says "Return the hash value of the object", I d

Re: [Python-Dev] Status of the fix for the hash collision vulnerability

Guido van Rossum, 15.01.2012 17:10: > On Sun, Jan 15, 2012 at 6:30 AM, Stefan Behnel wrote: >> Terry Reedy, 14.01.2012 06:43: >>> On 1/13/2012 8:58 PM, Gregory P. Smith wrote: >>> >>>> It is perfectly okay to break existing users who had anything depending &

Re: [Python-Dev] [issue13703] Hash collision security issue

Glenn Linderman, 27.01.2012 07:47: > Can we have a tree type in 3.3, independent of dict? I'd be happy to see that happen, but I guess the usual requirements on stdlib extensions would apply here. I.e., someone has to write the code, make sure people actually use it to prove that it's worth being

Re: [Python-Dev] [issue13703] Hash collision security issue

mar...@v.loewis.de, 27.01.2012 09:55: > So I found Ian Piumarta's AVL tree 1.0 from 2006. I trust Ian Piumarta > to get it right (plus I reviewed the code a little). There are some > API glitches (such as assuming a single comparison function, whereas > it would better be rewritten to directly invo

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

stefan brunthaler, 30.01.2012 20:18: >> Well, you're aware that Python already uses threaded code where >> available? Or are you testing against Python 2? >> > Yes, and I am building on that. I assume "yes" here means "yes, I'm aware" and not "yes, I'm using Python 2", right? And you're building o

[Python-Dev] PEPs and cons (was: Re: Store timestamps as decimal.Decimal objects)

Nick Coghlan, 31.01.2012 12:11: > On Tue, Jan 31, 2012 at 7:42 PM, Victor Stinner wrote: >>> I think this is definitely worth elaborating in a PEP (to recap the >>> long discussion in #11457 if nothing else). >> >> The discussion in issues #13882 and #11457 already lists many >> alternatives with t

Re: [Python-Dev] Python 3 optimizations, continued, continued again...

stefan brunthaler, 31.01.2012 22:17: >> Well, nobody wants to review generated code. >> > I agree. The code generator basically uses templates that contain the > information and a dump of the C-structure of several types to traverse > and see which one of them implements which functions. There is r

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Eli Bendersky, 08.02.2012 07:07: > On Wed, Feb 8, 2012 at 07:10, Fred Drake wrote: >> On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky wrote: >>> The initial proposal of changing *the stdlib >>> import facade* for xml.etree.ElementTree to use the C accelerator >>> (_elementtree) by default. >> >> I g

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Fred Drake, 08.02.2012 05:41: > On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky wrote: >> Besides, in >> http://mail.python.org/pipermail/python-dev/2011-December/114812.html >> Stefan Behnel said "[...] Today, ET is *only* being maintained in the >> stdlib by Flo

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Eli Bendersky, 10.02.2012 10:06: > On Fri, Feb 10, 2012 at 10:32, Florent wrote: >> 2012/2/10 Eli Bendersky >>> >>> Thanks for the input, Florent. So, to paraphrase, there already are >>> code changes in the stdlib version of ET/cET which are not upstream. >>> You made it explicit about the te

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

"Martin v. Löwis", 10.02.2012 10:37: >> Given that it was two months ago that I started the "Fixing the XML >> batteries" thread (and years since I brought up the topic for the first >> time), it seems to be hard enough already to get anyone on python-dev >> actually do something for Python's XML s

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

"Martin v. Löwis", 10.02.2012 11:32: >> What happens now? Do we give up on touching it until Fredrik Lundh >> decides on a come-back or some person who is willing to commit 5 years >> is found? Or do we just *keep* maintaining it in the stdlib as we do >> with other modules, fixing bugs, tests, doc

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Eli Bendersky, 13.02.2012 12:35: >> Since there appeared to be an overall positive response for making >> this change in Python 3.3, and since there isn't longer any doubt >> about the ownership of the package *in Python's stdlib* (see >> http://mail.python.org/pipermail/python-dev/2012-February/11

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

Nick Coghlan, 14.02.2012 05:44: > On Tue, Feb 14, 2012 at 2:25 PM, Eli Bendersky wrote: >> With the deprecation warning being silent, is there much to lose, though? > > Yes, it creates problems for anyone that deliberately converts all > warnings to errors when running their test suites. This forc

[Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Hi, the Cython and PyPy projects are currently working on getting Cython implemented extensions to build and run in PyPy, interfacing at the C-API level for now. One problem we encountered was that there is currently no "abstract" way to access tstate->exc_type and friends, i.e. the last exceptio

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Nick Coghlan, 19.02.2012 15:31: > On Mon, Feb 20, 2012 at 12:18 AM, Paul Moore wrote: >> Of course, you could always go through the Python API, getting the sys >> module, extracting the relevant functions and calling them using the >> abstract API. That's what I'd recommend if this were purely a CP

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

"Martin v. Löwis", 19.02.2012 23:24: >> When compiling for PyPy, Cython therefore needs a way to tell PyPy about >> any changes. For the tstate->curexc_* fields, there are the two functions >> PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official" >> functions for the exc_* fields?

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

Stefan Behnel, 23.02.2012 09:01: > "Martin v. Löwis", 19.02.2012 23:24: >>> When compiling for PyPy, Cython therefore needs a way to tell PyPy about >>> any changes. For the tstate->curexc_* fields, there are the two functions >>> PyErr_Fetch() and

[Python-Dev] Assertion in _PyManagedBuffer_FromObject()

Hi, I just stumbled over this assertion in _PyManagedBuffer_FromObject() in the latest Py3.3 branch: """ static PyObject * _PyManagedBuffer_FromObject(PyObject *base) { _PyManagedBufferObject *mbuf; mbuf = mbuf_alloc(); if (mbuf == NULL) return NULL; if (PyObject_GetBuff

Re: [Python-Dev] Assertion in _PyManagedBuffer_FromObject()

Stefan Krah, 02.03.2012 12:53: > Stefan Behnel wrote: >> if (PyObject_GetBuffer(base, &mbuf->master, PyBUF_FULL_RO) < 0) { >> /* mbuf->master.obj must be NULL. */ >> Py_DECREF(mbuf); >> return NULL; >> } >> >>

Re: [Python-Dev] Assertion in _PyManagedBuffer_FromObject()

with a C assert when we can easily give them a nice > Python traceback instead is unnecessarily unfriendly. As Stefan Behnel > pointed out, by tightening up the API semantics, we're already running > the risk of breaking applications that relied on looking at what the > old code *d

Re: [Python-Dev] Assertion in _PyManagedBuffer_FromObject()

;>> from _testbuffer import * >> >>> exporter = b'123' >> >>> nd = ndarray(exporter) >> >>> m = memoryview(nd) >> >>> nd.obj >> b'123' >> >>> m.obj >> > > Stefan (Behnel), do you have

Re: [Python-Dev] Assertion in _PyManagedBuffer_FromObject()

Nick Coghlan, 03.03.2012 00:49: > On Sat, Mar 3, 2012 at 3:14 AM, Stefan Behnel wrote: >> Stefan Krah, 02.03.2012 17:42: >>> The reason why this scheme was not chosen for a chain of memoryviews >>> was that 'exporter' (in theory) could implement a slideshow of

Re: [Python-Dev] slice subscripts for sequences and mappings

Eli Bendersky, 03.03.2012 09:36: > I find a strange discrepancy in Python with regards to slice > subscripting of objects, at the C API level. I mean things like > obj[start:end:step]. > > I'd expect slice subscripts to be part of the sequence interface, and > yet they are not. In fact, they are p

Re: [Python-Dev] slice subscripts for sequences and mappings

Thomas Wouters, 03.03.2012 21:59: > Why even have separate tp_as_sequence and tp_as_mapping anymore? That > particular distinction never existed for Python types, so why should it > exist for C types at all? I forget if there was ever a real point to it, > but all it seems to do now is create confu

[Python-Dev] Matrix testing against CPython releases (was: Re: Assertion in _PyManagedBuffer_FromObject())

Stefan Krah, 04.03.2012 12:33: > Thomas Wouters wrote: >> Do you test against pydebug builds of Python, or otherwise a build that >> actually enables asserts? > > Yes, I do (and much more than that): > > http://hg.python.org/features/cdecimal/file/40917e4b51aa/Modules/_decimal/python/runall-memor

Re: [Python-Dev] Undocumented view==NULL argument in PyObject_GetBuffer()

Nick Coghlan, 06.03.2012 12:19: > On Tue, Mar 6, 2012 at 8:34 PM, Stefan Krah wrote: >> The obvious question is: Will anyone need view==NULL in the future or >> can we remove the special case? > > The public API will still need a guard (to report an error), but +1 > for otherwise eliminating the u

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 1

Jim J. Jewett, 06.03.2012 20:43: > Hash Randomization (issue 13703) is now on by default. Unfortunately, > this does break some tests; it can be temporarily turned off by setting > the environment variable PYTHONHASHSEED to "0" before launching python. I don't think that makes it clear enough tha

[Python-Dev] problem with recursive "yield from" delegation

Hi, I found a problem in the current "yield from" implementation that I think is worth discussing: http://bugs.python.org/issue14220 Test code: def g1(): yield "y1" yield from g2() yield "y4" def g2(): yield "y2" try: yield from gi

Re: [Python-Dev] Sandboxing Python

Maciej Fijalkowski, 06.03.2012 00:08: > For a comparison, PyPy sandbox is a compiled from higher-level > language program that by design does not have all sorts of problems > described. The amount of code you need to carefully review is very > minimal (as compared to the entire CPython interpreter)

Re: [Python-Dev] problem with recursive "yield from" delegation

Stefan Behnel, 07.03.2012 21:40: > I found a problem in the current "yield from" implementation ... and here's another one, also in genobject.c: """ int PyGen_FetchStopIterationValue(PyObject **pvalue) { PyObject *et, *ev, *tb; PyObject *value = NULL

[Python-Dev] performance of generator termination (was: Re: problem with recursive "yield from" delegation)

Antoine Pitrou, 08.03.2012 21:36: > On Thu, 8 Mar 2012 14:36:06 -0600 > Benjamin Peterson wrote: >> 2012/3/8 Stefan Behnel: >>> Would that be acceptable for CPython as well or would you prefer full >>> fledged normalisation? >> >> I think we have to norma

Re: [Python-Dev] Raising assertions on wrong element types in ElementTree

Eli Bendersky, 16.03.2012 08:38: > The Element class in ElementTree > (http://docs.python.org/py3k/library/xml.etree.elementtree.html) has > some methods for adding new children: append, insert and extend. > Currently the documentation states that extend raises AssertionError > when something that'

Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)

Guido van Rossum, 17.03.2012 00:57: > OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ? In lxml, there was an "encoding=unicode" option that would let the XML/HTML/text serialisation function return a Unicode string. This was eventually deprecated in favour of "encoding='uni

Re: [Python-Dev] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)

Merlijn van Deen, 17.03.2012 15:20: > On 17 March 2012 10:43, Stefan Behnel wrote: >> In lxml, there was an "encoding=unicode" option that would let the >> XML/HTML/text serialisation function return a Unicode string. This was >> eventually deprecated in favo

Re: [Python-Dev] Issue 14417: consequences of new dict runtime error

R. David Murray, 29.03.2012 22:31: > On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum wrote: >> On Thu, Mar 29, 2012 at 12:58 PM, R. David Murray wrote: >>> Some of us have expressed uneasiness about the consequences of dict >>> raising an error on lookup if the dict has been modified, the fix

Re: [Python-Dev] Issue 14417: consequences of new dict runtime error

Etienne Robillard, 30.03.2012 17:45: > Sorry also if this is OT... :) Yes, it is. Please do as Nick told you. Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.o

Re: [Python-Dev] Issue 14417: consequences of new dict runtime error

Etienne Robillard, 30.03.2012 18:08: > are you also truth allergic or irritated by the consequences of > free speech ? Please note that "free speech" is a concept that is different from asking beginner's computer science questions on the core developer mailing list of a software development projec

Re: [Python-Dev] Using Cython for developing a module to be used from postgreSQL/pl/python

Hannu Krosing, 31.03.2012 14:22: > Has anyone used Cython for developing a module to be used from > postgreSQL/pl/python. > > Something that calls back to PostgreSQL internals. Note that this is the CPython core developers mailing list, for which your question is off-topic. Please ask on the cyth

Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo

Antoine Pitrou, 02.04.2012 13:50: > On Sun, 1 Apr 2012 19:44:00 -0500 > Brian Curtin wrote: >> On Sun, Apr 1, 2012 at 17:31, Matěj Cepl wrote: >>> On 1.4.2012 23:46, Brian Curtin wrote: For what reason? Are the git or bzr files causing issues on HG? >>> >>> >>> No, but wrong .gitignore causes

Re: [Python-Dev] Experimenting with STM on CPython

Armin Rigo, 11.04.2012 13:47: > This is an update on the (so far PyPy-only) project of adding "Automatic > Mutual Exclusion" to Python, via STM (Software Transactional Memory). > [...] > Moreover the performance hit is well below 2x, more like 20%. Hmm, those 20% refer to STM, right? Without hardw

Re: [Python-Dev] Experimenting with STM on CPython

Armin Rigo, 11.04.2012 14:51: > On Wed, Apr 11, 2012 at 14:29, Stefan Behnel wrote: >>> Moreover the performance hit is well below 2x, more like 20%. >> >> Hmm, those 20% refer to STM, right? Without hardware support? Then hardware >> support could be expected to dr

Re: [Python-Dev] Experimenting with STM on CPython

Stefan Behnel, 11.04.2012 15:31: > Armin Rigo, 11.04.2012 14:51: >> On Wed, Apr 11, 2012 at 14:29, Stefan Behnel wrote: >>> Did you do any experiments with running parallel code so far, to see if >>> that scales as expected? >> >> Yes, it scales very nicel

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

Brett Cannon, 14.04.2012 20:12: > My multi-year project -- started in 2006 according to my blog -- to rewrite > import in pure Python and then bootstrap it into CPython as *the* > implementation of __import__() is finally over (mostly)! Hopefully I didn't > break too much code in the process. =) W

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

Antoine Pitrou, 16.04.2012 13:13: > On Mon, 16 Apr 2012 09:54:41 +0200 > Stefan Behnel wrote: >> >> The new import cache broke Cython's load of on-the-fly compiled extension >> modules, which naively used "__import__(module_name)" after building

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

"Martin v. Löwis", 16.04.2012 16:07: >> We have other instances of this (e.g. the Objects/typeslots.inc file >> is generated and checked in), but in the case of importlib, we have >> to use the ./python binary for freezing to avoid bytecode >> incompatibilities, which obviously is a problem if ./py

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

Amaury Forgeot d'Arc, 16.04.2012 22:43: > 2012/4/16 Stefan Behnel >>> On the down side, we would depend on Cython for evolving . >> >> Right, although not as a strict dependency. The code would still work just >> fine in plain Python. > > Not quite, we a

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

Antoine Pitrou, 17.04.2012 02:27: > On Tue, 17 Apr 2012 01:11:14 +0200 > Georg Brandl wrote: >> No, it's not just an existing Python, it is (at least currently) the same >> version of Python being built. Therefore I wrote about the bootstrapping >> problems when bytecode changes. >> >> Depending o

[Python-Dev] Cython for cPickle?

Hi, I noticed that there is a PEP (3154) and a GSoC proposal about improving Pickle. Given the recent discussion on this list about using Cython for the import module, I wonder if it wouldn't make even more sense to switch from a C (accelerator) implementation to Cython for _pickle. The rationale

Re: [Python-Dev] Cython for cPickle?

Matt Joiner, 19.04.2012 16:13: > Personally I find the unholy product of C and Python that is Cython to be > more complex than the sum of the complexities of its parts. Is it really > wise to be learning Cython without already knowing C, Python, and the > CPython object model? The main obstacle th

Re: [Python-Dev] Cython for cPickle?

Brian Curtin, 19.04.2012 23:19: > On Thu, Apr 19, 2012 at 16:08, Stefan Behnel >>> While code generation alleviates the burden of tedious languages, it's also >>> infinitely more complex, makes debugging very difficult and adds to >>> prerequisite knowledge, a

Re: [Python-Dev] Does trunk still support any compilers that *don't* allow declaring variables after code?

Matt Joiner, 02.05.2012 15:37: > On May 2, 2012 6:00 PM, "Antoine Pitrou" wrote: >> On Wed, 02 May 2012 01:43:32 -0700 >> Larry Hastings wrote: >>> >>> I realize we can't jump to C99 because of A Certain Compiler. (Its name >>> rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even tha

Re: [Python-Dev] C-level duck typing

"Martin v. Löwis", 16.05.2012 10:36: >> And, we want this to somehow work with existing Python; we still >> support users on Python 2.4. > > This makes the question out-of-scope for python-dev - we only discuss > new versions of Python here. Old versions cannot be developed anymore > (as they are

Re: [Python-Dev] C-level duck typing

Dag Sverre Seljebotn, 16.05.2012 12:48: > On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote: >>> Agreed in general, but in this case, it's really not that easy. A C >>> function call involves a certain overhead all by itself, so calling into >>> the C-API multiple times may be substantially more cost

Re: [Python-Dev] C-level duck typing

Stefan Behnel, 16.05.2012 13:13: > Dag Sverre Seljebotn, 16.05.2012 12:48: >> On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote: >>>> Agreed in general, but in this case, it's really not that easy. A C >>>> function call involves a certain overhe

Re: [Python-Dev] C-level duck typing

Mark Shannon, 17.05.2012 12:38: > Dag Sverre Seljebotn wrote: >> On 05/16/2012 10:24 PM, Robert Bradshaw wrote: >>> On Wed, May 16, 2012 at 11:33 AM, "Martin v. Löwis" >>> wrote: > Does this use case make sense to everyone? > > The reason why we are discussing this on python-dev is tha

Re: [Python-Dev] CFFI released

Armin Rigo, 18.06.2012 23:29: > On Mon, Jun 18, 2012 at 9:10 PM, Maciej Fijalkowski wrote: >>> Make cffi less buggy (check the tracker for new test cases ;-), faster >>> (closer to swig type wrappers), and easier to use than ctypes, and I am sure >>> there will be interest. >> >> I would say it's a

Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)

Hi Raymond, Raymond Hettinger, 01.07.2012 09:07: > On Jun 30, 2012, at 10:44 PM, Stefan Behnel wrote: >>> Another addition could be a new subsection on grouping (chunking) that >>> would discuss post-processing of grouper (as discussed above), as well as >>> other re

Re: [Python-Dev] Announcing the python-static-type-checking google group

Paul Boddie, 01.07.2012 02:22: > Is there any reason why the compiler-sig mailing list wasn't chosen as a > venue Even I didn't know that this list even existed. And looking at the archives now, it's hard to see any relevant discussion in all the spam it received until it apparently died away in

Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)

anatoly techtonik, 04.07.2012 11:57: > On Fri, Jun 29, 2012 at 11:32 PM, Georg Brandl wrote: >> On 26.06.2012 10:03, anatoly techtonik wrote: >>> Now that Python 3 is all about iterators (which is a user killer >>> feature for Python according to StackOverflow - >>> http://stackoverflow.com/questio

Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)

anatoly techtonik, 05.07.2012 15:36: > On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: >> From Raymond's first message on http://bugs.python.org/issue6021 , add >> grouper: >> >> "This has been rejected before. > > I quite often see such arguments and I can't stand to repeat that > these are n

Re: [Python-Dev] Bloody FAQ (Was: [Python-ideas] itertools.chunks(iterable, size, fill=None))

anatoly techtonik, 05.07.2012 21:41: > On Thu, Jul 5, 2012 at 7:50 PM, Stefan Behnel wrote: >> anatoly techtonik, 05.07.2012 15:36: >>> On Sun, Jul 1, 2012 at 12:09 AM, Terry Reedy wrote: >>>> From Raymond's first message on http://bugs.python.org/issue6021 , ad

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Alex Gaynor, 15.07.2012 07:20: > there's no way for the __lenght_hint__ to specify that > that particular instance can't have a length hint computed. e.g. imagine > some sort of lazy stream that cached itself, and only wanted to offer a > length hint if it had already been evaluated. Without an e

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Mark Shannon, 15.07.2012 16:14: > Alex Gaynor wrote: >> CPython currently defines an ``__length_hint__`` method on several types, >> such >> as various iterators. This method is then used by various other functions >> (such as ``map``) to presize lists based on the estimated returned by > > Don't

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Antoine Pitrou, 15.07.2012 17:06: > On Sun, 15 Jul 2012 16:33:23 +0200 > Christian Heimes wrote: >> Am 15.07.2012 16:22, schrieb Antoine Pitrou: >>> On Mon, 16 Jul 2012 00:08:41 +1000 >>> Nick Coghlan wrote: Right, I agree on the value in being able to return something to say "this cannot

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Alex Gaynor, 15.07.2012 00:11: > CPython currently defines an ``__length_hint__`` method on several types, such > as various iterators. This method is then used by various other functions > (such > as ``map``) to presize lists based on the estimated returned by > ``__length_hint__``. Types can th

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Nick Coghlan, 16.07.2012 10:26: > Proposing anything substantially more complicated than what is currently > implemented in CPython will just get the idea rejected. The substantial > immediate gain for PyPy is in skipping the memory resizing when building > containers from itertools iterators, not

Re: [Python-Dev] Do we need __length_hint__ at all? (Was PEP 0424: A method for exposing a length hint)

Mark Shannon, 16.07.2012 10:37: > If resizing of lists is too slow, then we should reconsider the 9/8 factor > and/or look to tweak the resizing code. The thing is that the performance is platform specific. On systems with a fast memory allocator, especially on Linux, the difference is negligible.

Re: [Python-Dev] Do we need __length_hint__ at all? (Was PEP 0424: A method for exposing a length hint)

Maciej Fijalkowski, 16.07.2012 11:14: > On Mon, Jul 16, 2012 at 11:02 AM, Stefan Behnel wrote: >> Mark Shannon, 16.07.2012 10:37: >>> If resizing of lists is too slow, then we should reconsider the 9/8 >>> factor and/or look to tweak the resizing code. >> >&g

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Victor Stinner, 17.07.2012 20:38: > -- Subset of Python -- > > * `pymothoa `_: use LLVM; don't > support classes nor exceptions. > * `unpython `_: Python to C > * `Perthon `_: Python to Perl

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Maciej Fijalkowski, 17.07.2012 21:16: > It would be much better to concentrate efforts rather than write > yet another half-finished JIT (because reading code is hard). +1 Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/

Re: [Python-Dev] A new JIT compiler for a faster CPython?

Victor Stinner, 18.07.2012 00:15: >> Personally, I like the idea of having a JIT compiler more or less as an >> extension module at hand. Sort-of like a co-processor, just in software. >> Lets you run your code either interpreter or JITed, just as you need. > > Me too, so something like psyco. In

<    1   2   3   4   5   6   7   >