Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Nick Coghlan wrote: On Sun, Jul 15, 2012 at 9:18 AM, Benjamin Peterson wrote: Open questions == There are two open questions for this PEP: * Should ``list`` expose a kwarg in it's constructor for supplying a length hint. * Should a function be added either to ``builtins`` or som

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, Jul 15, 2012 at 6:21 PM, Steven D'Aprano wrote: > I suggest: > > * object (and hence all other types that don't explicitly override it) > should have a __length_hint__ that raises TypeError; We can keep it simpler than that just by changing the order of the checks. > * __length_hint__

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Alex Gaynor, 15.07.2012 07:20: > there's no way for the __lenght_hint__ to specify that > that particular instance can't have a length hint computed. e.g. imagine > some sort of lazy stream that cached itself, and only wanted to offer a > length hint if it had already been evaluated. Without an e

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, 15 Jul 2012 18:47:38 +1000 Nick Coghlan wrote: > > > * __length_hint__ should be allowed to return None to indicate "don't know" > > or -1 to indicate "infinite". > > > > Presumably anything that wishes to create a list or other sequence from an > > object with a hint of -1 could then r

Re: [Python-Dev] cpython: Take the first step in resolving the messy pkgutil vs importlib edge cases by

On Sun, 15 Jul 2012 10:10:07 +0200 (CEST) nick.coghlan wrote: > > int > +set_main_loader(PyObject *d, const char *filename, const char *loader_name) > +{ This function should be static. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net _

Re: [Python-Dev] cpython: Actually initialize __main__.__loader__ with loader instances, not the

On Sun, 15 Jul 2012 11:10:50 +0200 (CEST) nick.coghlan wrote: > tstate = PyThreadState_GET(); > interp = tstate->interp; > -loader = PyObject_GetAttrString(interp->importlib, loader_name); > +loader_type = PyObject_GetAttrString(interp->importlib, loader_name); > +if (loader_

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Antoine Pitrou wrote: The point is that 0 is a legitimate value for a length hint. Simple implementations of __length_hint__ will start returning 0 as a legitimate value and you will wrongly interpret that as "don't know", which kinds of defeat the purpose of __length-hint__ ;) That said, I

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Right, I agree on the value in being able to return something to say "this cannot be converted to a concrete container". I still haven't seen a use case where the appropriate response to "I don't know" differs from the appropriate response to a hint of zero - that is, you don't preallocate, you ju

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Mon, 16 Jul 2012 00:08:41 +1000 Nick Coghlan wrote: > Right, I agree on the value in being able to return something to say "this > cannot be converted to a concrete container". Who would be able to return that, apart from trivial cases like itertools.cycle()? Regards Antoine. -- Software

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Am 15.07.2012 16:22, schrieb Antoine Pitrou: > On Mon, 16 Jul 2012 00:08:41 +1000 > Nick Coghlan wrote: >> Right, I agree on the value in being able to return something to say "this >> cannot be converted to a concrete container". > > Who would be able to return that, apart from trivial cases lik

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Nick Coghlan wrote: Right, I agree on the value in being able to return something to say "this cannot be converted to a concrete container". I still haven't seen a use case where the appropriate response to "I don't know" differs from the appropriate response to a hint of zero - that is, you

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Alex Gaynor wrote: Hi all, I've just submitted a PEP proposing making __length_hint__ a public API for users to define and other VMs to implement: These seems back-to-front. __length_hint__ is *used* by the VM, not provided by it. It should be part of the object model, rather than the API.

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, Jul 15, 2012 at 10:39 AM, Mark Shannon wrote: > Nick Coghlan wrote: > >> Right, I agree on the value in being able to return something to say >> "this cannot be converted to a concrete container". >> >> I still haven't seen a use case where the appropriate response to "I >> don't know" di

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Am 15.07.2012 16:39, schrieb Mark Shannon: > 1. Don't implement it at all. > > 2. Implement __length_hint__() but don't want to return any value. >Either raise an exception (TypeError) -- As suggested in the PEP. >or return NotImplemented -- my preferred option. How is this different from

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Brett Cannon wrote: On Sun, Jul 15, 2012 at 10:39 AM, Mark Shannon > wrote: Nick Coghlan wrote: Right, I agree on the value in being able to return something to say "this cannot be converted to a concrete container". I still haven't seen a

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, 15 Jul 2012 16:33:23 +0200 Christian Heimes wrote: > Am 15.07.2012 16:22, schrieb Antoine Pitrou: > > On Mon, 16 Jul 2012 00:08:41 +1000 > > Nick Coghlan wrote: > >> Right, I agree on the value in being able to return something to say "this > >> cannot be converted to a concrete container

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, 15 Jul 2012 16:08:00 +0100 Mark Shannon wrote: > > What should happen if I am silly enough to do this: > >>> list(itertools.count()) > > This will fail; it should fail quickly. Why should it? AFAIK it's not a common complaint. You said it yourself: it's a silly thing to do. Regards A

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Sun, Jul 15, 2012 at 8:08 AM, Mark Shannon wrote: > Brett Cannon wrote: > >> >> >> On Sun, Jul 15, 2012 at 10:39 AM, Mark Shannon > > wrote: >> >> Nick Coghlan wrote: >> >> Right, I agree on the value in being able to return something to >> say "this c

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Mark Shannon wrote: So how does an iterator express infinite length? The suggestion was it should return -1. What should happen if I am silly enough to do this: >>> list(itertools.count()) This will fail; it should fail quickly. That depends on your OS. I've just tested it now on Linux

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Mon, Jul 16, 2012 at 1:55 AM, Steven D'Aprano wrote: > (I expect the difference in behaviour is due to the default ulimit under > Debian/Mint and RedHat/Fedora systems.) Possibly also virtual memory settings. Allocating gobs of memory with a huge page file slows everything down without raising

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Antoine Pitrou wrote: First, you can't implement __length_hint__ for a generator, which is the preferred (the most practical) way of writing iterators in pure Python. Limitations of generators are no reason for not improving iterators which are not generators. __length_hint__ already exists;

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Mon, 16 Jul 2012 02:00:58 +1000 Chris Angelico wrote: > On Mon, Jul 16, 2012 at 1:55 AM, Steven D'Aprano wrote: > > (I expect the difference in behaviour is due to the default ulimit under > > Debian/Mint and RedHat/Fedora systems.) > > Possibly also virtual memory settings. Allocating gobs o

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Mon, 16 Jul 2012 02:21:20 +1000 Steven D'Aprano wrote: > > > My conclusion is that an infinite iterator is a documentation issue. > > Just tell the user that it doesn't stop, and let them shoot themselves > > in the foot in they want to. > > Buffer overflows are a documentation issue. Just te

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Steven D'Aprano wrote: With a length hint, we could strengthen that promise: "if __length_hint__ returns a negative number, list, tuple and set will fail immediately with MemoryError" which I think is a good safety feature for some things which cannot possibly succeed, but risk DOSing your

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Nick Coghlan writes: > Right, I agree on the value in being able to return something to say "this > cannot be converted to a concrete container". > > I still haven't seen a use case where the appropriate response to "I don't > know" differs from the appropriate response to a hint of zero - t

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

On Jul 16, 2012 1:52 PM, "Stephen J. Turnbull" wrote: > The point is that I don't really see the value in returning a precise > estimate that cannot be relied on to be accurate. OK, Python is a > "consenting adults" language, but returning an integer here seems like > invitation to abuse. Becaus

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Stephen J. Turnbull wrote: The point is that I don't really see the value in returning a precise estimate that cannot be relied on to be accurate. OK, Python is a "consenting adults" language, but returning an integer here seems like invitation to abuse. Since __length_hint__ already exists a

Re: [Python-Dev] PEP 0424: A method for exposing a length hint

Mark Shannon, 15.07.2012 16:14: > Alex Gaynor wrote: >> CPython currently defines an ``__length_hint__`` method on several types, >> such >> as various iterators. This method is then used by various other functions >> (such as ``map``) to presize lists based on the estimated returned by > > Don't