PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

[Peter J. Holzer]

On 2020-03-19 08:05:18 -0700, Dan Stromberg wrote:
> On Thu, Mar 19, 2020 at 7:47 AM Peter J. Holzer <hjp-python at hjp.at> wrote:
> > On 2020-03-19 14:24:35 +0000, Rhodri James wrote:
> > > On 19/03/2020 13:00, Peter J. Holzer wrote:
> > > > It's more compact, especially, if "d" isn't a one-character variable,
> > > > but an expression:
> > > >
> > > >      fname, lname =
> > > >        db[people].employee.object.get(pk=1234)[['first_name', 'last_name']]
> > > >
> > > > vs.
> > > >
> > > >      fname = db[people].employee.object.get(pk=1234)['first_name']
> > > >      lname = db[people].employee.object.get(pk=1234)['last_name']
> > >
> > > I have to say I don't think that's more compact at all.  It's too wide
> > > to be compact.
> >
> > But 83 characters is still more compact than 121 characters.
> >
> 
> It's smaller (in a way), but is it more clear?

"Compact" is not the same word as "clear". I was claiming that it was
more compact, not that it was more clear. You can argue that it is less
clear, but you (well, Rhodri) can't redefine the meaning of "compact".

> Compare to regular expressions: they're small, but they tend to be a
> mess.

Usually because what they describe is complex. If you had to write a
matcher equivalent to a complex regexp by hand using basic string
operations, it would probably be harder to read. That would be many
lines of Python code and the reader would have to keep a lot of state
in their head while reading it.

So I would say that regular expressions are generally more clear than
the equivalent long-hand code.

This is similar to algebraic expressions: Have you ever tried to read a
mathematical paper from before the time the current notation (which we
of course now all learn in school) was invented? Long, convoluted
sentences instead of what can now be written as a short formula.

So sometimes "more compact" implies "clearer". Not always of course. The
Obfuscated C Code Contest is full of code which is very short but also
very hard to understand.

Would it be clearer in this case? I think so. Especially if you have
several keys to extract. In Python I would probably use a list or dict
comprehension, which probably isn't much longer, but it is an explicit
loop, so the reader has to think about the loop logic, it isn't "just
built in".


> Remember that the complexity of a programming a language varies with the
> square of its number of features.  Complex languages are not good
> languages.

I somewhat disagree with this. Languages which are too simple (think
"Turing machine") make it very hard to write useful programs, and
probably even harder to read them. As languages aquire more useful
features, they get easier to use and easier to read. At some point this
reverses again, especially if features are inconsistent or interact in
surprising ways. However, while you can just not use some features of a
language which is too complex for you, you can't easily extend a
language which is too simple.

> A good language has a small core and extensibility via
> libraries.

This would actually be a feature of the (standard) library.

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20200319/3cf79a73/attachment.sig>