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
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
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
Py
* 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 AB
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
> > vari
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 n
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
tran
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, f
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
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 a
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@pyt
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/mailma
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 t
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
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 probl
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 var
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
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, 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
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
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
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 inter
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
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 w
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 us
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 real
+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,
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,
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
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 (ht
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 o
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
Pyth
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,
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 stdli
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
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 stdli
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 inclusi
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
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
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
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 f
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.
htt
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
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 qua
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 b
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
>>
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 i
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 sh
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-transit
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 wou
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
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 sou
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
> > extensio
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 guarantee
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 o
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 b
56 matches
Mail list logo
