[Python-ideas] Fix the DRY problem (was Re: PEP 501 - i18n with marked strings)

[Guido van Rossum]

On Wed, Aug 12, 2015 at 6:02 AM, Andrew Barnert via Python-ideas <
python-ideas at python.org> wrote:

> On Aug 11, 2015, at 19:33, Nikolaus Rath <Nikolaus at rath.org> wrote:
> >
> >> On Aug 11 2015, Barry Warsaw <
> barry-+ZN9ApsXKcEdnm+yROfE0A at public.gmane.org> wrote:
> >> The complicated examples of f-strings I've seen really give me the
> shudders.
> >> Maybe in practice it won't be so bad, but it's definitely true that if
> it can
> >> be done, someone will do it.  So I expect to see "abuses" of them in
> >> the wild.
> > [...]
> >> Which is why I like the scope() and similar ideas.  Something like a
> built-in
> >> that provides you with a ChainMap of the current namespaces in effect.
> The
> >> tricky bit is that you still need something like _getframe()'s depth
> argument,
> >> or perhaps the object returned by scope() -or whatever it's called-
> would have
> >> links back to the namespaces of earlier call frames.
> >
> > You mean instead of allowing expressions inside strings, you want to
> > make it easier for functions to mess with their callers scope?
>
> I think he was proposing an immutable mapping (or at worst one that is
> mutable, but is or at least may be detached copy, a la locals()).
>
> And if he wasn't, it's trivial to change his proposal into one using
> immutable mappings. Which still retains all the benefits for string
> formatting, and does have the problem you raised.
>

If I understand the proposal for scope() correctly, it's just a cleverer
way to spell locals() etc.[1] and that means I don't want it to play any
role in the string formatting proposal.

It also has the same problems as locals(), sys._getframe(), etc., which is
that their presence makes certain optimizations harder (in IronPython IIRC
the creation of frame objects is normally skipped to speed up function
calls, but the optimizer must detect the presence of those functions in
order to disable that optimization). That doesn't mean I'm opposed to it (I
don't have a problem with locals()), but it does mean that I think their
use should probably not be encouraged.

TBH I'm sorry Barry, but whenever someone use DRY as a rallying cry I get a
bad taste in my mouth. The solutions that are then proposed are too often
uglier than the problem. (So I'm glad PEP 498 doesn't mention DRY. :-)

[1] I know it's not just locals(), but it's too much of a mouthful to give
the full definition.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150812/bb716382/attachment.html>