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