wrote:
> Elias,
> I'm a little confused about what you're suggesting. You want to have a
> Mapping that does not supply a keys method? What use case motivated your
> proposal?
>
>
> On Mon, Sep 10, 2018, 7:04 PM Elias Tarhini wrote:
>
>> This has been bouncing ar
This has been bouncing around in my head for a while regarding the
requisite keys() method on mappings:
How come the ** unpacking operator, a built-in language feature, relies on
a non-dunder to operate?
To me, I mean to say, requiring that classes implement keys() – a method
whose name is
Apologies for my initial response. Looks like I failed to expand the
initial email fully, which would have shown me the following :)
> Of course this would still not help for names of functions that might be
imported directly (do people write 'from numpy import where'?).
-- I do think the
I like it! The obvious question, though: How would "*from package import
keyword*" be handled, if not simply by SyntaxError? Would *from package
import keyword as keyword_* be allowed?
In a similar vein, what would happen with stdlib functions like
operator.not_? The thought of writing
