Python Forum

i love how python syntax stays simple through many complicated nestings. that works for code but not for data. lists end with a ] and dictionaries end with a } even if the data is spread over multiple lines. i wish the ending could be made optional in multiline data where nested data is indented.

for example:

modes = {
    'r': 4,
    'w': 2,
    'x': 1,
names = [
    'foo',
    'bar',

and maybe the , is not needed in these cases, too.

All this was set in stone thirty years ago. It would be a new language...

it could be an incremental change by being optional. i don't see any cases where leaving out the ending ] or } would present any meaning different than my suggestion. even leaving out the , at the end of a line presents no different meaning. it's either an error (no meaning at all) or it can be understood.

modes = {
    'r': 4
    'w': 2
    'x': 1
names = [
    'foo'
    'bar'

there is no ambiguity. what else can it mean? if we choose to let it have the one and only meaning it could have, how would it still not be python? of course it is a "major" change, so it cannot be part of python 3.x.

i could argue that f-strings should have been done in 4.0.

Here is the first issue:

>>> [
...     'foo'
...     'bar'
... ]
['foobar']

so the commas have to be there since this is a case where it ignores end of line.

I have simple question: why?

I think it'd be easier to make a new file format, that sort of looked like python/json, and you could write a simple parser to convert it into actual python data types.

(Jan-05-2020, 07:16 PM)perfringo Wrote: [ -> ]I have simple question: why?

why what?

originally i just wanted to make data, in a text-like form, look like python looks by doing nesting through indentation and having unindent be the end of nesting. i have been coding a lot stuff that does cloud API calls with so much similarity that i could express the many different calls by just different dictionaries used a as method keyword indexes. i started having lists of dictionaries and from there even more, all done through the same code making the actual call. while coding all this data, i realized my code was going back to having incremental symbol based unindenting. each list ends with ]. each dictionary ends with }. those have to be somewhere so it meant either a new line or appending everything to the last line of data.

---

then i noticed so many data lines ending ,. so i thought about removing those. that would have to be a totally new format.