Re: [Python-Dev] ctypes is not an acceptable implementation strategy for modules in the standard library?
On 5 Nov, 2012, at 8:31, anatoly techtonik wrote: > From http://bugs.python.org/issue16410 > Subj? > > Aren't there any modules in stdlib that access system API through ctypes? uuid uses ctypes to access platform APIs. > > My arguments for ctypes: > 1. doesn't require compilation > 2. easier to maintain (no C/toolchain knowledge/ownership needed) > 3. pure Python is impossible to exploit (unlike pure C) That's not not quite true, python code that uses ctypes can still cause buffer overflows and the like when you aren't careful, and adds new failure modes (such as incorrect specification of a C function prototype in the Python code that calls that C function) Ronald ___ 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] ctypes is not an acceptable implementation strategy for modules in the standard library?
I'm not sure that ctypes is always available (available on all platforms). Victor ___ 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] ctypes is not an acceptable implementation strategy for modules in the standard library?
On Mon, 05 Nov 2012 10:31:26 +0300, anatoly techtonik wrote: > Aren't there any modules in stdlib that access system API through ctypes? No. This is a policy. Changing that policy would require a PEP (*after* a discussion on python-ideas...which has probably already happened in the past, I would guess). --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
[Python-Dev] Okay to document the "exec tuple" form of the exec statement in Python 2.7?
In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
globals, locals) tuple:
>>> exec("print 2", {}, {})
2
This isn't currently documented at:
http://docs.python.org/reference/simple_stmts.html#the-exec-statement.
It's easy to fix the docs, but in doing so we'd effectively be
blessing this form of exec as an official part of the language. Do
people think it's acceptable to add this to the docs, or are there
good reasons for the 'exec tuple' form of the exec statement to remain
an undocumented feature?
See also http://bugs.python.org/issue16339.
Mark
___
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] Okay to document the "exec tuple" form of the exec statement in Python 2.7?
On Mon, Nov 5, 2012 at 10:08 PM, Mark Dickinson wrote:
> In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
> globals, locals) tuple:
>
exec("print 2", {}, {})
> 2
>
> This isn't currently documented at:
> http://docs.python.org/reference/simple_stmts.html#the-exec-statement.
> It's easy to fix the docs, but in doing so we'd effectively be
> blessing this form of exec as an official part of the language. Do
> people think it's acceptable to add this to the docs, or are there
> good reasons for the 'exec tuple' form of the exec statement to remain
> an undocumented feature?
>
> See also http://bugs.python.org/issue16339.
If you can find an existing test for it, then definitely (although the
fact it didn't previously work on Jython suggests there may not be
one).
If there's no test, then I'd still be in favour of making it official
both by testing *and* documenting it, for the forward compatibility
benefits you mention on the tracker.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
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] Okay to document the "exec tuple" form of the exec statement in Python 2.7?
On Mon, Nov 5, 2012 at 12:22 PM, Nick Coghlan wrote: > If you can find an existing test for it, then definitely (although the > fact it didn't previously work on Jython suggests there may not be > one). I don't see any *direct* tests for this feature, though there are a couple of tests that just happen to use that form of 'exec' (test_pkg.py, test_module.py, test_pep263,py). > If there's no test, then I'd still be in favour of making it official > both by testing *and* documenting it, for the forward compatibility > benefits you mention on the tracker. Sounds good to me. I'll add a note to the issue about tests. Mark ___ 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] ctypes is not an acceptable implementation strategy for modules in the standard library?
On Mon, Nov 5, 2012 at 9:31 AM, anatoly techtonik wrote: > From http://bugs.python.org/issue16410 > Subj? > > Aren't there any modules in stdlib that access system API through ctypes? > > My arguments for ctypes: > 1. doesn't require compilation > 2. easier to maintain (no C/toolchain knowledge/ownership needed) > 3. pure Python is impossible to exploit (unlike pure C) > 4. eating your own dogfood helps to make modules complete and notice > such silly/critical/timewasting/drivesmemad errors as > http://bugs.python.org/issue16376 a few years earlier > > Maybe it could even help to make ctypes faster (through some caching > mechanizm). > -- > anatoly t. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fijall%40gmail.com Hi anatoly. ctypes comes with it's own set of problems that manifest themselves more or less depending what sort of libary have you tried to wrap. Have you ever tried to use it seriously? The list of my personal issues is available here: http://morepypy.blogspot.com/2012/06/release-01-of-cffi.html The main problem is API vs ABI and the robustness of checks. I would not recommend using ctypes for any of the sdtlib (we actually tried in pypy, it turned out a bit awful). Cheers, fijal ___ 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] ctypes is not an acceptable implementation strategy for modules in the standard library?
On 2012-11-05, at 10:32 , Ronald Oussoren wrote: >> My arguments for ctypes: >> 1. doesn't require compilation >> 2. easier to maintain (no C/toolchain knowledge/ownership needed) >> 3. pure Python is impossible to exploit (unlike pure C) > > That's not not quite true, python code that uses ctypes can still cause > buffer overflows and the like Such as segfaulting the interpreter. I seem to reliably segfault everything every time I try to use ctypes. ___ 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] ctypes is not an acceptable implementation strategy for modules in the standard library?
On 05.11.2012 15:14, Xavier Morel wrote: > Such as segfaulting the interpreter. I seem to reliably segfault > everything every time I try to use ctypes. You can do that with C extensions too, by the way. Apart from that, dependency on ABI is more annoying to maintain across platforms than dependency on API. Function calls with ctypes are also very slow. For C extensions in the stdlib, Cython might be a better choice then ctypes. ctypes might be a good choice if you are to use a DLL on your own computer. Because then you only have one ABI to worry about. Not so for Python's standard library. Sturla ___ 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] Okay to document the "exec tuple" form of the exec statement in Python 2.7?
+1. This probably fell through the cracks because I changed my mind on
this. The function form was old, and I wanted to root it out in favor fo
the statement. But then I changed my mind for py3k. Good idea to document
and add tests in 2.x.
--Guido
On Monday, November 5, 2012, Nick Coghlan wrote:
> On Mon, Nov 5, 2012 at 10:08 PM, Mark Dickinson
> >
> wrote:
> > In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
> > globals, locals) tuple:
> >
> exec("print 2", {}, {})
> > 2
> >
> > This isn't currently documented at:
> > http://docs.python.org/reference/simple_stmts.html#the-exec-statement.
> > It's easy to fix the docs, but in doing so we'd effectively be
> > blessing this form of exec as an official part of the language. Do
> > people think it's acceptable to add this to the docs, or are there
> > good reasons for the 'exec tuple' form of the exec statement to remain
> > an undocumented feature?
> >
> > See also http://bugs.python.org/issue16339.
>
> If you can find an existing test for it, then definitely (although the
> fact it didn't previously work on Jython suggests there may not be
> one).
>
> If there's no test, then I'd still be in favour of making it official
> both by testing *and* documenting it, for the forward compatibility
> benefits you mention on the tracker.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | [email protected]| Brisbane,
> Australia
> ___
> 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] cpython (3.3): Add examples for opener argument of open (#13424).
Am 03.11.2012 22:10, schrieb eric.araujo: > http://hg.python.org/cpython/rev/17b094c08600 > changeset: 80219:17b094c08600 > branch: 3.3 > parent: 80214:e6d0951f412a > user:Éric Araujo > date:Sat Nov 03 17:06:52 2012 -0400 > summary: > Add examples for opener argument of open (#13424). > > Patch by Guillaume Pratte. > > files: > Doc/library/functions.rst | 30 +++ > Doc/library/io.rst| 3 ++ > Misc/ACKS | 1 + > 3 files changed, 34 insertions(+), 0 deletions(-) > > > diff --git a/Doc/library/functions.rst b/Doc/library/functions.rst > --- a/Doc/library/functions.rst > +++ b/Doc/library/functions.rst > @@ -935,6 +935,36 @@ > :mod:`os.open` as *opener* results in functionality similar to passing > ``None``). > > + The following example is an alternative implementation for opening files > + for exclusive writing. If we did not have support for the ``'x'`` mode, > + we could implement it with this opener:: > + > + >>> import os > + >>> def open_exclusive(path, mode): > + ... return os.open(path, mode | os.O_CREAT | os.O_EXCL) > + ... > + >>> filename = 'spam.txt' > + >>> fp = open(filename, 'w', opener=open_exclusive) > + >>> fp2 = open(filename, 'w', opener=open_exclusive) > + Traceback (most recent call last): > +... > + FileExistsError: [Errno 17] File exists: 'spam.txt' > + > + This other example uses the :ref:`dir_fd` parameter of the > + :func:`os.open` function to open a file relative to a given directory:: Please heed your Sphinx warnings: the :ref:`dir_fd` needs a link caption, since it can't autogenerate one (the dir_fd anchor does not point to a heading). Georg ___ 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] Okay to document the "exec tuple" form of the exec statement in Python 2.7?
Nick Coghlan wrote: On Mon, Nov 5, 2012 at 10:08 PM, Mark Dickinson wrote: In Python 2, the 'exec' statement supports 'exec'-ing a (statement, globals, locals) tuple: If this is a deliberate feature, I'd guess it's because exec is a statement rather than a function in Python 2, so you can't use * to pass a tuple of arguments to it. -- Greg ___ 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
