What does Python compatibility mean? #106
joshuataylor
started this conversation in
General
Replies: 2 comments
-
Supporting slicing should be trivial to add and I think it’s within the scope of this. I would try to mirror the parsing logic of Jinja2 as close as possible. The parser is quite similar in design between the two. What I would do however is implement it slightly differently than in Jinja in terms of what it expands to. I would create a value out of the slice expression (eg: a |
Beta Was this translation helpful? Give feedback.
0 replies
-
I changed my opinion on the way slices should be implemented to make the object model simpler. You can only slice lists and strings but for that it doesn’t require the value to gain a new primitive. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi!
Thought I would turn this into a discussion instead of an issue.
In the compatibility README, it mentions that Python methods are not supported.
Does this include slicing?
I know this is a filter, but doing string and list splitting like this (copied from my test):
Is super handy, and seems to be widely used.
What are your thoughts around this? This seems a bit messy to implement in the parser, where in In
parse_postfix()
, inToken::BracketOpen
:We have to...
:-32
GetItem
. If not, and the next character is a colon, we check if the next value is NOT a bracket end, if it is we know we can useparse_expr
to get the second value.4a. If it's not a colon, parse as a GetItem
The compiler for
Expr::Slice
is pretty straight forward, we just check if it has a first/second item and compile each expr. Then compile the general expression after that.VM becomes a bit more tricky, as we want to support both
ValueRepr::String
andValueRepr::Seq
. We need to cover a few edge cases here, but it's pretty straight forward.Beta Was this translation helpful? Give feedback.
All reactions