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 Sat, Aug 2, 2014 at 1:35 PM, David Wilson dw+python-...@hmmz.org wrote:
Repeated list and str concatenation both have quadratic O(N**2)
performance, but people frequently build up strings with +
join() isn't preferable in cases where it damages readability while
simultaneously
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 Mon, Aug 04, 2014 at 09:25:12AM -0700, Chris Barker wrote:
Good point -- I was trying to make the point about .join() vs + for strings
in an intro python class last year, and made the mistake of having the
students test the performance.
You need to concatenate a LOT of strings to see any
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
Steven D'Aprano schrieb am 04.08.2014 um 20:10:
On Mon, Aug 04, 2014 at 09:25:12AM -0700, Chris Barker wrote:
Good point -- I was trying to make the point about .join() vs + for strings
in an intro python class last year, and made the mistake of having the
students test the performance.
Sat Aug 2 12:11:54 CEST 2014, Julian Taylor wrote (in
https://mail.python.org/pipermail/python-dev/2014-August/135623.html ) wrote:
Andrea Griffini agriff at tin.it wrote:
However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists.
hm could this be a pure python case that
18 matches
Mail list logo
