On Fri, Mar 3, 2017 at 1:35 PM, Michel Desmoulin <desmoulinmic...@gmail.com> wrote:
> > > Le 03/03/2017 à 22:21, Chris Barker a écrit : > > On Fri, Mar 3, 2017 at 12:21 PM, Sven R. Kunze <srku...@mail.de > > <mailto:srku...@mail.de>> wrote: > > > >> For my part, I think casting a list to a dict is often the RIGHT > >> way to address these issues. > > > > You can't be serious about this. Especially because it would negate > > your response to Ed "conditional on a len() call is the way to go". > > Now you tell people to use "convert to dict". > > > > > > I am serious. It depends on the use case. If the data are an > > But that's the all problem isn't it? > > Since the start of the discussion, contesters have been offering > numerous solutions, all being contextual and with gotchas, none being > obvious, simple or elegant. > > The best is still try/except. > Which really isn't a big deal if you use it in one or two places. If you use it everywhere, it's not too hard to roll your own helper function. > > "There should be one obvious way to do it" right? > > Plus Sven already estimated the implementation would not be very hard. > So we have one obvious solution to a problem that: > > - several professional programmers said they have > - has a similar API in another built-in > You state that like it's a good thing ;-). I'm not quite so sure. > - has currently no elegant solutions > > The proposal is actionable, the cost of it seems low, and it's not > remotely controversial. > It seems to be pretty controversial to me :-). > > Honestly what evil would happen if it's get accepted ? Lots of things. For one thing, when scanning a function, if I see something with a `.get` method I generally think that it is probably a Mapping. Obviously that assumption may be wrong, but it's at least a good place to start. If this gets accepted, that's no longer a clear starting assumption. It breaks backward compatibility (in small ways). People might be relying on the presence/absence of a `.get` method in order to make their function polymorphic in some convoluted way which would break when this change is introduced. (I'm not saying that would be a good programming design idea -- and it might not hold water as an argument when real-world usage is looked at but it should be at least investigated before we claim that this change isn't going to hurt anybody). It's also not clear to me why we should be singling out `tuple` and `list`. Why not `str`, `bytes` and other sequences? Maybe it isn't that useful on those types, but I'd argue that it's not really useful on `tuple` either other than to keep the "`tuple` is an immutable `list`" paradigm. > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
