Re: [Python-Dev] Announcing PEP 436: The Argument Clinic DSL

[Stefan Krah]

Larry Hastings  wrote:
> http://bugs.python.org/issue16612
> 
> I'm guessing python-dev is the right place for the ten-thousand-foot view
> topics: the merits of the specific proposed DSL syntax, the possible runtime
> extension API, and the approach as a whole.  So for now let's just use the bug
> tracker issue for code reviews and the like.

For anyone who isn't following the issue: A PEP proposing a different DSL
will be forthcoming either this or next weekend.


Stefan Krah



___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Stephen J. Turnbull]

Ethan Furman writes:
> sjt wrote:

 > > Note that in both counting and listing the object of the
 > > operation is not an element.  It is a set, and set membership is
 > > the most important aspect of the elements for that purpose.
 > 
 > No, it isn't.  It may be in some cases.

I'm referring only to the dictionary definitions you quote.

It really sounds to me like your use case (and even more so,
Antoine's) would be perfectly well-served by a named constant class
that doesn't know anything about enumerability.

 > My enums even respect it to the point of not comparing equal to
 > different enum sets.  But, quite frankly, it's the enum's ability
 > to let me use a name to mean a number that is the most
 > important. And the most important thing for the Enum class is to
 > assign those numbers for me as automatically as possible.

But "mean a number" and "assigned automatically" are close to mutually
exclusive (except that "as possible" gives you a lot of wiggle room).

That is, if by "name means number" you imply that the numbers have
semantics (as in Antoine's HTTP status code example), you care what
the numbers are, and they can't be assigned automatically.

OTOH, if the numbers are assigned very automatically (ie, completely
implicitly), I have trouble with coming up with a use case where
ability to use integer arithmetic (including comparisons other than
equality and set membership) on them *by default* is anything but a
trap.  Eg, with a Likert scale for preference[1], I *do* want to order
them, but (at least when I'm teaching statistics) I *really* *don't*
want them added and subtracted without thinking about exactly what the
operation means.

And if you really need arithmetic and automatic assignment is good
enough, what's wrong with their ordinary names (ie, 1, 2, 3, ...)?


Footnotes: 
[1]  A qualitative expression of strength of feeling ("hate" = 1,
"dislike" = 2, "indifferent" = 3, "like" = 4, "love" = 5).
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Eli Bendersky]

On Mon, Feb 25, 2013 at 3:17 PM, Glyph  wrote:

>
> On Feb 25, 2013, at 12:32 PM, Barry Warsaw  wrote:
>
> Dumb question, but are flufl.enums ordered?  That's also an important use
> case.
>
>
> Kind of.  Ordered comparisons are explicitly not supported, but iteration
> over
> the Enum is guaranteed to be returned in int-value order.
>
>
> Sorry to jump in to a random leaf of this thread, but there is such a
> barrage here I cannot find the beginning :).
>
> I can see in 
> that Twisted is mentioned; it should probably reference <
> https://twistedmatrix.com/documents/current/api/twisted.python.constants.html>
> and 
> since we actually implemented a thing as well.
>
> (You can order constants by sorting them; off the top of my head,
> NamedConstant, ValueConstant, and FlagConstant all probably behave
> differently.)
>
>
Glyph, thanks for the input. I mentioned Twisted because in its code I
found a number of places with simple string enumerations used to represent
state. I was not aware of twisted.python.constants, but it doesn't appear
that this module is used  at least in the places I checked.

Examples:

* twisted/web/_newclient.py
* twisted/web/http.py
* twisted/protocol/sip.py

In general, many protocols have some "state" instance var that's usually
just a string, using either predefined constants or direct string literals.

Eli
___
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] Announcing PEP 436: The Argument Clinic DSL

[Eli Bendersky]

On Tue, Feb 26, 2013 at 12:30 AM, Stefan Krah  wrote:

> Larry Hastings  wrote:
> > http://bugs.python.org/issue16612
> >
> > I'm guessing python-dev is the right place for the ten-thousand-foot view
> > topics: the merits of the specific proposed DSL syntax, the possible
> runtime
> > extension API, and the approach as a whole.  So for now let's just use
> the bug
> > tracker issue for code reviews and the like.
>
> For anyone who isn't following the issue: A PEP proposing a different DSL
> will be forthcoming either this or next weekend.
>

If the two proposals share at least the motivation, would it not be more
constructive to just have them listed as alternatives in a single PEP? This
could serve as a useful single source of information for the new proposed
features.

Eli
___
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] Announcing PEP 436: The Argument Clinic DSL

[Eli Bendersky]

On Mon, Feb 25, 2013 at 4:11 PM, Larry Hastings  wrote:

>
> Following up on a conversation on python-dev from last December:
>
> http://mail.python.org/pipermail/python-dev/2012-December/122920.html
>
> I'm pleased to announced PEP 436, proposing Argument Clinic for adoption
> into the CPython source tree.
>
> http://www.python.org/dev/peps/pep-0436/
>
>
You really need to provide some realistic usage examples in the PEP. It's
hard to get a feel for the DSL just from looking at the spec.

Eli
___
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] Announcing PEP 436: The Argument Clinic DSL

[Stefan Krah]

Eli Bendersky  wrote:
> For anyone who isn't following the issue: A PEP proposing a different DSL
> will be forthcoming either this or next weekend.
> 
> 
> If the two proposals share at least the motivation, would it not be more
> constructive to just have them listed as alternatives in a single PEP? This
> could serve as a useful single source of information for the new proposed
> features.

I find PEPs that propose multiple alternatives hard to read. My PEP won't
be short:  It will contain a token specifications, a yacc grammar and
an attempt to specify the semantics of the DSL.


Stefan Krah



___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Terry Reedy]

On 2/25/2013 12:35 PM, Ethan Furman wrote:


But this I don't, and in both mine, Ted's, and Alex's versions enums
from different groups do not compare equal, regardless of the underlying
value.  Of course, this does have the potential problem of `green == 1
== bee` but not `green == bee` which would be a problem with set and
dicts -- but I'm the only one who has brought up that issue.


I have not been following the discussion in detail so I missed that 
before. Breaking transitivity of equality a no-no. It is basic to 
thought and logic.


decimal(0) == 0 == 0.0 != decimal(0)
was a problem we finally fixed by removing the inequality above.
http://bugs.python.org/issue4087
http://bugs.python.org/issue4090

We should NOT knowingly re-introduce the same problem again! If color 
and animal are isolated from each other, they should each be isolated 
from everything, including int.


--
Terry Jan Reedy

___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Terry Reedy]

On 2/25/2013 6:53 PM, Greg Ewing wrote:

Barry Warsaw wrote:

>>> Colors = make('Colors', 'red green blue'.split())
>>> Animals = make('Animals', 'ant bee cat'.split())
>>> Colors.green == Animals.bee


The currently suggested solution to that seems to be to
make comparison non-transitive, so that Colors.green == 1
and Animals.bee == 1 but Colors.green != Animals.bee.
And then hope that this does not create a quantum black
hole that sucks us all into a logical singularity...


But it will;-).
To repeat myself, transitivity of equality is basic to thought, logic, 
and sets and we should not deliver Python with it broken. (The 
non-reflexivity of NAN is a different issue, but NANs are intentionally 
insane.)


Decimal(0) == 0 == 0.0 != Decimal(0) != Fraction(0) == 0
was a problem we finally fixed by making integer-valued decimals
compare equal to the same valued floats and fractions. In 3.3:

>>> from decimal import Decimal as D
>>> from fractions import Fraction as F
>>> 0 == 0.0 == D(0) == F(0)
True

http://bugs.python.org/issue4087
http://bugs.python.org/issue4090
explain the practical problems. We should NOT knowingly go down this 
road again. If color and animal are isolated from each other, they 
should each be isolated from everything, including int.


--
Terry Jan Reedy

___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Terry Reedy]

On 2/25/2013 2:48 PM, Antoine Pitrou wrote:

On Mon, 25 Feb 2013 11:34:35 -0800
Ethan Furman  wrote:

Antoine, question for you:

Do you think enums from different groupings should compare equal?


Equality should be mostly transitive so, yes, I think they should.


Or if they do not, then they should neither compare equal to ints. One 
or the other, take your pick, or make both choices available.


--
Terry Jan Reedy

___
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

[Python-Dev] cffi in stdlib

[Maciej Fijalkowski]

Hello.

I would like to discuss on the language summit a potential inclusion
of cffi[1] into stdlib. This is a project Armin Rigo has been working
for a while, with some input from other developers. It seems that the
main reason why people would prefer ctypes over cffi these days is
"because it's included in stdlib", which is not generally the reason I
would like to hear. Our calls to not use C extensions and to use an
FFI instead has seen very limited success with ctypes and quite a lot
more since cffi got released. The API is fairly stable right now with
minor changes going in and it'll definitely stablize until Python 3.4
release. Notable projects using it:

* pypycore - gevent main loop ported to cffi
* pgsql2cffi
* sdl-cffi bindings
* tls-cffi bindings
* lxml-cffi port
* pyzmq
* cairo-cffi
* a bunch of others

So relatively a lot given that the project is not even a year old (it
got 0.1 release in June). As per documentation, the advantages over
ctypes:

* The goal is to call C code from Python. You should be able to do so
without learning a 3rd language: every alternative requires you to
learn their own language (Cython, SWIG) or API (ctypes). So we tried
to assume that you know Python and C and minimize the extra bits of
API that you need to learn.

* Keep all the Python-related logic in Python so that you don’t need
to write much C code (unlike CPython native C extensions).

* Work either at the level of the ABI (Application Binary Interface)
or the API (Application Programming Interface). Usually, C libraries
have a specified C API but often not an ABI (e.g. they may document a
“struct” as having at least these fields, but maybe more). (ctypes
works at the ABI level, whereas Cython and native C extensions work at
the API level.)

* We try to be complete. For now some C99 constructs are not
supported, but all C89 should be, including macros (and including
macro “abuses”, which you can manually wrap in saner-looking C
functions).

* We attempt to support both PyPy and CPython, with a reasonable path
for other Python implementations like IronPython and Jython.

* Note that this project is not about embedding executable C code in
Python, unlike Weave. This is about calling existing C libraries from
Python.

so among other things, making a cffi extension gives you the same
level of security as writing C (and unlike ctypes) and brings quite a
bit more flexibility (API vs ABI issue) that let's you wrap arbitrary
libraries, even those full of macros.

Cheers,
fijal

.. [1]: http://cffi.readthedocs.org/en/release-0.5/
___
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] Announcing PEP 436: The Argument Clinic DSL

[Nick Coghlan]

On Wed, Feb 27, 2013 at 12:40 AM, Stefan Krah  wrote:
> Eli Bendersky  wrote:
>> For anyone who isn't following the issue: A PEP proposing a different DSL
>> will be forthcoming either this or next weekend.
>>
>>
>> If the two proposals share at least the motivation, would it not be more
>> constructive to just have them listed as alternatives in a single PEP? This
>> could serve as a useful single source of information for the new proposed
>> features.
>
> I find PEPs that propose multiple alternatives hard to read. My PEP won't
> be short:  It will contain a token specifications, a yacc grammar and
> an attempt to specify the semantics of the DSL.

More importantly, the competing PEPs have different champions, so you
and Larry need to be free to make the best case you can.

Cheers,
Nick.

P.S. I was thinking the last time we had truly competing PEPs was way
back when the with statement was designed, but it turns out the
competing namespace package designs were also separate PEPs. PEP 315
was more an after the fact here's-a-better-way-to-implement-this
redesign of PEP 309, and PEP 3150 vs 403 is just me having an ongoing
discussion with myself (and occasionally others) over a feature I
doubt would ever make it past Guido even if I do eventually decide to
propose one of them.

-- 
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Nick Coghlan]

On Wed, Feb 27, 2013 at 1:09 AM, Terry Reedy  wrote:
> On 2/25/2013 2:48 PM, Antoine Pitrou wrote:
>>
>> On Mon, 25 Feb 2013 11:34:35 -0800
>> Ethan Furman  wrote:
>>>
>>> Antoine, question for you:
>>>
>>> Do you think enums from different groupings should compare equal?
>>
>>
>> Equality should be mostly transitive so, yes, I think they should.
>
>
> Or if they do not, then they should neither compare equal to ints. One or
> the other, take your pick, or make both choices available.

I'm already working on too many different things to take a serious run
at a labelled values proposal, but it is avoiding precisely this kind
of problem that makes me favour a permissive solution that *doesn't*
define any new behaviour for the instance, aside from changing the
result of repr() and the contents of pickles. (You could potentially
combine it with a "sensitive values" proposal that ensured repr() and
other operations only displayed the label without showing the contents
at all - this is also potentially useful for labelling large strings
that may otherwise overwhelm debug output).

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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Ethan Furman]

On 02/26/2013 07:01 AM, Terry Reedy wrote:

On 2/25/2013 6:53 PM, Greg Ewing wrote:

The currently suggested solution to that seems to be to
make comparison non-transitive, so that Colors.green == 1
and Animals.bee == 1 but Colors.green != Animals.bee.
And then hope that this does not create a quantum black
hole that sucks us all into a logical singularity...


But it will;-).
To repeat myself, transitivity of equality is basic to thought, logic, and sets 
and we should not deliver Python with it
broken. (The non-reflexivity of NAN is a different issue, but NANs are 
intentionally insane.)

Decimal(0) == 0 == 0.0 != Decimal(0) != Fraction(0) == 0
was a problem we finally fixed by making integer-valued decimals
compare equal to the same valued floats and fractions. In 3.3:


from decimal import Decimal as D
from fractions import Fraction as F
0 == 0.0 == D(0) == F(0)

True

http://bugs.python.org/issue4087
http://bugs.python.org/issue4090
explain the practical problems. We should NOT knowingly go down this road 
again. If color and animal are isolated from
each other, they should each be isolated from everything, including int.


Thank you, Terry.

--
~Ethan~
___
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] cffi in stdlib

[Nick Coghlan]

On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski  wrote:
> Hello.
>
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib.

I think cffi is well worth considering as a possible inclusion for
Python 3.4. (In particular, I'm a fan of the fact it just uses C
syntax to declare what you're trying to talk to)

If I'm reading the dependencies correctly, we would also need to bring
Eli Bendersky's pycparser into the stdlib, correct? (not an objection,
just an observation, although we'd obviously need Eli's explicit
endorsement for that).

There would also be the matter of converting the cffi test suite from
py.test to stdlib unittest.

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] Announcing PEP 436: The Argument Clinic DSL

[Terry Reedy]

On 2/25/2013 7:11 PM, Larry Hastings wrote:


Following up on a conversation on python-dev from last December:

http://mail.python.org/pipermail/python-dev/2012-December/122920.html

I'm pleased to announced PEP 436, proposing Argument Clinic for adoption
into the CPython source tree.

http://www.python.org/dev/peps/pep-0436/


The PEP gives an internal, developer-focused rationale. I think there is 
also an external, user-focused rationale. As much as possible (with 
obvious caveats about type introspection), I think it should be 
transparent to users (other than speed) whether a function is 
implemented in Python or C. People who love keyword calling currently 
have to learn which module by module and function by function. 
Tranparency will become even more important as more modules are dual 
coded, and as users move code between implementations. I presume some of 
the complexities of  PyArg_ParseTupleAndKeywords arise from pursuing 
this goal. And if I understand correctly, this PEP should reduce some of 
the complexities. The 'future goal' of C function signature info will 
further aid transparency.


This user rationale suggests that positional-only functions should be 
discouraged.


It also suggests another future goal: a clinic backend that would 
instead output a skeleton python file with def header lines and 
docstrings, leaving the bodies to be filled in. One could also wish for 
the opposite: a python file processor that would convert def header 
lines and docstrings to a skeleton C file with clinic specifications.


> Do we need to support tuple unpacking?

Well, Python 3 dropped that for python functions, so it is not needed 
needed for conversions to or from python 3 files. I suspect the same 
rationale applies to C as well as Python functions: the unpacking can be 
done explicitly in the body, as needed.


--
Terry Jan Reedy

___
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] cffi in stdlib

[Donald Stufft]

A big +1 from me for cffi in the stdlib it's a great library.

I just recently started using it to make bindings to a C library. I
looked at the ctypes library, but haven't actually used it, because
the docs confused me but with cffi I was able to get somewhere just
by a liberal use of copy/paste from the C library's home page. The
only C I know I figured out from working with cffi and fwiw even with
that minimal amount of gained knowledge I still am confused by the
Ctypes docs and where to even really start to try to use it.


On Tuesday, February 26, 2013 at 10:13 AM, Maciej Fijalkowski wrote:

> Hello.
>  
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers. It seems that the
> main reason why people would prefer ctypes over cffi these days is
> "because it's included in stdlib", which is not generally the reason I
> would like to hear. Our calls to not use C extensions and to use an
> FFI instead has seen very limited success with ctypes and quite a lot
> more since cffi got released. The API is fairly stable right now with
> minor changes going in and it'll definitely stablize until Python 3.4
> release. Notable projects using it:
>  
> * pypycore - gevent main loop ported to cffi
> * pgsql2cffi
> * sdl-cffi bindings
> * tls-cffi bindings
> * lxml-cffi port
> * pyzmq
> * cairo-cffi
> * a bunch of others
>  
> So relatively a lot given that the project is not even a year old (it
> got 0.1 release in June). As per documentation, the advantages over
> ctypes:
>  
> * The goal is to call C code from Python. You should be able to do so
> without learning a 3rd language: every alternative requires you to
> learn their own language (Cython, SWIG) or API (ctypes). So we tried
> to assume that you know Python and C and minimize the extra bits of
> API that you need to learn.
>  
> * Keep all the Python-related logic in Python so that you don’t need
> to write much C code (unlike CPython native C extensions).
>  
> * Work either at the level of the ABI (Application Binary Interface)
> or the API (Application Programming Interface). Usually, C libraries
> have a specified C API but often not an ABI (e.g. they may document a
> “struct” as having at least these fields, but maybe more). (ctypes
> works at the ABI level, whereas Cython and native C extensions work at
> the API level.)
>  
> * We try to be complete. For now some C99 constructs are not
> supported, but all C89 should be, including macros (and including
> macro “abuses”, which you can manually wrap in saner-looking C
> functions).
>  
> * We attempt to support both PyPy and CPython, with a reasonable path
> for other Python implementations like IronPython and Jython.
>  
> * Note that this project is not about embedding executable C code in
> Python, unlike Weave. This is about calling existing C libraries from
> Python.
>  
> so among other things, making a cffi extension gives you the same
> level of security as writing C (and unlike ctypes) and brings quite a
> bit more flexibility (API vs ABI issue) that let's you wrap arbitrary
> libraries, even those full of macros.
>  
> Cheers,
> fijal
>  
> .. [1]: http://cffi.readthedocs.org/en/release-0.5/
> ___
> Python-Dev mailing list
> Python-Dev@python.org (mailto:Python-Dev@python.org)
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/donald.stufft%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] cffi in stdlib

[Maciej Fijalkowski]

On Tue, Feb 26, 2013 at 5:42 PM, Nick Coghlan  wrote:
> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski  wrote:
>> Hello.
>>
>> I would like to discuss on the language summit a potential inclusion
>> of cffi[1] into stdlib.
>
> I think cffi is well worth considering as a possible inclusion for
> Python 3.4. (In particular, I'm a fan of the fact it just uses C
> syntax to declare what you're trying to talk to)
>
> If I'm reading the dependencies correctly, we would also need to bring
> Eli Bendersky's pycparser into the stdlib, correct? (not an objection,
> just an observation, although we'd obviously need Eli's explicit
> endorsement for that).

Yes, although, depending on the circumstances it's possible to hide it
somewhere in cffi and not make it an official stdlib API (then several
rules does not apply). It also pulls in some version of ply (or a
generated parser).

>
> There would also be the matter of converting the cffi test suite from
> py.test to stdlib unittest.

I volunteer to do that, if necessary.

>
> 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] cffi in stdlib

[Dirkjan Ochtman]

On Tue, Feb 26, 2013 at 4:13 PM, Maciej Fijalkowski  wrote:
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers. It seems that the
> main reason why people would prefer ctypes over cffi these days is
> "because it's included in stdlib", which is not generally the reason I
> would like to hear. Our calls to not use C extensions and to use an
> FFI instead has seen very limited success with ctypes and quite a lot
> more since cffi got released. The API is fairly stable right now with
> minor changes going in and it'll definitely stablize until Python 3.4
> release.

I think this would be great to have in the stdlib.

I think it's useful to note that PyPy is planning to include this in
their stdlib for the next release, too, right?

Cheers,

Dirkjan
___
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] cffi in stdlib

[Antoine Pitrou]

Le Tue, 26 Feb 2013 17:13:44 +0200,
Maciej Fijalkowski  a écrit :
> Hello.
> 
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. This is a project Armin Rigo has been working
> for a while, with some input from other developers. It seems that the
> main reason why people would prefer ctypes over cffi these days is
> "because it's included in stdlib", which is not generally the reason I
> would like to hear. Our calls to not use C extensions and to use an
> FFI instead has seen very limited success with ctypes and quite a lot
> more since cffi got released. The API is fairly stable right now with
> minor changes going in and it'll definitely stablize until Python 3.4
> release.

Do you intend to actually maintain it inside the CPython repository?

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] cffi in stdlib

[Eli Bendersky]

On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan  wrote:

> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski 
> wrote:
> > Hello.
> >
> > I would like to discuss on the language summit a potential inclusion
> > of cffi[1] into stdlib.
>
> I think cffi is well worth considering as a possible inclusion for
> Python 3.4. (In particular, I'm a fan of the fact it just uses C
> syntax to declare what you're trying to talk to)
>

I'm cautiously +0.5 because I'd really like to see a strong comparison case
being made vs. ctypes. I've used ctypes many times and it was easy and
effortless (well, except the segfaults when wrong argument types are
declared :-). I'll be really interesting in seeing concrete examples that
demonstrate how CFFI is superior.



> If I'm reading the dependencies correctly, we would also need to bring
> Eli Bendersky's pycparser into the stdlib, correct? (not an objection,
> just an observation, although we'd obviously need Eli's explicit
> endorsement for that).
>

Of course I have no problem with this. I obviously signed the contributor
agreement by this point ;-) pycparser depends on David Beazley's PLY
though, so that will have to be pulled in as well.

Eli
___
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] cffi in stdlib

[Eli Bendersky]

On Tue, Feb 26, 2013 at 8:26 AM, Maciej Fijalkowski wrote:

> On Tue, Feb 26, 2013 at 5:42 PM, Nick Coghlan  wrote:
> > On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski 
> wrote:
> >> Hello.
> >>
> >> I would like to discuss on the language summit a potential inclusion
> >> of cffi[1] into stdlib.
> >
> > I think cffi is well worth considering as a possible inclusion for
> > Python 3.4. (In particular, I'm a fan of the fact it just uses C
> > syntax to declare what you're trying to talk to)
> >
> > If I'm reading the dependencies correctly, we would also need to bring
> > Eli Bendersky's pycparser into the stdlib, correct? (not an objection,
> > just an observation, although we'd obviously need Eli's explicit
> > endorsement for that).
>
> Yes, although, depending on the circumstances it's possible to hide it
> somewhere in cffi and not make it an official stdlib API (then several
> rules does not apply). It also pulls in some version of ply (or a
> generated parser).
>

I'll be the first one to admit that pycparser is almost certainly not
generally useful enough to be exposed in the stdlib. So just using it as an
implementation detail is absolutely fine. PLY is a more interesting
question, however, since PLY is somewhat more generally useful. That said,
I see all this as implementation details that shouldn't distract us from
the main point of whether cffi should be added.

Eli
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Ethan Furman]

On 02/26/2013 01:29 AM, Stephen J. Turnbull wrote:

Ethan Furman writes:

Stephen J. Turnbull wrote:

Note that in both counting and listing the object of the
operation is not an element.  It is a set, and set membership is
the most important aspect of the elements for that purpose.


No, it isn't.  It may be in some cases.


I'm referring only to the dictionary definitions you quote.


Ah, okay.  Although, going with the first definition -- "ascertain the number of" -- I still maintain that the number is 
equally important, otherwise it could be a simple set.




It really sounds to me like your use case (and even more so,
Antoine's) would be perfectly well-served by a named constant class
that doesn't know anything about enumerability.


My enumeration needs tend to be sequential; hence, well served by a class that easily binds names and sequential natural 
numbers together.




My enums even respect it to the point of not comparing equal to
different enum sets.  But, quite frankly, it's the enum's ability
to let me use a name to mean a number that is the most
important. And the most important thing for the Enum class is to
assign those numbers for me as automatically as possible.


But "mean a number" and "assigned automatically" are close to mutually
exclusive (except that "as possible" gives you a lot of wiggle room).


My main "as possible" case is when a number (or short range of numbers) is reserved for future use; being able to easily 
skip to the next meaningful number is a Good Thing.




That is, if by "name means number" you imply that the numbers have
semantics (as in Antoine's HTTP status code example), you care what
the numbers are, and they can't be assigned automatically.


For the status code example I would probably manually assign all the numbers, since there are so few and the gaps 
between so large.


But for my use, which is mainly as list indices, all I have to do is list the names in the correct order -- so I do care 
what value they have, and they can be assigned automatically.




OTOH, if the numbers are assigned very automatically (ie, completely
implicitly), I have trouble with coming up with a use case where
ability to use integer arithmetic (including comparisons other than
equality and set membership) on them *by default* is anything but a
trap.  Eg, with a Likert scale for preference[1], I *do* want to order
them, but (at least when I'm teaching statistics) I *really* *don't*
want them added and subtracted without thinking about exactly what the
operation means.


Every time I do arithmetic with True/False I have to think about what's going on;  I see no difference between that and 
doing arithmetic with Color.red.




And if you really need arithmetic and automatic assignment is good
enough, what's wrong with their ordinary names (ie, 1, 2, 3, ...)?



Because in one file CITY is in column 13, in another it's in column 15, in a third it's in column 7.  Much better 
(easier, safer, more readable) to get the assignment done _once_ and then use CITY everywhere else.  And an easy to use 
int-based Enum class makes that easy.  (And before you ask, yes, I need all the other columns as well.)




Footnotes:
[1]  A qualitative expression of strength of feeling ("hate" = 1,
"dislike" = 2, "indifferent" = 3, "like" = 4, "love" = 5).


I'm beginning to see why enums as a class has not yet been added to Python.  We don't want to complicate the language 
with too many choices, yet there is no One Obvious Enum to fit the wide variety of use-cases:


  - named int enums  (http status codes)
  - named str enums  (tkinter options)
  - named bitmask enums  (file-type options)
  - named valueless enums  (any random set of names)
  - named valueless-yet-orderable enums  (any not-so-random set of names ;)

--
~Ethan~
___
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] cffi in stdlib

[Maciej Fijalkowski]

On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky  wrote:
>
> On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan  wrote:
>>
>> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski 
>> wrote:
>> > Hello.
>> >
>> > I would like to discuss on the language summit a potential inclusion
>> > of cffi[1] into stdlib.
>>
>> I think cffi is well worth considering as a possible inclusion for
>> Python 3.4. (In particular, I'm a fan of the fact it just uses C
>> syntax to declare what you're trying to talk to)
>
>
> I'm cautiously +0.5 because I'd really like to see a strong comparison case
> being made vs. ctypes. I've used ctypes many times and it was easy and
> effortless (well, except the segfaults when wrong argument types are
> declared :-). I'll be really interesting in seeing concrete examples that
> demonstrate how CFFI is superior.

My main issue with ctypes, other than confusing API, which is up to
taste, is that you just cannot wrap some libraries, like OpenSSL
because of API vs ABI. OpenSSL uses macros extensively. Another point
is that even C POSIX stdlib gives you incomplete structs and you have
to guess where to put what fields.
___
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] cffi in stdlib

[Maciej Fijalkowski]

On Tue, Feb 26, 2013 at 6:32 PM, Antoine Pitrou  wrote:
> Le Tue, 26 Feb 2013 17:13:44 +0200,
> Maciej Fijalkowski  a écrit :
>> Hello.
>>
>> I would like to discuss on the language summit a potential inclusion
>> of cffi[1] into stdlib. This is a project Armin Rigo has been working
>> for a while, with some input from other developers. It seems that the
>> main reason why people would prefer ctypes over cffi these days is
>> "because it's included in stdlib", which is not generally the reason I
>> would like to hear. Our calls to not use C extensions and to use an
>> FFI instead has seen very limited success with ctypes and quite a lot
>> more since cffi got released. The API is fairly stable right now with
>> minor changes going in and it'll definitely stablize until Python 3.4
>> release.
>
> Do you intend to actually maintain it inside the CPython repository?
>
> Regards
>
> Antoine.

Once we put it in, yes, of course. Me Armin and Alex.
___
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] cffi in stdlib

[Armin Rigo]

Hi,

On Tue, Feb 26, 2013 at 5:38 PM, Maciej Fijalkowski  wrote:
>> Do you intend to actually maintain it inside the CPython repository?
>
> Once we put it in, yes, of course. Me Armin and Alex.

Yes, I confirm. :-)

Armin
___
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] cffi in stdlib

[Nick Coghlan]

On Wed, Feb 27, 2013 at 2:39 AM, Maciej Fijalkowski  wrote:
> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky  wrote:
>>
>> On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan  wrote:
>>>
>>> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski 
>>> wrote:
>>> > Hello.
>>> >
>>> > I would like to discuss on the language summit a potential inclusion
>>> > of cffi[1] into stdlib.
>>>
>>> I think cffi is well worth considering as a possible inclusion for
>>> Python 3.4. (In particular, I'm a fan of the fact it just uses C
>>> syntax to declare what you're trying to talk to)
>>
>>
>> I'm cautiously +0.5 because I'd really like to see a strong comparison case
>> being made vs. ctypes. I've used ctypes many times and it was easy and
>> effortless (well, except the segfaults when wrong argument types are
>> declared :-). I'll be really interesting in seeing concrete examples that
>> demonstrate how CFFI is superior.
>
> My main issue with ctypes, other than confusing API, which is up to
> taste, is that you just cannot wrap some libraries, like OpenSSL
> because of API vs ABI. OpenSSL uses macros extensively. Another point
> is that even C POSIX stdlib gives you incomplete structs and you have
> to guess where to put what fields.

For me, it's mostly the fact that ctypes is *less* typesafe than C
itself, because you can't easily consume the header files directly,
which leads directly to the segfaults caused by wrong declarations.
While at the time of inclusion there was a solid "practicality beats
purity" case for adding ctypes (and it's taken us quite a long way),
being less typesafe than C is still quite an achievement :)

As an experienced C programmer, not having to learn a new hybrid
language for declarations is also a plus, but the "significantly less
likely to segfault" aspect is the big one.

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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Nick Coghlan]

On Wed, Feb 27, 2013 at 2:03 AM, Ethan Furman  wrote:
> I'm beginning to see why enums as a class has not yet been added to Python.
> We don't want to complicate the language with too many choices, yet there is
> no One Obvious Enum to fit the wide variety of use-cases:
>
>   - named int enums  (http status codes)
>   - named str enums  (tkinter options)
>   - named bitmask enums  (file-type options)
>   - named valueless enums  (any random set of names)
>   - named valueless-yet-orderable enums  (any not-so-random set of names ;)

That's probably the best succinct description of the core problem I've
seen, and I've been following the various enum-related dicussions for
years :)

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] cffi in stdlib

[Eli Bendersky]

On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski wrote:

> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky  wrote:
> >
> > On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan 
> wrote:
> >>
> >> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski 
> >> wrote:
> >> > Hello.
> >> >
> >> > I would like to discuss on the language summit a potential inclusion
> >> > of cffi[1] into stdlib.
> >>
> >> I think cffi is well worth considering as a possible inclusion for
> >> Python 3.4. (In particular, I'm a fan of the fact it just uses C
> >> syntax to declare what you're trying to talk to)
> >
> >
> > I'm cautiously +0.5 because I'd really like to see a strong comparison
> case
> > being made vs. ctypes. I've used ctypes many times and it was easy and
> > effortless (well, except the segfaults when wrong argument types are
> > declared :-). I'll be really interesting in seeing concrete examples that
> > demonstrate how CFFI is superior.
>
> My main issue with ctypes, other than confusing API, which is up to
> taste, is that you just cannot wrap some libraries, like OpenSSL
> because of API vs ABI. OpenSSL uses macros extensively. Another point
> is that even C POSIX stdlib gives you incomplete structs and you have
> to guess where to put what fields.
>

Yep, I can think of some reasons too. But just mentioning it so you
remember explicitly listing the advantages when it comes to writing a PEP
or some other sort of formal proposal. An FWIW, I think there's already
enough positive feedback to at least start drafting a PEP. It can always be
rejected later ;-)

Eli
___
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] cffi in stdlib

[Maciej Fijalkowski]

On Tue, Feb 26, 2013 at 7:07 PM, Eli Bendersky  wrote:
>
>
>
> On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski 
> wrote:
>>
>> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky  wrote:
>> >
>> > On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan 
>> > wrote:
>> >>
>> >> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski 
>> >> wrote:
>> >> > Hello.
>> >> >
>> >> > I would like to discuss on the language summit a potential inclusion
>> >> > of cffi[1] into stdlib.
>> >>
>> >> I think cffi is well worth considering as a possible inclusion for
>> >> Python 3.4. (In particular, I'm a fan of the fact it just uses C
>> >> syntax to declare what you're trying to talk to)
>> >
>> >
>> > I'm cautiously +0.5 because I'd really like to see a strong comparison
>> > case
>> > being made vs. ctypes. I've used ctypes many times and it was easy and
>> > effortless (well, except the segfaults when wrong argument types are
>> > declared :-). I'll be really interesting in seeing concrete examples
>> > that
>> > demonstrate how CFFI is superior.
>>
>> My main issue with ctypes, other than confusing API, which is up to
>> taste, is that you just cannot wrap some libraries, like OpenSSL
>> because of API vs ABI. OpenSSL uses macros extensively. Another point
>> is that even C POSIX stdlib gives you incomplete structs and you have
>> to guess where to put what fields.
>
>
> Yep, I can think of some reasons too. But just mentioning it so you remember
> explicitly listing the advantages when it comes to writing a PEP or some
> other sort of formal proposal. An FWIW, I think there's already enough
> positive feedback to at least start drafting a PEP. It can always be
> rejected later ;-)
>
> Eli
>

It's copy-pasted in the original mail and it's in the docs. Anyway,
this is just to familizarize people with the library. We're going to
discuss it on the language summit at pycon.
___
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] cffi in stdlib

[Daniel Holth]

+1


On Tue, Feb 26, 2013 at 12:14 PM, Maciej Fijalkowski wrote:

> On Tue, Feb 26, 2013 at 7:07 PM, Eli Bendersky  wrote:
> >
> >
> >
> > On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski 
> > wrote:
> >>
> >> On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky 
> wrote:
> >> >
> >> > On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan 
> >> > wrote:
> >> >>
> >> >> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski <
> fij...@gmail.com>
> >> >> wrote:
> >> >> > Hello.
> >> >> >
> >> >> > I would like to discuss on the language summit a potential
> inclusion
> >> >> > of cffi[1] into stdlib.
> >> >>
> >> >> I think cffi is well worth considering as a possible inclusion for
> >> >> Python 3.4. (In particular, I'm a fan of the fact it just uses C
> >> >> syntax to declare what you're trying to talk to)
> >> >
> >> >
> >> > I'm cautiously +0.5 because I'd really like to see a strong comparison
> >> > case
> >> > being made vs. ctypes. I've used ctypes many times and it was easy and
> >> > effortless (well, except the segfaults when wrong argument types are
> >> > declared :-). I'll be really interesting in seeing concrete examples
> >> > that
> >> > demonstrate how CFFI is superior.
> >>
> >> My main issue with ctypes, other than confusing API, which is up to
> >> taste, is that you just cannot wrap some libraries, like OpenSSL
> >> because of API vs ABI. OpenSSL uses macros extensively. Another point
> >> is that even C POSIX stdlib gives you incomplete structs and you have
> >> to guess where to put what fields.
> >
> >
> > Yep, I can think of some reasons too. But just mentioning it so you
> remember
> > explicitly listing the advantages when it comes to writing a PEP or some
> > other sort of formal proposal. An FWIW, I think there's already enough
> > positive feedback to at least start drafting a PEP. It can always be
> > rejected later ;-)
> >
> > Eli
> >
>
> It's copy-pasted in the original mail and it's in the docs. Anyway,
> this is just to familizarize people with the library. We're going to
> discuss it on the language summit at pycon.
> ___
> 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/dholth%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] cffi in stdlib

[Paul Moore]

On 26 February 2013 16:34, Eli Bendersky  wrote:
> I'm cautiously +0.5 because I'd really like to see a strong comparison case
> being made vs. ctypes. I've used ctypes many times and it was easy and
> effortless (well, except the segfaults when wrong argument types are
> declared :-). I'll be really interesting in seeing concrete examples that
> demonstrate how CFFI is superior.

I'm probably the same, mainly because I've successfully used ctypes in
the past, but I've never used cffi. That's something I need to
rectify.

One point which I *think* is correct, but which I don't see noted
anywhere. Am I right that cffi needs a C compiler involved in the
process, at least somewhere? If that's the case, then it is not a
suitable option for at least one use case that I have, writing quick
hacks involving the Windows API on a machine that doesn't have a C
compiler installed. Another possible case would be writing zip-safe
code - if cffi involves a compiled C extension, it won't work when
loaded from a zipfile.

In general, a proper, unbiased comparison between cffi and ctypes
would be useful.

BTW, I assume that the intention is that both cffi and ctypes remain
available indefinitely? Nobody's looking to deprecate ctypes?

Paul
___
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] cffi in stdlib

[Paul Moore]

On 26 February 2013 18:34, Maciej Fijalkowski  wrote:
>> One point which I *think* is correct, but which I don't see noted
>> anywhere. Am I right that cffi needs a C compiler involved in the
>> process, at least somewhere? If that's the case, then it is not a
>> suitable option for at least one use case that I have, writing quick
>> hacks involving the Windows API on a machine that doesn't have a C
>> compiler installed. Another possible case would be writing zip-safe
>> code - if cffi involves a compiled C extension, it won't work when
>> loaded from a zipfile.
>
> cffi does require a C compiler during either runtime or installation,
> if you use the API. You can still use the ABI level, which is like
> ctypes, only if you need the extra stuff, you need a C compiler.

Cool, thanks. So if I use it like ctypes, cffi doesn't need a C
compiler? That's nice, I never knew that.

I definitely need to try it out. (So many projects, so little time... :-))

Paul
___
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] cffi in stdlib

[Maciej Fijalkowski]

On Tue, Feb 26, 2013 at 8:14 PM, Paul Moore  wrote:
> On 26 February 2013 16:34, Eli Bendersky  wrote:
>> I'm cautiously +0.5 because I'd really like to see a strong comparison case
>> being made vs. ctypes. I've used ctypes many times and it was easy and
>> effortless (well, except the segfaults when wrong argument types are
>> declared :-). I'll be really interesting in seeing concrete examples that
>> demonstrate how CFFI is superior.
>
> I'm probably the same, mainly because I've successfully used ctypes in
> the past, but I've never used cffi. That's something I need to
> rectify.
>
> One point which I *think* is correct, but which I don't see noted
> anywhere. Am I right that cffi needs a C compiler involved in the
> process, at least somewhere? If that's the case, then it is not a
> suitable option for at least one use case that I have, writing quick
> hacks involving the Windows API on a machine that doesn't have a C
> compiler installed. Another possible case would be writing zip-safe
> code - if cffi involves a compiled C extension, it won't work when
> loaded from a zipfile.

cffi does require a C compiler during either runtime or installation,
if you use the API. You can still use the ABI level, which is like
ctypes, only if you need the extra stuff, you need a C compiler.

>
> In general, a proper, unbiased comparison between cffi and ctypes
> would be useful.

that obviously can't come from me.
___
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] Announcing PEP 436: The Argument Clinic DSL

[Larry Hastings]

On 02/26/2013 08:11 AM, Terry Reedy wrote:
The PEP gives an internal, developer-focused rationale. I think there 
is also an external, user-focused rationale. As much as possible (with 
obvious caveats about type introspection), I think it should be 
transparent to users (other than speed) whether a function is 
implemented in Python or C. People who love keyword calling currently 
have to learn which module by module and function by function. 
Tranparency will become even more important as more modules are dual 
coded, and as users move code between implementations. I presume some 
of the complexities of PyArg_ParseTupleAndKeywords arise from pursuing 
this goal. And if I understand correctly, this PEP should reduce some 
of the complexities. The 'future goal' of C function signature info 
will further aid transparency.


This user rationale suggests that positional-only functions should be 
discouraged.


I think positional-only functions should be discouraged, but we don't 
really need Clinic to do that.  I suppose we don't need Clinic to 
support signatures for built-in functions either, though Clinic would be 
a much bigger help in that department.


So, here's my interpretation of the above suggestion: one user-focused 
rationale for Clinic is that it'll make it easier for developers to 
write built-ins that behave identically to functions written in Python, 
and this benefits users.  Do you agree with that?


It also suggests another future goal: a clinic backend that would 
instead output a skeleton python file with def header lines and 
docstrings, leaving the bodies to be filled in.


Well, right now Clinic has no visibility into variables, just 
functions.  So such a skeleton python file would be a bit incomplete.


That's mildly interesting to consider, though--telling Clinic about 
module variables, that is.  Another possible use of Clinic is to do 
conformance testing for alternative implementations, that is, having 
PyPy (for example) make sure that they got their reimplemented standard 
library API correct.



//arry/
___
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] cffi in stdlib

[R. David Murray]

On Tue, 26 Feb 2013 18:14:26 +, Paul Moore  wrote:
> BTW, I assume that the intention is that both cffi and ctypes remain
> available indefinitely? Nobody's looking to deprecate ctypes?

I would expect that ctypes would be deprecated eventually simply because
there aren't very many people interested in maintaining it, and probably
fewer if cffi is accepted.  That said, I would not expect it to leave
the stdlib until either the bit rot was so bad it wouldn't be worth
shipping it, or (more likely) we reach Python4 and decide at that time
that it is time for it to go.

Of course, this is just me talking, we only have a *very* vague "sense of
the house" for what Python4 means at this point :)

--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] cffi in stdlib

[Guido van Rossum]

Generally speaking, deferring something to Python 4 means "never".

On Tue, Feb 26, 2013 at 11:06 AM, R. David Murray  wrote:
> On Tue, 26 Feb 2013 18:14:26 +, Paul Moore  wrote:
>> BTW, I assume that the intention is that both cffi and ctypes remain
>> available indefinitely? Nobody's looking to deprecate ctypes?
>
> I would expect that ctypes would be deprecated eventually simply because
> there aren't very many people interested in maintaining it, and probably
> fewer if cffi is accepted.  That said, I would not expect it to leave
> the stdlib until either the bit rot was so bad it wouldn't be worth
> shipping it, or (more likely) we reach Python4 and decide at that time
> that it is time for it to go.
>
> Of course, this is just me talking, we only have a *very* vague "sense of
> the house" for what Python4 means at this point :)
>
> --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/guido%40python.org



--
--Guido van Rossum (python.org/~guido)
___
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] cffi in stdlib

[Brett Cannon]

On Tue, Feb 26, 2013 at 2:12 PM, Guido van Rossum  wrote:

> Generally speaking, deferring something to Python 4 means "never".
>

Does that mean your aversion to double digit version numbers (i.e. 3.10) is
gone or you expect to freeze Python in carbonite by then?

-Brett


>
> On Tue, Feb 26, 2013 at 11:06 AM, R. David Murray 
> wrote:
> > On Tue, 26 Feb 2013 18:14:26 +, Paul Moore 
> wrote:
> >> BTW, I assume that the intention is that both cffi and ctypes remain
> >> available indefinitely? Nobody's looking to deprecate ctypes?
> >
> > I would expect that ctypes would be deprecated eventually simply because
> > there aren't very many people interested in maintaining it, and probably
> > fewer if cffi is accepted.  That said, I would not expect it to leave
> > the stdlib until either the bit rot was so bad it wouldn't be worth
> > shipping it, or (more likely) we reach Python4 and decide at that time
> > that it is time for it to go.
> >
> > Of course, this is just me talking, we only have a *very* vague "sense of
> > the house" for what Python4 means at this point :)
> >
> > --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/guido%40python.org
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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/brett%40python.org
>
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Antoine Pitrou]

On Tue, 26 Feb 2013 08:03:40 -0800
Ethan Furman  wrote:
> I'm beginning to see why enums as a class has not yet been added to Python.  
> We don't want to complicate the language 
> with too many choices, yet there is no One Obvious Enum to fit the wide 
> variety of use-cases:
> 
>- named int enums  (http status codes)
>- named str enums  (tkinter options)
>- named bitmask enums  (file-type options)
>- named valueless enums  (any random set of names)
>- named valueless-yet-orderable enums  (any not-so-random set of names ;)

I don't think valueless enums have a point. Just make them str enums.

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] cffi in stdlib

[Guido van Rossum]

With 1.5 years per release, it'd be 10 years before we'd hit 3.10.
>From a software engineering perspective, 10 years is indistinguishable
from infinity, so I don't care what happens 10 years from now -- as
long as you don't blame me. :-)

On Tue, Feb 26, 2013 at 11:21 AM, Brett Cannon  wrote:
>
>
>
> On Tue, Feb 26, 2013 at 2:12 PM, Guido van Rossum  wrote:
>>
>> Generally speaking, deferring something to Python 4 means "never".
>
>
> Does that mean your aversion to double digit version numbers (i.e. 3.10) is
> gone or you expect to freeze Python in carbonite by then?
>
> -Brett
>
>>
>>
>> On Tue, Feb 26, 2013 at 11:06 AM, R. David Murray 
>> wrote:
>> > On Tue, 26 Feb 2013 18:14:26 +, Paul Moore 
>> > wrote:
>> >> BTW, I assume that the intention is that both cffi and ctypes remain
>> >> available indefinitely? Nobody's looking to deprecate ctypes?
>> >
>> > I would expect that ctypes would be deprecated eventually simply because
>> > there aren't very many people interested in maintaining it, and probably
>> > fewer if cffi is accepted.  That said, I would not expect it to leave
>> > the stdlib until either the bit rot was so bad it wouldn't be worth
>> > shipping it, or (more likely) we reach Python4 and decide at that time
>> > that it is time for it to go.
>> >
>> > Of course, this is just me talking, we only have a *very* vague "sense
>> > of
>> > the house" for what Python4 means at this point :)
>> >
>> > --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/guido%40python.org
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> ___
>> 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/brett%40python.org
>
>



--
--Guido van Rossum (python.org/~guido)
___
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] cffi in stdlib

[Antoine Pitrou]

On Tue, 26 Feb 2013 14:21:03 -0500
Brett Cannon  wrote:
> On Tue, Feb 26, 2013 at 2:12 PM, Guido van Rossum  wrote:
> 
> > Generally speaking, deferring something to Python 4 means "never".
> >
> 
> Does that mean your aversion to double digit version numbers (i.e. 3.10) is
> gone or you expect to freeze Python in carbonite by then?

Or we'll go straight to 5.
(or switch to date-based numbering :-))

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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Ethan Furman]

On 02/26/2013 11:17 AM, Antoine Pitrou wrote:

On Tue, 26 Feb 2013 08:03:40 -0800
Ethan Furman  wrote:

I'm beginning to see why enums as a class has not yet been added to Python.  We 
don't want to complicate the language
with too many choices, yet there is no One Obvious Enum to fit the wide variety 
of use-cases:

- named int enums  (http status codes)
- named str enums  (tkinter options)
- named bitmask enums  (file-type options)
- named valueless enums  (any random set of names)
- named valueless-yet-orderable enums  (any not-so-random set of names ;)


I don't think valueless enums have a point. Just make them str enums.


If they're str enums then they would compare equal with strings and be strings 
and that may not be desired.

--
~Ethan~
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Tim Delaney]

On 27 February 2013 01:50, Terry Reedy  wrote:

> On 2/25/2013 12:35 PM, Ethan Furman wrote:
>
>  But this I don't, and in both mine, Ted's, and Alex's versions enums
>> from different groups do not compare equal, regardless of the underlying
>> value.  Of course, this does have the potential problem of `green == 1
>> == bee` but not `green == bee` which would be a problem with set and
>> dicts -- but I'm the only one who has brought up that issue.
>>
>
> I have not been following the discussion in detail so I missed that
> before. Breaking transitivity of equality a no-no. It is basic to thought
> and logic.
>
> decimal(0) == 0 == 0.0 != decimal(0)
> was a problem we finally fixed by removing the inequality above.
> http://bugs.python.org/**issue4087 
> http://bugs.python.org/**issue4090 
>
> We should NOT knowingly re-introduce the same problem again! If color and
> animal are isolated from each other, they should each be isolated from
> everything, including int.


FWIW the only reason I made my enums int-based (and comparable with ints)
was because I read somewhere that Guido had said that any stdlib enum would
have to be an int subclass.

I have no problems with having int-like enums that:

1. Are not int subclasses;

2. Do not compare equal with ints unless explicitly converted.

I do think an int-like enum should implement both __int__ and __index__.

Tim Delaney
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Greg Ewing]

Terry Reedy wrote:
(The 
non-reflexivity of NAN is a different issue, but NANs are intentionally 
insane.)


Yes, the non-transitivity in that case only applies to
one very special value. We're talking about making
comparison non-transitive for *all* values of the
types involved, which is a whole different level of
weirdness.

--
Greg
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Ethan Furman]

On 02/26/2013 12:52 PM, Tim Delaney wrote:

On 27 February 2013 01:50, Terry Reedy mailto:tjre...@udel.edu>> wrote:

We should NOT knowingly re-introduce the same problem again! If color and 
animal are isolated from each other, they
should each be isolated from everything, including int.


FWIW the only reason I made my enums int-based (and comparable with ints) was 
because I read somewhere that Guido had
said that any stdlib enum would have to be an int subclass.


I recall that as well.



I have no problems with having int-like enums that:

1. Are not int subclasses;

2. Do not compare equal with ints unless explicitly converted.

I do think an int-like enum should implement both __int__ and __index__.



I think it will take more than one type of Enum to handle the myriad needs.

1) Default enumeration: valueless, unordered:

class BreakfastMeat(Enum):
eggs = 'from a chicken'
ham = 'from a pig'
spam = 'from a ... um ... '

2) non-valued, yet ordered:

class DaysOfWeek(OrderedEnum):
sunday = 'last day of weekend'
monday = 'is it the 13th??'
tuesday = 'not as bad as monday'
wednesday = 'halfway through!'
thursday = 'almost there...'
friday = 'thank goodness'
saturday = 'sleeping in!'

3) bitmask: sub-classes int, but not directly interactable (except for shifts)

class DbfFieldOptions(BitMaskEnum):
binary = 'no unicode translation'
nullable = 'can store None'
system = 'internal use only'

4) named string (based on str, basically a named constant)

class TkGeometry(StrEnum):
top = north = 'top'
bottom = south = 'bottom'
left = west = 'left'
right = east = 'right'

5) named integer (based on int, basically a named constant)

class RowLabels(IntEnum):
name = 0
address = 1
city = 2
state = 3
zip = 4


In the first three examples the data in quotes is the doc string; in examples 4 and 5 the RHS is the actual value 
assigned.  For that matter, 4 and 5 could be compacted into a NamedValue class, allowing whatever type is needed (since 
set membership is not restricted anyway):


class Constants(NamedValues):
top = 'top', 'top, or north, edge'
bottom = 'bottom', 'bottom, or south, edge'
pi = 3.14159, "circle's circumference divided by it's radius"
lucky = 7, 'come on, 7!'
unlucky = 2, 'snake eyes!'

That would get us to three enum classes and one namedvalue class, and should 
cover 99% of the use cases out there.

Does anyone still reading this thread have a use case not covered by the above?

--
~Ethan~
___
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] cffi in stdlib

[Greg Ewing]

Antoine Pitrou wrote:

Or we'll go straight to 5.
(or switch to date-based numbering :-))


We could go the Apple route and start naming them after
species of snake.

--
Greg
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Greg Ewing]

Ethan Furman wrote:
In the first three examples the data in quotes is the doc string; in 
examples 4 and 5 the RHS is the actual value assigned.


What if you want to assign both values and docstrings?

--
Greg

___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Ethan Furman]

On 02/26/2013 03:26 PM, Greg Ewing wrote:

Ethan Furman wrote:

In the first three examples the data in quotes is the doc string; in examples
4 and 5 the RHS is the actual value assigned.


What if you want to assign both values and docstrings?


Let the bike shedding begin, eh?  ;)

It could be as simple as

   name = (0, 'customers full legal name')

or as complex as

name = enum(value=0, doc="customer's full legal name", xyz='some other 
attribute')

--
~Ethan~
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Glyph]

On Feb 26, 2013, at 5:25 AM, Eli Bendersky  wrote:

> Glyph, thanks for the input. I mentioned Twisted because in its code I found 
> a number of places with simple string enumerations used to represent state. I 
> was not aware of twisted.python.constants, but it doesn't appear that this 
> module is used  at least in the places I checked.

Quite so.  twisted.python.constants was created because we made the same 
observation that you did.  Hopefully, more of these protocols will be 
transitioned to make use of twisted.python.constants internally.

> In general, many protocols have some "state" instance var that's usually just 
> a string, using either predefined constants or direct string literals.

Indeed.  This idiom varies considerably.  Another thing that Twisted needs is a 
mechanism for explicitly building state-machine, but that's a discussion for 
another day.

-glyph

___
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] cffi in stdlib

[Terry Reedy]

On 2/26/2013 10:13 AM, Maciej Fijalkowski wrote:


I would like to discuss on the language summit a potential inclusion
of cffi[1] into stdlib.


How does it compare in terms of speed. One reason ctypes has not 
replaces hand-tuned swig is that it apparently is much slower. I know 
that someone, for instance, once did a pygame fork using ctypes to wrap 
SDL, and got it to run, but gave it up for comparative slowness reasons.


--
Terry Jan Reedy

___
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] Announcing PEP 436: The Argument Clinic DSL

[Terry Reedy]

On 2/26/2013 1:47 PM, Larry Hastings wrote:

On 02/26/2013 08:11 AM, Terry Reedy wrote:

The PEP gives an internal, developer-focused rationale. I think there
is also an external, user-focused rationale. As much as possible (with
obvious caveats about type introspection), I think it should be
transparent to users (other than speed) whether a function is
implemented in Python or C. People who love keyword calling currently
have to learn which module by module and function by function.
Tranparency will become even more important as more modules are dual
coded, and as users move code between implementations. I presume some
of the complexities of PyArg_ParseTupleAndKeywords arise from pursuing
this goal. And if I understand correctly, this PEP should reduce some
of the complexities. The 'future goal' of C function signature info
will further aid transparency.

This user rationale suggests that positional-only functions should be
discouraged.


I think positional-only functions should be discouraged, but we don't


If I were writing something like Clinic, I would be tempted to not have 
that option. But I was actually thinking about something in the 
positional-only writeup that mentioned the possibility of adding 
something to the positional-only option.



really need Clinic to do that.  I suppose we don't need Clinic to
support signatures for built-in functions either, though Clinic would be
a much bigger help in that department.

So, here's my interpretation of the above suggestion: one user-focused
rationale for Clinic is that it'll make it easier for developers to
write built-ins that behave identically to functions written in Python,
and this benefits users.  Do you agree with that?


yes, especially with signatures.



It also suggests another future goal: a clinic backend that would
instead output a skeleton python file with def header lines and
docstrings, leaving the bodies to be filled in.


Well, right now Clinic has no visibility into variables, just
functions.  So such a skeleton python file would be a bit incomplete.


Module variables are option few enough to copy by hand. Methods are more 
of a problem. As I understand it, C module files are structured 
something like the following, which is 'unusual' for a python file.


def meth1_impl(...

def meth2_impl(...

class C:
  meth1 = meth1_impl
  meth2 = meth2_impl

So producing an idiomatic skeleton would require more that an alternate 
backend. Rather function entries should be stored and not output until 
the structure (class) definition is encountered. Two passes would be a 
lot easier than one.



That's mildly interesting to consider, though--telling Clinic about
module variables, that is.  Another possible use of Clinic is to do
conformance testing for alternative implementations, that is, having
PyPy (for example) make sure that they got their reimplemented standard
library API correct.


//arry/





--
Terry Jan Reedy

___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Stephen J. Turnbull]

Ethan Furman writes:

 > Ah, okay.  Although, going with the first definition -- "ascertain
 > the number of" -- I still maintain that the number is equally
 > important, otherwise it could be a simple set.

Of course "number" is central to counting -- but you can count a set
of objects that have no numerical value.  You can also count objects
with numerical values that cannot be a count for that set: fractions,
negative integers, etc.  There's no necessary connection between the
integers used for counting, and those that are values of the things
counted.

 > But for my use, which is mainly as list indices, all I have to do
 > is list the names in the correct order -- so I do care what value
 > they have, and they can be assigned automatically.

OK, that sounds like a valid use case to me.  I don't mean to
deprecate it, I just don't understand it because I'd never do that
myself -- in all the cases where I care about the names and there's a
variable order, the names are in the data.  Eg, a CSV file with a
header row.  So I read them and need to create an inverse mapping.
And in general, I need a string->index mapping for UI.  So using an
enum so I can hard-code column names doesn't help me much -- I'm doing
a lot of string manipulation anyway.

Worse for me, most of the applications I have, I'd like the enumerator
identifiers to be both string-valued and int-valued: the int used to
index into Python sequences, and the string used in formatting SQL.

 > Every time I do arithmetic with True/False I have to think about
 > what's going on; I see no difference between that and doing
 > arithmetic with Color.red.

The pedagogical problem is that in a Likert scale "have to think"
is a prescriptive requirement that students and even experienced
researchers ignore all the time.  They easily think of "hate" and
"like" as the numbers 1 and 4, and they want to take averages across
people.  But that doesn't make sense if you examine behavior
carefully: even though everybody agrees on order, the size of the
steps and origin are different for different people.

So I want to make it a logical constraint enforced by Enum, to be
relaxed only if the user signs a no-damages release.  I don't have an
objection to making that easy by providing derived Enum types that
have int or string values, or to a subclass of ordered Enums.  Just
that the base Enum type should be a collection of Python identifiers
that you can't do much with except compare for identity, and
operations would be added only with some kind of explicit indication
like IntEnum, OrderedEnum, etc.

___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > On Tue, 26 Feb 2013 08:03:40 -0800
 > Ethan Furman  wrote:
 > > I'm beginning to see why enums as a class has not yet been added
 > > to Python.  We don't want to complicate the language with too
 > > many choices, yet there is no One Obvious Enum to fit the wide
 > > variety of use-cases:
 > > 
 > >- named int enums  (http status codes)
 > >- named str enums  (tkinter options)
 > >- named bitmask enums  (file-type options)
 > >- named valueless enums  (any random set of names)
 > >- named valueless-yet-orderable enums  (any not-so-random set of names 
 > > ;)

I don't see what the problem is with having a very restricted base
Enum class and providing a number of convenience subclasses.

 > I don't think valueless enums have a point. Just make them str enums.

I suppose Ethan doesn't mean "no value at all", he means "no operations
available on the value" (ie, you need to explicitly convert from the
enumerator to an int or str to add or compare them).  str enums won't
satisfy that requirement.  They are implicitly orderable and addable.
Furthermore, the str order is probably quite wrong.  If the enum is
orderable, I would expect declaration order.

As far as I can see, what you (Antoine) want is an identifier with a
constant value, no more and no less.  Grouping into an enum is merely
a lexical convention, since you are happy to compare enums of
different enum classes and enums with ints.

I think such a thing is pretty generally desirable, but most of the
people who have created Enum classes implement some type-checking that
this value came from that Enum.  To me that is what differentiates an
enumerated constant from a generic named constant.  I don't see why
you keep deprecating that feature.  Do you really think it's useless,
or is it just that you wouldn't use it yourself?
___
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] cffi in stdlib

[Eli Bendersky]

* Work either at the level of the ABI (Application Binary Interface)

> or the API (Application Programming Interface). Usually, C libraries
> have a specified C API but often not an ABI (e.g. they may document a
> “struct” as having at least these fields, but maybe more). (ctypes
> works at the ABI level, whereas Cython and native C extensions work at
> the API level.)
>


I read the cffi docs once again and went through some of the examples. I
want to divide this to two topics.

One is what you call the "ABI" level. IMHO, it's hands down superior to
ctypes. Your readdir demo demonstrates this very nicely. I would definitely
want to see this in the stdlib as an alternative way to interface to C
shared objects & DLLs.

Two is what you call the "API" level, which is where my opinion becomes
mixed. Some things just don't feel right to me:

1. Tying in a C compiler into the flow of a program. I'm not sure whether
we have precedents for it in the stdlib. Does this work on Windows where
libraries and DLLs are usually built with MSVC?

2. Using a function called "verify" to create stuff. This may sound like a
naming bikeshed, but it's not. It ties in to the question - why is this
needed?

3. The partial type specifications in C with ellipsis. What is the point?
You have the C declarations somewhere anyhow, so why introduce this? The
"ABI level" boasts having just C and Python to write, but those partial
ellipsis-ridden declarations are hardly C.

Please see this as constructive criticism, and I fully admit that I may not
have went deep enough to see the big benefits of the "API" level that would
justify all that complexity.

Eli
___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Greg Ewing]

Stephen J. Turnbull wrote:

Worse for me, most of the applications I have, I'd like the enumerator
identifiers to be both string-valued and int-valued: the int used to
index into Python sequences, and the string used in formatting SQL.


Is the string value required the same as the name used in
Python code? If so, this requirement would be met by having
__index__ return the int value and __str__ return the
unqualified name.

--
Greg

___
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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Stephen J. Turnbull]

Greg Ewing writes:
 > Stephen J. Turnbull wrote:
 > > Worse for me, most of the applications I have, I'd like the enumerator
 > > identifiers to be both string-valued and int-valued: the int used to
 > > index into Python sequences, and the string used in formatting SQL.
 > 
 > Is the string value required the same as the name used in
 > Python code? If so, this requirement would be met by having
 > __index__ return the int value and __str__ return the
 > unqualified name.

Ah, that's right (and Ethan already mentioned using __index__).  Yes,
I think that should work for me.  Very cool!

... If I had a use for it.  But I'm mostly trying to understand
Ethan's use case; I can't recall having a case where I would be
hard-coding an index by name.  In my typical use, I might have several
data set with columns CITY, INCOME, NUMBER_OF_CARS, ... and need to
compute various correlations based on user-specified models.  Then my
list of indicies for internal use is just

[column_index[name] for name in user_provided_name_list]

and the inverse (for formatting output) is

[column_name[index] for index in internal_indicies] .

The column_index and column_name dicts are computed when reading the
data set (typically from column headers in a CSV file).

Then I said to myself, "instead of using 'internal_indicies', let me
hard-code enum constants for indicies -- what would that look like?"
and that's where my requirement came from.

If I am guessing Ethan's use case correctly, the computations are very
specific to the columns involved (eg, he can't use a generic function
like "correlation" for arbitrary pairs of columns).  Then he does
these idiosyncratic computations for various data sets.

Are such applications common?  Evidently, they're bread and butter for
Ethan, but anybody else?




___
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] cffi in stdlib

[Ronald Oussoren]

On 26 Feb, 2013, at 16:13, Maciej Fijalkowski  wrote:

> Hello.
> 
> I would like to discuss on the language summit a potential inclusion
> of cffi[1] into stdlib. 

The API in general looks nice, but I do have some concens w.r.t. including cffi 
in the stdlib.

1. Why is cffi completely separate from ctypes, instead of layered on top of 
it? That is, add a utility module to ctypes that can parse C declarations and 
generate the right ctypes definitions. 

2. Cffi has a dependencies on pycparser and that module and its dependencies 
would therefore also be added to the stdlib (even if they'd be hidden in the 
cffi package)

3. Cffi basicly contains a (limited) C parser, and those are notoriously hard 
to get exactly right. Luckily cffi only needs to interpret declarations and not 
the full language, but even so this can be a risk of subtle bugs.

4. And finally a technical concern: how well does cffi work with fat binaries 
on OSX? In particular, will the distutils support generate cached data for all 
architectures supported by a fat binary?

Also, after playing around with it for 5 minutes I don't quite understand how 
to use it. Let's say I want to wrap a function "CGPoint CGPointMake(CGFloat x, 
CGFloat y)". Is is possible to avoid mentioning the exact typedef for CGFloat 
somewhere? I tried using:

   ffi.cdef("typedef ... CGFloat; typedef struct { CGFloat x; CGFloat y; } 
CGPoint; CGPoint CGPointMake(CGFloat x, CGFloat y);")

But that results in an error when calling verify:

   TypeError: field 'struct $CGPoint.x' has ctype 'struct $CGFloat' of unknown 
size

>From a first glance this doesn't seem to buy me that much w.r.t. ctypes, I 
>still have to declare the actual type of CGFloat which is documented as "some 
>floating point type".

Ronald
___
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