Why "from __future__" stinks; a counter-offer

[Carlos Ribeiro]

At 16:04 18/03/01 -0500, you wrote:
>Good -- then it will stick out <0.5 wink>.  Double double-underscore names
>are intended to "stick out", btw, and future_statements are intended to be
>temporary.  In that sense, the uglier they are, the more incentive to get rid
>of them ASAP.

Have you ever seen this happen in *any* sufficiently complex system? I'm 
afraid we'll be stuck with this "solution" for a long, long time.

> > Lastly and most importantly, it's not too late to do
> > something saner.
>
>Unclear, although in the absence of a competing PEP it's certain to remain as
>it is, and the last 2.1 beta release is scheduled for this coming Friday (as
>noted in PEP 226)

So thats the matter? Forgive me, I'm pretty new on this list and I may be 
missing something. The lack of a PEP... this sound too much like 
design-by-comitee to me. I agree with the *intent* of the PEP - to keep 
everything nice and documented, and to put some order into the process. 
However I feel that in this case it sounds as a lazy excuse for not 
thinking about a better to solve the problem. It's something like "the PEP 
is everything, lets follow the PEP as-is". Why is it so difficult to write 
or change the existing PEP?

>(...) future_statements are a temporary aid for
>use during a transition period.  "require", "using", "this_code_uses" and
>"feature" all send a wrong message in that respect. "pragma" is
>inappropriate because future_statements are about syntax and semantics, not
>pragmatics.

You are right - the message is important, and this is one of the most 
compelling reason to abandon "import from __future__". It does send the 
wrong message - in fact it does not make any sense (if you were talking 
about "import quantum computing", that's in the future :-). And don't let 
me get started on the relativity aspects, because the "future" is not an 
absolute, defined state - it's going to be differente for every release.

I think that some people got used to the proposed syntax, and as such they 
dont see anything wrong with it. On the other hand, words as "pragma", 
"directive" are not so "fashionable" - they sound too much like C or 
similar stuff. But *lots* of people are not comfortable with the "import 
from __future__ " construction. I'm one of them. And unfortunately I dont 
have the resources to grab the source and actually *do* something about it, 
this rant aside.

Part of my rants are about the name of the module - __future__.py is a bad 
and misleading name in my opinion. One alternative would be to call this 
module __compiler__.py. It's a better name because:

- it is related to the *function* carried out by this module (it is handled 
at compile time, and carries compile-time information)
- it has nothing to do with the perception of time
- it could export other symbols and mappings useful for the script about 
the compile-time environment.

I dont think that this is a real solution to the problem, but it makes it 
look a little better. It is also more consistent and has some prospect of 
being extensible. Also it's a easy change to make now without breaking any 
PEPs or the schedule.


OTHER ISSUES & WEIRD IDEAS

1) A different way to handle the problem is to make the Python compiler 
itself scriptable. However, this is also dangerous, and poses a much bigger 
set of problems. The basic concept is to have a __compiler__ symbol, pretty 
much like the __main__ symbol, except that this one is set only inside the 
compiler. All code inside an if __compiler__: block would be executed 
immediately by the compiler.

2) There is something else bugging me. It is not clear what is the effect 
that "from __future__" has on the compiler. PEP-236 states that this is 
handled at compile time. However the __future__.py module does exist and 
has some information in it. For python applications that get distributed, 
this has a lot of potential side effects. Someone may have the right 
version of the interpreter, but the wrong version of the __future__ module. 
(this is even worse if the compiler is scriptable...) What is going to happen?

3) In some time it may become be impossible to tell which subset of the 
language you are using - for instance, from a code snippet. This is *very* 
important to understand, because we are changing the semantics of the 
language, not the syntax, and it will not be obvious from the context of a 
snippet which "switch" has to be used. (We have to concede that this is 
going to be a problem whenever there is any semantic change - it is just 
impossible to avoid).


Ouch! That was a long rant... going to sleep now :-)



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com