On 04/24/2015 09:45 PM, Nick Coghlan wrote:
Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
Not exactly. The way I figure it, the best way to achieve this with
unary plus is to ast.parse it (as we currently do) and then modify the
parse tree. That works but it's
On 25 April 2015 at 17:58, Larry Hastings la...@hastings.org wrote:
On 04/24/2015 09:45 PM, Nick Coghlan wrote:
Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
Not exactly. The way I figure it, the best way to achieve this with unary
plus is to ast.parse it (as
On Sat, Apr 25, 2015 at 10:58 AM, Larry Hastings la...@hastings.org wrote:
On 04/24/2015 09:45 PM, Nick Coghlan wrote:
Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
Not exactly. The way I figure it, the best way to achieve this with unary
plus is to ast.parse
On 22 April 2015 at 03:31, Larry Hastings la...@hastings.org wrote:
On 04/21/2015 04:50 AM, Tal Einat wrote:
As for the default set of accepted types for various convertors, if we
could choose any syntax we liked, something like accept=+{NoneType}
would be much better IMO.
In theory
On 25 April 2015 at 14:44, Nick Coghlan ncogh...@gmail.com wrote:
On 22 April 2015 at 03:31, Larry Hastings la...@hastings.org wrote:
On 04/21/2015 04:50 AM, Tal Einat wrote:
As for the default set of accepted types for various convertors, if we
could choose any syntax we liked, something
On 04/21/2015 04:50 AM, Tal Einat wrote:
As for the default set of accepted types for various convertors, if we
could choose any syntax we liked, something like accept=+{NoneType}
would be much better IMO.
In theory Argument Clinic could use any syntax it likes. In practice,
under the
On Tue, Apr 21, 2015 at 8:31 PM, Larry Hastings la...@hastings.org wrote:
On 04/21/2015 04:50 AM, Tal Einat wrote:
As for the default set of accepted types for various convertors, if we
could choose any syntax we liked, something like accept=+{NoneType}
would be much better IMO.
In theory
On Mon, Apr 20, 2015 at 6:55 AM Barry Warsaw ba...@python.org wrote:
On Apr 19, 2015, at 01:19 AM, Larry Hastings wrote:
We should rename types to accept. accept should takes a set of
types;
these types specify the types of Python objects the Clinic parameter
should
accept. For the funny
On Sun, Apr 19, 2015 at 11:19 AM, Larry Hastings la...@hastings.org wrote:
On 08/07/2014 09:41 PM, Larry Hastings wrote:
Well! It's rare that the core dev community is so consistent in its
opinion. I still think nullable is totally appropriate, but I'll change
it to allow_none.
On Apr 19, 2015, at 01:19 AM, Larry Hastings wrote:
We should rename types to accept. accept should takes a set of types;
these types specify the types of Python objects the Clinic parameter should
accept. For the funny pseudo-types needed in some Clinic declarations
(buffer, robuffer, and
On 08/07/2014 09:41 PM, Larry Hastings wrote:
Well! It's rare that the core dev community is so consistent in its
opinion. I still think nullable is totally appropriate, but I'll
change it to allow_none.
(reviving eight-month-old thread)
In case anybody here is still interested in
On 4/19/2015 1:19 AM, Larry Hastings wrote:
On 08/07/2014 09:41 PM, Larry Hastings wrote:
Well! It's rare that the core dev community is so consistent in its
opinion. I still think nullable is totally appropriate, but I'll
change it to allow_none.
(reviving eight-month-old thread)
*
On 04/19/2015 01:26 PM, Glenn Linderman wrote:
Is argument clinic a special case of type annotations? (Quoted and
worded to be provocative, intentionally but not maliciously.)
OK, I know that argument clinic applies to C code and I know that type
annotations apply to Python code. And I know
On 08/05/2014 08:13 AM, Martin v. Löwis wrote:
For the feature in question,
I find both allow_none and nullable acceptable; noneable is not.
Well! It's rare that the core dev community is so consistent in its
opinion. I still think nullable is totally appropriate, but I'll
change it to
On Mon, Aug 4, 2014 at 10:12 AM, Larry Hastings la...@hastings.org wrote:
It's my contention that nullable is the correct name. But I've been asked
to bring up the topic for discussion, to see if a consensus forms around
this or around some other name.
Let the bike-shedding begin,
/arry
Am 04.08.14 09:12, schrieb Larry Hastings:
It's my contention that nullable is the correct name. But I've been
asked to bring up the topic for discussion, to see if a consensus forms
around this or around some other name.
I have personally no problems with calling a type nullable even in
Argument Clinic converters specify how to convert an individual
argument to the function you're defining. Although a converter could
theoretically represent any sort of conversion, most of the time they
directly represent types like int or double or str.
Because there's such variety in
On Mon, Aug 4, 2014 at 12:12 AM, Larry Hastings la...@hastings.org wrote:
Several people have said they found the name nullable surprising,
suggesting I use another name like allow_none or noneable. I, in turn,
find their surprise surprising; nullable is a term long associated with
exactly
On 8/4/2014 12:35 AM, Stephen Hansen wrote:
On Mon, Aug 4, 2014 at 12:12 AM, Larry Hastings la...@hastings.org
mailto:la...@hastings.org wrote:
Several people have said they found the name nullable
surprising, suggesting I use another name like allow_none or
noneable. I, in turn,
Hi!
On Mon, Aug 04, 2014 at 05:12:47PM +1000, Larry Hastings la...@hastings.org
wrote:
nullable=True, which means also accept None
for this parameter. This was originally intended for use with
strings (compare the s and z format units for PyArg_ParseTuple),
however it looks like we'll have
On 4 Aug 2014 18:16, Oleg Broytman p...@phdru.name wrote:
Hi!
On Mon, Aug 04, 2014 at 05:12:47PM +1000, Larry Hastings
la...@hastings.org wrote:
nullable=True, which means also accept None
for this parameter. This was originally intended for use with
strings (compare the s and z format
Le 04/08/2014 03:35, Stephen Hansen a écrit :
Before you say the term 'nullable' will confuse end users, let me
remind you: this is not user-facing. This is a parameter for an
Argument Clinic converter, and will only ever be seen by CPython
core developers. A group which I
I admit I spent the first half of the email scratching my head and trying
to figure out what NULL had to do with argument clinic specs. (Maybe it
would mean that if the argument is not given in some appropriate way then
we set the corresponding C variable to NULL?) Finding out you were talking
On 08/04/2014 05:46 PM, Glenn Linderman wrote:
There remains, of course, one potential justification for using
nullable, that you didn't make 100% clear. Because argument clinic
is it is all about clearly defining the C-side of how things are done
in Python API's. and that is that C uses NULL
On 08/04/2014 12:12 AM, Larry Hastings wrote:
It's my contention that nullable is the correct name. But I've been asked to
bring up the topic for discussion, to
see if a consensus forms around this or around some other name.
Let the bike-shedding begin,
I think the original name is okay,
On Mon, Aug 4, 2014 at 12:57 PM, Ethan Furman et...@stoneleaf.us wrote:
'allow_none' is definitely clearer.
I disagree. Unlike nullable, allow_none does not tell me what happens
on the C side when I pass in None. If the receiving type is PyObject*,
either NULL or Py_None is a valid choice.
Le 04/08/2014 13:36, Alexander Belopolsky a écrit :
On Mon, Aug 4, 2014 at 12:57 PM, Ethan Furman et...@stoneleaf.us
mailto:et...@stoneleaf.us wrote:
'allow_none' is definitely clearer.
I disagree. Unlike nullable, allow_none does not tell me what
happens on the C side when I pass in
On Mon, Aug 4, 2014 at 1:53 PM, Antoine Pitrou anto...@python.org wrote:
I disagree. Unlike nullable, allow_none does not tell me what
happens on the C side when I pass in None. If the receiving type is
PyObject*, either NULL or Py_None is a valid choice.
But here the receiving type can be
On 08/05/2014 03:53 AM, Antoine Pitrou wrote:
Le 04/08/2014 13:36, Alexander Belopolsky a écrit :
If the receiving type is PyObject*, either NULL or Py_None is a valid
choice.
But here the receiving type can be an int.
Just to be precise: in the case where the receiving type *would* have
Le 04/08/2014 14:18, Larry Hastings a écrit :
On 08/05/2014 03:53 AM, Antoine Pitrou wrote:
Le 04/08/2014 13:36, Alexander Belopolsky a écrit :
If the receiving type is PyObject*, either NULL or Py_None is a valid
choice.
But here the receiving type can be an int.
Just to be precise: in
30 matches
Mail list logo
