<p>There's no way *any* variant of this idea (regardless of spelling) is getting anywhere near the stdlib without a long history on PyPI as a popular templating and code embedding tool. </p>
<p>--<br>
Nick Coghlan (via Gmail on Android, so likely to be more terse than usual)</p>
<div class="gmail_quote">On Dec 15, 2011 5:06 PM, "Ron Adam" <<a href="mailto:ron3200@gmail.com">ron3200@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, 2011-12-15 at 15:25 +1000, Nick Coghlan wrote:<br>
> On Thu, Dec 15, 2011 at 3:09 PM, Ron Adam <<a href="mailto:ron3200@gmail.com">ron3200@gmail.com</a>> wrote:<br>
> > Lets say you are going to past in several locations in a file and those<br>
> > locations may have different indent levels. How would you write that<br>
> > using your suggestion so you don't have to change it in anyway for it to<br>
> > work.<br>
> ><br>
> > With my suggestion, that would just work no matter the source file<br>
> > indent level. (*) All you need is the line numbers to insert it at. I<br>
> > think with your idea, you would also need a place holder of some type.<br>
><br>
> OK, I at least understand what you're trying to do now. However, I<br>
> don't think you have a valid use case. What would a templating<br>
> language based on your notation look like?<br>
<br>
Any program that can patch text files together. As to how it does it,<br>
it probably would use a script of some sort. This would just make it<br>
easier to by offering a way around indenting issues.<br>
<br>
Another use case is it makes transmitting python compatible code easier<br>
in a web page or email. The braces version would do that also. I think<br>
it could make python a bit more attractive for things like that. Where<br>
a app is transmitted and run at the destination. There are still the<br>
security issues to work out, but this would knock down one domino in<br>
that direction.<br>
<br>
For example they don't have to event ways to avoid the white space<br>
munging. Python could be represented as code blocks that might look<br>
like...<br>
<br>
<pycode = ";;; for x in items: \\\ sum = op(x) ;;; if sum > MAX:<br>
\\\ break"><br>
<br>
Except much longer. In this case there isn't a need for it to be<br>
pretty. But there is a need for it to work correctly.<br>
<br>
<br>
I was thinking it might be possible to have the python shell echo the<br>
indent markes in the left side as it scroll lines up. Replacing the<br>
'>>>' and '...' with the respective markes as you enter the lines. And<br>
it could also take these if they are pasted in. Cutting and pasting<br>
from one shell to another could work in that case.<br>
<br>
As far as unglyness goes... is it really that bad? you can leave the<br>
white space in. The indent hints are used not the spaces in this case.<br>
<br>
;;; for x in items:<br>
\\\ sum = op(x)<br>
;;; if sum > MAX:<br>
\\\ break<br>
<br>
And keep in mind that this isn't something you will see in normal use.<br>
It's just available for when its needed. But if you run across code<br>
like this it will still work. Nothing special would need to be done to<br>
make it work.<br>
<br>
> How would you extend it to<br>
> implement multi-line lambdas?<br>
<br>
As I said, it doesn't change the language at all. So extending lambda<br>
is not in the scope of this topic. That would be something new and<br>
should be done separately in any case.<br>
<br>
> If you can't cleanly do those two<br>
> things, who cares if it lets you copy and paste snippets at arbitrary<br>
> points in a Python file? What's the *functional* pay-off for the<br>
> ugliness?<br>
<br>
? See above.<br>
<br>
> (And I freely admit that my suggestion is also quite ugly. However,<br>
> the status quo, with everyone inventing assorted templating languages<br>
> for use with Python that are largely independent of Python itself<br>
> already sucks)<br>
<br>
If it was a big patch to many files, I would say it isn't worth it.<br>
But it would be a very small patch to only one file and wouldn't change<br>
the grammer, ast, or anything else. It's almost free.<br>
<br>
I think it may have a nice benefit for very little effort. But I think<br>
we should just wait a bit and see if there is more interest first.<br>
;-)<br>
<br>
Cheers,<br>
Ron<br>
<br>
<br>
</blockquote></div>