New PEP: The directive statement

Martin von Loewis loewis at informatik.hu-berlin.de
Thu Mar 22 04:15:52 EST 2001


hzhu at users.sourceforge.net (Huaiyu Zhu) writes:

> So with this directive PEP, the parallel would be
> 
> directive transitional nested_scope
> directive experimentatal stackless
> directive optional static_type
> directive mandatory string_methods
> 
> Is this correspondence correct?  (You may not agree on the need for other
> directives, but I want to know if the keyword translations are correct.)

That is a possible application. The syntax allows other choices as well,
e.g.

  directive static_type
  directive stackless 0

> 1. It introduces a new syntax while an existing syntax could be reused
>    without much cost.

You mean, import can be reused without much cost? The cost of reusing
import is quite high; it causes irritation among users.

> 2. There is no place for version and documentation info.

That is true.

> So far as I can see, the impetus for directive keyword is that import is a
> run time action, while the __future__ is a compile time declaration.  But is
> it so far a stretch?  All Python __magic__ words go beyond normal meaning.
> Defining __setattr__ will affect more than this method alone.  Having
> __init__.py will cause other modules to be imported.  And so on.

That is what I dislike in the __ convention. Syntactically, they are
identifiers. Semantically, they are reserved words.

> If we look more broadly, in *nix, devices, processes, pipe and others are
> also represented as files.  Would it better to assign special syntax to all
> of them?

Or, taking the analogy further: sockets should be represented as files
as well, to open a socket, you should really open some file, not
invoke a special function. Yet, history shows that the version with
the special API was the successful one, not the version with the files.

Generalization is a dangerous thing: you can too easily cross the
border to over-generalization.

> IMHO, reusing existing syntax is closer to Python than Perl, which
> introduces new syntax for many things that are only slightly different.

Are you saying that activating nested scopes is only slightly
different from importing modules?

Regards,
Martin




More information about the Python-list mailing list