On Fri, May 11, 2018 at 9:39 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Mon, May 7, 2018 at 9:45 PM, Mikhail V <mikhail...@gmail.com> wrote:
>> *Example 1. Multi-line strings*
>>
>> data === S :
>> this is multi-line string
>> escape chars: same as in strings (\\, \\n, \\t ...) ,
>> but "no need to 'escape' quotes"
>
> My reaction #1: why 'S'? Python strings have a name: it's 'str'.
> ...
> My reaction #2: what's the point of this construct? Python already has
> multi-line strings that can be used as expressions, not as statements
> only.
#1. I think passing multiline data structures as arguments
is not especially beautiful. Necessary? I don't know.
#2. What is the point? If introduce the new syntax _at all_,
- the cost of adding some additional common types is less -
IOW worth investigating some options?
About string type id - I agree it may be suboptimal with "S", since
it is not like tuples. But well, there must be something.
In this case:
s = """\
multi line string multi multi line string
multi line string multi line string"""
vs:
s === S:
multi line string multi multi line string
multi line string multi line string
Nothing revolutional, just a bit cleaner and with
an indent (which is not necesserily always a good thing
but IMO a bit more presentable).
The problem though, this will require editors to
modify their lexers for highlighting - this is a problem :/
> My reaction #3: Not a fan of adding an '===' operator. We already have
> '=' and '=='. Javascript is another language that uses '===' to mean
> something completely different from this proposal (it's another
> equality operator) and it's a mess there. Come up with something else.
>
"===" is just the least disturbing one I've come up with while
experimenting. I thought it should start with "=" at least.
E.g.
data =% T :
data =\\ T :
(\\ now is syntaxError: unexpected character after line continuation)
I dont know - frankly I think its too early to start the game of
perfect operator choice.
>> Benefits are easy to see: say I want a tuple of strings:
>>
>> data === T :
>> "foo bar"
>> "hello world"
>> "to be continued..."
>>
>> VS current:
>>
>> data = (
>> "foo bar" ,
>> "hello world" ,
>> "to be continued..." ,
>> )
>>
>> Main problem with the latter are commas, it is not easy
>> to type
>
> In what bizarro world are commas harder to type than tabs? At least if
> I type a comma I know I'll get a comma. If I type a tab then it
> depends on my editor settings what I'll actually get.
Well, in the above case you don't have to type tabs or commas.
As for what character is easier to type : commas or tabs :
I find that Tab key is maybe a bit harder when using together
with upper number row keys - OTOH when using keypad -
it feels easier. On average I think its comparable.
Also if you type commas, usually you want to type
space after a comma, or a Tab ;-)
So Tab maybe will win this race.
>> and, whats more important - hard to notice missing commas.
>
> But it's totally easy to notice missing tabs, right? Not.
**Those are two different things** - commas must be there -
and the issue persists, you want it or not.
I still have feeling that you try to imply that commas have
some role apart from Disambiguation of closely positioned
tokens - that's what they are from reader's POV.
In other words, if inter-token spacing is solid - commas are nothing
but redundant noise.
Do you understand this or not?
Also there was a topic about string lists on 'Ideas' recently -
so thats not only me who notices it.
Issues with input of tabs is more of psychology &
experience I'd say. I haven't problems with that.
Normally I input 2 tabs to make it form a solid whitespace- it
gives me optimal look. And I don't bother too much with
perfect alignment usually.
>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>
> What about T/S? S/T? S/S? Are these allowed?
Not really. The idea is: to identify common cases
and data structures and try to find an optimal
set of ID's to represent them. But the slash
indicates that it's 2D case - so this one
is sort of explicit sign of higher dimension.
>
> Also, why is there a division operator here?
"slash"
>
>> 1 2 3 "hello"
>> a b c + d e f
>>
>> is a synonym for:
>>
>> data = (
>> (1, 2, 3, "hello") ,
>> (a, b, c + d, e, f ) )
>
> If this is supposed to be a tabular format then why is the second row
> allowed to have a different number of elements than the first row?
why not ?
>
> What about named fields? Is there a proposal for extending this syntax
> to allow construction of dicts or namedtuples?
Maybe - though there already exist Python built-in methods to convert
e.g. tuples to dicts and lists.
>
>> The rule here is: TAB character is inner elements' separator, and the
>> new line is outer elements' separator. Line continuation
>> character is \ (to help with long lines).
>
> So brackets and commas are too ugly, but line continuation characters
> are just fine?
Yes.
>> - implicit string concatenation disallowed
>
> So this would be a syntax error?
>
> foo === T:
> "one" "two" "three"
Yes I think so.
>
> That seems reasonable, but what about this?
>
> foo === T/T:
> "this is a very " \
> "long string " \
This one not, I'd say it should give:
foo = (("this is a very ", "long string "))
M
--
https://mail.python.org/mailman/listinfo/python-list
