[Python-Dev] python-checkins is down
I haven't gotten emails for any of the commits I've done in the last 12 hours or so. -- Regards, Benjamin ___ 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] python-checkins is down
On Mon, May 25, 2009, Benjamin Peterson wrote: > > I haven't gotten emails for any of the commits I've done in the last > 12 hours or so. Forwarded to [email protected] -- if there's a problem with the checkins process itself, that won't help. Have you verified that the commits are landing? (I.e. is svn working properly?) Also, if you could double-check the python-checkins archives to see whether it's just you not getting the messages, that would help. -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." --Ralph Waldo Emerson ___ 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] python-checkins is down
Aahz pythoncraft.com> writes: > > Forwarded to postmaster python.org -- if there's a problem with the > checkins process itself, that won't help. Have you verified that the > commits are landing? (I.e. is svn working properly?) Yes, it is. > Also, if you > could double-check the python-checkins archives to see whether it's just > you not getting the messages, that would help. The messages aren't in the archives either. cheers Antoine. ___ 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] PEP 384: Defining a Stable ABI
Martin v. Löwis wrote: > Thomas Wouters reminded me of a long-standing idea; I finally > found the time to write it down. > > Please comment! > ... > Up until this PEP proposal, we had a very simple scheme for the Python C-API: all documented functions and variables with a "Py" prefix were part of the C-API, everything else was not and could change between releases (in particular the private "_Py" prefix APIs). Changing the published APIs was considered a bad thing in the 2.x development process and generally required a good reason to get supported. Changing private functions or ones that were not documented was generally never a big problem. Now, with the PEP, I have a feeling that the Python C-API will in effect be limited to what's in the PEP's idea of a usable ABI and open up the non-inluded public C-APIs to the same rate of change as the private APIs. If that's the case, the PEP should be discussed on the C-API list first, in order to identify a complete list of APIs that is supposed to define the Python C-API. Ideally, all other APIs would then need to be made private. However, I doubt that this is possible before switching to Python 4.0. Then again, I'm not sure whether that's what you're aiming for... An optional cross-version ABI would certainly be a good thing. Limiting the Python C-API would be counterproductive. > During the compilation of applications, the preprocessor macro > Py_LIMITED_API must be defined. Doing so will hide all definitions > that are not part of the ABI. So extensions wanting to use the full Python C-API as documented in the C-API docs will still be able to do this, right ? > Type Objects > > > The structure of type objects is not available to applications; > declaration of "static" type objects is not possible anymore > (for applications using this ABI). Hmm, that's going to create big problems for extensions that want to expose a C-API for their types: Type checks are normally done by pointer comparison using those static type objects. > Functions and function-like Macros > -- > > Function-like macros (in particular, field access macros) remain > available to applications, but get replaced by function calls > (unless their definition only refers to features of the ABI, such > as the various _Check macros) Including Py_INCREF()/Py_DECREF() ? > Excluded Functions > -- > > Functions declared in the following header files are not part > of the ABI: > - cellobject.h > - classobject.h > - code.h > - frameobject.h > - funcobject.h > - genobject.h > - pyarena.h > - pydebug.h > - symtable.h > - token.h > - traceback.h I don't think that's feasable: you basically remove all introspection functions that way. This will need a more fine-grained approach. > Linkage > --- > > On Windows, applications shall link with python3.dll; You mean: extensions that were compiled with Py_LIMITED_API, right ? > an import > library python3.lib will be available. This DLL will redirect all of > its API functions through /export linker options to the full > interpreter DLL, i.e. python3y.dll. What if you mix extensions that use the full C-API with ones that restrict themselves to the limited version ? Would creating a Python object in a full-API extension and free'ing it in a limited-API extension cause problems ? > Implementation Strategy > === > > This PEP will be implemented in a branch, allowing users to check > whether their modules conform to the ABI. To simplify this testing, an > additional macro Py_LIMITED_API_WITH_TYPES will expose the existing > type object layout, to let users postpone rewriting all types. When > the this branch is merged into the 3.2 code base, this macro will > be removed. Now I'm confused again: this sounds a lot like you do want all extension writers to only use the limited API. [And in another post] >> Something I haven't seen explicitly mentioned as yet (in the PEP or the >> > python-dev list discussion) are the memory management APIs and the FILE* >> > APIs which can cause the MSVCRT versioning issues on Windows. >> > >> > Those would either need to be excluded from the stable ABI or else >> > changed to use opaque pointers. > > Good point. As a separate issue, I would actually like to deprecate, > then remove these APIs. I had originally hoped that this would happen > for 3.0 already, alas, nobody worked on it. > > In any case, I have removed them from the ABI now. How do you expect Python extensions to allocate memory and objects in a platform independent way without those APIs ? And as an aside: Which API families are you referring to ? PyMem_Malloc, PyObject_Malloc, or PyObject_New ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 25 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>
Re: [Python-Dev] PEP 384: Defining a Stable ABI
M.-A. Lemburg wrote: > Now, with the PEP, I have a feeling that the Python C-API > will in effect be limited to what's in the PEP's idea of > a usable ABI and open up the non-inluded public C-APIs > to the same rate of change as the private APIs. Not really - before this PEP it was already fairly easy to write an extension that was source-level compatible with multiple versions of Python (depending on exactly what you wanted to do, of course). However, it is essentially impossible to make an extension that is binary level compatible with multiple versions. With the defined stable ABI in place, each extension module author will be able to make a choice: - choose binary compatibility by limiting themselves to the stable ABI and be able to provide a single binary that will still work with later versions of Py3k - stick with source compatibility and continue to provide new binaries for each version of Python > An optional cross-version ABI would certainly be a good thing. > > Limiting the Python C-API would be counterproductive. I don't think anyone would disagree with that. A discussion on C-API sig would certainly be a good idea. >> During the compilation of applications, the preprocessor macro >> Py_LIMITED_API must be defined. Doing so will hide all definitions >> that are not part of the ABI. > > So extensions wanting to use the full Python C-API as documented > in the C-API docs will still be able to do this, right ? Yep - they just wouldn't define the new macro. >> Type Objects >> >> >> The structure of type objects is not available to applications; >> declaration of "static" type objects is not possible anymore >> (for applications using this ABI). > > Hmm, that's going to create big problems for extensions that > want to expose a C-API for their types: Type checks are normally > done by pointer comparison using those static type objects. They would just have to expose "MyExtensionPrefix_MyType_Check" and "MyExtensionPrefix_MyType_CheckExact" functions the same way that types in the C API do. >> Functions and function-like Macros >> -- >> >> Function-like macros (in particular, field access macros) remain >> available to applications, but get replaced by function calls >> (unless their definition only refers to features of the ABI, such >> as the various _Check macros) > > Including Py_INCREF()/Py_DECREF() ? I believe so - MvL deliberately left the fields that the ref counting relies on as part of the ABI. >> Excluded Functions >> -- >> >> Functions declared in the following header files are not part >> of the ABI: >> - cellobject.h >> - classobject.h >> - code.h >> - frameobject.h >> - funcobject.h >> - genobject.h >> - pyarena.h >> - pydebug.h >> - symtable.h >> - token.h >> - traceback.h > > I don't think that's feasable: you basically remove all introspection > functions that way. > > This will need a more fine-grained approach. I don't think it is reasonable to expect the introspection interfaces to remain stable at a binary level across versions. Having "I want deep introspection support from C" and "I want to use a single binary for multiple Python versions" be mutually exclusive choices sounds like a perfectly sensible position to me. Also, keep in mind that even an extension module that restricts itself to Py_LIMITED_API would still be able to call in to the Python equivalents via PyObject_Call and friends (e.g. by importing and using the inspect and traceback modules). > What if you mix extensions that use the full C-API with ones > that restrict themselves to the limited version ? > > Would creating a Python object in a full-API extension and > free'ing it in a limited-API extension cause problems ? Possibly, if you end up mixing C runtimes in the process. Specifically: 1. Python linked with MSVCRT X 2. Full extension module linked with MSVCRT Y 3. Limited extension module linked with MSVCRT Z The PyMem/PyObject APIs in the limited extension module will use the heap in MSVCRT X, since they will be redirected through the Python stable ABI as function calls. However, if the full extension module uses the macro forms and links with the wrong MSVCRT version, then you have the usual opportunities for conflicts between the two C runtimes. This isn't a problem created by defining a stable ABI though - it's the main reason mixing C runtimes is a bad idea. (The two others we have noted so far being IO issues, especially attempting to share FILE* instances and the fact that changing the locale will only affect whichever runtime the extension module linked against). >> Good point. As a separate issue, I would actually like to deprecate, >> then remove these APIs. I had originally hoped that this would happen >> for 3.0 already, alas, nobody worked on it. >> >> In any case, I have removed them from the ABI now. > > How do you expect Python extensions to allocate memory and objects > in a platform independent way wit
[Python-Dev] FWD: python-checkins is down
- Forwarded message from Ralf Hildebrandt - > Date: Mon, 25 May 2009 21:59:32 +0200 > From: Ralf Hildebrandt > To: Patrick Ben Koetter > Cc: Aahz , [email protected] > Subject: Re: FWD: Re: [Python-Dev] python-checkins is down > > * Patrick Ben Koetter : >> This just hit [email protected]: >> >> May 25 20:50:33 albatross postfix/local[12976]: A029ED5FF: >> to=, orig_to=, >> relay=local, delay=0.17, delays=0.09/0/0/0.08, dsn=2.0.0, status=sent >> (delivered to command: /usr/local/mailman/mail/mailman post python-checkins) >> >> Looks like the list itself is online and can be reached. >> >> I didn't read the whole thread (deleted part of it already). >> If that isn't the problem, what should I look for then? > > I let all the mails through and set the senders to the "may send > although they're not members" > > -- > Ralf Hildebrandt > Gesch?ftsbereich IT | Abteilung Netzwerk > Charit? - Universit?tsmedizin Berlin > Campus Benjamin Franklin > Hindenburgdamm 30 | D-12200 Berlin > Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 > [email protected] | http://www.charite.de - End forwarded message - -- Aahz ([email protected]) <*> http://www.pythoncraft.com/ "A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." --Ralph Waldo Emerson ___ 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] Arguments of MatchObject in re module
I've just noticed an oddity of the re module while looking at the
sources. I'll illustrate it below:
>>> import re
>>> p = re.compile("foo")
>>> help(p.match)
Help on built-in function match:
match(...)
match(string[, pos[, endpos]]) --> match object or None.
Matches zero or more characters at the beginning of the string
>>> p.match(string="foo")
Traceback (most recent call last):
File "", line 1, in
p.match(string="foo")
TypeError: Required argument 'pattern' (pos 1) not found
>>>
The name of the first argument should be "string", yet it's "pattern".
Does anyone know if it's anything other than a mistake? Should it be
fixed in the next version of the re module, or are we just stuck with it
(and should just change the docstring to match)?
___
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
