In article <6b4065b0-6af7-4aff-8023-40e5d521f...@v19g2000yqn.googlegroups.com>,
Luis Gonzalez wrote:
>
>Yes, I know the python approach is to use built-ins.
>But wouldn't it be cool if we could do mydict.values().tolist()
>instead?
>It would be more regular and intuitive and readable from an OO p
Hi Larry
I actually feel this is a bad idea, (that is making list() a method of
all iterators)
because quite often iterators are created that don't end.
What happens then, is you have a method that will intentionally cause
you to run out of memory
or you exclude it from such iterators (creating i
I see list(x.f()) as like x.f().iter().list(), where "list()"
is a method of all "iterator" objects, and "iter()" is a method
of all "iterable" objects, and whatever object is returned by
x.f() is of a type which conforms to the "iterable" interface.
I am not saying this is the way things /should/
Hi Aaron
I personally don't understand how somedict.values().to_list() is
actually preferable to
list(somedict.keys())
In the standard python idiom I am constructing a new object (which I
can control the type of) using a standard language mechanism (and I
can substitute list with set or for that
On Sun, 29 Mar 2009 08:39:10 +0100, Aaron Brady
wrote:
I guess there are two arguments for the change.
1. Flat is better than nested.
I don't think that's really what this is refering to.
2. It interferes with the way people read text.
Insert "some" before "people" and I'd have to ag
On Mar 27, 7:26 pm, Terry Reedy wrote:
> Luis Gonzalez wrote:
> > Yes, I know the python approach is to use built-ins.
> > But wouldn't it be cool if we could do mydict.values().tolist()
> > instead?
>
> Should we also give every collection a .toset(), .tofrozenset(),
> .totuple(), and .todict() m
Luis Gonzalez wrote:
Yes, I know the python approach is to use built-ins.
But wouldn't it be cool if we could do mydict.values().tolist()
instead?
Should we also give every collection a .toset(), .tofrozenset(),
.totuple(), and .todict() method? This way lies the madness of
combinatorial exp
Yes, I know the python approach is to use built-ins.
But wouldn't it be cool if we could do mydict.values().tolist()
instead?
It would be more regular and intuitive and readable from an OO point
of view.
In my oppinion, this would be cleaner.
Built-ins used like this look like an early decission ma
On Fri, Mar 27, 2009 at 9:58 AM, Aaron Brady wrote:
> The suggestion is entirely a "look and feel" observation. In an
> interactive session, to examine the contents of a dictionary I've just
> created, I need to type list(_), and lose the previous return value.
> It's a better for my train of tho
On Mar 27, 7:14 am, alex23 wrote:
> On Mar 27, 3:44 pm, Aaron Brady wrote:
>
> > Is there a possibility of the dict_values, dict_items, and dict_keys
> > objects growing a 'tolist' method? It's one of those little things
> > that contributes to one's user experience.
>
> Probably not, because th
On Mar 27, 3:44 pm, Aaron Brady wrote:
> Is there a possibility of the dict_values, dict_items, and dict_keys
> objects growing a 'tolist' method? It's one of those little things
> that contributes to one's user experience.
Probably not, because the Python approach is to use the builtins. I'm
no
Hi.
Is there a possibility of the dict_values, dict_items, and dict_keys
objects growing a 'tolist' method? It's one of those little things
that contributes to one's user experience.
P.S. Yes, yes, I know, -1.
--
http://mail.python.org/mailman/listinfo/python-list
12 matches
Mail list logo
