Inline content too restrictive

[Deleted user]

Considering the rendering code dmsl.Template('index.dmsl').render(hello="World")

The following crashes in a template: %p Hello, { hello }

Where %p Hello, {hello} does not.

The whitespace here shouldn't matter to the parser. Also, the PEP-8 states that variables enclosed in dictionaries and tuples should have a space on both ends.

PEP-8 approves: a = { 'foo' : 'bar' } and discourages a = {'foo':'bar'} making this restriction feel unnatural.

[Daniel Skinner]

This is using the builtin python string Formatter. If you open a python console and try

"{ 0 }".format("hi")
"{ hello }".format(hello="World")

You'll notice both of them crash as each are expected to be a dictionary key with whitespace on each end. You can read more about the python string Formatter here.

http://docs.python.org/library/string.html#format-string-syntax

[Daniel Skinner]

Also, you can reference PEP-3101 if you're curious

http://www.python.org/dev/peps/pep-3101/

[Deleted user]

Why should this change... let me count the ways.

1. The restriction is arbitrarily dependent on the implementation.
2. The errors generated are non-obvious.
3. It is a good habit to be whitespace agnostic after initial indentation
4. It follows naturally for people used to PEP-8. (See above)
5. It enhances usability, and friendliness.
6. For the same reason you should also support {hello } and { hello}
7. Designers suck at syntax.

Cheers,
Raymond Chandler III

[Daniel Skinner]

You're barking up the wrong tree. This is using the builtin format function. If you take issue with this, you need to address it with the python development team as any changes they make could then be used in dmsl.

This is high performance C code in python, not dmsl. It's not even a wont-fix, it's a can't-fix. PEP-8 isn't even relevant as this is for string formatting. Review PEP-3101.

Again, this is python's implementation.

As for addressing designer concerns, those are valid and hopefully down the road something can be done to address that.

[Daniel Skinner]

I'm on the road a lot right now, but it this could be accomplished by
extending the Formatter (this is covered in PEP-3101) and overriding the
fmt in the dmsl sandbox, though there might be a little more leg work
involved with dmsl.

But it'd be interesting to offer support since python provides the facility
to override default functionality.

The negatives here are having to handle things like XSS yourself and expect
render times to double.

I don't agree with the initial example given here, but there's valid use
cases (mostly related to security and providing defaults on 2.x for
designers to work with in the future) for needing to override the default
behaviour so I'll create a new issue related.
On Apr 6, 2012 12:39 AM, "Raymond Chandler III" <
[e-mail]>
wrote:

Why should this change... let me count the ways.

1. The restriction is arbitrarily dependent on the implementation.
2. The errors generated are non-obvious.
3. It is a good habit to be whitespace agnostic after initial indentation
4. It follows naturally for people used to PEP-8. (See above)
5. It enhances usability, and friendliness.
6. For the same reason you should also support {hello } and { hello}
7. Designers suck at syntax.

Cheers,
Raymond Chandler III

---

Reply to this email directly or view it on GitHub:
https://github.com/dasacc22/dmsl/issues/26#issuecomment-4991019