Re: [Python-Dev] PEP 384 status
On Mon, Aug 30, 2010 at 6:43 AM, Antoine Pitrou wrote: > On Mon, 30 Aug 2010 07:31:34 +1000 > Nick Coghlan wrote: >> Since part of the point of >> PEP 384 is to support multiple versions of the C runtime in a single >> process, [...] > > I think that's quite a maximalist goal. The point of PEP 384 should be > to define a standard API for Python, (hopefully) spanning multiple > versions. Whether the API effectively guarantees a standard ABI can > only depend on whether the system itself hasn't changed its own > conventions (including, for example, function call conventions, or the > binary representation of standard C types). > > In other words, PEP 384 should only care to stabilize the ABI as > long as the underlying system doesn't change. It sounds a bit foolish > for us to try to hide potential unstabilities in the underlying > platform. And it's equally foolish to try to forbid people from using > well-known system facilities such as FILE* or (worse) errno. > > So, perhaps the C API docs can simply mention the caveat of using FILE* > (and perhaps errno, if there's a problem there as well) for C extensions > under Windows. C extension writers are (usually) consenting adults, for > all. This significantly decrease the value of such an API, to the point of making it useless on windows, since historically different python versions are built with different runtimes. And I would think that windows is the platform where PEP 384 would be the most useful - at least it would for numpy/scipy, where those runtimes issues have bitten us several times (and are painful to debug, especially when you don't know windows so well). cheers, David ___ 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] r84355 - python/branches/py3k/Lib/test/test_ssl.py
Sorry, I didn't get how the context-manager actually worked. Fixed in r84356. 2010/8/29 Michael Foord : > On 30/08/2010 00:23, Antoine Pitrou wrote: >> >> On Sun, 29 Aug 2010 22:56:56 +0200 (CEST) >> giampaolo.rodola wrote: >>> >>> + with self.assertRaises(IOError) as err: >>> + ssl.wrap_socket(socket.socket(), certfile=WRONGCERT) >>> + self.assertEqual(err.errno, errno.ENOENT) >> >> The assertEqual will never get executed since the previous line raises. > > If it is dedented once then it will work (in Python 2.7 / 3.2). > > Michael >>> >>> + with self.assertRaises(IOError) as err: >>> + ssl.wrap_socket(socket.socket(), certfile=WRONGCERT, >>> keyfile=WRONGCERT) >>> + self.assertEqual(err.errno, errno.ENOENT) >> >> Same here. >> >> >> ___ >> 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/fuzzyman%40voidspace.org.uk > > > -- > http://www.ironpythoninaction.com/ > > ___ > 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/g.rodola%40gmail.com > ___ 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] PEP 384 status
On Mon, 30 Aug 2010 07:31:34 +1000 Nick Coghlan wrote: > Since part of the point of > PEP 384 is to support multiple versions of the C runtime in a single > process, [...] I think that's quite a maximalist goal. The point of PEP 384 should be to define a standard API for Python, (hopefully) spanning multiple versions. Whether the API effectively guarantees a standard ABI can only depend on whether the system itself hasn't changed its own conventions (including, for example, function call conventions, or the binary representation of standard C types). In other words, PEP 384 should only care to stabilize the ABI as long as the underlying system doesn't change. It sounds a bit foolish for us to try to hide potential unstabilities in the underlying platform. And it's equally foolish to try to forbid people from using well-known system facilities such as FILE* or (worse) errno. So, perhaps the C API docs can simply mention the caveat of using FILE* (and perhaps errno, if there's a problem there as well) for C extensions under Windows. C extension writers are (usually) consenting adults, for all. 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] PEP 384 status
On Mon, Aug 30, 2010 at 1:43 AM, Antoine Pitrou wrote: > On Sun, 29 Aug 2010 22:16:57 +1000 > Nick Coghlan wrote: > (actually, I'm baffled that Windows has such problems, and I would > suggest that it's not Python's job to shield Windows > application developers from Windows-specific development issues) It depends on how you view different versions of a shared library - with relocatable addresses, there's nothing fundamental preventing you from allowing separately compiled components to depend on those different versions, with the dynamic linker placing them at different points in memory. If you start from an independent binary distribution mindset and an attitude that the easiest way to ensure backwards compatibility is to avoid forced upgrades of dependencies, allowing it makes perfect sense (whereas *nix systems tend work to with a "don't repeat yourself" philosophy at the system level and are quite happy to let old binaries and source code become unusable, or at least incompatible with modern components, as their dependencies update below them). With the benefit of hindsight, the Windows approach turns out to have some pretty severe downsides (the name "DLL hell" is well earned), but there are some positive aspects to the approach. Back on the main topic, I am not in a position to state that Windows is the only platform that currently, or will ever, allow two different versions of the C runtime to be loaded into the same address space (I thought you could even persuade *nix to do it if you really wanted to, although you tell me I'm wrong about that). Since part of the point of PEP 384 is to support multiple versions of the C runtime in a single process, relying on Windows-specific or post-C89 options seems unnecessary when there are platform neutral C89 compatible approaches that achieve the same end in a way that will be completely obvious to most C programmers. 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] r84355 - python/branches/py3k/Lib/test/test_ssl.py
On 30/08/2010 00:23, Antoine Pitrou wrote: On Sun, 29 Aug 2010 22:56:56 +0200 (CEST) giampaolo.rodola wrote: +with self.assertRaises(IOError) as err: +ssl.wrap_socket(socket.socket(), certfile=WRONGCERT) +self.assertEqual(err.errno, errno.ENOENT) The assertEqual will never get executed since the previous line raises. If it is dedented once then it will work (in Python 2.7 / 3.2). Michael +with self.assertRaises(IOError) as err: +ssl.wrap_socket(socket.socket(), certfile=WRONGCERT, keyfile=WRONGCERT) +self.assertEqual(err.errno, errno.ENOENT) Same here. ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ 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] r84355 - python/branches/py3k/Lib/test/test_ssl.py
On Sun, 29 Aug 2010 22:56:56 +0200 (CEST) giampaolo.rodola wrote: > +with self.assertRaises(IOError) as err: > +ssl.wrap_socket(socket.socket(), certfile=WRONGCERT) > +self.assertEqual(err.errno, errno.ENOENT) The assertEqual will never get executed since the previous line raises. > +with self.assertRaises(IOError) as err: > +ssl.wrap_socket(socket.socket(), certfile=WRONGCERT, > keyfile=WRONGCERT) > +self.assertEqual(err.errno, errno.ENOENT) Same here. ___ 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] PEP 384 status
On Aug 29, 2010, at 8:16 AM, Nick Coghlan wrote: > However, since even platforms other than Windows aren't immune to > version upgrades of the standard C runtime Aren't they? I don't know of any other platform that lets you have two versions of libc linked into a single address space. Linux has had incompatible libc updates in the past, but it was not possible to use both in one program. I believe BSD works the same way. James ___ 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] PEP 384 status
On Sun, 29 Aug 2010 22:16:57 +1000 Nick Coghlan wrote: > > However, since even platforms other than Windows aren't immune to > version upgrades of the standard C runtime, I'm still more comfortable > with the idea that the strict ABI should refuse to pass FILE* pointers > across extension module boundaries. I'm not sure what the worry is. Under an Unix-like system, there shouldn't be any situation where two different versions of the libc are loaded in the same process. And since FILE* is an opaque pointer whose referent is only accessed by the libc, things should be fine. (actually, I'm baffled that Windows has such problems, and I would suggest that it's not Python's job to shield Windows application developers from Windows-specific development issues) > The advantage of the preprocessor > macro approach is that it allows us to provide assistance with > operations on FILE* pointers while still obeying that restriction > regardless of the specific compilers involved in creating the Python > and extension module binaries. An inline function should provide the same advantage since it will be compiled with the calling library/executable, rather than the Python DLL. 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] PEP 384 status
On Sun, Aug 29, 2010 at 7:10 PM, Antoine Pitrou wrote: > On Sun, 29 Aug 2010 18:41:45 +1000 > Nick Coghlan wrote: >> I believe both that option, and my third option, would run into >> trouble due to the potential for errno confusion. > > I don't understand. What's the difference with the macro you proposed > (the fourth option)? Oh, you meant combining it with the suggested change to the errno handling rather than merely inlining the existing PyObject_Print? Yes, that should work and would be even more seamless from the point of view of the extension modules. However, since even platforms other than Windows aren't immune to version upgrades of the standard C runtime, I'm still more comfortable with the idea that the strict ABI should refuse to pass FILE* pointers across extension module boundaries. The advantage of the preprocessor macro approach is that it allows us to provide assistance with operations on FILE* pointers while still obeying that restriction regardless of the specific compilers involved in creating the Python and extension module binaries. It would be nice to get rid of the resultp parameter by rewriting the internals of the macro as a collection of ternary and comma expressions instead of a scope, but I haven't managed to crack the problem of feeding the correct arguments to fwrite with that approach (it's been quite a while since I've attempted to abuse C expressions to this extent, so I've forgotten most of the tricks for avoiding temporary variables). 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] PEP 384 status
On Sun, 29 Aug 2010 18:41:45 +1000 Nick Coghlan wrote: > On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou wrote: > > On Sun, 29 Aug 2010 09:20:56 +1000 > > Nick Coghlan wrote: > >> > >> Four options come to mind: > >> > >> - just leave it out of the limited API, extensions can do their own > >> thing to print objects > >> - leave PyObject_Print out of the limited API, but create a > >> PyObject_PrintEx that takes a Python IO stream via PyObject* rather > >> than a C level FILE*. > >> - leave PyObject_Print out of the limited API, but create a > >> PyObject_PrintEx that takes function pointers for the above 4 > >> operations (so the FILE* pointer is only every operated on by > >> functions from the extension module's CRT) > >> - leave PyObject_Print out of the limited API, but create a > >> PyObject_PRINT macro that does much the same thing with the logic > >> rearranged so there is an inner function that figures out the string > >> to be printed, but an outer macro that does all the operations on the > >> FILE * object (so again, the FILE * is never passed to Python's CRT) > > > > Fifth option: > > - make PyObject_Print() an inline function (similar to your macro > > proposal), but only on Windows. This would retain the name and > > current signature. Apparently we could use something like > > "__forceinline" or "extern __forceinline"? > > I believe both that option, and my third option, would run into > trouble due to the potential for errno confusion. I don't understand. What's the difference with the macro you proposed (the fourth option)? 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] PEP 384 status
On Sun, Aug 29, 2010 at 6:24 PM, Antoine Pitrou wrote: > On Sun, 29 Aug 2010 09:20:56 +1000 > Nick Coghlan wrote: >> >> Four options come to mind: >> >> - just leave it out of the limited API, extensions can do their own >> thing to print objects >> - leave PyObject_Print out of the limited API, but create a >> PyObject_PrintEx that takes a Python IO stream via PyObject* rather >> than a C level FILE*. >> - leave PyObject_Print out of the limited API, but create a >> PyObject_PrintEx that takes function pointers for the above 4 >> operations (so the FILE* pointer is only every operated on by >> functions from the extension module's CRT) >> - leave PyObject_Print out of the limited API, but create a >> PyObject_PRINT macro that does much the same thing with the logic >> rearranged so there is an inner function that figures out the string >> to be printed, but an outer macro that does all the operations on the >> FILE * object (so again, the FILE * is never passed to Python's CRT) > > Fifth option: > - make PyObject_Print() an inline function (similar to your macro > proposal), but only on Windows. This would retain the name and > current signature. Apparently we could use something like > "__forceinline" or "extern __forceinline"? I believe both that option, and my third option, would run into trouble due to the potential for errno confusion. 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] PEP 384 status
On Sun, 29 Aug 2010 09:20:56 +1000 Nick Coghlan wrote: > > Four options come to mind: > > - just leave it out of the limited API, extensions can do their own > thing to print objects > - leave PyObject_Print out of the limited API, but create a > PyObject_PrintEx that takes a Python IO stream via PyObject* rather > than a C level FILE*. > - leave PyObject_Print out of the limited API, but create a > PyObject_PrintEx that takes function pointers for the above 4 > operations (so the FILE* pointer is only every operated on by > functions from the extension module's CRT) > - leave PyObject_Print out of the limited API, but create a > PyObject_PRINT macro that does much the same thing with the logic > rearranged so there is an inner function that figures out the string > to be printed, but an outer macro that does all the operations on the > FILE * object (so again, the FILE * is never passed to Python's CRT) Fifth option: - make PyObject_Print() an inline function (similar to your macro proposal), but only on Windows. This would retain the name and current signature. Apparently we could use something like "__forceinline" or "extern __forceinline"? 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
