New PEP: The directive statement

[Martin von Loewis]

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

> True, but I've written many harder analyzers + translators for Python, and
> several have been in the distribution for years (e.g., tabnanny.py,
> checkappend.py, most recently reindent.py for 2.1).  So this FUD won't fly.

I wasn't questioning that you *can* write such a tool - I was asking
whether it should work in the way you've been outlining.

> Ah, note that I'm not signing up for writing a general *directive*
> manipulation tool.  That's too open-ended for me.  The tool PEP 236
> hypothesizes is limited to nuking obsolete future stmts, and PEP 236
> is not an open-ended scheme.  The tool is easy because the PEP is
> limited.

My point is that even though you can nuke all obsolete future
statements, it might not be desirable to do so - since the module then
become silently incorrect in an older release, instead of outright
failing.

> I put the assert near the line it's complaining about, because the line it's
> complaining about is the line I want to get rid of someday, and I want the
> assert to tell me that.  Maybe a wordier version would be clearer:
> 
>     assert nested_scopes.getMandatoryRelease() > sys.version_info, \
>          "no more need for the nested_scopes stmt above -- nuke it"

I see. Sounds like a good application of the versioning.

> >> In that case I may very well have an acute need to ship one version
> >> of my source that exploits the new semantics but falls back to an
> >> older & slower module if the compiler it's running under can't play
> >> along.
> 
> > People routinely use sys.*version* for that; I'm really curious
> > whether they'd prefer to investigate other variables instead.
> 
> I think PEP 236 is extremely clear that the release info in __future__.py is
> in sys.version_info format

That is absolutely clear. I was asking you to predict the future: Do
you think that people will prefer to write

  if __future__.nested_scopes.getOptionalRelease() >= sys.version_info:

instead of

  if sys.version_info < (2,1):

> How could it be clearer?  Nobody complained; Barry pointed out that
> he generally uses sys.hexversion (not sys.version) instead, but
> allowed that sys.version_info is easier to read; and I can't imagine
> that anyone in their right mind uses sys.version for stuff like this

I have really no problem with the format of the _Feature members; I
very much like using tuples for versioning, since it is quite elegant.
My question is whether you think that people will use those computed
version numbers instead of hard-coded ones, when comparing to
sys.version_info.

> have-yet-to-hear-a-complaint-from-anyone-using-it<0.6-wink>-ly y'rs  - tim

*Now* you get my question :-)

Martin