[Python-ideas] An Alternate Suite Delineation Syntax For Python? (was Re: [Python-Dev] [PATCH] Adding braces to __future__)

[Mike Meyer]

On Sun, 11 Dec 2011 09:44:17 +0100
Masklinn <masklinn at masklinn.net> wrote:
> On 2011-12-11, at 01:16 , Mike Meyer wrote:
> > A minor improvement in just that one method, but it will show up in
> > every generate method of every class, making it significant in total.
> If users are not supposed to read the generated code, why not generate
> pyc files directly? That would avoid the issue would it not?

Users generally aren't expected to read generated code. It's pretty
ugly for systems that generate python now.

The reason you generate python instead of pyc is that backward
compatibility of python source is a priority for python development,
so with a little care your generated code will work across multiple
versions of python. The same is not true for byte code files (and if
that's changed with 3.x, I couldn't find anything saying so), so your
code generator is liable to depend on the version of the target python
interpreter.

On Sun, 11 Dec 2011 12:55:51 +1100
Steven D'Aprano <steve at pearwood.info> wrote:
> Mike Meyer wrote:
> 
> That's hardly an onerous requirement. As you show, the two code snippets are 
> almost identical, except that the indent version takes an explicit level 
> argument, while your braces version neglects to close suites at all. A fair 
> comparison should show the close-suite code, even if it is only a single line.

Correct. I thought it, but forgot to add it.

> > A minor improvement in just that one method, but it will show up in
> > every generate method of every class, making it significant in total.
> I wouldn't use the term "minor improvement" so much as "trivial difference".

I wouldn't refer to any change that involves adding a variable as
"trivial". Especially one that's part of the API. Part of the issue is
that I understated the problem - this change is ubiquitous, and large
enough that it adds up.

> But even if I grant that it is an improvement, how many generate methods do 
> you expect there to be?

Because it's in the API, not only does this affect every generate
method, but anything that might call them. You have to thread the
indent level to anything that might want to write code. It might be
better to make it a global (i.e. - instance or module variable) value
of some sort.

Basically, this "trivial difference" needs to be taken into
consideration when designing the system architecture.

You came close to the real reason for rejecting this here:

> When you defend a feature on the basis that "people will hardly ever use it, 
> except for trivial pieces of code that don't need it", that speaks volumes.

Two use cases are at or over the edge. Writing in something that lets
you embed python code? You arguably aren't writing python. Writing
code that generates python? *You* may not be writing python at all,
even if your code is.

That leaves the case of turning statements into expressions. While
suggestions/requests for similar things keep coming up, they aren't
all that frequent, and the tools we have for that have been acceptable
so far.

While Nick is to be congratulated for providing a solution to that
problem that's much better than it's predecessors, I don't think it's
worth the complexity it looks like it would require in the compiler.

   <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org