A counter-proposal to __future__ in PEP 236

[Martin von Loewis]

"Tim Peters" <tim.one at home.com> writes:

> I don't.  "__future__" screams "Deep Magic" because of the double
> double-underscores; it *is* a perfectly vanilla import statement at runtime;
> the word "future" helpfully suggests temporality; it works with all existing
> tools today without change (so it's not confusing even the stupidest of them
> <0.1 wink>)

No, it doesn't. Python 2.1 does not introduce __future__ alone, it introduces

from __future__ import nested_scopes

I can enumerate a number of tools which will be confused (i.e. they'll
operate in a way which is incorrect given what they were designed to
do) - tools looking at or producing byte code being the most prominent
cases.

> > directive nested_scopes
> 
> Which loses all of that.

"all of that" now being the meta information of whether nested scopes
are on-by-default? Yes, that meta information is not available when
using directives.

> I really dislike that
> 
>     directive nested_scopes
> 
> *looks* exactly the same as
> 
>     directive favor_space

So it is the keyword that bothers you? I can propose a different syntax, e.g.

incompatible_language_change nested_scopes

(which would add another keyword incompatible_language_change)

or

directive incompatible_language_change nested_scopes

(which wouldn't - the latter syntax is already supported in my parser
patches). incompatible_language_change is meant as a placeholder;
not speaking English as a first language means that I obviously fail
to propose keywords that sound right to people.

> > In this implementation, directive is only considered as a keyword if
> > it appears at the beginning of the module.
> 
> In that case it's too feeble for a pragma facility; e.g., perhaps I want to
> optimize one method for space but another for time.

With that patch, it is not possible to specify optimization for
time. However, the patch can be certainly extended in that way, e.g. to say

directive optimize_for_time foo

Whether or not that directive still has to appear at the beginning of
the source file would be an issue of the PEP proposing such a pragma;
as would be the debate whether that should be specified through a
directive, or, say, through a function attribute.

> Or perhaps I want to specify that one class in a module uses
> traditional dicts for its namespace, but another freezes its
> attributes into integer-indexable vectors at compile-time.

I don't see your point; I have to admit I can't even follow this
example.

> Etc.  A usefully general pragma facility can't be restricted to the
> top of the module, because not all useful pragmatic choices apply to
> an entire module.

Introduction of the directive keyword needs a transition
mechanism. When other uses are found, that restriction might need to
be dropped. According to PEP 5, a transition period is necessary;
starting today would be better than starting with the next release
(since in Python 2.1, the directive won't be used for anything but
requesting nested scopes).

Of course, other parsing techniques could allow to drop this
restriction even today; e.g. allowing 'name name' at indent 0, iff the
first name is 'directive'.

> Make it general enough to be useful, and it will get hairier than that.  Bite
> the bullet:  if you want a new statement, make directive a reserved word.

It *is* a reserved word. However, PEP 5 requires a transition period,
so the reservation is not enforced in Python 2.1.

> Then we can introduce it via
> 
>     from __future__ import directive_is_reserved
> 
> in the release before it breaks code <0.7 wink>.

I knew somebody would propose that; I didn't guess it would be you...

> Note that it's also not enough to allow just one or two optional tokens
> following "directive".

Is it not?

> One of the primary reasons no pragma facility ever got into Python
> is that in previous attempts nobody could agree on syntax that *was*
> sufficiently general (as a hint of the horrors you're signing up
> for, note that "optional static typing" fits-- because of the
> "optional" part --into a pragma framework; and once people realize
> that, they're going to hijack your proposal into an
> overly-generalized mess too).

I see that differently. First, I think it is quite general, as it
allows an arbitrary atom following the directive's name (e.g. a
dictionary). Furthermore, it is not necessary to agree it is general
enough for all unforeseen needs - it is sufficient if it is necessary
for today's needs, and perhaps for the foreseen ones.

> IMO it would be *much* better for everything *except* incompatible language
> changes, for which latter purpose I dislike it.  The future_statement is
> specifically aimed at the latter, and I believe will support it very well.

If you look at it carefully, you find that it does not "support
incompatible language changes". In the proposed use for nested scopes,
it actually does not - there is no incompatible change. The
incompatible change will occur when nested scopes are activated by
default, at which time the future import is not needed. Instead, it is
a boolean switch for an optional language feature.

So you seem to say that language evolution will occur in terms of
boolean switches; something which I cannot predict accurately.

> sell-it-on-its-real-merits-ly y'rs  - tim

I'm certain that supporting binary switches is one of its merits...

Regards,
Martin