Re: [Python-Dev] sum(...) limitation

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 wrote: >>However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists. > hm could this be a pure python case that would profit from

Re: [Python-Dev] sum(...) limitation

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 performanc

Re: [Python-Dev] Surely "nullable" is a reasonable name?

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 the

Re: [Python-Dev] Surely "nullable" is a reasonable name?

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 be

Re: [Python-Dev] sum(...) limitation

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

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On Mon, Aug 4, 2014 at 1:53 PM, Antoine Pitrou 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 an in

Re: [Python-Dev] Surely "nullable" is a reasonable name?

Le 04/08/2014 13:36, Alexander Belopolsky a écrit : On Mon, Aug 4, 2014 at 12:57 PM, Ethan Furman 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 None. If the rec

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On Mon, Aug 4, 2014 at 12:57 PM, Ethan Furman 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.

Re: [Python-Dev] Surely "nullable" is a reasonable name?

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,

Re: [Python-Dev] Surely "nullable" is a reasonable name?

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 N

Re: [Python-Dev] sum(...) limitation

On Sat, Aug 2, 2014 at 1:35 PM, David Wilson 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 providing zero or negat

Re: [Python-Dev] Surely "nullable" is a reasonable name?

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 ab

Re: [Python-Dev] Surely "nullable" is a reasonable name?

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 ho

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 4 Aug 2014 18:16, "Oleg Broytman" 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"

Re: [Python-Dev] Surely "nullable" is a reasonable name?

Hi! On Mon, Aug 04, 2014 at 05:12:47PM +1000, Larry Hastings 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 a use f

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On 8/4/2014 12:35 AM, Stephen Hansen wrote: On Mon, Aug 4, 2014 at 12:12 AM, Larry Hastings > 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

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On Mon, Aug 4, 2014 at 12:12 AM, Larry Hastings 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 this c

[Python-Dev] Surely "nullable" is a reasonable name?

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 variet