[Python-ideas] Adding "Typed" collections/iterators to Python
nathan.alexander.rice at gmail.com
Mon Dec 19 05:31:31 CET 2011
My apologies for the direct email. Gmail is somewhat retarded when it
comes to the python lists, and I don't always remember to change the
>> Nathan Rice <nathan.alexander.r... at gmail.com> wrote:
>> I fail to see how the clunky act of importing a function most python
>> users probably don't know exists then creating another new function is
>> better than chaining one or two method calls.
> If you consider importing functionality 'clunky', then we're already
> at an impasse over what we consider to be 'elegant'. I also don't
> believe that user ignorance of standard library features mandates the
> inclusion of _everything_ into the base langauge.
There are a lot of warts in the standard library, (thus Py3). I'm all
for importing things that deserve to be in their own namespace with
other, similar things. I'm not for having to import something that is
needlessly more verbose than solutions that are available without an
import (see comprehensions). If you were just trying to map a single
argument function I'd say "yeah, go for it" but from my perspective,
that code is square peg, meet round hole.
>> Just because you CAN do something already doesn't mean you can do it in
>> an elegant way.
> And just because YOU find it inelegant doesn't make it so. I find
> using operator & functools _far_ clearer in intent than using lambda,
> _and it works right now_, which was the point I was trying to make
> here. You wrote unreadable code and then tried to use that as an
> argument for your idea. Breaking down complex statements into clearer
> parts isn't a radical notion; cramming more and more functionality
> onto a single line isn't something to which Python needs to aspire.
What makes a solution elegant? I'd say having access to a cross
cutting paradigm that is backwards compatible, reduces code while
making it more readable and provides opportunities to improve the
toolchain is more elegant. At any rate, I could care less about the
lambda, that is a strawman.
>> If the only metric was "can we do this?" we would all still be using Fortran.
> And if it's "I don't want to have to code to deal with this, let the
> language change to do it", you end up with PHP.
Well, that would be true if you also added "I don't care if the
language is internally consistent in any way" and a few others, but
I'm not here to bash PHP.
More information about the Python-ideas