Kindness

[Mikhail V]

Steven D'Aprano wrote:

> Over the many months, I've tried defending Bart, engaging with him,
> patiently explaining that his choices and our choices are not always the
> same and that there's no objective "right" and "wrong" between them,
> making subtle hints, and less subtle hints that he's being a dick.


Calm down a bit. Of course it is good that you communicate with Bart - it
seems to me he is an old dude and kind of over-nostalgic about
his language or something. But I can not remember he ever insulted
anybody here. Trolling and old man's grumbling are completely different
things.


> ... in our programming language ..
> ... at the rest of us ...
> ... we ... we ... we

>From Marko's check-list:
[ ] The group has a polarized us-versus-them mentality
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

Steven D'Aprano wrote:

> In Explorer and the open-file dialog of most applications, they will see
> paths like this:
>
> directory\file name with spaces
>
> with the extension (.jpg, .pdf, .docx etc) suppressed. So by your
> argument, Python needs to accept strings without quotes:
>
> open(directory\file name with spaces, 'r')
>
> and guess which extension you mean.
>
> That would be fun to watch in action.


I think it's what is called 'English humor'?
Funny (just a little bit).

Wait a moment - you are well aware of Windows features,
that's suspicious...


BTW Explorer with hidden extension that's a sign of
"double-click, drag-and-drop" category of users.
Definitely more advanced users turn on extensions,
or don't even use explorer as a file manager.

> Linux programmers will
> see paths with spaces and other metacharacters escaped:
>
> directory/file\ name\ with\ spaces.txt


ick. what I see is escaping of the most frequent Latin character.
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

ChrisA wrote:

> Mikhail V wrote:
>> Yes, and the answer was a week ago: just put "r" before  the string.
>> r"C:\programs\util"
>>
>> And it worked till now. So why should I replace backslashes with
>> forward slashes?
>> There is one issue that I can't write \ on the end:
>> r"C:\programs\util\"
>>
>> But since I know it's a path and not a file, I just write without trailing \.

> That's exactly the issue.

If its about trailing \ - then this is issue with the syntax - not
with the path.


> But if you just always separate paths with
> forward slashes, you never have a problem. There is no "replace"
> happening; you simply use the correct path separation character from
> the start.

I am on windows, and the OP is (othrwise why would he ask?).
If next version of windows will use forward slashes everywhere,
then yes - there will be no "replace" happening.

To the subject of the question - for the user it is most important to
*see* and copy-paste the path string exactly as it is displayed everywhere
else on windows.
Other problems, like designing cross-platform utils, etc. are not really
relevant to the simple use case (on windows).
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

Joe Pfeiffer wrote:

>> On Windows a path is e.g.:
>> C:\programs\util\
>> So what is reasonable about using forward slashes?
>> It happens to me that I need to copy-paste real paths like 100 times
>> a day into scripts - do you propose to convert to forward slashes each time?

> That's what started the thread -- using backslashes caused a \a to be
> interpreted as a special character instead of two characters in the
> path.

Yes, and the answer was a week ago: just put "r" before  the string.
r"C:\programs\util"

And it worked till now. So why should I replace backslashes with
forward slashes?
There is one issue that I can't write \ on the end:
r"C:\programs\util\"

But since I know it's a path and not a file, I just write without trailing \.
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

Greg wrote:

> Mikhail V wrote:
> >   s= "\"s\""   ->
> >   s=  {"s"}
>
> But now you need to find another way to represent set literals.


I need to find? That comment was not about (current) Python but
rather how I think string should have been from the beginning.

So you already like it and want in Python ?  :-)
Fitting it into current Python would need some prefix e.g.

s = !{hello}
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

[Chris A]

> [Mikhail]
> > So Imo default syntax should be something like:
> >
> > S = "A:{x41}B:{x42}"
> >
> > instead of backslashes and Co.
>
> So how do you represent brace characters in a string?


\{ and \}


just kidding :-D
I would be ok with {L} and {R} - easy on eye and easy to remember.
Why don't ask how would I represent double-quote character?
It's more important, but I would not use double quote as string delimiter,
I'd use {} as delimiter:

  s= "\"s\""   ->
  s=  {"s"}

is much better.

> > 2. raw strings, including multiline raw strings which should be PEP-8 
> > compliant.
>
> ???

Raw strings - as I suggested here like 3 weeks ago or so?

S = `op`
multi-line raw string block
parsed by indentation
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: File names with slashes [was Re: error in os.chdir]

[Mikhail V]

[Richard Damon]

> The one major issue with backslashes is that they are a special
> character in string literals, so you either need to use raw literals a
> remember the few cases they still act as special characters, or remember
> to convert them to double back slashes, at a minimum for all the
> characters that they are special for (easier to double them all).

> I think it was originally an error to make the backslash followed by a
> character not defined as special with a backslash as keeping the
> backslash as a literal as it causes a number of these issues. Yes, it
> allows you to not need to double it in many cases but that just sets you
> up for the mistakes that started the thread. It is probably too late to
> change that behavior now though.

Yes this would at least make less mistakes.
I find the whole situation with strings a bit disappointing.
On the one hand - there were so many string types added, on the other
hand - there are still many inconveniences. There is an english proverb,
"it does too much, but still too little". (or something like that)

The initial string syntax -- I think it's direct copy of C strings syntax.
And it sucks. (path dependency?)

I'd say there should be just two main string types:
1. string literal where all special character goes into, say, figure braces {};
(if only there was a time machine)
2. raw strings, including multiline raw strings which should be PEP-8 compliant.

So Imo default syntax should be something like:

S = "A:{x41}B:{x42}"

instead of backslashes and Co.
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

[Steven D'Aprano]

> (The same applies to Unix/Linux systems too, of course.) But while you're
> using Python to manipulate files, you should use Python rules, and that
> is "always use forward slashes".
>
> Is that reasonable?
>
> Under what circumstances would a user calling open(pathname) in Python
> need to care about backslashes?

Cough cough

On Windows a path is e.g.:
C:\programs\util\

So why should I use forward slashes in a Python literal?
I don't remember any problem caused by using backslashes in paths in Python -
are there problems?
(Apart from the fact that Python dos not have true raw string literals)

So what is reasonable about using forward slashes?
It happens to me that I need to copy-paste real paths like 100 times
a day into scripts - do you propose to convert to forward slashes each time?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Raw string statement (proposal)

[Mikhail V]

On Sat, May 26, 2018 at 10:21 PM, Chris Angelico  wrote:

>
> I'm done. Argue with brick walls for the rest of eternity if you like.

I see you like me, but I can reciprocate your feelings.


>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Raw string statement (proposal)

[Mikhail V]

On Sat, May 26, 2018 at 7:10 PM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote:
>
>>> Here is a string assigned to name `s` using Python's current syntax:
>>>
>>> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>>>
>>> How do you represent that assignment using your syntax?
>>
>> Hope its not mandatory to decipher your random example. If for example
>> I'd want to work with a lot of non-presentable characters, I'd use a
>> more human-oriented notation than this ^. And that is exactly where raw
>> strings are needed.
>>
>> So I'd make a readable notation where I can present a character by its
>> ordinal enclosed in some tag for example {10}. Then just write a
>> function which collapses those depending on further needs:
>>
>> data >>| abc{10}def
>> data = f(data)
>>
>> And the notation itself can be chosen depending on my needs. Hope you
>> get the point.
>
> Loud and clear: your syntax has no way of representing the string s.

Just 5 lines before it is - you did not notice.


> temp = >>| Mikhail's syntax for {65290} is {65290}
> Can you see the problem yet? How does your collapse function f()
> distinguish between the escape code {65290} and the literal string
> {65290}?

Look, there is no any problem here. You can choose
whatever YOU want to write "{" and "}". e.g. I'd pick {<} {>}.

temp = >>| Mikhail's syntax for {65290} is {<}65290{>}


I just show you that syntax allows you not only input TEXT
without any manipulations, but also it allows to solve any task related
to custom presentation - in this case you want work with
ordinals for example. And you may end up with a scheme which
reads way better than your cryptic example.

This motivation is covered in documentation, but maybe
not good enough? anyway you're welcome to make suggestion for
the documentation.

I'll also ask you a question  -
Which such non-text codes you may need to
generate C code? Python code? HTML code?


>
> And we've gone from a single string literal, which is an expression that
> can be used anywhere, to a statement that cannot be used in expressions.

Ok show me your suggestion for a raw string definition for expressions
(no modifications to source text and no usage of invisible control chars).

> I don't know what TQS is supposed to mean.
Triple Quoted String



> s = >>>
> this is some text
> x = 'a'
> y = 'b'
> t = 'c'
>
>
> Am I close?

Yes very close, just shift it with a char of your choice, e.g. 1 space:
s >>> !" "
 this is some text
 x = 'a'
 y = 'b'
t = 'c'

or use a tag of your choice (no shifting needed in this case):

s >>> ?"#your favorite closing tag"
this is some text
x = 'a'
y = 'b'
#your favorite closing tag
t = 'c'

There can be other suggestions for symbols, etc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Raw string statement (proposal)

[Mikhail V]

On Sat, May 26, 2018 at 10:55 AM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 26 May 2018 08:09:51 +0300, Mikhail V wrote:
>
>> On Fri, May 25, 2018 at 1:15 PM, bartc <b...@freeuk.com> wrote:
> [...]
>>> One problem here is how to deal with embedded non-printable characters:
>>> CR, LF and TAB might become part of the normal source text, but how
>>> about anything else? Or would you only allow text that might appear in
>>> a text file where those characters would also cause issues?
>>
>> This syntax does not imply anything about text. From the editor's POV
>> it's just the same as it is now - you can insert anything in a .py file.
>> So it does not add new cases to current state of affairs in this regard.
>> But maybe I'm not completely understand your question.
>
> Here is a string assigned to name `s` using Python's current syntax:
>
> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>
> How do you represent that assignment using your syntax?

Hope its not mandatory to decipher your random example.
If for example I'd want to work with a lot of non-presentable
characters, I'd use a more human-oriented notation than this ^.
And that is exactly where raw strings are needed.

So I'd make a readable notation where I can present a character
by its ordinal enclosed in some tag for example {10}. Then just
write a function which collapses those depending on further needs:

data >>| abc{10}def
data = f(data)

And the notation itself can be chosen depending on my needs.
Hope you get the point.

>
>
> And another example:
>
> s = """this is some text
> x = 'a'
> y = 'b'"""
> t = 'c'
>
> How do we write that piece of code using your syntax?

That's too easy - maybe you can try it yourself?
I am not trying to imply anything, but I don't see how
this example can cause problems - just put the TQS in a block.


>>> Would it then be possible to create a source file PROG2.PY which
>>> contains PROG1.PY as a raw string? That is, without changing the text
>>> from PROG1.PY at all.
>>
>> Should be fine, with only difference that you must indent the PROG1.PY
>> if it will be placed inside an indented suite.
>
> Bart said WITHOUT CHANGING THE TEXT. Indenting it is changing the text.

I know. So you've decided to share that you also understood this?
Good, I'm glad that you understand :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Raw string statement (proposal)

[Mikhail V]

On Fri, May 25, 2018 at 1:15 PM, bartc <b...@freeuk.com> wrote:
> On 25/05/2018 05:34, Mikhail V wrote:
>

> I had one big problem with your proposal, which is that I couldn't make head
> or tail of your syntax. Such a thing should be immediately obvious.
>
> (In your first two examples, what IS the exact string that you're trying to
> incorporate? That is not clear at all.)

You re right, this part is not very clear.
I was working on syntax mainly, but the document is getting better.
I make constant changes to it, here is a link on github:

https://github.com/Mikhail22/Documents/blob/master/raw-strings.rst


> One problem here is how to deal with embedded non-printable characters: CR,
> LF and TAB might become part of the normal source text, but how about
> anything else? Or would you only allow text that might appear in a text file
> where those characters would also cause issues?

This syntax does not imply anything about text. From the editor's POV
it's just the same as it is now - you can insert anything in a .py file.
So it does not add new cases to current state of affairs in this regard.
But maybe I'm not completely understand your question.



> Another thing that might come up: suppose you do come up with a workable
> scheme, and have a source file PROG1.PY which contains such raw strings.
>
> Would it then be possible to create a source file PROG2.PY which contains
> PROG1.PY as a raw string? That is, without changing the text from PROG1.PY
> at all.

Should be fine, with only difference that you must
indent the PROG1.PY if it will be placed inside an indented suite.
I was thinking about this nuance - I've added a special case for this
in addition to the ? flag.

data >>> X"#tag"
...
#tag

It will treat the block "as is", namely grab everythin together with indents,
like in TQS. This may cover some edge-cases.


> Here's one scheme I use in another language:
>
>print strinclude "file.txt"
>
> 'strinclude "file.txt"' is interpreted as a string literal which contains
> the contents of file.txt, with escapes used as needed. In fact it can be
> used for binary files too.
> [...]
> As for a better proposal, I'm inclined not to make it part of the language
> at all, but to make it an editor feature: insert a block of arbitrary text,
> and give a command to turn it into a string literal. With perhaps another
> command to take a string literal within a program and view it as un-escaped
> text.

I think it may be vice-versa - including links to external files
might be more effective approach in some sense. It only needs
some special kind of editor that would seamlessly embed them.
Though I don't know of such feature frankly speaking.
And there might be many caveats here.

And the feature to convert a text piece to Python string directly -
it is already possible in many editors - via macros or scripting.
But I think you falsely think that it is the solution to the problem.
Such changes - it's exactly what should be avoided.

In theory - an adequate feature like this (if it has real value)
will require the editor to track all manipulations - and give feedback.
You don't know when you have escaped some string or
not. And how do you save or see this events?
IOW this might be way harder to implement than the
approach with external text bits.


The simplest solution would be of course to write a translator.
For such syntax change - it is **millions** times easier than
what you've described.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Raw string statement (proposal)

[Mikhail V]

Hi.
I've put some thoughts together, and
need some feedback on this proposal.
Main question is:  Is it convincing?
Is there any flaw?
My own opinion - there IS something to chase.
Still the justification for such syntax is hard.



Raw string statement
--

Issue
-

Vast majority of tasks include operations with text in
various grades of complexity. It is relevant even by
simple ubiquitous tasks, like for example defining file paths.
String literals are interpreted - i.e. special character "\" may
change the contents of a string.
Python raw string r"" has the least amount of such cases :
namely the inclusion of the quote character requires escaping.
There is still no string type which is totally uninterpreted.
As a result, any text piece that contains a quote must
be *edited* before it can be used in sources.

This may seem a minor problem, but if we count all
cases, then the cumulative long-term impact may be significant.
Also this problem may become more acute in cases related to:
- development of text/code generators
- and, in general, all text processing with a lot of
  literal data definition
- proofreading

Such applications may *require* a lot of embedded text definitions and
this may even lead to frustration by proofreading of 'escaped' pieces
and it adds necessity for keeping track of changes in these pieces.
Using external resources for these tasks could help, but it may lead to
even worse experience because of spread definitions
and increased maintenance times.

The most common solution in existing syntax - triple quoted
strings and raw strings has some additional issues:

- Data is parsed including indents. This may be a benefit for some
cases (e.g. start lines always without any indent) but it also may
become confusing for the readers when not aligned with
containing block. So-called "de-denting" is also needed.

- Triple quotes cause visual ambiguity in some edge-cases,
e.g. when a string starts or ends with a quote. Also in many fonts
a pair of single quotes is visually identical to one double quote.


Proposal
---

Current proposal suggests adding syntax for the "raw text" statement.
This should enable the possibility to define text pieces in source
code without the need for interpreted characters.
Thereby it should solve the mentioned issues.
Additionally it should solve some issues with visual appearance.


Specification
-

Raw string statement has the following form:

name >>> "condition_string"
... text ...

in example:

data >>> "  "
  begin
  end
#rest

will parse the block by comparing each next
line part with the string "  " (2 spaces here).
This will return: "  begin\n  end"

-- Additional option: parse and remove:

data >>> !"  "
  begin
  end
#rest

Will parse by the same rule but also remove
the string from the result: "begin\nend"

- Additional option: parse *until* condition:

data >>> ?"#eof"
begin
end
#eof

Will parse up to character sequence "#eof" (if it is on the
same level) and returns: "begin\nend".
The benefit of last option - the data can be put at zero
level. It may be also prefered due to explicit terminator.


General rules:

- parsing is aware of the indent of containing
  block, i.e. no de-dention needed.
- single line assignment may be allowed with
  some restrictions.

Difficulties:

- change of core parsing rules
- backward compatibility broken
- syntax highlighting may not work
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 11:56 PM, Bob van der Poel  wrote:
> On Wed, May 23, 2018 at 1:45 PM, MRAB  wrote:
>
>> If you want additional indentation, then provide a string literal:
>>
>> def func():
>> foobar
>> data = >> '':
>>   first line
>>   last line
>> foobar
>>
>> for 'first line\nlast line\n' or:
>>
>> def func():
>> foobar
>> data = >> '\t':
>>   first line
>>   last line
>> foobar
>>
>> for '\tfirst line\n\tlast line\n'.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> I think this is getting way too complex to fix a problem which doesn't
> exist.

@Bob
It is not clear at all about which issue are you writing the comment.
Also not clear to whom is it addressed (me or MRAB).

Please - can you be specific and respectful.

And a general note - It is hard to support the conversation when the
amount of rational content becomes low.
May be it surprises you but I _read_ the comments and try to
understand them.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 11:45 PM, MRAB  wrote:

>>> def func():
>>> foobar
>>> data = /// s2
>>>   first line
>>>   last line
>>> foobar
>>>

> Instead of the "s2", etc:
>
> def func():
> foobar
> data = >> :
>   first line
>   last line
> foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
> foobar
> data = >> '':
>   first line
>   last line
> foobar

Such approach has its benefits.
and ">>" looks nice.

So the benefit here is that you make it more
compact - no parameters needed.
But as you see, it just cannot parse the text in
case of positive indent.
Or otherwise I need to edit the text and then, if say I want
to paste it back elsewhere - edit again. This small nuance can
get in the way.
Also semantically - I find it a bit of implication - it's something
automatic.


> As the last line also ends with '\n', the result should be 'first line\nlast
> line\n'.

Sorry, I can't see how this would be beneficial?
This would mean every string will have trailing \n.
Even if it is one word.
Maybe it could help in some cases, for example
if you write a code generator and then append to
a file consequently.
But in general I disagree with this approach.

Also it is counter-intuitive - for example if I open a
text editor and type "a", save it and then read it with
python script - then I get only "a" but not "a\n".

But maybe I am missing something.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 8:08 PM, Mikhail V <mikhail...@gmail.com> wrote:
> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl <d.str...@f5.com> wrote:

> data = /// sN # and
> data = /// tN
>
> Where N - is the amount of characters, spaces (s) or
> tabs (t).
> This should cover most use cases.
> It implies of course that the user should know himself
> what he is doing.
>
> More concrete example:
>
> def func():
> foobar
> data = /// s2
>   first line
>   last line
> foobar
>
> will store same data as:
> data = "first linelast line"

oops, I meant it to be:
data = "first line\nlast line"

sorry for possible confusion

>
> (assuming of course no trailing spaces were
> in original lines)
-- 
https://mail.python.org/mailman/listinfo/python-list

Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:
> First of all, I suggest splitting this into a separate proposal (new thread) 
> that way you will avoid confusion for people who are still considering the 
> older proposal, and for the (probably many) people who have stopped reding 
> the old thread due to some of the more heated conversations in there.
>
>>
>> Though hard-coded knock-out is also very useful, e.g. for this:
>>
>> data = /// s4
>> First line indented more (8 spaces)
>> second - less (4 spaces)
>> rest code
>>
>> So this will preserve formatting.
>>

> True, but in everything, there is a balance between
> flexibility and complexity. Nothing else in python
> (that I can think of) forces people to use 4 spaces,
> that's merely a style thing.  If I want to use 2 spaces,
> I can, I've seen modules that use 3 spaces for
> indenting and it works fine.  So, the flexibility of
> adding the ability to further indent the first line seems
> to me to be outweighed by the added complexity
> of this being "different".

I think we might have a misunderstanding here.
I admit I have tendency to use false terms sometimes -
in this case I did not mean "hard-coded", but rather with
parameter which is taken by the parser.

Namely the proposal is to use 'de-dention' parameter in
such form:

data = /// sN # and
data = /// tN

Where N - is the amount of characters, spaces (s) or
tabs (t).
This should cover most use cases.
It implies of course that the user should know himself
what he is doing.

More concrete example:

def func():
foobar
data = /// s2
  first line
  last line
foobar

will store same data as:
data = "first linelast line"

(assuming of course no trailing spaces were
in original lines)

So obviously the minimal amount in a parameter is 1,
otherwise it will not work at all.

That's actually it. I am inclining to opinion that no
further parameters are necessary, but of course
there might be few other common use case.
IOW it would be not correct to totally disregard
considering some additional options.



>> # lang "yaml"
>> data = /// t
>> first line
>> last line
>> rest
>
> Again, you're complicating the thought without really
> [...] primitives should have as few caveats as possible.
> [...] Extra features are fine, but when they start making
> it "more complex" to use, then you should back off.>

I 100% agree with you. In this case it is better to concentrate
on the most 'low-level' behaviour.


>> Also I am thinking about this - there might be one useful 'hack".
>> One could even allow single-line usage, e.g.; (with a semicolon)
>>
>> data = /// s2:  first line
>>
>> - so this would start parsing just after colon :
>> "pretending it is block.
>> This may be not so fat-fingered-proof and 'inconsistent', but in the end of 
>> the
>> day, might be a win actually.
>>
>>
>
> If you are thinking about this road, what about
> instead making another reserved word and
> approaching it like class or def, for example;
>
> datablock data:
> first line
> second line

Well it looks ok, but traditionally it is forbidden to introduce
any new keywords, unless it is absolutely necessary.


M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Wed, May 23, 2018 at 2:25 AM, Dan Strohl  wrote:
>

>>
>> Explanation:
>> [here i'll use same symbol /// for the data entry point, but of course it 
>> can be
>> changed if a better idea comes later. Also for now, just for simplicity - 
>> the rule
>> is that the contents of a block starts always on the new line.
>>
>> So, e.g. this:
>>
>> data = /// s4
>> first line
>> last line
>> the rest python code
>>
>> - will parse the block and knock out leading 4 spaces.
>> i.e. if the first line has 5 leading spaces then 1 space will be left in the 
>> string.
>> Block parsing terminates when the next line does not satisfy the indent
>> sequence (4 spaces in this case).
>
>
> Personally though, I would not hard code it to knock out 4 leading spaces.
> I would have it handle spaces the same was that the existing parser does,

If I understand you correctly, then I think I have this option already
described,
i.e. these:

>> data = /// ts
>>
>> - "any whitespace" (mimic current Python behaviour)
>>
>> data = /// s# or
>> data = /// t
>>
>> - simply count amount of spaces (tabs) from first
>>   line and proceed, otherwise terminate.


Though hard-coded knock-out is also very useful, e.g. for this:

data = /// s4
First line indented more (8 spaces)
second - less (4 spaces)
rest code

So this will preserve formatting.


>> data = /// "???"
>> ??? abc foo bar
>> ???
>>
>> - defines indent character by string: crazy idea but why not.
>>
>
> Nope, don't like this one... It's far enough from Python normal that it seems
> unlikely to not get through, and (personally at least), I struggle to see the 
> benefit.

Heh, that was merely joke - but OTOH one could use it for hard-coded
indent sequences:

data = /// ""
First line indented more (8 spaces)
second - less (4 spaces)
rest code

A bit sloppy look, but it generalizes some uses. But granted - I don't
see much real applications besides than space and tab indented block
anyway - so it's under question.


>> Language  parameter, e.g.:
>> data = /// t1."yaml"
>>
>> -this can be reserved for future usage by code analysis tools or dynamic
>> syntax highlighting.
>>
>
> I can see where this might be interesting, but again, I just don't see the 
> need,

I think you're right  - if need a directive for some analysis tool then one
can make for example a consideration to precede the whole statement
with a directive, say in a comment:

# lang "yaml"
data = /// t
first line
last line
rest




Also I am thinking about this - there might be one useful 'hack".
One could even allow single-line usage, e.g.;
(with a semicolon)

data = /// s2:  first line

- so this would start parsing just after colon :
"pretending it is block.
This may be not so fat-fingered-proof and 'inconsistent',
but in the end of the day, might be a win actually.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Tue, May 22, 2018 at 1:25 PM, bartc <b...@freeuk.com> wrote:
> On 22/05/2018 03:49, Mikhail V wrote:
>>
>> On Mon, May 21, 2018 at 3:48 PM, bartc <b...@freeuk.com> wrote:
>>
>> # t
>> # t
>>11  22  33
>>
>
> Is this example complete? Presumably it means ((11,22,33),).

Yep.

>
>> You get the point?
>> So basically all nice chars are already occupied.
>
> You mean for introducing tuple, list and dict literals?

No, I've meant the node (or whole data block) entry point chars ///.

So in such an language full of various operators, it is
just hard to find anything that does not clash with some
current meaning yet looks adequate and is ASCII.

A quick note: thanks for your comments, I'll  just note that I've
moved to some more promising related proposal (see last posts in this thread),
so the original one will move to later considerations.
so the nuances will be reconsidered anyway.


> Python already uses
> (, [ and { for those, with the advantage of having a closing ), ] and } to
> make it easier to see where each ends.

Ehm, for inline usage - i.e. everywhere on a line - closing tags are necessity.
My whole idea was about indentation based data - so there it is redundant noise.
You may disagree as well, since I've noticed in some previous thread
that you prefer Fortran-like termination tags. So that's quite personal I think.

As for more objective points: currently many brackets are 'overloaded'
and moreover, they are all almost "homoglyphs" - very similar characters.

For an inline solution I'd prefer it e.g.
for a tuple:

{t  11  22  33}

nested:
{t  11  {t  11  22}  22}

Yes, it IS worse than:
{11  {11  22}  22}

But still one might need _various types_ so brackets only - has
limited potential in this sense.


>>> The ///d dictionary example is ambiguous: can you have more than one
>>> key:value per line or not? If so, it would look like this:
>>>
>>>///d "a" "b" "c" "d" "e" "f"
>>
>>
>> ///d   "a" "b""c" "d""e" "f"
>>
>> Now better? :-)
>
>
> Not really.
> Suppose one got accidentally missed out, and there was some
> spurious name at the end,

Not sure about your case, but it is up to you to format it to make it
more readable - whitespace / newline separation gives enough possibilities to
do so. And for me the lack of commas is of great benefit.
 _Some_ punctuation can be added in some cases (see e.g. "node
stacking section" in original document - dicts may adopt this as well
but I see no necessity at least for this case)


> It's not clear whether:
>
>   ///d a b
> c e
> f x
>
> is allowed ?

allowed, but i'd say merely discouraged for industrial usage. better start
newline at least for multiline contents.

> I think this is an interesting first draft of an idea, but it doesn't seem
> rigorous. And people don't like that triple stroke prefix, or those single
> letter codes (why not just use 'tuple', 'list', 'dict')?
>
> For example, here is a proposal I've just made up for a similar idea, but to
> make such constructors obey similar rules to Python blocks:
>
>  tuple:
>  10
>  20
>  30
>
>  list:
>  list:
>  10
>  tuple: 5,6,7
>  30
>  "forty"
>  "fifty"
>

Cool, I've commented on similar option actually in some post before -
it might be ok
with type codes grayed-out and good coloring, but in black and white it is a bit
"wall of text" - not much emphasis on _structure_. But its ok - good option.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Tue, May 22, 2018 at 9:01 AM, Christian Gollwitzer <aurio...@gmx.de> wrote:
> Am 22.05.18 um 04:17 schrieb Mikhail V:
>>> YAML comes to mind
>>
>>
>> Actually plugging a data syntax in existing language is not a new idea.
>> Though I don't know real success stories.
>>
>
> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation
>


Yes. That is exactly what I wanted to discuss actually.
So the feature, which makes it possible in this case  is
triple quote string (TQS).

I think it would be appropriate to propose an alternative
to TQS for this specific purposes. Namely for making it
easier to implement parsers and embedded syntaxes.

So what do I have now with triple quoted strings -
a simple example:

if 1:
s = """\
print ("\n") \\
foo = 5
"""

So there is a _possibility_ in the sense it is possible to do, so
let's say I have a lib with a parser, etc. Though now a developer
and a user will face quite real issues:

- TQS itself has its specific purpose already in many contents,
  which may mean for example hard-coded syntax highlighting
- there a lot of things happening here: e.g. in the above example
  I use "\n" which I assume a part of string, or \\ - but it is interpreted.
  Maybe some other things regarding escaping. This particular
  issue maybe a blocker for making use of TQS in some data cases,
  Say if the target source text need these very characters.

- indentation is the part of TQS. That is of couse by design
  so and it's quite logical, though it is hard-coded behaviour and thus
  does not make the presentation a natural part of blocks containing
  this string.
- appearance: imagine you have some small chunks of embedded
  code parts and you will still have the closing """ everywhere -
  that would be really hairy.


The alternative proposal therefore comes down to a "data block" syntax,
without much assumption about the contents of the block.

This should be simpler to implement, because it should not need a lot
of parsing rules - only some basic options. At the same time it enables
the 'embedding' of user-defined blocks/syntax more naturally
looking than TQS.

My thoughts on possible solution.
-

Problem one: make it look natural inside python source.
Current Python behaviour: very simply speaking, first leading white space
on a line is taken and compared with the one from the next line.
Its Okay for statements, but not okay for raw text data -
because probably I want custom leading whitespaces:

string =
 abc
   abc

(So the TQS takes it simple - grabs it from the line beginning)

So the idea:
- add such a block  to syntax
- *force explicit parameter for the indent charaters.*

Explanation:
[here i'll use same symbol /// for the data entry point, but of course it can
be changed if a better idea comes later. Also for now, just for simplicity -
the rule is that the contents of a block starts always on the new line.

So, e.g. this:

data = /// s4
first line
last line
the rest python code

- will parse the block and knock out leading 4 spaces.
i.e. if the first line has 5 leading spaces then 1 space will be left
in the string. Block parsing terminates when the next line does not
satisfy the indent sequence (4 spaces in this case).
Another obvious type: tabs:

data = /// t1
first line
last line
the rest python code

Will do the same but with one tabstop character.

Actually that's it!
Some further ideas:

data = /// ts
- "any whitespace" (mimic current Python behaviour)

data = /// s# or
data = /// t
- simply count amount of spaces (tabs) from first
  line and proceed, otherwise terminate.

data = /// "???"
??? abc foo bar
???

- defines indent character by string: crazy idea but why not.

Language  parameter, e.g.:
data = /// t1."yaml"

-this can be reserved for future usage by code analysis tools
or dynamic syntax highlighting.

That's just a rough specification.

What should it give as result:

1. No clash with current TQS rules - less worries
  about reserved characters.

2. Built-in indentation parsing parameter makes it more or
  less natural continuation of Python blocks and is char-precise,
  which is very important here.

3. Independent of the indent of containing block!

4. Parameter descriptor can be developed in such manner
   that it allows more customisation and additions in the future.


Does seem to be more generalized problem-solving here.

One problem, as usual - tabs may be implicitly converted
to spaces by some software. That obviously could brake
something, but so is with any tabs, and its not related to
Python problem.


Is there something I miss here?
What caveats can be with such approach?



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:48 PM, bartc  wrote:

>
> This is intended to be used inside actual Python programs?
>
> In that case code is normally displayed in fixed pitch, as it would normally
> be viewed in a code editor, even if part of a document.
>
> But I have to say it looks pretty terrible, and I can't see that it buys
> much over normal syntax.

Ha, here we go. Last time I have used fixed pitch font for work -
maybe 4 years ago.
(and IMO fixed pitch font plus specifically Python - I find quite a blasphemy)

So, you re right, of course in one sense: "///" looks terrible with
a fixed pitch font! That's so true, but also it is true that this ///
I well maybe change for something less font-sensitive.
And in all fonts other than fixed pitch it looks cute enough.

Simply speaking, if it was not for Python, I might propose something
like:

# t
   # t
  11  22  33

You get the point?
So basically all nice chars are already occupied.
Proposing Unicode symbols -- that will probably will be
dead on arrival (just remembering some of such past proposals).
Leaving out symbols could be an option as well.
Still the structure needs a syntactical entry point.
E.g.

data = ///
t
   t
  11  22  33

Hmm. not bad. But I must think about parsing as well.


> It's not clear what ///. is for, or why it's necessary (presumably you have
> to use ///. /// instead of /// ///).

"///."  is meant to inherit the previous (parent) type:

/// t
   /// .
  /// .

is same as

/// t
   /// t
  /// t

So I can change types of all child nodes with one keystroke.


>
> The ///d dictionary example is ambiguous: can you have more than one
> key:value per line or not? If so, it would look like this:
>
>   ///d "a" "b" "c" "d" "e" "f"

///d   "a" "b""c" "d""e" "f"

Now better? :-)

Or compare these two:

{"a": "b", "c": "d", "e": "f"}

///d   "a" "b""c" "d""e" "f"

I'd say, the second one is much better.


> Or do you also allow: date = ///  with data following on the next line?

Yes, all this should be legal:

data = /// t
   11 22 33

data =\
/// t
   11 22 33

data = /// t  11 22 33


But this probly not good:

data = /// t  11 22 33  /// t  44  55

Because it will not be clear for the reader how further suite termination
happens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
 wrote:

> If a block of static data is large enough to start to be ugly, a common
> approach is to load the data from some other file, in a language which is
> designed around structured data.


Maybe it is common in industrial applications but not in smaller production,
and according to my observation not common at all in all occasional scripts.

>YAML comes to mind

Actually plugging a data syntax in existing language is not a new idea.
Though I don't know real success stories.

> What use-case do you foresee for your proposed new format, that isn't
> already (better) accomplished by using a separate structured
> data/serialisation language?

Well everything described in the doc is quite common. So simply put,
for all data beyond trivial inline [1,2,3].

If your idea is to use external data for all scenarios - then there are
many questions - which toolchains, file organisation, distribution etc.
One common approach is an TSV/ CSV editor plus a quick dirty
self-defined parser.
One criteria for a syntax - how simple to edit it in normal text editor
and how other existing data editors can do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder <n...@nedbatchelder.com> wrote:
> On 5/19/18 10:58 PM, Mikhail V wrote:
>>
>> I have made up a printable PDF with the current version
>> of the syntax suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further
>> re-considerations, e.g. element separation should
>> be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
> Mikhail, you have a completely different esthetic for syntax than the rest
> of the Python world.

In what sense? I don't propose to add braces to Python or anything like that.

> Your proposal seems to have almost nothing in common
> with existing Python syntax.

Well, if  speak of adding any embedded data syntax at all - how do you think:
should the embedded syntax copy everything? Even if it will look worse
in the end?
Frankly, I don't think so.
If you ask me:  may it be totally different syntax than Python?
I'd say - no, but it should be something compromising.

What other criteria is there?
Main benefits i see in Python syntax: indentation-based,
no termination tokens, new-line statement separation. Overall tendency
to prioritize readability
(e.g. over parse-ability). All these points i try to oblige.
Actually if think deeper of it - these points are not even something "Pythonic"
but merely just common sense and some basic readability principles.

> Your approach to whitespace is different.
> You've ignored existing words (tuple, str) in favor of new shorthands (t,s).

Yes. Turns out these two things should work better for presentation,
so nothing much unexpectable and nothing personal against existing words ;-).
Type abbreviations deserve more explanation in the doc though.
Simply put - if I write whole words - then type names _will dominate over data_.
E.g.:

/// tuple
   /// tuple
  foo  bar

and even so:

tuple:
   tuple:
  foo  bar

Might it be that the latter is more 'Pythonic'? Maybe yes. But how it
will look on average structure - should be compared.
Again: with proper highlighting this _might_ be an option, but without
highlighting -
sorry, would be just too hard to eyeball the nodes.

Regarding further smaller details - semicolons, asterisks - those are
subject for
further observations and may change.


> Parentheses enclosing strings!?

:-) Ok, here I agree -   the whole 'string type' part - that would be
just too much to
slip through. This would cause inconsistence and add confusion when
placed together with
normal token presentation structs. Although e.g. in a separate file
with a string-only data
it could make the difference.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 7:05 AM, Chris Angelico  wrote:
>>> Forcing us to download a PDF and then read it? Well, it's your
>>> decision. My decision is that I cannot be bothered going to THAT much
>>> effort to figure out what you're saying.
>>
>> THAT much effort to click two times instead of one - and get a
>> formatted document instead of plain bw text. o-kaay..
>
> Two clicks? No, that isn't how it happened for me. I clicked on it and
> then I couldn't see the content.

Sorry I don't know - seems that everyone can see it.

> What second click am I supposed to do
> that shows me the page?

No, no second click is needed. But if you want to download a file -
there is a button "download file". So in a pair of clicks you get
a file on your PC and you can use your favorite viewer to view
PDF, which is IMO more convenient than in a browser.

>> Ok. How is about images? this proposal will require a lot of images
>> - otherwise people who read it are forced to copy-paste snippets
>> into their code editors to understand how it may look in reality.
>
> If you're proposing syntax for Python, it's ultimately going to have
> to be text.

All of files that I provided are TEXT. Well maybe PDF is a bit "less text
than TXT" but still its just text pieces.

> You cannot say "and every text editor has to render it
> like this". If you can't demonstrate it using plain text, you have a
> major problem on your hands.

How do you do that?!  You're truly unsurpassed master of polemics.
How you turn everything upside down so easily? - that is _me_ who tells
to make _various_ samples so as to be able to see difference by
various fonts. And it is _you_ who say "everybody look at black and
white sample with a font out of 80' ".
WTF means "If you can't demonstrate it using plain text"?
There is nothing more simple than demonstrate it in plain text.
But it is not enough to judge the syntax since there is
_huge_ difference of fonts, and presence of highlighting makes huge
difference especially for expressions with keywords.

>>> I'm not going to read your proposal if you force me to go to heaps of
>>> effort for it.
>>
>> heaps! oh come on, youre making up again.
>
> No, I'm not making it up. Just because the PDF works perfectly for
> you, you assume that it'll work perfectly for everyone.

Look, PDF is one of the most widely used document exchange formats.
And you know it. I personally  don't need the PDF either - creating it
just adds me
work. And I am not debating anything about it, just made it for convenience
since someone maybe prefer it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 5:20 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Mon, May 21, 2018 at 8:28 AM, Mikhail V <mikhail...@gmail.com> wrote:
>>> >
>>> > Comments, suggestions are welcome.
>>> >
>>>
>>> One comment.
>>>
>>> I'm not interested in downloading a PDF. Can you rework your document
>>> to be in a more textual format like Markdown or reStructuredText?
>>> Since you're hosting on GitHub anyway, the rendering can be done
>>> automatically.
>>>
>>> ChrisA
>>
>>
>> What against PDF?
>> Anyway, I have reloaded files with most recent corrections in various 
>> formats:
>
> The very best way to put your proposal is right here in the body of
> the email, as plain Unicode (and primarily ASCII) text, no images, no
> external links, no side dependencies.

Well that's the easiest way for me, but - if the document changes constantly
then it is more convenient to have a web link for a document.

> The second best way is to have a simple link that anyone can click on
> to read your proposal. It's an external dependency, but you're
> depending on a web browser and a basic internet connection, and
> nothing more.
>
> Forcing us to download a PDF and then read it? Well, it's your
> decision. My decision is that I cannot be bothered going to THAT much
> effort to figure out what you're saying.

THAT much effort to click two times instead of one - and get a
formatted document instead of plain bw text. o-kaay..

> The PDF link you give is not viewable on the web

Dunno, works for me - I click it and see immediately my PDF in
the browser. But I (and many people) prefer to download anyway.
Also I provided a link to HTML - also works per click and looks even
better than PDF.

> As Ian says, reStructuredText is the only supported format [1] for
> PEPs, so you may as well just start using it straight away. GitHub
> automatically renders it if you use a ".rst" extension on your file,
> so the rendered form would be visible on the web.

Ok. How is about images? this proposal will require a lot of images
- otherwise people who read it are forced to copy-paste snippets
into their code editors to understand how it may look in reality.

> I'm not going to read your proposal if you force me to go to heaps of
> effort for it.

heaps! oh come on, youre making up again.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:02 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Sun, May 20, 2018 at 4:28 PM, Mikhail V <mikhail...@gmail.com> wrote:
>> "Markdown" is too vague - there dozens of markdown styles and
>> also they include subsets of HTML. It is just plain text with tags
>
> The whole point of Markdown is that it's readable as plain text
> precisely because it *doesn't* use obvious tags like HTML.
>
>> it cannot represent syntax in civilized form (unless I embed images
>> for every source example - but then it is too inconvenient for editing).
>
> Why would you need images to represent syntax? What's wrong with code blocks?

Code blocks where? In what software/webkit it is supposed to be
rendered?
How do you imagine a serious proposal with such syntax comparisons
without ability to make more or less precise presentation in various
fonts?
To speak about significant syntax change seriously you need many samples
in at least 2-3 modern quality fonts. Modulo a pair of reasonable color schemes.
Modern editors (and users) are far beyond type-writer fonts.

>> I suggest you just view HTML or PDF - it looks better and if you need
>> source - just download TXT - it has tabs preserved at least.
>
> You know, if you're serious about this proposal, then eventually you
> will have to write a PEP for it. And that PEP has a required style and
> format. And that format is reStructuredText.

Making reStructuredText is not a problem, but as said - it is not
serious to speak of syntax without good samples. IOW besides a
Markdown PEP such proposal requires a lot of supplementary material.
The best method is to create images of code snippets in addition to
text. Main advantage of images that it will be independent of browser/OS
but it requires some extra job.
-- 
https://mail.python.org/mailman/listinfo/python-list

"Data blocks" syntax specification draft

[Mikhail V]

> >
> > Comments, suggestions are welcome.
> >
>
> One comment.
>
> I'm not interested in downloading a PDF. Can you rework your document
> to be in a more textual format like Markdown or reStructuredText?
> Since you're hosting on GitHub anyway, the rendering can be done
> automatically.
>
> ChrisA


What against PDF?
Anyway, I have reloaded files with most recent corrections in various formats:

PDF
https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

TXT
https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.txt

HTML(direct preview link)
http://htmlpreview.github.io/?https://raw.githubusercontent.com/Mikhail22/Documents/master/data-blocks-v01.html


"Markdown" is too vague - there dozens of markdown styles and
also they include subsets of HTML. It is just plain text with tags -
it cannot represent syntax in civilized form (unless I embed images
for every source example - but then it is too inconvenient for editing).
Source examples on Github will force a crappy font and replace tabs.

I suggest you just view HTML or PDF - it looks better and if you need
source - just download TXT - it has tabs preserved at least.
-- 
https://mail.python.org/mailman/listinfo/python-list

"Data blocks" syntax specification draft

[Mikhail V]

I have made up a printable PDF with the current version
of the syntax suggestion.

https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

After some of your comments I've made some further
re-considerations, e.g. element separation should
be now much simpler.
A lot of examples with comparison included.


Comments, suggestions are welcome.


M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Sat, May 12, 2018 at 5:38 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Fri, May 11, 2018 at 5:26 PM, Mikhail V <mikhail...@gmail.com> wrote:
>> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhail...@gmail.com> wrote:
>>>> Do you understand that basically any python code sent by e-mail converts 
>>>> tabs to
>>>> spaces, thus the only way to receive it - is to send binary file?

>> So what is false?
>
> Your absurd assertion that the only way to safely email Python code is
> as a binary file.

Why you say so? You have agreed yourself with the assertion.
Also I did not say "safe" but meant that I cannot receive the exact file
in the body of e-mail in case of tabs.


> no support for _fancy features_ like viewing tabs and spaces

:\
is syntax highlighting fancy feature?


>> Sorry, not sure what you mean. Do you propose _visible_ character
>> instead of e.g. tab? But then you need to hide it to be able
>> to read normally.
>
> Why would I need to hide the separator character in order to be able
> to read the data?

So you find e.g. this ok:
→1 →→ 2 →→ 3 →→ 4

>> presentable to the reader. Initial  idea is just use current
>> Python syntax for further nesting:
>>
>> image === T/T:
>> (127,127,127)(127,127,127)(127,127,127)
>> (127,127,127)(127,127,127)(127,127,127)
>> (127,127,127)(127,127,127)(127,127,127)
>>
>> vs:
>> image = (
>> ((127,127,127), (127,127,127), (127,127,127),),
>> ((127,127,127), (127,127,127), (127,127,127),),
>> ((127,127,127), (127,127,127), (127,127,127),),
>> )
>
> And if you have more than three levels of nesting, and you don't
> conveniently just have a bunch of 3-tuples that line up perfectly with
> one another?

Maybe you can come up with some example in current syntax?
I have browsed some projects with a lot of resource definitions.
sometimes it has 3-4 levels of nesting, and I have hard time
understanding the structure - so maybe it is possible to simplify
those according to this syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Sat, May 12, 2018 at 7:54 AM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote:
>
>> it is just  not a trivial task to find an optimal solution to this
>
> We already have an optimal solution to this.

Yes. current syntax will not go anyway so proposal
addresses cases where it is appropriate and
clearly better.

>
> * It works with any editor, including simple ones.

Ok

> * It is safe for transmit over email, or on web forums,
>   so long as you avoid tabs and use spaces.

I don't use spaces so I'm out of luck already.

> * It is readable by humans without them needing to distinguish
>   between two different kinds of invisible space.

I'm using tabs from childhood and don't find it a problem.

> * It can be easily parsed by hand or by machine.

Parsed by hand?

> * It works with a multitude of text processing tools whether
>   or not they can cope with tabs.

Ok. But this is bullet #1, see above, you repeat it

>
> * It is resistant to many sorts of typos.

Here I think you oversimplify - In fact current syntax
introduces typing problems in many cases:
as a user with very high proficiency in typing and
good sight, I have some trouble inputting nested bracketed
arrays  and spend some time trying to match
corresponding suites. Plus the comma noise here,
so your statement is too one-sided and overestimated.

As said, I remember this and similar issues were raised on 'ideas'
so don't pretend it does not exist.

>
> * It allows great flexibility in the presentation, you aren't
>   forced to lay things out in one specific 2D format.

Only words - but nothing concrete

> * It uses the same consistent rules for the rest of the language,
>   without adding special cases and complexity.

I'll grant you for "special cases", but the rest is quite contradictive.
As said, Python uses indented blocks - not bracketed
blocks as in C.
Python does not make semicolons mandatory.
All this is a great improvement, but it seems you
don't see the parallel here.


> * It is a tried-and-true solution that has been used (with minor
>   modifications) for dozens, possibly hundreds, of programming
>   languages, natural language lists and data formats.

> "natural language lists and data formats"

OTOH all _real_ data list, tables, matrices do not include redundant commas,
unless it is really needed.
Any book, lectures, etc. presents them without commas so its
second nature to any human to see it without commas
and its just better so.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

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"


>
>> 123"hello"
>> abc + de 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 

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Fri, May 11, 2018 at 9:12 AM, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:34 PM, Mikhail V <mikhail...@gmail.com> wrote:
>> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
>> <steve+comp.lang.pyt...@pearwood.info> wrote:
>>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>>>
>>
>>>> but I propose Tab-separated elements.
>
> Then these are not ordinary expressions, are they? They're a different
> type of expression and will require a modified parser. This adds
> complexity.

Definitely such syntax will require modifed parser.


>> "GvR have invented amazing new syntax that cannot be preserved
>> by sending it by e-mail"!
>> (not me)
>>
>> Do you understand that basically any python code sent by e-mail converts 
>> tabs to
>> spaces, thus the only way to receive it - is to send binary file?
>
> Um, no, this is false. We send Python code by email all the time.
> 1) Tabs as indentation: Python permits the use of both tabs and spaces

This means if I paste some code _inside_ an existing  block,
I get a Syntax error:
"TabError: inconsistent use of tabs and spaces in indentation"

> 3) Tabs that appear in strings: This one I'll grant you.

This too.

So what is false? Yes with my syntax it will just become
more prone to environments which replace tabs with
spaces. Mostly this happens in e-mails and web forms.
Why they do it I don't have an idea.

Anyway keeping this in mind, I'd prefer not to adapt
the syntax to such things. It would be fair that the software
solutions should address those, as it should not happen.


> In any case, the use of tabs is entirely optional. For the most part,
> programs can be safely emailed whether they contain tabs or not, the

In real situation just send as attachment, with or without such
syntax, it will be
more polite and safe if you wish the person to run the program.
For some talks in email its not *far* worse than now.


>> Yes, I have told already that there are _some_ cases when
>>  tabulation formatting can cause visual confusion.
>> *But why do you blame me*?
>> It just the issues with editor's incompleteness.
>
> That's great, but if I'm editing a file on an embedded system over a
> serial port and the only editor I have available is nano, I should be
> able to use it. You can't just assume that everybody has a fully
> featured editor (and knows how to use it -- what was that point you
> made just above about beginners?)

Wait, wait, wait - we are adult people - what problem causes nano?
I don't have nano so maybe you can tell what happens in nano if you
load for example a text file this:

→a + b →→ a + b →→a + b  →→a + b
→1 →→ 2 →→ 3 →→ 4
→width:→→100% →→!important;

In the above example one arrow → is one tab char.
What exact problem do you experience?
(note, I don't ask to align the columns, I just ask what
real problems you have with that?)
TBH I cant say for tools other than normal editor.
Just hope it will not become my problem to test
all legacy stuff out there.


>> For instance, there is real demand on adding new control characters
>> to syntax, so as IDE developers can utilize those for making
>> better user experience. If you apply same one-sided principles here
>> then you behave good to one group of people, but just ignorant
>> to other group of people who want better new experience.
>
> Please link the approved PEP that is going to add syntactically
> meaningful control characters.

Sorry, i was writing too fast - not control characters, but characters in
general. That was kind of general parallel to the current situation.
I'll try to ask better: for instance, if propose to use some unicode character
operator - so I can use the editor feature.
In theory - many people may potentially benefit but some people
have issues with it in some software.
And the issues may vary in nature - e.g. Steven can't bind a keyboard
shortcut to type it.
OTOH it may be something really bad - a software failure or general
problem. So the question is what would be more _serious/general_ problem.


>>>> I don't want spaces or tabs visible - there is toggle "show tabs"
>>>> and "toggle show space" for that

> Needing to fiddle with editor settings in order to determine how the
> code in front of me that somebody else wrote is organized doesn't
> sound to me like a good feature. That sounds to me like poor
> readability.
>

Sorry, not sure what you mean. Do you propose _visible_ character
instead of e.g. tab? But then you need to hide it to be able
to read normally.


>>
>> "So the idea is to _hide brackets for_ first two levels of
>> nesting of course."
>
> In other words, this syntax is really not

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>

>> but I propose Tab-separated elements.
>
> We already have tab-separated elements in Python. It is allowed to use
> tabs between any whitespace separated tokens.

Yes, exactly. So in the proposed syntactic construct, it is *not*
allowed to insert tabs between _any_ tokens.
Namely if you will insert tabs _inside_ equations,
like:
a  + b

Then it will not work (it will parse 2 elements) .

So -  the simple answer, which follows directly from the
proposal: no, you don't insert tabs inside equations in this construct.
In simple words, if you want to do it nevertheless - this proposal is
not for you.

*But I am glad that at least you have managed to formulate your concern
finally,  thanks.*


>> If I allow commas as well, this will become not so simple, probably.
>> Also I don't propose syntax for e-mail code exchange, but rather syntax
>> for *work* an this can potentially help a lot of people in everyday
>> work.
>
> /head-desk
>
> You: "I have invented amazing new syntax that cannot be exchanged by
> email. Here, let me email some examples to you."

"GvR have invented amazing new syntax that cannot be preserved
by sending it by e-mail"!
(not me)

Do you understand that basically any python code sent by e-mail converts tabs to
spaces, thus the only way to receive it - is to send binary file?

Maybe you should've made more influence on that in the past and now we
all would have to use spaces only to format the code.
Also maybe include C-brackets so as not to worry when e-mail clients
add extra spaces in front of lines?


>> Also I don't know what kind of human thinks that this:
>>  a + b
>>  is two elements "a" and "+ b"
>> What is "+ b"?
>
> It is unary plus followed by b.
>
> If you don't know Python's existing syntax, how can you possibly expect
> to invent new syntax?

Wow! Uncle Steven knows Python operators.
My question was: why would you have "+ b" in
the first place in your code? So you treat the worst-case scenario
as a normal case - interesting approach  indeed!

By the way, since you are into unrealistic worst-case scenarios:
Imagine you start with Python learning, how you'd like such constructs:

L = [a + b, c, d]
L = [a + b, (c, d)]

For a starter, reading this will be quite painful.

Yes, I have told already that there are _some_ cases when
 tabulation formatting can cause visual confusion.
*But why do you blame me*?
It just the issues with editor's incompleteness.
Simple feature like "set the minimal tab size" would have solved
this issue by 100%. Maybe it even exists in some editors,
I would not be surprised at least.

 I hope you are not seriously thinking that there is good syntax
 that gives retro-tools, wacky people, not wacky people,
 pros, etc. same opportunities.

For instance, there is real demand on adding new control characters
to syntax, so as IDE developers can utilize those for making
better user experience. If you apply same one-sided principles here
then you behave good to one group of people, but just ignorant
to other group of people who want better new experience.

Seriously, your sarcasm is pretty one-sided.
You should try to think a bit wider.


>> I don't want spaces or tabs visible - there is toggle "show tabs"
>> and "toggle show space" for that
>
> /head-desk
>
> You: "This syntax doesn't need tabs and spaces to be visible. Just use
> the Show Tabs and Show Spaces commands on your editor to make them
> visible."

Yep!  Just toggle them if you want to find out. That's a good feature!

And you know, **head-desk'ing too often (and without reason) may
be not good to you.**
We need healthy Steven.


>
>>> Using a particular editor is not and will not be a mandatory
>>> requirement for Python.
>>
>> Using outdated tools or being PEBCAK are not and will not be
>> justification for language syntax improvements.
>
> It is not your choice of what editors people are permitted to use in
> order to read and write Python.

Yeah, but most people do not want to sit with technologies from 80's,
especially when many new possibilities are already available.
And that's why the scene of editors is changing so fast,
there is a lot that makes it easier to work.


>>> - the first one can include nested data structures, while
>>>   the second cannot.
>>
>> Why it can't? did you read the original e-mail?
>
> Of course I did. You said:
>
> "So the idea is to cover only first two levels of
> nesting of course."
>
> With bracket syntax, I can cover unlimited levels of nesting. Yours
> cannot.

Ok, that was a typo, it must be:

"So the idea is to _hide brackets for_ first two levels of
nesting of course."

Thanks for noticing. So it can, but that's not an easy one to
implement.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Mikhail V]

On Wed, May 9, 2018 at 8:50 AM, Chris Angelico  wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly  wrote:
>>
>> while True:
>> if we_are_done():
>> break
>> # do some stuff
>> ...
>> if error_occurred():
>> break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Python and without needing to use assignment in
>> an expression.
>
> Why is it that "while True" is idiomatic Python for a non-infinite
> loop? Is it merely because Python currently has no other way to spell
> certain loops? Surely it would be more idiomatic to encode the loop's
> termination condition in the header, if it were possible.

Don't know about 'idiomatic', but the above spelling is exactly what i
tend to use lately for almost all loops. It noticeably reduces cognitive load.
Though lately more often i prefer "while 1:" so it makes
the nodes more lightweight and distinct from the rest lines.
And not even official declaration of "idiomatic" as something else will
make me switch back.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 3:14 AM, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> Mikhail V <mikhail...@gmail.com> writes:
>
>> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico <ros...@gmail.com> wrote:
>> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> >> Just admit it, you try to troll me (or just pretend, I don't know).
>> >
>> > No, I am not trolling you.
>>
>> I don't believe you.
>
> If that's true – if you believe Chris is trolling you – then please do
> not continue the conversation. Since you have already decided Chris is
> trolling you,

Well, the thing is I don't know how exactly the word "trolling" can
be understood by different persons. I use it here in sense of "nitpicking".
Or "fooling around" I don't know actually.
So may be "trolling" has too negative associations to your ears?

As for Chris' attitude in this thread, and my point on this -
well, honestly yes, I believe he uses an opportunity to push
his own game. It has happened before - and now I know already,
so I know that trying to explain and honestly answer his questions ends up
in the same game of Chris - so I suppose he amuses himself
in such a way.
Same scenario happens here - he just completely neglects the whole
proposal straight away with a bold provoking statement.
But then asks "why do you think this a good proposal?"
Which I actually tried to describe in the very proposal.

So honestly I can't understand what game this time he prepared,
and not very much into this kind of things.



>
> This forum has no need of another thread attempting to “win” an argument
> that one side believes is dishonest.
>
> --
>  \   “The best in us does not require the worst in us: Our love of |
>   `\ other human beings does not need to be nurtured by delusion.” |
> _o__) —Sam Harris, at _Beyond Belief 2006_ |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 12:33 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Wed, May 9, 2018 at 7:15 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <ros...@gmail.com> wrote:
>>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhail...@gmail.com> wrote:
>>>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>>>> the readability improvement. Not even speaking of how
>>>> many commas and bracket you need to type in the first case.
>>>
>>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>>
>> Just admit it, you try to troll me (or just pretend, I don't know).
>
> No, I am not trolling you.

I don't believe you.


> Neither of those examples is program code. You are asking for a
> syntactic change to a *programming language*. Everything you've said
> is fine for a non-code format. Nothing is applicable to a programming
> language.

Everything I said in previous mail was related to your claim that it's
Ok (or even better?) readable
with brackets and commas in a table than without them.
I was not even starting this terminology course.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Tue, May 8, 2018 at 10:52 PM, Mikhail V <mikhail...@gmail.com> wrote:
>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>> the readability improvement. Not even speaking of how
>> many commas and bracket you need to type in the first case.
>
> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Just admit it, you try to troll me (or just pretend, I don't know).

Have you ever seen tables with commas left in there?
I've never seen in my whole life. And you should understand why.

Have you ever seen a website with sparse menu items or 'cloud' tags
with commas attached?
Have you ever heard someone claim that writing a 2d matrix down in a
single line is better that present it as a table?

So what you find _incredibly_ subjective here?

I am not telling tabulations work as they should in many code editors, but
there is a lot of work people invest to make better support for them in editors.
Here is another indirect benefit of adding such syntax, as editor developers
will be more motivated to improve the tabulation features.


> Why should this be a language feature? Why not just create a data file
> and then load it, or use a triple quoted string and write your own
> parser? What's the advantage of making this language syntax?

I am not sure what happens if I make another argument -
if it feels so easy for you to deny the obvious improvements (which
also supported by whole worlds' typography experience) then you can
just as easy deny pretty everything. How would we build any conversation
then?




>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 6:20 PM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> 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").
>
> 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;
>

Sorry this all does not seem to even refer to my proposal.

I don't propose to remove spaces, but I propose Tab-separated
elements. If I allow commas as well, this will become not so simple,
probably. Also I don't propose syntax for e-mail code exchange,
but rather syntax for *work* an this can potentially help a lot of people
in everyday work.

Also I don't know what kind of human thinks that this:
 a + b
 is two elements "a" and "+ b"
What is "+ b"? And who writes "- b" with a space in unary minus?
I don't. Nobody does. Is it allowed? yes. no problem.

(It would be great if you group the issues
related to usability separetely from technical problems
with parser. That will help to understand you comments.)


>> 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.

Yes my idea, but not sure what is you concern right now.
IIRC back then, you were the *only one* who commented something about
Tab and parsing, and made some mysterious example with eval("\t") which
I still don't know what it should explain exactly.
You say "everyone?" ... Hmm, now I am starting to suspect - maybe
each your post really represents a result of a quick meeting
regarding each raised proposal?
That would explain the usage of plural "us".

>>> There's also the problem that your syntax requires the *invisible*
>>> difference between tabs and spaces to be treated as syntactically
>>> meaningful.

There is "invisible" difference in indentations tabs vs spaces - so what?
I don't want spaces or tabs visible - there is toggle "show tabs" and "toggle
show space" for that and many more usability features, as I already said.
Look, I work with layouts - there are: Indents, Tabs, spaces, En
space, Em space,
thin space, non-breaking space, "indent to here" control characters.
All those are useful parts of inner syntax - all are "invisible".
What point are you making after all?

Those are basically universal features. And thousands of Python people
already use tabs to align columns so you have to accept it - it is
part of many source code and tabulation formatting is a good and
useful feature, although not all editors cope good with that.


>>
>> 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.

Using outdated tools or being PEBCAK are not and will not be justification for
language syntax improvements. Using an editor from 85 - everyone else
should bother?
As said there is already tons of code with which you may be unsatisfied
when you paste it into REPL, but nearly nobody uses REPL for work.

>
> [...]
>> So you would prefer this:
>>
>> L = (
>> (a, 1),
>> (b, 2),
>> (c, 3),
>> (foobar, 4))
>>
>> over this:
>>
>> L === T/T:
>> a1
>> b2
>> c3
>> foobar4
>>
>> 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 -- 

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 10:15 AM, Steven D'Aprano
<steve+comp.lang.pyt...@pearwood.info> wrote:
> On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:
>
>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>> 123"hello"
>> ab c + de f
>>
>> is a synonym for:
>>
>> data = (
>> (1, 2, 3, "hello") ,
>> (a, b, c + d, e, f ) )
>
> 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?
Last time and this time I told it uses TAB character to
separate elements.


> 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.

The only real issue I know that there may be no option to adjust the
minimal size for a tabulation, so it can become too small
in some rare cases, and there is the highlight function for that.

I never had problems with inputing tables - It seems you are having
an issue or may be it's even some personal pet-pieve.

>
> [...]
>> *The benefits is just as in above examples : readability and
>> 'typeability' boost.*
>
> But your syntax is not more readable, it is less readable and ambiguous.
> It requires us to care about the difference between two kinds of
> invisible whitespace.

Yes it requires you to care about tabulation - which many users already do
to improve readability in their code. As well as any software like
Matlab, Excel, etc presents matrices as tables.
So they are all making it "less readable", lol.
Ok Steven, you like the brackets and commas noise, that's
quite funny. Your opinion is heard, but I would be thankful if you'll
speak for yourself,
and not try to enforce your opinion with these "us", "for us".

Also you seem to start with cherry-picking straight away - trying
to find an issue and wind it up with the whole idea, totally ignoring
obvious benefits for most frequent use cases like multiline
strings,1d tuples/lists  and simple tables.
A very common table case is a 2-column table.

So you would prefer this:

L = (
(a, 1),
(b, 2),
(c, 3),
(foobar, 4))

over this:

L === T/T:
a1
b2
c3
foobar4

Right? Your issues with tabs aside, I think it is impossible to ignore the
the readability improvement. Not even speaking of how
many commas and bracket you need to type in the first case.


M
-- 
https://mail.python.org/mailman/listinfo/python-list

Suggestion for a "data" object syntax

[Mikhail V]

Here is an idea for 'data object' a syntax.
For me it is interesting, how would users find such syntax.
I personally find that this should be attractive from users
perspective.
Main aim is more readable presenting of typical data chunks
and some typical data types (tuples/lists) directly in code.
Further this should significantly simplify typing.

*Example 1. Multi-line strings*

Here is a 3 lines multi-line string, it will be automatically 'dedented'
by the parser by one level of indent:

data === S :
this is multi-line string
escape chars: same as in strings (\\, \\n, \\t ...) ,
but "no need to 'escape' quotes"

(Of course, assuming this feature will be added to the lexers
of your editor, otherwise it may mess up syntax highlighting)

So the proposed statement header is like:

variable === "type" :
...

The "===" token and type id's are of course subject to discussion.
"type" is type of data, which tells the parser to
convert data to specific type of Python object.
The above is type "S", a multi-line string.


*Example 2. Tuples*

Tuple is a data block with normal Python elements.

data === T :
123"hello"
abc + d

Here the separators of elements are : tab character,
new line (and maybe some white-space character like em-space?)
The above construct will be direct synonym for:

data = (1, 2, 3, "hello", a, b, c + d)

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 and, whats more important - hard to notice missing commas.
And brackets of course does not make it nicer either.

The above are typical cases where I see clear win, and
IMO they are quite common constructs.

More complicated examples :


*Example 3. Two-dimensional tuple.*

data === T/T :
123"hello"
ab c + de f

is a synonym for:

data = (
(1, 2, 3, "hello") ,
(a, b, c + d, e, f ) )

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).

*The benefits is just as in above examples :
readability and 'typeability' boost.*

To present nesting of elements of higher than 2 levels,
normal Python syntax can be used for deeper nesting:

data === T/T :
12(345)
ab c

Or maybe even allow commas:
data === T/T :
12(3, 4, 5)
ab c

VS normal:

data = (
(1, 2, (3, 4, 5) ) ,
(a, b, c ) )

So the idea is to cover only first two levels of
nesting of course.

Further, common types may be defined, like e.g. L/L (list of lists)
but I don't want to go far into details and want to stop
on common cases to help evaluate the idea in general.


*Main rules: *
- the definition is allowed  only as a statement (no passing as argument)
- (imo) data starts always as a new line after the header
- implicit string concatenation disallowed


So the question is, how do you like such syntax, and
if so, what common examples can be fit in here.
Any ideas, comments are of course welcome.
Suggest some data and I'll try to express it in this syntax.



M
-- 
https://mail.python.org/mailman/listinfo/python-list

Beta release of pip version 10

[Mikhail V]

MRAB writes:


> > UnicodeEncodeError: 'charmap' codec can't encode character
> >
> > when it meets a non-ascii char.
> >
> > e.g. tried this:
> > pip search pygame > a.txt
> >
> Well, _I_ didn't get an error!
>
> One of the lines is:
>
> kundalini (0.4)- LրVE-like PyGame API
>
> So it's down to what system encoding (active code page) is in use.

Dunno, it gives me error regardless of active codepage,
my default is 866, i've set to 1252 or 65001, same error.

The output itself is fine - I see correct glyphs, so the error
only appears when I redirect to file.
if I try some python script e.g. "a.py":
print ("абв")

and run:
py a.py > a.txt

I get some gibberish in the file.
So it is probably a global issue. Nothing works in this life :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Beta release of pip version 10

[Mikhail V]

Steven D'Aprano writes:

>>
>> PS: was looking forward to PIP improvements on Windows, on 9.0.3 still
>> some issues. E.g. trying to redirect output from 'pip search ... >
>> a.txt' gives a wall of errors. it's on Windows 10.
>
>
>
> Don't be shy, tell us what those errors are.


You meant - don't be lazy to figure out how to reproduce it.

UnicodeEncodeError: 'charmap' codec can't encode character

when it meets a non-ascii char.

e.g. tried this:
pip search pygame > a.txt
-- 
https://mail.python.org/mailman/listinfo/python-list

Beta release of pip version 10

[Mikhail V]

Paul Moore writes :

If you discover any bugs while testing the new release, please report
> them at https://github.com/pypa/pip/issues.


Link not working (on pipermail archive -- remove the period on the end)
https://github.com/pypa/pip/issues

PS: was looking forward to PIP improvements on Windows,
on 9.0.3 still some issues. E.g. trying to redirect output
from 'pip search ... > a.txt' gives a wall of errors.
it's on Windows 10.

(logging to file is needed because there is no advanced
search, so need some filtering to restrict the output to
packages only, since it searches in description too and
that may be a lng list of packages).



Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Simple graphic library for beginners

[Mikhail V]

On Fri, Jan 12, 2018 at 10:38 AM, Paul Moore  wrote:
> On 12 January 2018 at 06:47, Steven D'Aprano
>  wrote:

>> If pip is joined at the hip to a specific version of Python, I think that
>> we ought to be able to specify the version number like we can with Python.
>>
>> Something like:
>>
>> pip ...  # use whichever version of pip comes first on the PATH
>> pip3.6 ...  # use the pip installed with Python 3.6
>> pip2.7 ...  # use the pip installed with Python 2.7
>
> Well, that's sort of how it's intended to work, but in practice it
> doesn't seem to be as straightforward as it ought to be. I can't
> really say why, as it's a Unix-only thing and I don't really
> understand the reasons, but it's why I'm a fan of the "python -m pip"
> approach. There's discussion on the pip tracker if you're interested
> enough to go searching - I know it's something that's been debated,
> but I don't recall the context.

In general I think more than one app and executable with same name
on a system already asks for problems.
On Windows I had issues with pip and pygame and I have two Pythons -
2.7.14 and 3.6.2.
The problem was that I could not make it install to 2.7, and tried many options,
looking in SO there were so many different solutions, but finally I found
something that reinstalled newer pip, but I don't remember frankly.

My opinion (from Windows user's POV) - I'd prefer if there should be
only one PIP in system,
so running pip will unambigiosly mean that I run (or upgrade) THE pip.
(and not something which I don't
even know where it is located). Ideally also it should be installed in
separate Directory.
So I'd have folders:

python 27
python 36
pip

And the target Python where the package will be installed should be defined by
a switch, e.g. 'pip -2', 'pip -3' (in analogy with 'py -2', 'py -3').
The question is though, how pip will know what version(s) of python I have, and
if I installed them later? Hmm, not an easy problem. So in this case pip shoud
track the multiple versions each time I install another version of python.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Simple graphic library for beginners

[Mikhail V]

> > But the OP isn't looking for a full-blown GUI toolkit.  I went back and
> > re-read his post to be sure I wasn't misunderstanding.  Therefore I
> > don't think the suggestion to use wxPython or PyQt is that helpful.
> >
> > Do you have any other suggestions?
> >
> > Even Cairo is pretty complicated (requiring pens and contexts) for what
> > he's asking for.
> >
> > Personally I don't think it gets much easier or simpler than this sort
> > of thing:
> > https://github.com/Mekire/pygame-samples
>
> I couldn't see anything obviously simple there. A lot seems to do with
> interaction which is always much more complicated than just drawing stuff.
>
> 'Turtle' will do it (assuming there's a way of drawing things without
> having to watch an actual turtle symbol crawling around the screen).
>

That's right. Cairo, IIRC is mainly used as a rasterizer backend, so it
is not what OP wants.

Pygame is a SDL wrapper (a low-level lib), and NOT a wrapper for
GUI widgets. Almost everything must be made from ground up -
keyborad/mouse input, buttons (OP told about buttons).

So there not even such thing as "button" there - Pygame has nothing
of that high-level concept by default, so it will require an 3d party
module that implements those.

But, for *programming* classes, I personally would still recommend Pygame.

As for something quick and simple, Turtle seems to be good.

BTW - openCV is an excellent lib for drawing and image manipulation.
It has tons of ready-to-use functions and can show things up in a
window without additional coding.
But again: if you want *buttons*, then you are merely speaking about
a framework, not a lib. IOW if you drop the beloved by
people "buttons" idea, then you have much more good options.

PyQT is probably overkill, but it has a tool for GUI construction (qtdesigner)
and it makes it child-easy to draw a window with buttons, and some
canvas object, and then auto-creates pieces of code with objects and
interaction slots. So PyQT is imo better option for noobs than Pygame.
So here you have buttons and lots of OOP bloat as a consequence.



Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Goto

[Mikhail V]

MRAB wrote:


> It's OK for code that's close to the metal, but in high-level code? No.
> Python has managed for >25 years without it, and I've yet to see a
> convincing use-case.

"convincing" is a broad term I think, especially for syntax proposals ;)

I think often one wish to use it just to avoid "if" blocks in
obvious situations - no need to setup flags and  indent/unindent code blocks.

Apart from that, I personally would prefer it in such typical code:

if a :
a()
goto "end"
if b :
b()
goto "end"
if c :
c()
goto "end"
"end"

I know I can do it with "elif", but "elif" is just not my cup of tea.
For this case goto provides symmetrical and explicit look, which I value a lot.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Increasing the diversity of people who write Python

[Mikhail V]

On Mon, Nov 27, 2017 at 8:09 PM, Alexandre Brault  wrote:
> A quick Google search turned up WinCompose. It defaults to Right-Alt for
> its compose key, but that's configurable
>
> On 2017-11-27 02:05 PM, Paul Moore wrote:
>> On 27 November 2017 at 18:13, Skip Montanaro  
>> wrote:
 If you have a Windows key, you can assign it to be
 the Compose key.
>>> Would this be true on a machine running Windows? My work environment
>>> has me developing on Linux, with a Windows desktop. It's not clear to
>>> me that any sort of xmodmap shennanigans would work. Won't Windows
>>> itself always gobble up that key?
>> Programs can access the Windows key. IIRC, there is a utility that
>> provides compose-key functionality on Windows. I can't recall the name
>> right now and it's on my other PC, not this one, but I'll try to
>> remember to post the name tomorrow...
>>
>> Paul


On Windows people usually use AHK (Autohotkey).
It is a programming language, so you can do anything you
want. For example, here is a script that converts two
characters to the left of current cursor position:
if it is "e" followed by apostrophe then it replaces it with é,

;---
#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%

parse_clip(str) {
firstchar := substr(str, 1,1)
lastchar := substr(str, 2,2)
if  (lastchar = "'") {
if (firstchar = "e") {
Send, {raw}é
}
if (firstchar = "a") {
Send, {raw}á
}
}
else {
Send, {right}
}
}


Esc:: ExitApp

!c::
clipboard := ""
Send, {Shift down}{left}{left}{Shift up}
Send, ^c
Clipwait, 1
gettext := clipboard
parse_clip(gettext)
return

;---

So here the command is bound to Alt-C,
it selects two previus chars (shift+arrow commands), copies to clipboard
and parses the contents. It works system-wide, but
can be programmed to specific app as well.
Best thing is, you can program it youself as you like.
However if you want to program with AHK,
be prepared to invest time, it is not the easiest
programming language out there, only built-ins
probably more than hundred, so better not try to code without
syntax highlighting :)
.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 11:26 PM, Richard Damon
 wrote:
>
> Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in
> fact it is in XID_START) so should be available.
>

Hi Richard.

U+2010 is SyntaxError.
5 days ago I made a proposal on python-ideas, and we have already discussed
many aspects including straw-man arguments about fonts,etc


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 9:08 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Nov 25, 2017 at 7:00 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> I agree that one should have more choices, but
>> people still can't really choose many things.
>> I can't choose hyphen, I can't choose minus sign,
>> and many tech people would probably want more operators.
>> It counts probably not so *big* amount of people, compared to *all*
>> people that potentially would say "oh how wonderful is it to be able
>> to write in various scripts", still it is just a "use it at your own risk"
>> thing at a minimum, and merely based on emotions rather than
>> common sense.
>>
>> Regardless of what Unicode decides for classifications, there simply must
>> be careful analysis how the major *Python* code actually looks in the end
>> of all experiments. Especially true for characters in regard
>> identifiers versus operators.
>
> And it's the "identifiers versus operators" question that is why you
> can't use hyphen in an identifier. Underscore is available as an ASCII
> joiner, and there are various non-ASCII joiners available too. Why is
> hyphen so important?

Yes I understand this, so it is how Unicode defines joiners.
Yeah, debates about the classifications can be
hold forever, but one should not forget about the hyphen during
these debates. Hyphen is used I think more then six hundreds
years as a joiner (or probably some other classification term one prefer).
And just comes so it works very well.
Among Unicode joiners, middledot reminds of hyphen,
but it is not used in typography for this task. So it is not good option
and has issues in most fonts (too small or not aligned with lowercase).
Often it is used to show up whitespace in editors,
so it is kind of 'reserved'.
Other joiners in unicode classification - well probably ok for a 1st April
proposal.

About importance, it was already covered in the proposal.
Why it is SO important? It is rhetorical question.
Important compared to what? Compared to the question, what
one will eat and where sleep tomorrow? Then it is not so important.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 5:37 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Sat, Nov 25, 2017 at 3:33 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico <ros...@gmail.com> wrote:
>>
>>>> and in Python in particular, because they will be not only forced to learn
>>>> some english, but also will have all 'pleasures' of  multi-script editing.
>>>> But wait, probably one can write python code in, say Arabic script *only*?
>>>> How about such feature proposal?
>>>
>>> If Python supports ASCII identifiers only, people have no choice but
>>> to transliterate. As it is, people get to choose which is better for
>>> them - to transliterate or not to transliterate, that is the
>>> readability question.
>>
>> Sure, let them choose.
>> Transliteration though is way more reasonable solution.
>
> That right there has settled it: you agree that identifiers have to
> use the broader Unicode set, not limited to ASCII. Otherwise they
> can't choose. Everything else is down to style guides; the language
> MUST support all alphabets so that people have this choice.

That's a valid and somewhat obvious point.
I agree that one should have more choices, but
people still can't really choose many things.
I can't choose hyphen, I can't choose minus sign,
and many tech people would probably want more operators.
It counts probably not so *big* amount of people, compared to *all*
people that potentially would say "oh how wonderful is it to be able
to write in various scripts", still it is just a "use it at your own risk"
thing at a minimum, and merely based on emotions rather than
common sense.

Regardless of what Unicode decides for classifications, there simply must
be careful analysis how the major *Python* code actually looks in the end
of all experiments. Especially true for characters in regard
identifiers versus operators.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico  wrote:

>> and in Python in particular, because they will be not only forced to learn
>> some english, but also will have all 'pleasures' of  multi-script editing.
>> But wait, probably one can write python code in, say Arabic script *only*?
>> How about such feature proposal?
>
> If Python supports ASCII identifiers only, people have no choice but
> to transliterate. As it is, people get to choose which is better for
> them - to transliterate or not to transliterate, that is the
> readability question.

Sure, let them choose.
Transliteration though is way more reasonable solution.

>
>> As for non-english speaker who know some English already,
>> could of course want to include identifiers in those scripts.
>> But how about libraries?
>
> If you want to use numpy, you have to understand the language of
> numpy. That's a lot of technical jargon, so even if you understand
> English, you have to learn that. So there's ultimately no difference.

That's what I'm saying. There will be anyway major parts of code in
English and pretty much every already existing modules that can
further  help the developer will be in English, like it or not.

>> Ok, so we return back to my original question: apart from
>> ability to do so, how beneficial is it on a pragmatical basis?
>> I mean, e.g. Cyrillic will introduce homoglyph issues.
>> CJK and Arabic scripts are metrically and optically incompatible with
>> latin, so such mixing will end up with messy look. So just for
>> the experiment, yes, it's fun.
>
> Does it really introduce homoglyph issues in real-world situations,
> though? Are there really cases where people can't figure out from
> context what's going on? I haven't seen that happening. Usually there
> are *entire words* (and more) in a single language, making it pretty
> easy to figure out.

The issues can be discussed long, but I have no doubt that even placing words
in two different scripts on one text line is a bad idea, not only for source
code. For mixing Cyrillic+Latin, yes, this also causes extra issues due to
homoglyphs in many cases, I know it practically from everyday work with
Cyrillic filenames, and from past experience with English-Russian textbooks.
In textbooks at least I can help it by proper layout - separating them
in tables,
or putting in quotes or bold for inline usage.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 4:13 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Nov 24, 2017 at 1:44 PM, Mikhail V <mikhail...@gmail.com> wrote:
>> From my above example, you could probably see that I prefer somewhat
>> middle-sized identifiers, one-two syllables. And naturally, they tend to
>> reflect some process/meaining, it is not always achievable,
>> but yes there is such a natural tendency, although by me personally
>> not so strong, and quite often I use totally meaningless names,
>> mainly to avoid visual similarity to already created names.
>> So for very expanded names, it ends up with a lot of underscores :(
>
> Okay. So if it makes sense for you to use English words instead of
> individual letters, since you are fluent in English, does it stand to
> reason that it would make sense for other programmers to use Russian,
> Norwegian, Hebrew, Korean, or Japanese words the same way?

I don't know. Probably, especially if those *programmers* don't know latin
letters, then they would want to write code with their letters and their
language. This target group, as I said, will have really hard time
with programming,
and in Python in particular, because they will be not only forced to learn
some english, but also will have all 'pleasures' of  multi-script editing.
But wait, probably one can write python code in, say Arabic script *only*?
How about such feature proposal?

As for non-english speaker who know some English already,
could of course want to include identifiers in those scripts.
But how about libraries?
Ok, so we return back to my original question: apart from
ability to do so, how beneficial is it on a pragmatical basis?
I mean, e.g. Cyrillic will introduce homoglyph issues.
CJK and Arabic scripts are metrically and optically incompatible with
latin, so such mixing will end up with messy look. So just for
the experiment, yes, it's fun.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 10:05 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Nov 24, 2017 at 8:02 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico <ros...@gmail.com> wrote:
>>> On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V <mikhail...@gmail.com> wrote:
>>>> I see you manually 'optimise' the look?
>>>> I personally would end with something like this:
>>>>
>>>> def zip_longest(*A, **K):
>>>> value = K.get ('fillvalue')
>>>> count = len(a) - 1
>>>> def sentinel():
>>>> nonlocal count
>>>> if not count:
>>>> raise ZipExhausted
>>>> count -= 1
>>>> yield  value
>>>> fillers = repeat (value)
>>>> iterators = [chain (it, sentinel(), fillers) for it in A]
>>>> try:
>>>> while iterators:
>>>> yield tuple (map (next, iterators))
>>>> except ZipExhausted:
>>>> pass
>>>>
>>>>
>>>> So I would say, my option would be something inbetween.
>>>> Note that I tweaked it for proportional font, namely Times New Roman.
>>
>>> I don't see how the font applies here, but whatever.
>>
>> For a different font, say CourierNew (monospaced) the tweaking strategy might
>> be different.
>
> If you have ANY font-specific "tweaking", you're doing it wrong.
> Thanks for making it look worse on everyone else's screen.

Trolling attempt counted :)
No I don't have any particular font-specific strategy,
it is just my wording reflecting the fact that things look different
in different fonts, even among proportional fonts.


>
>>> Which is better? The one-letter names or the longer ones that tie in with 
>>> what they're
>>> doing?
>>
>> I think I have answered more or less in previous post, that you cutted off.
>> So you were not satisfied?
>> But now I am probably not get your 'better' meaning.
>> Better for understanding, or purely visually, i.e. less eye-straining?
>
> Which one would you prefer to maintain? Which would you prefer in a code 
> review?
>
> Do you want to have one- and two-letter variable names, or longer and
> more descriptive ones?
>
> Seriously? Do I need to wrench this part out of you? This was supposed
> to be the EASY question that everyone can agree on, from which I can
> then draw my line of argument.


>From my above example, you could probably see that I prefer somewhat
middle-sized identifiers, one-two syllables. And naturally, they tend to
reflect some process/meaining, it is not always achievable,
but yes there is such a natural tendency, although by me personally
not so strong, and quite often I use totally meaningless names,
mainly to avoid visual similarity to already created names.
So for very expanded names, it ends up with a lot of underscores :(


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> I see you manually 'optimise' the look?
>> I personally would end with something like this:
>>
>> def zip_longest(*A, **K):
>> value = K.get ('fillvalue')
>> count = len(a) - 1
>> def sentinel():
>> nonlocal count
>> if not count:
>> raise ZipExhausted
>> count -= 1
>> yield  value
>> fillers = repeat (value)
>> iterators = [chain (it, sentinel(), fillers) for it in A]
>> try:
>> while iterators:
>> yield tuple (map (next, iterators))
>> except ZipExhausted:
>> pass
>>
>>
>> So I would say, my option would be something inbetween.
>> Note that I tweaked it for proportional font, namely Times New Roman.

> I don't see how the font applies here, but whatever.

For a different font, say CourierNew (monospaced) the tweaking strategy might
be different.

> Which is better? The one-letter names or the longer ones that tie in with 
> what they're
> doing?

I think I have answered more or less in previous post, that you cutted off.
So you were not satisfied?
But now I am probably not get your 'better' meaning.
Better for understanding, or purely visually, i.e. less eye-straining?

> Also, why do you have those loose spaces stuck in random places, eg
> before some of the open parentheses but not others?

Is it not allowed? I like how it looks with Times font.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 8:15 PM, Chris Angelico  wrote:

>
> Let's start with a simpler question. Which of these is better code?
>
> # == Option 1
> class ZipExhausted(Exception):
> pass
>
> def zip_longest(*args, **kwds):
> # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
> fillvalue = kwds.get('fillvalue')
> counter = len(args) - 1
> def sentinel():
> nonlocal counter
> if not counter:
> raise ZipExhausted
> counter -= 1
> yield fillvalue
> fillers = repeat(fillvalue)
> iterators = [chain(it, sentinel(), fillers) for it in args]
> try:
> while iterators:
> yield tuple(map(next, iterators))
> except ZipExhausted:
> pass
>
> # = Option 2
>
> class e(Exception):
> pass
>
> def zl(*a, **k):
> f = f.get('fillvalue')
> c = len(a) - 1
> def s():
> nonlocal c
> if not c:
> raise e
> c -= 1
> yield f
> ff = repeat(f)
> i = [chain(i, s(), ff) for i in args]
> try:
> while i:
> yield tuple(map(next, i))
> except e:
> pass
>
> # 
>
> One of them is cribbed straight from the itertools docs. The other is
> the same functionality with shorter variable names. What makes one of
> them better than the other? Answer me that, and I'll continue.


I see you manually 'optimise' the look?
I personally would end with something like this:

def zip_longest(*A, **K):
value = K.get ('fillvalue')
count = len(a) - 1
def sentinel():
nonlocal count
if not count:
raise ZipExhausted
count -= 1
yield  value
fillers = repeat (value)
iterators = [chain (it, sentinel(), fillers) for it in A]
try:
while iterators:
yield tuple (map (next, iterators))
except ZipExhausted:
pass


So I would say, my option would be something inbetween.
Note that I tweaked it for proportional font, namely Times New Roman.

Particularly I find too narrow lines/words a bit eye-straining at times.
Also self-explanation is important in many cases. But that depends of
what context you cut the example.

But if you only ask which code of two looks better for me,
then, probably Second, but it has some issues for me, e.g. "c" and "e"
almost homoglyhs, too loose 'sieve'-like, short lines.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 8:46 PM, Thomas Jollans <t...@tjol.eu> wrote:
> On 23/11/17 19:42, Mikhail V wrote:
>> I mean for a real practical situation - for example for an average
>> Python programmer or someone who seeks a programmer job.
>> And who does not have a 500-key keyboard,
>
> I don't think it's too much to ask for a programmer to have the
> technology and expertise necessary to type their own language in its
> proper alphabet.

And I don't think it is too much of benefit of using two scripts in one
source to compensate the need to constantly switching. Do you
have a method to input e.g. Cyrillic and Latin without switching the
layout? If I just use few extra chars, then I'll bind a keyboard shortcut.
but even a two-language input is annoyance.
And I need to use Cyrillic and Latin constantly, so I know how it feels.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

Chris A wrote:

>> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote:
>>
>>> Chris A wrote:
>>>
>>> Fortunately for the world, you're not the one who decided which
>>> characters were permitted in Python identifiers. The ability to use
>>> non-English words for function/variable names is of huge value; the
>>> ability to use a hyphen is of some value, but not nearly as much.
>>
>> Fortunately for the world we have Chris A. Who knows what is
>> fortunate and of huge values.
>> So is there any real world projects example of usage of non-latin scripts
>> in identifiers? Or is it still only a plan for the new world?


> Yes, I've used them personally. And I know other people who have.


Oh, I though it would be more impressive showcase for 'huge value'.
If we drop the benefit of the bare fact that you can do it, or you just
don't know English, how would describe the practical benefit?
If you don't know english, then programming at all will be just too hard.
(or one must define a new whole language specially for some local script)

I mean for a real practical situation - for example for an average
Python programmer or someone who seeks a programmer job.
And who does not have a 500-key keyboard, and who has
a not enough high threshold of vision sensitivity to bear the look
of various scripts in one small text piece?

Ok, I personally could find some practical usage for that, but
merely for fun. I doubt though that someone with less
typographical experience and overall computer literacy could
really make benefits even for personal usage.

So - fun is one benefit. And fun is important. But is that the
idea behind it?


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Allow additional separator character in variables

[Mikhail V]

Chris A wrote:

On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V  wrote:
>
> > Well, then there is some bitter irony in this, so it allows pretty
> > much everything,
> > but does not allow me to beautify code with hyphens.
> > I can fully understand the wish to use non-latin scripts in strings or 
> > comments.
> > As for identifiers, IMO, apart from latin letters and underscore, the
> > first unicode candidate
> > I would add is U+2010. And probably the LAST one I would add.
> >
>
> Fortunately for the world, you're not the one who decided which
> characters were permitted in Python identifiers. The ability to use
> non-English words for function/variable names is of huge value; the
> ability to use a hyphen is of some value, but not nearly as much.
>


Fortunately for the world we have Chris A. Who knows what is
fortunate and of huge values.
So is there any real world projects example of usage of non-latin scripts
in identifiers? Or is it still only a plan for the new world?


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to read in the newsreader

[Mikhail V]

Thomas wrote:
>
> On 16/10/17 20:02, Pete Forman wrote:
> > Thomas Jollans  writes:
> > ...
> >>> If you do stick with a digest then check your newsreader for a feature
> >>> to expand it. Then you can read and reply as if you were getting
> >>> individual posts.
> >>>
> >> That exists? How does it work?
> >
> > The Gnus newsreader in Emacs allows you to type C-d on a digest to run
> > gnus-summary-enter-digest-group. That then behaves the same as if you
> > opened any other summary such as a regular Usenet group.
> >
>
> Does it set the References header correctly when replying?

Hi Thomas, regarding the issue with my reply-to header you told me recently -
Does this message looks ok in your threaded view now?

Now I reply by the href of the message I looked up in pipermail archive,
just curious if it looks now correctly.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Lies in education [was Re: The "loop and a half"]

[Mikhail V]

Bill wrote:
> Mikhail V wrote:
> > Python? Superior syntax for sure
>
> I believe that.  What accounts for the popularity of PHP then?


I can't tell for PHP for sure... As in many cases in software world, there is
a principle of "who was the first there to solve some task".
Probably also it was bundled with many Web solutions at the time when
Web market started to grow, IDK.


PS Off-topic:
I have a related observation regarding popularity of software.
There is such a program "VLC", which is a video player. Some would
think it is sort of best free player, etc. I was also under impression,
but then I've found a video player called "MPC-HC".
I have started to use it and quickly understood that it is by far more
superior player than VLC, literally by all core parameters - performance,
codec support, customizable key bindings with a lot of internal commands.
(Remark for Linux users: there is no Linux version of that player, it
is Windows-only)

So, I think one key to popularity is mostly related to *marketing*, in
case of MPC, there is also a problem of a *good name* for the software.
Once I was trying to remember, what was that nice player and just couldnt
remember. MPC, MTC, HTC... So if it was from the beginning somthing
more catchy like "Vulcano" or "Tornado" then I bet it would had way
bigger user community now. And surprisingly, VLC seems to be
more popular (if we take Windows), despite
it can't even read some video formats, which MPC can.
So go figure. Most important, one should not rely on those
trashy "Top-10 ..." articles, and don't judge by the fancy GUI,
 but try the software yourself for some time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Lies in education [was Re: The "loop and a half"]

[Mikhail V]

> >> [...] I'm not here to "cast stones", I like Python. I just think
> >> that you shouldn't cast stones at C/C++.
> > Not while PHP exists.  There aren't enough stones in the world...
> >
>
> PHP seems (seemed?) popular for laying out web pages.  Are their vastly
> superior options?

Python? Superior syntax for sure
-- 
https://mail.python.org/mailman/listinfo/python-list

Keyboard Input [was: The "loop and a half"]

[Mikhail V]

Chris Angelico wrote:

> On Mon, Oct 9, 2017 at 7:05 PM, Mikhail V  wrote:
> > The first thing a developer should provide - the keys and mouse input
> > should be
> > *customizable* by the user. It is so by most serious application I have
> > ever used.
>
> And they most certainly are. Often, in something in the host platform.
> For instance, Xfce allows me to change the keys used for various
> purposes, by going into the menu and choosing "Settings" and then
> "Keyboard". (Or, of course, by editing the config files.) The most
> obvious and dramatic change you can do is to choose a specific
> keyboard layout - Qwerty vs Dvorak, US vs German, etc, etc, etc. Do
> you think that sort of thing should be in the hands of the
> application, or the platform? (Note that I'm not saying "OS" here.
> Usually the platform is at a higher level than that; in my case, I
> would consider Xfce (my desktop manager) to be that.)


I am not sure I correctly understand your question.
Do you ask whether the application should bypass the OS
selected layout and use own character input tables?
It is of course possible, but since the OS provides
input events, why not use those?
We were speaking about a text editor, so yes this
will be useful if one wants multilingual text input.

Also I am almost sure I can programmatically switch
the layout pages from Python (some Winapi calls I suppose)
So theoretically, based only on keyb scancodes, one
can use own LUTS and flags to replicate the unicode
input. I personally never wrote apps with multilingual text input though.

Seems that for keyboard input everything is already invented and
well-established.
Below is a minimal app showing pressed keys.
Try switching layouts and see 'unicode'  field changing for
same key scancode.


import pygame
pygame.init()
window_w = 300# display width
window_h = 200# display height
pygame.display.set_mode((window_w, window_h))
clock = pygame.time.Clock( )
FPS = 15
MainLoop = True
while MainLoop :
clock.tick(FPS)
for E in pygame.event.get():
if E.type == pygame.QUIT:
MainLoop = False
if E.type == pygame.KEYDOWN:
print (E)
if E.key == pygame.K_ESCAPE:
MainLoop = False
pygame.quit( )




Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

The "loop and a half"

[Mikhail V]

>>> Have you ever worked on a slow remote session where a GUI is
>>> completely impracticable (or maybe even unavailable), and redrawing
>>> the screen is too expensive to do all the time?
>>
>> So where does the redrawing happen? The machine youre sitting on (let's
>> call it 'A') and send remote commands or retrieving text files? Or the
>> redrawing must be synced on both A and
>> the remote machine? If so, then why so?

Peter J. Holzer wrote:

> Because you want to see what you are typing. Imagine you are logged into
> a server on the other side of the world. You want to edit a file on that
> machine (for example a configuration file for the web server). You
> invoke the editor on that server.

I've never done this, but if one told me to edit a file,
my first attempt would be like:
- get read/write access to the file system
- browse it (e.g. some file browser plugin?)
- get the file to the local machine
- edit locally
- write it back to the remote machine


>> And not in a nice editor with normal fonts?
>> Am i missing something or your 'A' machine cannot use graphics?

> ... The server may not be able to
> (it's a server, why would anyone install a GUI on it?)

If I ever work on it (locally) why would I want a GUI on it?
o_O   I'm not sure if I'm getting you.
You mean probably a server which is never worked on locally?
If it has a display and a keyb, and I must do something on it, even
seldom, then certainly I want a GUI on it (not just to see
a desktop wallpaper ;).

> streaming the screen contents of a rich GUI around the world may be not
> be possible for bandwidth or delay reasons.
Sure, streaming video consumes a lot, but that is what one tries to
avoid if under limitations so streaming messages only is faster.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

The "loop and a half"

[Mikhail V]

bartc wrote:
>> Your job is to port an editor that people have been using for 30 years to
>> Linux. The first thing you do is to change all the commands and
shortcuts to
>> match what is typical on Linux? So that no-one who was familiar with it
as
>> it was can actually use it?

Chris Angelico wrote:
> Is it graphical? Does it use any well-known toolkit? If so, then yeah,
> the first thing - and the automatic thing - is that it will respond to
> the host platform's keys and so on.

In case of a toolkit probably, but generally there is no such thing as
"host platform's keys" in context of a desktop application. There are keys
which the application defines.
OS is used only to run the application, (some system keys, e.g. Alt-Tab,
Ctrl-Alt-del, are of course better left alone).

The first thing a developer should provide - the keys and mouse input
should be
*customizable* by the user. It is so by most serious application I have
ever used.
(I don't know though if it is so in Bart's application)
Anything that can not - is for me 'below the bar' usability straightaway.
(With the exception when the defaults are so good that there is no much
need to redefine them, or it is a very simple app with only few input
commands)
Some frameworks do not provide such customization and that is simply bad
design.

The second thing - the default keys should be optimized for
the input efficiency and ergonomics.

Other issues, e.g. whether the keys are same as in some other app or not,
becomes irrelevant if the app fulfils the first two criteria (see above).
If not, I would consider looking for an alternative app with
customizable keys.

bartc wrote:
>> * Under Windows, if you press Shift while Caps Lock is on, you get lower
>> case letters. I've never, ever wanted to do this (probably no one else
has).
>> My own editor doesn't obey that convention: shift-A will always come out
as
>> 'A' whatever the caps lock setting.
>>
>> There are dozens more, yet you are surprised why sometimes I prefer doing
>> things my own way? There are good reasons!

Chris Angelico wrote:
>Yep. Good reasons like that you're a moron. You assume that
> since *you* have never needed to produce one lower-case letter
> in a block of upper-case, that "probably no one else has",
> and then you make it impossible to do that in your editor.
> I have wanted to produce a lower-case letter by holding Shift.

I think I've never advocated anybody on the list, but here
I really don't understand why you are attacking Bart.
In this particular Caps lock example - it's pretty clear for me that the
input of lowercase letters with Shift is historically there just for the
'symmetry'.
Obviously there is zero practical need for that in general case,
so "probably no one else need this" is quite appropriate statement.

> I have wanted to produce a lower-case letter by holding Shift.
Ok, once in my life I have wanted too, just to see what happens, which
does not mean that this feature has any value.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

The "loop and a half"

[Mikhail V]

bartc wrote:
>> But as it happens, I could make computers talk to each when I was working
>> with microprocessors, using home-made interfaces, rs232 or rs423. I
wouldn't
>> know how to do it now because it depends on other people's over-complex
>> tech.

Chris Angelico wrote:
> I don't know if you're an idiot or a troll. Using TCP/IP networking is
> pretty simple (at least if you're using a real language - your own toy
> languages might have made it unnecessarily hard, for all I know),
> hardly "over-complex" by comparison to RS-232 programming.

I suppose he is a programmer who is just not much interested in
networking and what you can do in beloved console.
And if you have remote editing you still need
to work in a line by line input?

Just for people like me who know nothing about networking,
can you popularly explain the :

> Have you ever worked on a slow remote session where a GUI is
> completely impracticable (or maybe even unavailable), and redrawing
> the screen is too expensive to do all the time?

So where does the redrawing happen? The machine youre sitting on (let's
call it 'A') and send remote commands or retrieving text files? Or the
redrawing must be synced on both A and
the remote machine? If so, then why so?
How does the bandwidth implies that you must edit stuff in the console on
A?
And not in a nice editor with normal fonts?
Am i missing something or your 'A' machine cannot use graphics? Even on 386
computers
there was graphics and keybord input. That is definitely what I would
want
for editing files. Yes I've tried line by line eding back in DOS times and
that really sucks.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Proposed new syntax

[Mikhail V]

>
> What would you expect this syntax to return?
>
> [x + 1 for x in (0, 1, 2, 999, 3, 4) while x < 5]
>

Nice question BTW
I'd suppose two possible outcomes:
a) It will behave exactly the same as if there was "if" instead of "while"
so [1, 2, 3, 4, 5].
b) It will return  syntax error, because "while" is a loop statement withot
following colon and anything.
but at a first glance, "while" reads as "if" as in english.


For comparison, what would you expect this to return? (Without actually
> trying
> it, thank you.)
>
> [x + 1 for x in (0, 1, 2, 999, 3, 4) if x < 5]
>
>
I'd say it will return: [1, 2, 3, 4, 5]


How about these?
>
> [x + y for x in (0, 1, 2, 999, 3, 4) while x < 5 for y in (100, 200)]
>
> [x + y for x in (0, 1, 2, 999, 3, 4) if x < 5 for y in (100, 200)]
>

No idea... cognitive dissonans ;)

By answering I did not test it and did not look into others answers,
serious.
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

Steven D'Aprano wrote:

>On Wed, 19 Jul 2017 10:34 am, Mikhail V wrote:
>> Ok, in this narrow context I can also agree.
>> But in slightly wider context that phrase may sound almost like:
>> "neither geometrical shape is better than the other as a basis
>> for a wheel. If you have polygonal wheels, they are still called wheels."


> I'm not talking about wheels, I'm talking about writing systems which are
> fundamentally collections of arbitrary shapes. There's nothing about the sound
> of "f" that looks like the letter "f".

> But since you mentioned non-circular wheels, such things do exist, and are 
> still
> called "wheels" (or "gears", which is a kind of specialised wheel).

> https://eric.ed.gov/?id=EJ937593
> https://en.wikipedia.org/wiki/Non-circular_gear
> https://en.wikipedia.org/wiki/Square_wheel
> https://www.youtube.com/watch?v=vk7s4PfvCZg


Triangular wheels, sure, why not?
A default "wheel" in a conversation, unless other meaning stated,
is a common wheel of a bike or a car. At least I believe so, but since I'm
non-native speaker I may be wrong.

As well as the default merit of goodness of a writing system is how
easy one can read texts in it (_a healthy person, done with the
learning process_).

Fundamentally, yes, a system in theory can be a set of _any_ shapes.
This means that its goodness, in respect to the shapes alone,
can vary from absolute zero (as e.g. in a hand-written recipe from a doctor :)
and up to the optimum domain.

Even if we take more obvious criteria - the ease of input -
I suppose it is obvious that inputting German text by rules which need initial
Caps in _all_ nouns, is harder than inputting the same text without Caps.
Same for inputting diacritics.
It is also pretty obvious that these Caps makes it harder to read in general.
(more obvious that excessive diacritics, like in French)

Thus, even in a narrow context, "no system is better or worse" sounds very
suspect to me.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

ChrisA wrote:
>On Wed, Jul 19, 2017 at 6:05 AM, Mikhail V  wrote:
>> On 2017-07-18, Steve D'Aprano <steve+python at pearwood.info> wrote:
>>
>>> That's neither better nor worse than the system used by English and French,
>>> where letters with dicritics are not distinct letters, but guides to
>>> pronunciation.
>>
>>>_Neither system is right or wrong, or better than the other._
>>
>>
>> If that is said just "not to hurt anybody" then its ok.
>> Though this statement is pretty absurd, not so many
>> (intelligent) people will buy this out today.

>Let me give you one concrete example: the letter "ö". In English, it
>is (very occasionally) used to indicate diaeresis, where a pair of
>letters is not a double letter - for example, "coöperate". (You can
>also hyphenate, "co-operate".) In German, it is the letter "o" with a
>pronunciation mark (umlaut), and is considered the same letter as "o".
>In Swedish, it is a distinct letter, alphabetized last (following z,
>å, and ä, in that order). But in all these languages, it's represented
>the exact same way.
>
>Steven is pointing out that there's nothing fundamentally wrong about
>using "ö" as a unique letter, nor is there anything fundamentally
>wrong about using it as "o" with a pronunciation mark. Which I agree
>with.
>

Ok, in this narrow context I can also agree.
But in slightly wider context that phrase may sound almost like:
"neither geometrical shape is better than the other as a basis
for a wheel. If you have polygonal wheels, they are still called wheels."


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

Marko Rauhamaa wrote:

>What did you think of my concrete examples, then? (Say, finding
>"Alvárez" with the regular expression "Alv[aá]rez".)

I think that should match both "Alvarez" and "Alvárez" ...?
But firstly, I feel like I need to _guess_ what ideas you
are presenting. Unless I open up Vim and apply my imagination,
it is hard even to get involved in your ideas.
I wonder why it is hard to elaborate a pair
of examples like e.g. :
- now the task A (concrete task defined) is solved with the code C1
- with the new syntax/method, the same task could be solved with the code C2

Just trying to guess related tasks:
For the automation of regex search-related tasks I would make a function
which generates the RE pattern first, i.e. define tables with
"variations" for glyphs, e.g. groups={"a": "aá"} or similar.
Then I'll need some micro-syntax for the conversion,
e.g. generate_re("Alv{a}rez", groups)

Intuitively, I suppose the groupings and even
the functions hardly can be standardized in a nice manner,
since I'll need to define and redefine them all the time for various cases.
But probably there can be some generality, hard to say.

What I need often is the "approximate" search function,
which returns a match "similar" to the input string. But I think even
the regex module
cannot fully solve this and I would end up with a function
which goes through each string element and calculate various
similarity criteria.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

On 2017-07-18, Steve D'Aprano  wrote:

> That's neither better nor worse than the system used by English and French,
> where letters with dicritics are not distinct letters, but guides to
> pronunciation.

>_Neither system is right or wrong, or better than the other._


If that is said just "not to hurt anybody" then its ok.
Though this statement is pretty absurd, not so many
(intelligent) people will buy this out today.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

ChrisA wrote:

>Yep! Nobody would take any notice of the fact that you just put dots
>on all those letters. It's not like it's going to make any difference
>to anything. We're not dealing with matters of life and death here.

>Oh wait.

>https://www.theinquirer.net/inquirer/news/1017243/cellphone-localisation-glitch

>I'll leave you with that thought.


For Turkish and Slavic languages there is actually
a demand for at least one Yeru letter to distinguish
the common i  and Yeru. In cyrillic it is "ы".
It should be romanized as "y".
And the Yot /j/ should be romanized as "j".
I.e. for Turkish:
yazım - should be : jazym
For Russian:
ярлык - should be : jarlyk

Simple, asscii input, no ambiguity.
How many exercises in futility could be avoided...

And just in case still its not clear: this is not
solved by adding dirt around the letter: if there is
enough significance of the phoneme distinction then
one should add a distinct letter for a syntax in question.

And not like: well it is not so significant then we'll
add a bit of dirt, it is more significant - we add some more dirt.
It is not how the textual representation is made effecient.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

 ChrisA wrote:

>On Sun, Jul 16, 2017 at 2:33 PM, Rustom Mody  wrote:
>> Right now in an adjacent mailing list (debian) I see someone signed off with 
>> a
>>
>> grüß
>>
>> I guess the third character is a u with some ‘dirt’
>> Whats the fourth?

>It's a "sharp S".

or "Eszett", is a merge of two symbols that were used in old german
texts: "f"-like glyph
and "s" glyph, i.e. sort of ligature. Or simply, ß is a symbol that is
quite similar to "B".

I would just write : gruss
since it is simpler to type and has cleaner look.
"ß" is sort of deprecated, often subsituted with "ss". If I am not mistaken,
this substitution is oficially allowed in many regions (what a liberality!).

>>Heck even in the English that I learnt in school we had
>>ægis, homœopath etc

Similar to the above, historical symbols. These are (should be)
deprecated due to
legibility issues, roughly speaking. OTOH good for freaking-out.
Like: I was in Ægypt. and a reader so: aaagypt


 ChrisA wrote:
>Tell me, is "å" an a with some 'dirt', or is it a separate character?

From the way you are asking, it seems that you are planning some tricky
business again... Hope not to argue on terminology again, å simply
makes the text flow inconsistent, such things are parasitic for
readability regardless if someone proclaims it a separate character or
not. In a reader-oriented medium should be used only as a last resort.

Looks like "a" whith a circle above, so yes, an "a" with a good deal of dirt.

>Is "i" an ı with some dirt, or a separate letter? Oh wait, you
>probably think that "i" is a letter, and "ı" is the same letter but
>with some dirt missing.

 "i" is a letter, you can't just remove the dot. So there can be just
dirt and there is
'dirt' which is in fact the natural part of the letter. Like a serif
for example.
but I am not expecting your acceptance of these statements,
I am just telling what follows from my long experience with the topic.
Though you can try to replace "i" with "ı" globally in a text and there
are chances you will notice something. Then you can try also with å.


>What about "p"? Is that just "d" written the
>wrong way up?

Sort of. The early designers did not find a better solution than taking
the rotated version of one glyph. Are you curious about all other letters?
Then probably you should start trying to design a legible typeface.
But ideally you should try to design a typeface from scratch, say some
20 glyphs,
not just a Latin-based variation, but truly from scratch. Then some
question should become more transparent, words are too weak in
transmitting these kind of things.

>At what point does something merit being called a
>different letter?

For truly different, when the structural difference is significant,
i.e. much more significant than the difference
between "ı" and "i". Yes in Turkish both are used.
And what can I say, its misfortunate for the users: suboptimal for
legibility + non ascii typing.
But could be much worse, look at Vietnamese writings.



Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

>> On Sat, 15 Jul 2017 05:50 pm, Marko Rauhamaa wrote:
>>> Random access to code points is as uninteresting as random access to
>>> UTF-8 bytes. I might want random access to the "Grapheme clusters,
>>> a.k.a.real characters".
>>
>> What _real_ characters are you referring to?
>> If your data has "á" (U00E1), then it is one real character,
>> if you have "a" (U0061) and "ˊ" (U02CA) then it is _two_
>> real characters. So in both cases you have access to code points =
>> real characters.

>It's true that confusion is caused by the ambiguity of the term
>"character."

Yes, but you have said "I might want random access to the "Grapheme clusters,
a.k.a. real characters" and I had impression that you have some concrete
concept of grapheme clusters and some (generally useful) example of
implementation.
Without concrete examples it is just juggling with the terms.

>> But opinions may vary, and in case you prefer or forced to write "á",
>> then it can be impractical to store it as two characters, regardless
>> of encoding.

> Now I'm not following you.

For example, I want to type in cyrillic " рекá " (with an acute accent to denote
the stress on the last vowel, say for a pronunciation tutorial).
Most frequent solution to it would be just typing á instead of a.
And it is indeed most pratical: if I use modifier acute accent
character instead,
then it will be hard to select/paste such text and it will  not render
accurately.

Obvious consequences we have: á is not from the cyrillic code range,
eg. it will break hyphenation rules, and it will look consistent only
if the cyrillic font's "a" has exactly the same look as the latin "a".
Not to tell that it is not always possible to find the glyph with the
'right kind of dirt around'.
For such cases, technically better solution would be using separate
accent character to denote a stroke. In case of font issues it would
at least render as, say an apostrophe.
Still in practice, just typing "á" works better because editors and
even some professional DTP software cannot handle context-based glyph
rendering well.
In other words, I think the internal representation should use
separate modifier character, despite it seems impractical from many
points of view. And it _is_ impractical in case one has such
things as "á" as frequent character in normal writing (the latter
should not be the case for adequate modern writing system though).


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Grapheme clusters, a.k.a.real characters

[Mikhail V]

On Sat, 15 Jul 2017 05:50 pm, Marko Rauhamaa wrote:
> Random access to code points is as uninteresting as random access to
> UTF-8 bytes.
> I might want random access to the "Grapheme clusters, a.k.a.real
> characters".

What _real_ characters are you referring to?
If your data has "á" (U00E1), then it is one real character,
if you have "a" (U0061) and "ˊ" (U02CA) then it is _two_
real characters. So in both cases you have access to code points =
real characters.

For metaphysical discussion -  in _my_ definition there
is no such "real" character as "á", since it is the "a" glyph with some dirt,
so according to my definition, it should be two separate characters,
both semantically and technically seen.

And, in my definition, the whole Unicode is a huge junkyard, to start with.

But opinions may vary, and in case you prefer or forced to write "á",
then it can be impractical to store it as two characters, regardless of
encoding.



Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Scala considering significant indentation like Python

[Mikhail V]

> The creator of Scala, Martin Odersky, has proposed introducing Python-like
> significant indentation to Scala and getting rid of braces:
>
>   I was playing for a while now with ways to make Scala's syntax
>indentation-based. I always admired the neatness of Python syntax
>and also found that F# has benefited greatly from its optional
>indentation-based syntax, so much so that nobody seems to use
>the original syntax anymore.
>
> https://github.com/lampepfl/dotty/issues/2491


People sort of like indentation structuring.
It introduces some typography into source code representaion,
and restricts possibilities to [ugly]format the code.
I've looked quickly through the linked discussion, and not sure
if many think of the whole issue globally.

I understand the indentation, as well as many other syntactical tricks
as a trade-off for bringing nice code look in pure *textual* editors.
And that's one part of the indentation concept - a trade-off, assuming that one
looks at the code by means of relatively primitive text renderer.

Once I've came across this blog:
http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs.html

This man seems to have the 'feel' for the whole issue and
I agree with his many points about the tendencies.

So to look slightly further than own nose -
I suppose the era of "char-by-char" code rendering/editing will not
last so long and code editors should deal with the code in
a structured way.
The question how exactly to show structure - as indent,
or vertical lines with nodes, will become just a user setup option,
same as colors, etc.
IOW for future human-oriented development environment,
the look of a source file in an average notepad should become
a secondary criteria, but a better *parse-ability* will become
primary criterion.

Even if speak about 'now' situation - looking e.g. into C code
I understand that braces are not the biggest problem for me.
I can ignore them more or less, but then come other readability
issues - lines starting with type names, unintuitive declarations,
asterisks jumping to the left or right depending on author's habits, etc.

So braces is not the major issue in the whole syntax problematics.
In some cases (though rare and if used with craft) they can help to avoid
unwanted indentations.
For sure an average indented Python code looks way better than
any 'braced' analogue and for common textual presentation
indented blocks is probably the optimal way.



Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String escaping utility for Python (was: Rawest raw string literals)

[Mikhail V]

On 23 April 2017 at 05:03, MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 2017-04-22 23:30, Mikhail V wrote:
>>
>> On 20 April 2017 at 23:54, MRAB <pyt...@mrabarnett.plus.com> wrote:
>> > On 2017-04-20 22:03, Mikhail V wrote:
>> >>
>> >> On 20 April 2017 at 22:43, Random832 <random...@fastmail.com> wrote:
>> >>> [snip]
>> >>>
>> >>> The best solution I can think of is to have a text editor designed to
>> >>> parse a string literal, spawn a nested editor with the unescaped
>> >>> contents of that string literal, and then re-escape it back to place
>> >>> in
>> >>> the code. If we had that, then we wouldn't even need raw strings.
>> >>
>> >>
>> >> Yes exactly, it would be cool to have such a satellite app
>> >> which can escape and unescape strings according to rules.
>> >> And which can also convert unicode literals to their ascii
>> >> analogues and back on the fly, this would very useful
>> >> for programming.
>> >> Probably it is a good idea to even include such thing
>> >> in Python package. So it would be a small standalone app
>> >> running parallel with text editor making it to copy paste strings.
>> >>
>> > I'm sure it's possible in, say, Emacs.
>> >
>> > The editor that I use (EditPad Pro) can call external tools, so I could:
>> >
>> > 1. Select the string literal (easy when it is syntax-aware, so I can
>> > select
>> > all of the literal with 2 keypresses).
>> >
>> > 2. Call the external tool (1 keypress), to open, say, a simple tkinter
>> > app.
>> >
>> > 3. Edit the unescaped text (unescape with ast.literal_eval, re-escape
>> > with
>> > 'ascii').
>> >
>> > 4. Close the external tool, and the selection is replaced.
>>
>> I have done a quick google search and could not find
>> such utility for Python.
>>
>> I am very interested in having such utility.
>> And I think it would be fair that such utility
>> should be made by the Python team so that
>> all syntax nuances will be correctly implemented.
>>
>> The purpose is simple: reduce manual work to escape special
>> characters in string literals (and escape non-ASCII characters).
>>
>> Simple usage scenario:
>> - I have a long command-line string in some text editor.
>> - Copy this string and paste into the utility edit box
>> - In the second edit box same string with escaped characters
>>appears (i.e tab becomes \t, etc)
>> - Further, if I edit the text in the second edit box,
>>an unescaped string appears in the first box.
>>
>> Possible toggle options, e.g. :
>> - 'asciify' non-ascii characters
>>
>> It could be not only useful to eliminate boilerplate typing,
>> but also a great way to learn string rules for Python learners.
>>
> Here's a very simple tkinter GUI app. It only goes one way (plain to escaped
> (asciified)), but it shows what's possible with very little code.
>
>
> #! python3.6
> # -*- coding: utf-8 -*-
> import tkinter as tk
>
> class App(tk.Tk):
> def __init__(self):
> tk.Tk.__init__(self)
> self.title('Escaper')
>
> tk.Label(self, text='Plain string').pack()
>
> self.plain_box = tk.Text(self)
> self.plain_box.pack()
> self.plain_box.focus()
>
> tk.Label(self, text='Escaped string').pack()
>
> self.escaped_box = tk.Text(self)
> self.escaped_box.pack()
>
> self.after(100, self.on_tick)
>
> def on_tick(self):
> plain_string = self.plain_box.get('1.0', 'end')[ : -1]
>
> escaped_string = ascii(plain_string)
>
> self.escaped_box.delete('1.0', 'end')
> self.escaped_box.insert('1.0', escaped_string)
>
> self.after(100, self.on_tick)
>
> App().mainloop()
>

Thank you for sharing! Works fine on Win 7.
So that is what I mean, even such simple app is
uncomparably better that any workarounds and already
covers most cases.
Unfortunately I am not proficient in tkinter so I hope
that will gain some support from other folks and then
could be pinned somewhere and be accessible for
everyone.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String escaping utility for Python (was: Rawest raw string literals)

[Mikhail V]

On 23 April 2017 at 02:33, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Apr 23, 2017 at 10:19 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> On 23 April 2017 at 00:48, Chris Angelico <ros...@gmail.com> wrote:
>>> On Sun, Apr 23, 2017 at 8:30 AM, Mikhail V <mikhail...@gmail.com> wrote:
>>>> The purpose is simple: reduce manual work to escape special
>>>> characters in string literals (and escape non-ASCII characters).
>>>>
>>>> Simple usage scenario:
>>>> - I have a long command-line string in some text editor.
>>>> - Copy this string and paste into the utility edit box
>>>> - In the second edit box same string with escaped characters
>>>>   appears (i.e tab becomes \t, etc)
>>>> - Further, if I edit the text in the second edit box,
>>>>   an unescaped string appears in the first box.
>>>
>>> Easy.
>>>
>>>>>> input()
>>> This string has "quotes" of 'various' «styles», and \backslashes\ too.
>>> 'This string has "quotes" of \'various\' «styles», and \\backslashes\\ too.'
>>>
>>> The repr of a string does pretty much everything you want. If you want
>>> a nice GUI, you can easily put one together that uses repr() to escape
>>> and ast.literal_eval() to unescape.
>>
>> I am sorry, could you elaborate what have you shown here?
>> So in Python console I can become escaped string, but what
>> commands do you use? I never use Python console actually :/
>
> You type "input()" at the Python console, then type the string you
> want. It will be echoed back in representation form, with everything
> correctly escaped.
>
>> And yes the idea is to have a nice GUI. And the idea is exactly opposite
>> to "everyone let's roll an own tool". Obviously I can spend day
>> or two and create such a tool, e.g. with PyQt.
>> But since the task is very common and quite unambiguos I think it is
>> a good reason for a standard official tool.
>
> Or you could spend two seconds firing up the Python REPL, which has
> all the tools you need right there :)
>

Don't know, all I see is "SyntaxError: invalid syntax" if I paste
there some text.
Try to paste e.g. this:
"ffmpeg -i "D:\VIDEO\exp\intro.mp4" -vf "crop=1280:720:0:40,
scale=640:360" -pix_fmt yuv420p  "D:\ART\0MASTER_UMST\yt_pico.mp4""

But are you joking, right? Even if it worked, how can this be convinient,
e.g. in console one cannot even select and copy paste easily.

Probably one can make a python script which takes clipboard contents
then place the conversion result back to clipboard.
Like:
- copy some text to clipboard
- run the script, which replace the clipboard contents with result
- paste text

I haven't tried that, but even this would be very inconvenient and
limited in comparison
to a GUI utility.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: String escaping utility for Python (was: Rawest raw string literals)

[Mikhail V]

On 23 April 2017 at 00:48, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Apr 23, 2017 at 8:30 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> The purpose is simple: reduce manual work to escape special
>> characters in string literals (and escape non-ASCII characters).
>>
>> Simple usage scenario:
>> - I have a long command-line string in some text editor.
>> - Copy this string and paste into the utility edit box
>> - In the second edit box same string with escaped characters
>>   appears (i.e tab becomes \t, etc)
>> - Further, if I edit the text in the second edit box,
>>   an unescaped string appears in the first box.
>
> Easy.
>
>>>> input()
> This string has "quotes" of 'various' «styles», and \backslashes\ too.
> 'This string has "quotes" of \'various\' «styles», and \\backslashes\\ too.'
>
> The repr of a string does pretty much everything you want. If you want
> a nice GUI, you can easily put one together that uses repr() to escape
> and ast.literal_eval() to unescape.

I am sorry, could you elaborate what have you shown here?
So in Python console I can become escaped string, but what
commands do you use? I never use Python console actually :/

And yes the idea is to have a nice GUI. And the idea is exactly opposite
to "everyone let's roll an own tool". Obviously I can spend day
or two and create such a tool, e.g. with PyQt.
But since the task is very common and quite unambiguos I think it is
a good reason for a standard official tool.


>
>> PS:
>> Also I remember now about the python-ideas thread
>> on entering unicode characters with decimals instead of
>> hex values. It was met somewhat negatively but then it turned out
>> that in recent Python version it can be done with f-strings.
>> E.g. a string :
>>
>> s="абв"
>> one can write as:
>> s = f"{1072:c}{1073:c}{1074:c}"
>> instead of traditional hex:
>> "\u0430\u0431\u0432"
>>
>> It was told however this is not normal usage.
>> Still I find it very helpful, so if this is correct syntax, I'd
>> personally find such a conversion option also very useful.
>
> Most of the world finds the hex form MUCH more logical, since Unicode
> is built around 16s and 256s and such. Please don't proliferate more
> messes - currently, the only place I can think of where decimal is
> supported is HTML character entities, and hex is equally supported
> there.
>
> Of course, the best way to represent most non-ASCII characters is as
> themselves - s="абв" from your example. The main exception is
> combining characters and related incomplete forms, such as this table
> of diacritical marks more-or-less lifted from an app of mine:
>
> {
> "\\`":"\u0300","\\'":"\u0301","\\^":"\u0302","\\~":"\u0303",
> "\\-":"\u0304","\\@":"\u0306","\\.":"\u0307","\\\"":"\u0308",
> "\\o":"\u030A","\\=":"\u030B","\\v":"\u030C","\\<":"\u0326",
> "\\,":"\u0327","\\k":"\u0328",
> }
>
> All of them are in the 03xx range. Much easier than pointing out that
> they're in the range 768 to 879. Please stick to hex.

I don't insist on decimals, I want to use decimals for my own pleasure
in own projects, may I?
And don't worry in my whole life I will not produce so many software
that will significantly increase the 'messes'.
(Anyway I've got used already to decimals somehow, ord(char), etc.,
so for me it's too late for the ugly hex)


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

String escaping utility for Python (was: Rawest raw string literals)

[Mikhail V]

On 20 April 2017 at 23:54, MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 2017-04-20 22:03, Mikhail V wrote:
>>
>> On 20 April 2017 at 22:43, Random832 <random...@fastmail.com> wrote:
>>> [snip]
>>>
>>> The best solution I can think of is to have a text editor designed to
>>> parse a string literal, spawn a nested editor with the unescaped
>>> contents of that string literal, and then re-escape it back to place in
>>> the code. If we had that, then we wouldn't even need raw strings.
>>
>>
>> Yes exactly, it would be cool to have such a satellite app
>> which can escape and unescape strings according to rules.
>> And which can also convert unicode literals to their ascii
>> analogues and back on the fly, this would very useful
>> for programming.
>> Probably it is a good idea to even include such thing
>> in Python package. So it would be a small standalone app
>> running parallel with text editor making it to copy paste strings.
>>
> I'm sure it's possible in, say, Emacs.
>
> The editor that I use (EditPad Pro) can call external tools, so I could:
>
> 1. Select the string literal (easy when it is syntax-aware, so I can select
> all of the literal with 2 keypresses).
>
> 2. Call the external tool (1 keypress), to open, say, a simple tkinter app.
>
> 3. Edit the unescaped text (unescape with ast.literal_eval, re-escape with
> 'ascii').
>
> 4. Close the external tool, and the selection is replaced.

I have done a quick google search and could not find
such utility for Python.

I am very interested in having such utility.
And I think it would be fair that such utility
should be made by the Python team so that
all syntax nuances will be correctly implemented.

The purpose is simple: reduce manual work to escape special
characters in string literals (and escape non-ASCII characters).

Simple usage scenario:
- I have a long command-line string in some text editor.
- Copy this string and paste into the utility edit box
- In the second edit box same string with escaped characters
  appears (i.e tab becomes \t, etc)
- Further, if I edit the text in the second edit box,
  an unescaped string appears in the first box.

Possible toggle options, e.g. :
- 'asciify' non-ascii characters

It could be not only useful to eliminate boilerplate typing,
but also a great way to learn string rules for Python learners.


PS:
Also I remember now about the python-ideas thread
on entering unicode characters with decimals instead of
hex values. It was met somewhat negatively but then it turned out
that in recent Python version it can be done with f-strings.
E.g. a string :

s="абв"
one can write as:
s = f"{1072:c}{1073:c}{1074:c}"
instead of traditional hex:
"\u0430\u0431\u0432"

It was told however this is not normal usage.
Still I find it very helpful, so if this is correct syntax, I'd
personally find such a conversion option also very useful.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 18:40, Grant Edwards <grant.b.edwa...@gmail.com> wrote:
> On 2017-04-20, Mikhail V <mikhail...@gmail.com> wrote:
>> On 20 April 2017 at 17:59, Grant Edwards <grant.b.edwa...@gmail.com> wrote:
>>> On 2017-04-20, Mikhail V <mikhail...@gmail.com> wrote:
>>>> Quite often I need raw string literals for concatenating console commands.
>>>> I want to input them exactly as they are in python sources.
>>>>
>>>> There is r"" string, but it is obviously not enough because e.g. this:
>>>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>>>
>>>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>>>
>>> Does that do what you want?
>>
>> Yes but it still needs to watch out if there is no ' inside or vice
>> versa with " characters if use r"". I would like a universal
>> solution.
>
> IOW, you want something that just reads your mind.
>
> How can there exist a "universal solution" even in theory?
>
> There has to be some sort of "end of literal" terminator character
> sequence.  That means there has to be some sort of escaping mechanism
> when that "end of literal" sequence appears in the literal itself.
>

In *theory* one can define what characters can be part of the raw string.
In Python e.g. the newline character cannot be part of
the r"" string (unless a line ends with \):

k = r"abc
  def"

gives an error:

k = r"abc
^
SyntaxError: EOL while scanning string literal

So one could define a rule, that a raw string *must*
be terminated by the sequence quote + newline.
In theory.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 22:43, Random832  wrote:
> On Thu, Apr 20, 2017, at 16:01, Grant Edwards wrote:
>> On 2017-04-20, MRAB  wrote:
>> > There _is_ a "universal solution"; it's called a Hollerith constant. :-)
>>
>> Wow, I haven't seen one of those in a _long_ time -- probably about 45
>> years.  I think the first FORTAN implementation I used was WATFIV,
>> which had just introduced the character type. But, books/classes on
>> FORTRAN all still covered Hollerith constants.
>
> The IMAP protocol uses a similar kind of construct (the length is
> enclosed in braces)
>
> Even ignoring the maintenance difficulty, I don't think it's possible to
> syntax highlight something like that on most common editors.
>
> The best solution I can think of is to have a text editor designed to
> parse a string literal, spawn a nested editor with the unescaped
> contents of that string literal, and then re-escape it back to place in
> the code. If we had that, then we wouldn't even need raw strings.

Yes exactly, it would be cool to have such a satellite app
which can escape and unescape strings according to rules.
And which can also convert unicode literals to their ascii
analogues and back on the fly, this would very useful
for programming.
Probably it is a good idea to even include such thing
in Python package. So it would be a small standalone app
running parallel with text editor making it to copy paste strings.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 19:27, Chris Angelico  wrote:
> On Fri, Apr 21, 2017 at 2:26 AM,   wrote:
>> I find this:-
>>
>> s = r"ffmpeg -i  '\\server-01\D\SER_Bigl.mpg' "
>>
>> vastly superior.
>
> It's semantically different though. I don't know whether single quotes
> are valid in that context, on Windows.
>

For ffmpeg on Windows at least, both single and double quotes work equally.
So yes, if I keep the rule to use single quotes only inside commands
then I'd be fine with r"".
I simply don't like single quotes, and tend to use doble quotes
everywhere for better readability.

Well it is just somewhat unfortunate, because literals use
the quotes as a open/close tag, which are very common character in
strings. So the idea was to choose something that is not so
frequent and much less probable to appear in a string.
But the less probable it is, the more complex or ugly would the tag
become.
E.g. curly braces {} seems to be much less frequent characters
for filenames and command line arguments.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 17:59, Grant Edwards <grant.b.edwa...@gmail.com> wrote:
> On 2017-04-20, Mikhail V <mikhail...@gmail.com> wrote:
>> Quite often I need raw string literals for concatenating console commands.
>> I want to input them exactly as they are in python sources.
>>
>> There is r"" string, but it is obviously not enough because e.g. this:
>> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>
>s = r'ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" '
>
> Does that do what you want?
>

Yes but it still needs to watch out if there is no ' inside or vice versa
with " characters if use r"". I would like a universal solution.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 17:55, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Apr 21, 2017 at 1:44 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> What I think: why there is no some built-in function, for example like:
>> s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")
>>
>> which would just need *one* quote sign in the beginning and on the end.
>> Would it be useful, what do you think? I think looks better than triple 
>> quote.
>> In the past there were quite a lot additions to string manipulation,
>> probably there is already something like this.
>
> What would be the argument passed to this function?
>
> ChrisA


Yeah that is right, I cant imagine how this would work.
But I think you get the idea- I'd want something dedicated
to input raw strings with cute syntax and *no* escaping
at all.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Rawest raw string literals

[Mikhail V]

On 20 April 2017 at 17:44, Mikhail V <mikhail...@gmail.com> wrote:
> Quite often I need raw string literals for concatenating console commands.
> I want to input them exactly as they are in python sources.
>
> There is r"" string, but it is obviously not enough because e.g. this:
> s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "
>
> is not valid.
>
> The closest I've found is triple quote literal:
> s = r"""ffmpeg -i  "\\server-01\D\SER_Bigl__" """
>
> This is what I use now, still there is problem: last quote inside the string
> needs escaping or a space character before closing triple quote,
> otherwise there is again an error.
>
> What I think: why there is no some built-in function, for example like:
> s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")
>
> which would just need *one* quote sign in the beginning and on the end.
> Would it be useful, what do you think? I think looks better than triple quote.
> In the past there were quite a lot additions to string manipulation,
> probably there is already something like this.

A function probably would not be possible to implement directly,
but probably such a syntax for example:
s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg""r

i.e. an opening and closing "r" particle.
-- 
https://mail.python.org/mailman/listinfo/python-list

Rawest raw string literals

[Mikhail V]

Quite often I need raw string literals for concatenating console commands.
I want to input them exactly as they are in python sources.

There is r"" string, but it is obviously not enough because e.g. this:
s = r"ffmpeg -i  "\\server-01\D\SER_Bigl.mpg" "

is not valid.

The closest I've found is triple quote literal:
s = r"""ffmpeg -i  "\\server-01\D\SER_Bigl__" """

This is what I use now, still there is problem: last quote inside the string
needs escaping or a space character before closing triple quote,
otherwise there is again an error.

What I think: why there is no some built-in function, for example like:
s = raw("ffmpeg -i  "\\server-01\D\SER_Bigl__"")

which would just need *one* quote sign in the beginning and on the end.
Would it be useful, what do you think? I think looks better than triple quote.
In the past there were quite a lot additions to string manipulation,
probably there is already something like this.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Looping [was Re: Python and the need for speed]

[Mikhail V]

On 17 April 2017 at 04:00, Steve D'Aprano  wrote:
> On Mon, 17 Apr 2017 05:49 am, Dennis Lee Bieber wrote:
>
>> On Mon, 17 Apr 2017 02:48:08 +1000, Steve D'Aprano
>>  declaimed the following:
>>
>>>On Sun, 16 Apr 2017 11:57 pm, bartc wrote:
>>>
 But people just don't want it.
>>>
>>>Damn straight. Now you get it. It's not about how easy it is to implement,
>>>it's about whether it is needed and wanted. It isn't needed, and it isn't
>>>wanted.
>>>
>>
>> Let's go all the way, and just get rid of "while ".
>
> Sure, why not? If it's your language, you can make it as minimalist or
> maximalist as you like. You get to choose.
>

I think it is right not to touch anything for .py file rules.
Seriously there are much more problems, and better code editors
should adress those, not current syntax.


As for loops, well, if we speak of some 'my' language,
it could be interesting whether there are common patterns.
But is it on-topic here to speak of, say PyBasic2020 fantasy
language?

For real-time application development the amount of
"while(condition)" vs "while True" can play bad jokes
with readability.
I would find such looping schema simpler:

loop:
if contitioin 1 : contitioin_break = 1
blabla bla = bla  + foo
make something
make something
if contitioin 2 : contitioin_break = 1
if contitioin 3 : contitioin_break = 0
if contitioin_break :  *break
/loop


Anyway it is just question where to show this last line,
or to make an emphasis on it.
so I'd just leave it there, for me it helps when I imagine
a cascade of functions and my eyes go down to the
bottom.  If I have kilometers of "if"s inside the loop,
then hiding one line can become more a problem than an aid.

Constructs like "repeat 100 times {}" or other sort of
"let's pronounce it in English" found in
some languages looks sort of confusing, it takes
me time to "unwrap" their sense into a cascade
especially when there are many different keywords.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 14 April 2017 at 03:44, Steve D'Aprano  wrote:
> On Fri, 14 Apr 2017 12:52 am, bartc wrote:
>
>> I know this isn't the Python need-for-speed thread, but this is a
>> classic example where the lack of one simple feature leads to using
>> slower, more cumbersome ones.
>
> Dear gods, have I fallen back in time to 1975 again?
>

Everything new is definitely better, right?

> Are there reasonable uses for GOTO? Perhaps. There are semi-structured
> restricted versions of GOTO, like exceptions, break and return, but an
> unrestricted GOTO where you can jump anywhere in the program is a terrible
> feature

Yes I suppose, but I know too little about who restricts or
allows and how. And in python it is allowed to mistype
for example "while True :" in any part of the
.py file, as well as one can accidentally mess up with
indentation.
But indeed, Python has very restricted syntax and it is very good.


> Even that's not enough for some. Donald Knuth, who supports the use of GOTO
> under some circumstances, maintains that any program using GOTOs should
> have the invariant that its flow chart can be drawn with all forward
> branches on the left, all backward branches on the right, and no branches
> crossing each other.

I am in the category "I just want to express some
algorithm and don't want to learn every year new concepts".
I tend to think that extremely restricted syntax, in the sence
of having only few flow control instructions actually helps with
readability, despite I have never seriously used other languages
than python so I cannot judge GOTO specifically.

But that comes to many other aspects, most of the time
I just want my code look consistent and readable
and this is more representational problem.
And I suppose that with Python, what bothers
me is  zig-zags of indentation.

Now regardless of Python :
if I would have, say 2 forms of GOTO,
ie direct GOTO and e.g. 'loop' ,

an improvised pseudocode example:

"""
in_menu = true

SUB -
 init some
 draw thing

 # if skip_scan : goto .x

loop
|K=readkey()
|if  K[shift] :
|goto .1
|if  K[m] :
|in_menu = false
|goto .1
|if  K[o] :
|in_menu = false
|.1  make something
|make something
|if (in_menu = false) : goto .x
\__

.x
 clean_up something
 clean_up something

"""

or a classic:

x, y = 0
xx, yy = 300

loop
|loop
||
||   x = x + 1
||   if (x+y) > 100 : goto .x
||   if (x>xx) : goto .1
|\__
|
|.1
|y = y + 1
|if (x>xx) : goto .x
\__

.x

"""

So with 'else'-less condition statement, goto, and loop
construct I would have simpler representation simply because
I would have no 'else', for(), etc... And I'd avoid nested loops as much
as i can.
So less indentation zig-zags and plain "column" code look everywhere,
I think that is what many programmers are looking for.
Just from the reader's POV: having implicit labels for exiting loop
is IMO not worse than additional keywords e.g. "break"...
At least I would not be so fast to judge that.
It is just the question, *how would I input and edit such code*
to avoids typos and renaming labels.


[...]
>> (** Although I find code full of class definitions, one-liners, decorators
>> and all the other esoterics, incomprehensive. I'm sure I'm not the only
>> one, so perhaps readability isn't too much of a priority either.)

>Classes and decorators are not esoteric. You sound like an old man who
>complains about this new-fangled "telephone", and how things were so much
>better when we had messenger boys to deliver messages anywhere in the city.

Seriously, when I open some random .py file from the web
and everywhere see class, class, class, kilometers of indentation...
Hair around one-liners all over the files.
And hedgehogs of try: except blocks, well, this is
straining, and trying to learn why I need
some of those, multiplies the pain.
So your comment applies to me too and I must sound
like an old stupid man I suppose?
And I don't like new "telephones" - they are heavy, need charge
every 2 day, does not fit in the hand well, and just to repat
the last call I need to swipe the stupid touch screen.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 19:38, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Thu, Apr 13, 2017 at 11:25 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> On 13 April 2017 at 18:48, Ian Kelly <ian.g.ke...@gmail.com> wrote:
>>> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V <mikhail...@gmail.com> wrote:
>>>> Now I wonder, have we already collected *all* bells and whistles of Python
>>>> in these two examples, or is there something else for expressing trivial 
>>>> thing.
>>>
>>> Functions and exceptions are considered "bells and whistles"?
>>
>> You mean probably classes and exceptions? For me, indeed they are,
>> but it depends.
>
> No, I meant functions (the first example) and exceptions (the second example).
>
>> And breaking the code into def() chunks that are not
>> functions but just chunks... I don't know, looks bad.
>
> I don't know what you mean by this. There is no such thing as a "def()
> chunk" that is not a function.

I mean that in my example I have consequent code and Rob takes a part of the
code and puts it in a function. And this is just a part of code, I don't need
here anything to wrap or return and don't want to scroll up and down and
collect it all in my brain back into original sequence. Therefore I've called
it abstract art.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 18:48, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Thu, Apr 13, 2017 at 10:23 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> Now I wonder, have we already collected *all* bells and whistles of Python
>> in these two examples, or is there something else for expressing trivial 
>> thing.
>
> Functions and exceptions are considered "bells and whistles"?

You mean probably classes and exceptions? For me, indeed they are,
but it depends.

And breaking the code into def() chunks that are not
functions but just chunks... I don't know, looks bad.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Goto" statement in Python

[Mikhail V]

On 13 April 2017 at 02:17, Rob Gaddi  wrote:

>
> def finder:
>   for s in S:
> if s == 'i':
>   return 'found on stage 1'
>
>   S = S + ' hello world'
>   for s in S:
> if s == 'd':
>   return 'found on stage 2'
>
>   raise ValueError('not found; S=' + S)
>
> try:
>   message = finder()
>   print(message)
>   log += message
> except ValueError as e:
>   print(e)
>

Mother of God... This is like placing some abstract art into a gallery
of monumentalism art.
I am upset and need some healing therapy now.
I'll stay here  for a while:
https://www.pinterest.com/soren19/arqbrt/


On 13 April 2017 at 13:31, alister  wrote:
>
> I expect you could simulate most of these with a custom exception
> for example break from nested loop:
>
> class GoTo(Exception):
> pass
>
> try:
> for i in range(100):
> print i
> for j in range (50):
> print j
> if i*j>60:
> raise GoTo
> except GoTo:
> print "Exit Early"
> print "end of loop"
>

Now I wonder, have we already collected *all* bells and whistles of Python
in these two examples, or is there something else for expressing trivial thing.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

"Goto" statement in Python

[Mikhail V]

On 12 April 2017 at 02:44, Nathan Ernst  wrote:
> goto is a misunderstood and much misaligned creature. It is a very useful
> feature, but like nearly any programming construct can be abused.
>
> Constructs like 'break', 'continue' or 'next' in languages like Python or
> C/C++ are goto's with implied labels.
>
> As Mikhail said, goto's can be great to break out of nested loops (only a
> handful of languages support named 'breaks').
>
> So, instead of:
> bool found = false;
> for (int i = 0; i = ...; ++i)
> {
>  for (int h = 0; h = ...; ++h)
>  {
>if (some_condition)
>  found = true;
>  }
>  if (found) break;
> }
>
> You can have:
>
> for (int i = 0; i = ...; ++i)
> {
>  for (int h = 0; h = ...; ++h)
>  {
>if (some_condition)
>  goto found;
>  }
> }
> // not found
>
> found:
> // handle found
>
> The second is better for a number of reasons: it's clearer. It has fewer
> variables (smaller stack), it has fewer branches (better for the CPU's
> branch prediction), and it has fewer instructions (better for CPU
> instruction cache).  This is a trivial, contrived example, but I've seen
> more than 4x nested loops using an exit flag like this (at every level of
> the loops) that could have been replaced with a lot less code.
>
> People need to stop drinking "X is considered harmful." Even Dijkstra later
> lamented that his "Goto considered harmful" paper was misinterpreted and
> misrepresented as advocating that goto should never be used.
>
> Additionally, I'd recommend everyone read '"Considered Harmful" Essays
> Considered Harmful': http://meyerweb.com/eric/comment/chech.html
>
> Regards,
> Nate
>



Here are recent related discussions about exiting from
nested loops (at least seems to be so):
https://mail.python.org/pipermail/python-ideas/2017-March/044932.html
https://mail.python.org/pipermail/python-ideas/2017-March/045049.html

I personally have difficulties to fully understand some
of the examples given in those proposals, namely
that proposals were thought for other(?) purposes also,
not only breaking nested loops.

At a first glance it seems to me that "goto" would solve
the nested breaking problem and in a nice flexible way.
(correct  me if I am wrong, probably I'm missing something)

So besides nested loops, in my practice I had occasions
when I would want to use "goto".
It would be fair to say that those occasions are not so common,
but I'll try to give an example. Say, there is some
pure procedural processing for some simple task
and I don't want to make the script heavy and just
care for the clarity:

===
Log = ""
S = "lorem ipsum"

for s in S:
if s == "i" :
message = "found on stage 1"
goto .output

S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
goto .output

print "not found"
print "S = ", S
goto .exit

.output
print message
Log = Log + message

.exit:
print "exiting"
=

For me it looks clear and I'd say easy to comprehend,
Main critic would be obviously that it is not
a good, *scalable application*, but quite often I don't
even have this in mind, and just want to express a
step-by-step direct instructions.
In this case sticking any "def():.." inside the script
does not make any sense for me. Simplicity here
reflects the fact that this code represents
exactly what I want the computer to do.

And a working variant of this would be like:

===
Log = ""
found = False
Error = False
S = "lorem ipsum"

if not found:
for s in S:
if s == "i" :
message = "found on stage 1"
found = True

if not found:
S = S + " hello world"
for s in S:
if s == "d" :
message = "found on stage 2"
found = True

if not found:
Error = True
print "Error : not found"
print "S = ", S


if not Error:
print message
Log = Log + message

print "exiting"
==

This is working code, but I would say there is
a lot extra indentation, and if I don't care about
application scalability, those are just adding noise
and I it needs some boolean flags.

I am not sure what examples to add here ...
it seems to me that e.g. if I would use Python
for modelling "pipeline" algorithms
this could be helpful also.

Now if I count in the nested loops breaking problematic,
seems that there is at least a prerequisite for existence of "goto".
Am I right?


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and the need for speed

[Mikhail V]

On 12 April 2017 at 00:02, Rick Johnson <rantingrickjohn...@gmail.com> wrote:
> On Monday, April 10, 2017 at 7:25:48 AM UTC-5, Mikhail V wrote:
>> Still I miss some old school features in Python, e.g.
>> "goto" statement would be very useful in some cases.
>
> Are you serious?

Not so serious to think it is needed much.
And it easy enough to imagine where it
would be more readable than setting up flags and if-blocks
just to jump along the script.

n.d., it reminds me also about the discussion about
exiting from nested loops.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and the need for speed

[Mikhail V]

On 11 April 2017 at 23:45, MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 2017-04-11 21:58, Mikhail V wrote:
>>
>> On 11 April 2017 at 16:56, Steve D'Aprano <steve+pyt...@pearwood.info>
>> wrote:
>>>
>>> On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote:
>>>
>>> [...]
>>>
>>>> DropBox and
>>>> Google seem to agree that there are no good solutions, since they are
>>>> moving to Go.
>>>
>>>
>>> That's a good solution! Maybe we should be writing extensions in Go,
>>> instead
>>> of C. Or for maths-heavy work, using extensions written in Julia.
>>
>>
>> Just my curiosity, I've always been intersted in such question: are devs
>> still writing extensions in C, I mean type in C code? Aren't they using
>> some translator or IDE which at lest hides the brackets and semicolons?
>> I personally don't have problems with understanding low-level
>> concepts of programming, but I find it pretty hard to see
>> through the mangroves of brackets, asterisks and Co.
>>
> The regex module does the matching using code written in C.

That is tough... I feel like a sissy with my humanistic readability
ideas. And those monospaced, green-on-black texts...

(not trolling, I just have have rich imagination)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pound sign problem

[Mikhail V]

On 10 April 2017 at 15:17, David Shi via Python-list
 wrote:
> In the data set, pound sign escape appears:
> u'price_currency': u'\xa3', u'price_formatted': u'\xa3525,000',
> When using table.to_csv after importing pandas as pd, an error message 
> persists as follows:
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in position 
> 0: ordinal not in range(128)
>

The error indicates clearly that you have a character which is not part
of the standard ASCII range, hence the message : "ordinal not in range(128)"
To understand it better, try to imagine characters as numbers and that basic
ASCII defines characters in this range.
see http://www.ascii-code.com/
So the pound character is out this range, its ordinal is being read by
your program as #a3 in hex (#163 in decimal). So *probably* your data
originally is in Latin-1 encoding,

First , you should find out where the data comes from:
is it text file, or some input, then in which application and
encoding was it created.

To get rid of errors, I'd say there are 2 common strategies:
ensure that all source data is saved in Unicode (save as UTF-8)
Or, replace the pound sign with something which is
representable in standard ASCII, e.g. replace the
pound sign with "GBP" in sources.

Otherwise, you must find out which encoding is
used in source data and apply re-encoding
accordingly to input-output format specification.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and the need for speed

[Mikhail V]

On 11 April 2017 at 16:56, Steve D'Aprano  wrote:
> On Tue, 11 Apr 2017 07:56 pm, Brecht Machiels wrote:
>
>[...]
>
>> DropBox and
>> Google seem to agree that there are no good solutions, since they are
>> moving to Go.
>
> That's a good solution! Maybe we should be writing extensions in Go, instead
> of C. Or for maths-heavy work, using extensions written in Julia.

Just my curiosity, I've always been intersted in such question: are devs
still writing extensions in C, I mean type in C code? Aren't they using
some translator or IDE which at lest hides the brackets and semicolons?
I personally don't have problems with understanding low-level
concepts of programming, but I find it pretty hard to see
through the mangroves of brackets, asterisks and Co.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python and the need for speed

[Mikhail V]

On 10 April 2017 at 02:21, Gregory Ewing  wrote:
>
> 
>
> My take on the idea of making Python less dynamic in order
> to improve speed is that you'll end up with a language that,
> while it may superficially resemble Python, doesn't
> really feel like Python.
>
> Boo is an example of that. It has a Python-like syntax, but
> to get any speed advantage you need to add static type
> delarations, and then it feels more like programming in
> C# than Python. At that point, you wonder whether you might
> just be better off writing your program in C# to begin with.
>
> That's not to say this kind of approach isn't worth pursuing,
> but like the JIT attempts mentioned in the article, it has
> also been tried before, with varying levels of success.

Agree. python is python and I suppose that performance issues
has much to do with types and OOP.
When I first started with python I thought - no, it is not possible
without types, if I'll write something more complicated than
hello world, it will all break at some point.
But hell, this works and works good.

Still I miss some old school features in Python, e.g. "goto" statement would
be very useful in some cases. I know it is considered bad style
to use goto, but in some cases it is just most natural thing to use.

What I am (and probably many people) missing is a good tool for
performance middle- and low-level applications.
For me it would be a coding tool, sort of minimalist IDE, with simple
readable syntax which generates compilable C code.
And it would not be necessarily python-like syntax,
but I tend to agree that for today python's syntax is
most readable.

The problem that many are overlooking still is that the
possibilities for syntaxes are very limited in pure text-mode
presentation.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Mikhail V]

On 3 April 2017 at 19:55, Steve D'Aprano  wrote:

> I didn't see you calling out Rick for his prejudice against those who aren't
> American, his absurd belief that "most" people are satisfied with ASCII,

Hmm... that is interesting.
Everyone has some beliefs...
If I make a bit more on-topic question:
What is "satisfied" with ASCII, or what is
"we need Unicode", where and what for?
What is your "satisfaction" with Unicode?

For me it is a font, where images given
numbers, ok, then we need obviosly to
look at it,  e.g.  if you make a codec.

So you are just stating the fact that font files
store them in this order and a txt file in Notepad
will show them in correct order?
hmm... I just thought you have some idea,
e.g. what glyphs you adore esthetically
or find especially useful in your life.

Which of some 40 images that are needed for _you_
to represent speech and numbers, you find
IDK, appealing or annoying, or what?

In typesetting, I find annoying caps inculsion, too
little space between sentences and not so good separator
character design, some flaws in letter design.
For development purposes I would need some
glyphs for non-printable characters, ok
few glyphs more.

Tak zachem _nuzhen_ Unikod ?
Rasskazhi chto-nibud interesnoe.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Text-mode apps (Was :Who are the "spacists"?)

[Mikhail V]

On 2 April 2017 at 02:01, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Apr 2, 2017 at 9:25 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> On 2 April 2017 at 00:22, Chris Angelico <ros...@gmail.com> wrote:
>>> On Sun, Apr 2, 2017 at 8:16 AM, Mikhail V <mikhail...@gmail.com> wrote:
>>>> For multiple-alphabet rendering I will use some
>>>> custom text format, e.g. with tags
>>>> 

Re: Text-mode apps (Was :Who are the "spacists"?)

[Mikhail V]

On 2 April 2017 at 00:22, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Apr 2, 2017 at 8:16 AM, Mikhail V <mikhail...@gmail.com> wrote:
>> For multiple-alphabet rendering I will use some
>> custom text format, e.g. with tags
>>