Suggestion for a "data" object syntax
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Tue May 8 11:20:37 EDT 2018
On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote:
>> Last time you brought up this idea, you were told that it is ambiguous.
>> Using whitespace alone, it is impossible to distinguish between
>>
>> a + b
>>
>> and
>>
>> a + b
>>
>>
>> Can you see the difference? Of course not. That's the whole point. It
>> is ambiguous. The first is a single item consisting of a plus b, and
>> the second is two items consisting of a, following by unary plus b.
>
> Can you be more precise what issue are you addressing?
Was I not clear enough the first time?
When you write "a + b" it is impossible for either the human reader or
the interpreter to tell whether that is meant to be two items separated
by white space ("a" and "+b") or a single item ("a+b").
The same applies to "a - b".
There is no acceptable work-around or fix for this.
* It is not acceptable to prohibit whitespace between unary operators
and their operand;
* or to require spaces rather than tabs between binary operators
and their operands;
* or to make a subtle semantic difference between tabs and spaces
of this sort.
Unix "make" files require tabs rather than spaces, and it is a constant
source of bugs and frustration.
> Last time and
> this time I told it uses TAB character to separate elements.
That's not my recollection. As I remember it, it was *your* idea to use
tab characters, and everyone told you that was not an acceptable work-
around.
Who told you to use tab characters? It would not have been any of the
core developers. Many of them would rather ban tabs than require them.
>> There's also the problem that your syntax requires the *invisible*
>> difference between tabs and spaces to be treated as syntactically
>> meaningful.
>
> What editor do you use? My editor can toggle tabs highlighting as
> arrows, and I suppose almost any editor has good support for
> highlighting of characters by search, etc. For NPP there are even
> plugins like Regex helper.
Using a particular editor is not and will not be a mandatory requirement
for Python.
[...]
> So you would prefer this:
>
> L = (
> (a, 1),
> (b, 2),
> (c, 3),
> (foobar, 4))
>
> over this:
>
> L === T/T:
> a 1
> b 2
> c 3
> foobar 4
>
> Right?
I am amused that you have obviously gone to a lot of trouble to carefully
line up the columns, and yet they aren't even aligned -- "foobar" extends
into the second column, pushing the "4" out to the right.
There is no doubt that the first is HUGELY better:
- it uses the standard = assignment operator, not a
special "===" operator;
- there's no cryptic and mysterious "T/T" code which looks like
you are dividing T by T;
- the first one allows you to write it as a single line:
L = ((a, 1), (b, 2), (c, 3), (foobar, 4))
instead of wasting vertical space;
- the first one is unambiguous while the second is ambiguous;
- the first one can include nested data structures, while
the second cannot.
There is only one advantage to the second format. It gives bad
programmers a justification to waste time while pretending to be working,
as they carefully align their columns, then realign them each time the
data changes.
> Your issues with tabs aside, I think it is impossible to ignore
> the the readability improvement.
An interesting philosophical conundrum... is it possible to ignore
something which isn't there?
If there is no elephant in the room, and nobody mentions it, are they
ignoring it?
--
Steve
More information about the Python-list
mailing list