[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rob Cliffe via Python-ideas]

On 24/05/2020 19:01, David Mertz wrote:
The old images I find lack the '1', but not the '0'.  What model was 
this you had?
Sorry, no way I can remember that far back.  I'm not even certain about 
the missing 0.



On Sun, May 24, 2020 at 1:48 PM Rob Cliffe via Python-ideas 
mailto:python-ideas@python.org>> wrote:




On 22/05/2020 13:28, Steven D'Aprano wrote:
> On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:
>
>> I had a customer who was old enough to
>> use upper case letter O for zero and lower case letter l for 1
because
>> she was old enough to have learned to type before typewriters
had number
>> keys; that made a real mess of sorting street addresses.
> How old was your customer?
>
>
IIRC when I was a child, we had a typewriter that had keys for the
digits 2-9,
but for 0 and 1 you had to use the above trick.
___
Python-ideas mailing list -- python-ideas@python.org

To unsubscribe send an email to python-ideas-le...@python.org

https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at

https://mail.python.org/archives/list/python-ideas@python.org/message/6RYKJFDTBUSUJZWRWM5ION4ESTV2GEIJ/
Code of Conduct: http://python.org/psf/codeofconduct/



--
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/V76O4PNWTQXAU2T464XGZJTVXIDODJOZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rob Cliffe via Python-ideas]

On 22/05/2020 13:28, Steven D'Aprano wrote:

On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:


I had a customer who was old enough to
use upper case letter O for zero and lower case letter l for 1 because
she was old enough to have learned to type before typewriters had number
keys; that made a real mess of sorting street addresses.

How old was your customer?


IIRC when I was a child, we had a typewriter that had keys for the 
digits 2-9,

but for 0 and 1 you had to use the above trick.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6RYKJFDTBUSUJZWRWM5ION4ESTV2GEIJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Tiago Illipronti Girardi]

Wouldn't it be better implemented on an editor as a display option instead of 
changing python?
Because, as I understand, it's an issue of appearing nice on screen,
rather than storing (and parsing) `'\u2192'` as an alias to `'->'` on type 
hints.

It *would* look nice, though
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HEWJOAZIXZY2ESGPC2OCGSD25KKFVLSU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Edwin Zimmerman]

On 5/23/2020 8:52 AM, Stephen J. Turnbull wrote:
> Executive summary:
>
> I'd like to make three points.
>
> 1.  Accessibility matters, and I think this change would be
> inaccessible to users of screen readers.
> 2.  Yes, a variety of tools imposes a burden, but also confers
> benefits.
> 3.  There's no such thing as "pretty source code."  There are only
> tools that display source code beautifully.
>
> Down and dirty details:
>
> The first is new to this discussion:
>
> Let's not make life more annoying for the accessibility developers and
> the people who *need* accessibility accommodations.  Not all visual
> puns are audible puns.  "→" looks like "->", but "Unicode U+2192
> RIGHTWARDS ARROW" sounds nothing like "HYPHEN GREATER-THAN".  (I'm
> guessing at the pronunciation, I don't use a screen reader myself.
> OK, probably the reader just says "RIGHTWARDS ARROW" or even
> "RIGHTARROW", but it's still not close to the same.)
Microsoft Narrator totally skips → when I got it to read the subject line on 
this email (Result:  "I'd like to suggest allowing unicode as an alternative to 
'dash'").  There might be other screen readers that work better, but I agree 
that this would increase inaccessibility.

--Edwin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2SZG2GVHGTMVPDZXFWWC6D2VVSZZ7XBP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Stephen J. Turnbull]

Executive summary:

I'd like to make three points.

1.  Accessibility matters, and I think this change would be
inaccessible to users of screen readers.
2.  Yes, a variety of tools imposes a burden, but also confers
benefits.
3.  There's no such thing as "pretty source code."  There are only
tools that display source code beautifully.

Down and dirty details:

The first is new to this discussion:

Let's not make life more annoying for the accessibility developers and
the people who *need* accessibility accommodations.  Not all visual
puns are audible puns.  "→" looks like "->", but "Unicode U+2192
RIGHTWARDS ARROW" sounds nothing like "HYPHEN GREATER-THAN".  (I'm
guessing at the pronunciation, I don't use a screen reader myself.
OK, probably the reader just says "RIGHTWARDS ARROW" or even
"RIGHTARROW", but it's still not close to the same.)

At the very least, we should do a case-by-case check when we want to
pun this way, and also ask an accessibility expert (better three)
about whether screen readers make this connection, and if not, whether
their users would be able to.

Second, about Tower-of-Babelonian tool proliferation:

Thierry Parmentelat writes:

 > people need to mess with solutions on the outside sphere - editors,
 > IDE’s, documentation post-processing - that essentially have no
 > chance to be sustainable, and/as it causes extra burden for
 > everybody

This situation that has no chance to be sustainable obviously *is*
sustainable.  It's been this way for as long as I've been using
computers (daily use for work or study since 1979).  I very much doubt
it is going to change, ever, because tools are personal.  Yes, it
causes a certain amount of burden for everybody, but it also provides
great benefits for everybody, or network externalities would impel us
to accept a common set of tools.

 > We should allow code to be natively pretty, and not rely on other
 > tools to do the prettifying job - or not

There's no such thing as code being "natively pretty".  Code (source
code) is a sequence of bits grouped into bytes grouped into characters
grouped into statements grouped into a file.  I can't see the pits on
a BD or the microwaves in a wireless connection, and I doubt you can.
There are software tools doing a prettifying job every time source
code is displayed, printed, or read out loud, and a mass audience
language like Python needs to adapt to the tools of the mass audience.
Yes, we humans can help relatively "dumb" tools do a better job of
displaying pretty code (for example, "significant whitespace"), but
it's the quality of tool that matters most.

Fred Brooks had a good essay on "sharp tools", slightly off-point, in
*The Mythical Man-Month*.  (I'm pretty sure of the citation but
unfortunately my copies of MMM are all at school for access by my
students. :-)  He advocated having a tool-building specialist on his
"surgical team" of (proprietary) developers, but in the open source
world, we all publish our tools, which is both the glory and the
disaster of something like Emacs.

There are also habits that won't change -- even if *you* habitually
use one of the many right arrows in Unicode instead of "->", most of
us will continue to touch-type "->", and you're going to have to read
it.  And code is eternal: 20 years from now, somebody's going to be
upset about some misfeature in the stdlib, and they're going to have
to read it.  (Well, maybe not "->", depends on whether they need to
look at the stub files, which is a "probably not", stub files are more
useful to the Python compiler than to humans most of the time.)  If
you want all your Python code to use non-ASCII characters in the
syntax whether you wrote it or not, *your tools will have to do it for
you*.

Steve

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RQORZK7MMUCXJAJEDMFIF2CQRMT5LFTW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rhodri James]

On 22/05/2020 20:40, Steven D'Aprano wrote:

Imagine the confusion if somebody had variables spam, Spam, sPAM, SPam,
sPAm. Or worse, SPΑM, SPАM and SPAM.


Randall is way ahead of you.  https://xkcd.com/2309/

:-)

--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RD26H7FMPTKUAYZWG6DJRLVG2SIMNJEU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Steven D'Aprano]

On Thu, May 21, 2020 at 06:48:55PM +0300, Serhiy Storchaka wrote:
> 21.05.20 16:45, Alex Hall пише:
> >≥ instead of >= might be an improvement because that's a 
> >symbol learned in school, but ultimately the student still needs to 
> >learn what `>=` means as it will be used most of the time.
> 
> But in my school I learned ⩾, not ≥. It was used in USSR and I believe 
> in other European countries (maybe it is French or Germany tradition?).

As far as I am aware, there is no mathematical difference between the 
two greater-than-or-equal operators ⩾ and ≥ it is a purely stylistic 
issue, just as some fonts use two lines in dollar signs and some only 
one. I don't know why Unicode gives them two different code points, but 
if I were a betting man, I would put money on it being because some 
legacy character set provided them both.

(One of the motivations of Unicode is to allow the round-tripping from 
every common legacy charset without loss.)

> If Python will become accepting ≥ as an alias of >=, I insist that it 
> should accept also ⩾. And ⊃, because it is the symbol used for superset 
> relations for sets (currently written as >= in Python). 

An annoying thing about superset and subset operators is that 
mathematicians don't agree on whether the superset symbol ⊃ is strict or 
not. This is why we also have unambiguous symbols ⊇ (superset-or-equal) 
and ⊋ (strict superset not equal).


> And maybe other 
> national or domain specific mathematical symbols. Imagine confusion when 
> >=, ≥, ⩾ and ⊃ are occurred in the same program.

Imagine the confusion if somebody had variables spam, Spam, sPAM, SPam, 
sPAm. Or worse, SPΑM, SPАM and SPAM.

*wink*

Let's not worry too much encouraging people's bad habits. People can 
write obfuscated code in any language. I am sure that before this is a 
problem, linters and code formatters like black will keep it under 
control.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5727HGSASTJSUYSQMQ3H3UAXY4R57HMV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rhodri James]

On 22/05/2020 18:21, Mike Miller wrote:
More importantly, does it help readability?  I think it does, however 
not strongly.  I'm perhaps +0.5 on a few of these characters.  Word 
processors do upgrades to hyphens, for example, to make the resulting 
doc more readable.  Is that kind of thing useful for Python?


Generally speaking, no.  Editors that do things for you behind your back 
are an open invitation to bugs.  I find that for most word processing 
that I do, I have to turn off the automatic 
translation/correction/whatever to prevent them from incorrectly 
rewriting my input.  Prettifying code so that it no longer runs when you 
cut and paste is one example; more often I find they mangle the 
capitalisation of company names, product ID and so forth.  I would hate 
to find an editor starting to do similar things for me.  Sometimes even 
basic things like "electric modes" (auto-indentation after you hit 
RETURN) can make more work for you!


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SICQPMANE6YBDRAHVYGIWF4KXQZ7U4ZF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Mike Miller]

On 2020-05-22 05:57, Joao S. O. Bueno wrote:

render . However, that does not mean it will render ok
as a single-cell character in a mono-spaced font - as the
character "east asian width" property is marked as "A" (Ambiguous),



Yes, though I'm sure no one is seriously proposing using wide, or combining 
chars, or other obscure things.  Just some useful symbols from around the 0x2000 
range of the BMP, which are widely/universally supported by now.  To be honest, 
keyboard entry is the least interesting aspect of this.


To reiterate, we found a zero-ongoing-effort entry method, typing and leaving " 
-> " in the source, and "upgrading it" to " → " with a formatter or other tool 
when desired.  That's assuming you already have tools set up.  I recommend them, 
but they would not be required obviously and neither would the upgraded 
character for compatibility reasons.


More importantly, does it help readability?  I think it does, however not 
strongly.  I'm perhaps +0.5 on a few of these characters.  Word processors do 
upgrades to hyphens, for example, to make the resulting doc more readable.  Is 
that kind of thing useful for Python?


-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/L2GR7SZZGCTVN2JTXBPGAJ3AMCTPC6FY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Ricky Teachey]

On Fri, May 22, 2020 at 11:21 AM David Mertz  wrote:


> The main point of this, is that the code is still just plain ASCII, it
> just happens to look "fancier."  It requires no plugins, and it does not
> require a JetBrains IDE or editor.  I haven't tried every editor, but I
> believe that most or all that use GUI fonts will work fine.  Not sure about
> ligatures and Linux terminal, someone can try it.
>

The ability to pretty-ify code in this way is inspiring; I'm going to have
to look into it.

There could be many other IMO more useful/helpful pretty-fication ideas out
there that could not be accomplished with unicode, or simple "replace these
symbols with another one" configurations.

Couple of examples:

1. I've often thought it would be nice if the parameter type-hints sort of
floated underneath (or maybe above? underneath makes more sense to me) the
parameter names, rather than using the colon at all. Or, perhaps using
colors to specify types - Indigo for ints, scarlet for strings, fuchsia for
floats, perhaps italics for optionals, that sort of thing.

2. Another really nice improvement, so that I could share raw,
copy-and-pasted pretty-ified code with my professional engineering
coworkers (as a set of engineering calculations), would be for the editor
to detect mathematical equations and display them that way. Like:

from scipy.integrate import quad

def f(x, i, j, a, b):
return quad(a*x**2 + b , 0, 1, args=(a,b))

...would be displayed *automatically* (without having to muck about with
sympy), and able to be copied, as:

[image: image.png]

( latex code: $f=\int_{i}^{j} a x^2 + b \,dx$ )

*BACK ON TOPIC:*

The point of giving the examples above is not to rabbit trail, but to agree
with others who have basically said going down this particular road--
putting a lot of effort into including fancy unicode symbols as part of the
syntax-- would be a mistake.

IMO, a big reason it would be a mistake is, it doesn't bring *ENOUGH* to
the table for making things look nicer-- there is so much more that could
be done to make reading python an even more pleasurable experience beyond
using unicode symbols. And not only that, make it useful to more people
beyond the circle of those who actually even *KNOW* they are reading
"python" (as opposed to just English pseudocode describing
mathematical/algorithmic processes).

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/J7NDPLZKA4JDXVAEMCFHII556MWJP63N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[David Mertz]

As is... my editor looks like this.  I don't type all those special things,
except once in a configuration file.  But the "prettification" is handled
transparently when I type some ASCII sequences.
[image: Python-arrow.png]



> that’s nice ! it’s a real shame though, and a bit of a waste honestly,
> that everybody needs to cook their own brew of an editor to get there
> and primarily all I’m trying to say is that, one day, this will be a legal
> piece of code, so that we can share and enjoy exactly like this
> instead of in poor work-it-out-yourself ascii
>

The first screenshot (of completely pointless code I just typed to use a
few symbols or sequences) used vim conceal plugin; also my particular
configuration of what to substitute visually on screen.  That approach lets
entire patterns get replaced by... whatever you want.  E.g. I replace
`set()` with the empty-set symbol, but no one else is required to by the
plugin if they don't want to (or the script Z/R for int/float, likewise).

For comparison, I changed my system text editor to use JetBrains Mono
Medium.  The editor is called "Text Editor" on my system, but it's a
rebranded gEdit, which is a pretty reasonable code editor.  Someone else in
the thread pointed to that font which uses ligatures to make composed
characters.  So it's not a substitution but simply another way of drawing
some letter pairs.  The result is in the attached screenshot.

This approach is somewhat less flexible in that it gets exactly those
ligatures that JetBrains decides you want.  In concept, there is no reason
this couldn't create a 'float' ligature that renders as a script R, for
example.  But that is not a combo JetBrains decided to use.

The main point of this, is that the code is still just plain ASCII, it just
happens to look "fancier."  It requires no plugins, and it does not require
a JetBrains IDE or editor.  I haven't tried every editor, but I believe
that most or all that use GUI fonts will work fine.  Not sure about
ligatures and Linux terminal, someone can try it.



-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/25AQCLEWJXK6IQ23KSIKQW3E5IUOGP43/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Chris Angelico]

On Fri, May 22, 2020 at 11:02 PM Joao S. O. Bueno  wrote:
> I am recording a video series trying to present Python programing to
> absolute beginners - and to keep things timely, the ambiguity between
> two valid quote types is already a _pain_  - which I simply try to avoid
> by making consistent use of just one quote type. But after a 4 hour
> crash course,
> no one that is not already familiar with coding, could come up comfortable 
> with
> using both ' or " interchangibly unless I spend 30 minutes focusing ont that.

Seriously? In primary school English class I learned that you can nest
quotations by using different quote characters. Maybe we need to
consider that first-grade English (or whatever your native language
is) should be considered a prerequisite for coding, and just teach
those kinds of concepts (including words like "singular" and "plural",
since they're so helpful for diagnosing bugs).

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6NUXGP76X5BODZ6CTQO2XNDTVGFHOMV7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Dan Sommers]

On Friday, May 22, 2020, at  8:28, Steven D'Aprano wrote:

> On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:
>
>> I had a customer who was old enough to
>> use upper case letter O for zero and lower case letter l for 1 because
>> she was old enough to have learned to type before typewriters had number
>> keys; that made a real mess of sorting street addresses.

> https://historythings.com/life-changing-invention-typewriters/

I can see 0, 2, 3, 4, 5, and 6 clearly.  I can't see a 1, although it
appears that the key between the 0 and the Q is missing its label.

> https://historythings.com/wp-content/uploads/2016/07/006136-l.jpg
> 
> The photo isn't clear enough to see the keys, but there are 44 of
> them. Since the Sholdes typewriter didn't have lowercase letters, it's
> hard to imagine what the remaining keys after the uppercase letters
> and punctuation marks were if they weren't digits.

The photo is not clear, but I can convince myself that the keys on the
top row start at 2 and run through 9 and 0.  Still no 1.

> And this 1903 Olympia typewriter clearly has digits:
>
> https://historythings.com/wp-content/uploads/2016/07/SAM_2381_clipped_rev_1.png

Still no 1.

> It is certainly true that many people of a certain age used to
> interchange 0 and O, and 1 and l, but I don't think it had anything to
> do with learning to type on typewriters without digits. What did they
> use when they needed the digits 2 through 9?

Okay, "before typewriters had number keys" is obviously wrong.  Those
pictures support "before typewriters had 1 keys."

-- 
“Atoms are not things.” – Werner Heisenberg
Dan Sommers, http://www.tombstonezero.net/dan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/A3VY7HYW6XOJT4XOGHETRMOZALGSXSC2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Joao S. O. Bueno]

On Thu, 21 May 2020 at 18:15, Mike Miller  wrote:
>
>
> On 2020-05-21 05:48, Joao S. O. Bueno wrote:
> > Input _is_ hard or rare. Deal with it.
> > Even the font is not uniformily configured across systems, and  a glyph  one
> > does see here may not show properly on the terminal, or other
>
>
> Maybe long ago.  My terminals support even color emoji, have for years, and 
> are
> all free.
>

If you format all your computers from a single image, maybe.

My pet project over the last year is a unicode art library,
I use a Ubuntu 2018 and a Fedora system daily  -
on my personal machine, which is the Fedora, I've installed
all available font packages an their kitchen sink.

Still, emoji support varies wildly across terminal programs
and even across the same terminal program in Ubuntu and
on Fedora.

Although, yes, it is likely that "older" glyphs like unicode
mathematic symbols will be present in all of then and
render . However, that does not mean it will render ok
as a single-cell character in a mono-spaced font - as the
character "east asian width" property is marked as "A" (Ambiguous),
and may vary according to the installed font - even Qt5, perhaps
the most sophisticated windowing toolkit available in the World,
is severely bugged when displaying non single-width characters
in a monospaced cell character environment such as
coding space. (Of course, it may be that native Windows character
and widget engines or Mac OS's are better in this particular
requisite)



> The only thing I've seen recently that doesn't is the Linux console, which I 
> use
> rarely for admin tasks.  (Oddly enough, it does handle right arrow properly.)
> fbterm is an option there for those wanting more.
>
> Even Windows 10 has gotten in on the act terminal-wise.  If you're still on XP
> or 7, it's way past time to upgrade.
>

I consider this thread to be moot at this time - I am just answering this
e-mail because you answered me directly - but I had seem no
strong support, I had seem you not answering direct questioning
about how this will make things harder to learn and use
but for writting down your own rationalizations on it.

I'd suggest you'd just pause for a bit, and read carefully some of the
other e-mails, if mine, focused mainly technical infeasibility
of even typing or displaying that character, and consider these
questionings for real - not with the ready made answers you have
ready in your mind.

I am recording a video series trying to present Python programing to
absolute beginners - and to keep things timely, the ambiguity between
two valid quote types is already a _pain_  - which I simply try to avoid
by making consistent use of just one quote type. But after a 4 hour
crash course,
no one that is not already familiar with coding, could come up comfortable with
using both ' or " interchangibly unless I spend 30 minutes focusing ont that.
> -Mike
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/IMQFQ7JLOMJ2PE3MLPEHYTTWNUSH3HBQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2544WLVWARH23QSLRMX2USP25RCXAOOE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Steven D'Aprano]

On Thu, May 21, 2020 at 09:43:33AM -0400, Dan Sommers wrote:

> I had a customer who was old enough to
> use upper case letter O for zero and lower case letter l for 1 because
> she was old enough to have learned to type before typewriters had number
> keys; that made a real mess of sorting street addresses.

How old was your customer?

The Hansen Writing Ball, first commercially sold in 1870, had digit 
keys:

https://historythings.com/life-changing-invention-typewriters/

The first recognisable typewriter, the Sholdes and Glidden Type-writer 
(note the hyphen!), was sold in 1864. Here's a photo of one:

https://historythings.com/wp-content/uploads/2016/07/006136-l.jpg

The photo isn't clear enough to see the keys, but there are 44 of 
them. Since the Sholdes typewriter didn't have lowercase letters, it's 
hard to imagine what the remaining keys after the uppercase letters 
and punctuation marks were if they weren't digits.

(44 keys would nicely match 26 letters, 10 digits, space and seven 
punctuation marks.)

And this 1903 Olympia typewriter clearly has digits:

https://historythings.com/wp-content/uploads/2016/07/SAM_2381_clipped_rev_1.png

It is certainly true that many people of a certain age used to 
interchange 0 and O, and 1 and l, but I don't think it had anything to 
do with learning to type on typewriters without digits. What did they 
use when they needed the digits 2 through 9?


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/T3D76PIO7VE2FSKEXYHORWGWFDY544MR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Bernardo Sulzbach]

>
> I believe I speak for a significant majority of professional programmers
> when I say that eye-candy like this adds no value to the language for me.
> It gives me no new capabilities, I don't see it making me more productive,
> and we have syntax that works quite well already.
>

This speaks for me. Not only such an addition requires substantial support,
which it doesn't seem to be gathering, it requires some quantitative
evidence that this is better than what we already have in some meaningful
aspect.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IYT344CYIOOI7FJAOERTE5ID5EYEJFMY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Edwin Zimmerman]

On 5/21/2020 5:51 PM, Thierry Parmentelat wrote:
>>
>>
>> Python-arrow.png
>
> that’s nice ! it’s a real shame though, and a bit of a waste honestly, that 
> everybody needs to cook their own brew of an editor to get there
> and primarily all I’m trying to say is that, one day, this will be a legal 
> piece of code, so that we can share and enjoy exactly like this
> instead of in poor work-it-out-yourself ascii
Could you please explain to me how an entry method for → makes for better 
programmer productivity than what you call "work-it-out-yourself ascii"?  I 
want a specific scenario, like "1 less key press" or whatever, not some kind of 
"we all use emojis" hand-waving.  How would this make me a more productive 
programmer?  Given that -> is never going to disappear from Python anyway, how 
will this make the code easier to understand?

I believe I speak for a significant majority of professional programmers when I 
say that eye-candy like this adds no value to the language for me.  It gives me 
no new capabilities, I don't see it making me more productive, and we have 
syntax that works quite well already.

What if I want to use a font in my editor that doesn't support →?  Does that 
mean that I won't be able to edit some random bit of code I download?

--Edwin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YHVCOUVYWYKMKMXSMMBQ4PWGEWDU25L3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Steven D'Aprano]

On Thu, May 21, 2020 at 04:04:20PM +0200, Thierry Parmentelat wrote:

> for all the rest, I am sorry, all the arguments about people having 
> trouble inputing those characters are not relevant, it’s not as if 
> using unicode characters was mandatory

If we still have to come up with a good looking, unambiguous per ASCII 
digraph or trigraph symbol, then what does the Unicode symbol grant us?

The moment we say "why bother with the ASCII digraph, everyone can use 
the Unicode symbol?" then we are proposing that it be mandatory.

Even if it is not mandatory, people will want to use the same symbol 
throughout a project. Once somebody allows → in a module, they're 
probably going to require → and reject patches using ->

Now of course people can *work around this* by copying and pasting, 
symbol palettes, etc but it does add to the friction of using Python. If 
the benefit isn't greater than the amount of friction, the overall 
experience is worse.

Allowing Unicode symbols expands the range of operators and special 
symbols we can use, and potentially makes it easier to add new language 
features. But if we have ASCII fallbacks for every one of those, then it 
doesn't add any extra power or functionality to the language, it just 
adds complexity for minimal benefit.

> arguments about some people not seeing such code properly are of 
> course much more valid but you seem to forget that using unicode 
> characters is already possible in strings, and identifiers even so 
> somebody else opened that box already … And if IDLE can’t do it, it’s 
> a problem already

Indeed, this is true, but neither identifiers nor strings carry 
syntactic meaning. We don't has to ask what the identifier straß means 
to understand the code, at worst we could treat it as an obfuscated name 
like xyz. Likewise for string constants.

Mandatory or not, giving syntactic meaning to Unicode symbols (as 
opposed to merely allowing them in indentifiers and strings) will lead 
to a massive increase in community questions:

"What's the meaning of that curly less than sign ⊰ in Python?"

or more likely:

"What's with all the small boxes '￸' in Python code?"

(assuming they even display at all, in my mail client the above symbol 
displays as a space; they could easily also display as �).

So unless you're volunteering to personally seek out and answer all 
those questions, this can only increase the amount of community support 
needed for not very much benefit at all.

We have had non-ASCII identifiers for, oh, 15 or 20 years now, but still 
the vast bulk of identifiers use nothing but ASCII, even when not 
written in English. At least for projects which have much visibility in 
the public, English-speaking internet :-)

(I expect that people and companies use a lot more non-ASCII in their 
private code. And there is an interesting little project called 
ChinesePython that translates the language into Chinese, but I don't 
know how successful it is or if it is even still maintained.)

So the cost of allowing non-ASCII identifers is much lower than the cost 
of non-ASCII symbols; even if the benefit is low, it can still be a win 
for non-ASCII identifiers and strings, while the cost:benefit ratio end 
up negative for non-ASCII symbols.

> I am convinced this will happen, one day or another, with or without 
> Python, only question is when, not if

*shrug*

If you are serious about persuing this, you could start by doing a 
survey of what other languages allow non-ASCII symbols, and report on 
their experience and popularity. You might also check out Coconut, which 
is superset of Python that compiles down to Python.

Another option might be to provide a pre-processor that translates 
(say) → into -> for example. We might have .pyu files (u for unicode) 
translate into .py files before being compiled or run.

A good practical project for someone seriously interested in advancing 
this idea would be a translator that goes in both directions, from pure 
ASCII to non-ASCII. (Remember that string literals, docstrings and 
comments shouldn't be touched.)


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HQLA3UW5LFSOLT6JZXGSPPHKVPZQ3J4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[David Mertz]

On Thu, May 21, 2020, 5:51 PM Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:

> You are SERIOUSLY suggesting that typing 'Ctrl-Shift-U 2 1 9 2 ' is
> easier for me than typing '->' as I do now!?
>
> that’s not how I’d do it; and I dont think I said or suggested anything to
> that effect
> this thread seems to be obsessing on entering with the keyboard; that is
> not my point at all
>

I don't know how'd you'd do it on you particular OS, certain, operating
system, editor, etc. But I very much doubt that's a key on your keyboard,
so you'd have to do something akin to this. Maybe you have an old APL
keyboard, but most people don't.

The reason everyone is "obsessing" about how someone would actually make
your symbol appear is that it won't happen magically by thinking it. So you
are proposing and huge hit to ergonomics for everyone for no discernable
benefit.

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that
> everybody needs to cook their own brew of an editor to get there
>

I'm more than happy to share my vim conceal config. There plugin comes with
something similar, but I've customized it to my liking. But other people
would probably prefer something different... Which they can have.

and primarily all I’m trying to say is that, one day, this will be a legal
> piece of code,
>

I very much hope that will never happen. I'm 99% sure my hope will be
realized. I will never be able to use a keyboard with 100k keys on it...
Admittedly, I don't really understand Chinese character entry methods.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YYL4YW4A3CJ52DDCOQGZGCL4JTYTAINJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 21 May 2020, at 23:03, David Mertz  wrote:
> 
> You are SERIOUSLY suggesting that typing 'Ctrl-Shift-U 2 1 9 2 ' is 
> easier for me than typing '->' as I do now!?

that’s not how I’d do it; and I dont think I said or suggested anything to that 
effect

> And it remains easier if I use a different computer where I have to figure 
> out or remember some different way of getting the Unicode code point into the 
> editor?
> 
> The goal of this being to wind up with source code that will render gray 
> boxes for unknown character if I don't have the right font or the right 
> display context?
> 
> Even if *I* don't start using that special character (or others), I wind up 
> having to edit and view code that other people have written, which means I 
> need to deal with a tool stack to handle things that are hard to enter on 
> most keyboards.

this thread seems to be obsessing on entering with the keyboard; that is not my 
point at all

> As is... my editor looks like this.  I don't type all those special things, 
> except once in a configuration file.  But the "prettification" is handled 
> transparently when I type some ASCII sequences.
> 
> 
> 

that’s nice ! it’s a real shame though, and a bit of a waste honestly, that 
everybody needs to cook their own brew of an editor to get there
and primarily all I’m trying to say is that, one day, this will be a legal 
piece of code, so that we can share and enjoy exactly like this
instead of in poor work-it-out-yourself ascii___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MGR3HCKJC5DHWZZKVVT2XFWUYGJUYIYH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rhodri James]

On 21/05/2020 22:11, Mike Miller wrote:
The only thing I've seen recently that doesn't is the Linux console, 
which I use rarely for admin tasks.  (Oddly enough, it does handle right 
arrow properly.)


Guess what I use.  In conjunction with Emacs, of course :-/

--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NLU7RE4TX5CIFHTVA54LVE6QZCCAHU5I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Mike Miller]

On 2020-05-21 05:48, Joao S. O. Bueno wrote:

Input _is_ hard or rare. Deal with it.
Even the font is not uniformily configured across systems, and  a glyph  one
does see here may not show properly on the terminal, or other



Maybe long ago.  My terminals support even color emoji, have for years, and are 
all free.


The only thing I've seen recently that doesn't is the Linux console, which I use 
rarely for admin tasks.  (Oddly enough, it does handle right arrow properly.) 
fbterm is an option there for those wanting more.


Even Windows 10 has gotten in on the act terminal-wise.  If you're still on XP 
or 7, it's way past time to upgrade.


-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IMQFQ7JLOMJ2PE3MLPEHYTTWNUSH3HBQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[David Mertz]

You are SERIOUSLY suggesting that typing 'Ctrl-Shift-U 2 1 9 2 ' is
easier for me than typing '->' as I do now!?

And it remains easier if I use a different computer where I have to figure
out or remember some different way of getting the Unicode code point into
the editor?

The goal of this being to wind up with source code that will render gray
boxes for unknown character if I don't have the right font or the right
display context?

Even if *I* don't start using that special character (or others), I wind up
having to edit and view code that other people have written, which means I
need to deal with a tool stack to handle things that are hard to enter on
most keyboards.

As is... my editor looks like this.  I don't type all those special things,
except once in a configuration file.  But the "prettification" is handled
transparently when I type some ASCII sequences.




-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WQVN7JN6VID73UOAFOFROUTYJ26PWLRG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Mike Miller]

On 2020-05-20 14:56, Steven D'Aprano wrote:

Not everyone is programming in a GUI environment all the time


Well, I gave a number of examples to show there are many ways to do it.  Not 
every example will work well for everyone.  The best that works for your 
platform and tools should be chosen.  There are numerous others I didn't bother 
to mention.




- Code formatters such as "go fmt", yapf, black, etc could update them.


I think this is the choice with the least effort required, a code formatter.

For example, a tip was given to me that you can save keystrokes writing Python 
by using single-quotes exclusively (which I do) then let black change them to 
double later.



I still come across

monospaced fonts where certain symbols have annoying "off by one pixel"
display bugs, or are missing the exact symbol you need.


I use "Source code pro" often and Symbola occasionally and they work well.  Full 
math notation is problematic and likely farther than anyone is proposing.  I do 
use box-drawing occasionally and don't have any alignment problems with them 
even cross-platform.




I can sincerely say that I am very happy that your experience is so
good, but I'm also exceedingly jealous of it. I don't think your
experience scales to the majority of people.


It's true that I did take a few moments to configure things to make it easier 
for me.  Once done however, easy.


But, the majority is now using emoji everywhere, in defiance of curmudgeons. 
I've never heard anyone complain it's "too hard."


-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ETVCYEN4VG3RRKC35AN3Q3ZJVG4X2HLC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Edwin Zimmerman]

On Thursday, May 21, 2020 1:14 PM MRAB [mailto:pyt...@mrabarnett.plus.com] wrote
> On 2020-05-21 16:48, Serhiy Storchaka wrote:
> > 21.05.20 16:45, Alex Hall пише:
> >> ≥ instead of >= might be an improvement because that's a
> >> symbol learned in school, but ultimately the student still needs to
> >> learn what `>=` means as it will be used most of the time.
> >
> > But in my school I learned ⩾, not ≥. It was used in USSR and I believe
> > in other European countries (maybe it is French or Germany tradition?).
> >
> ⩾ is also what I learned here in the UK. ≥ _is_ clearer on-screen, though.
> 
> > If Python will become accepting ≥ as an alias of >=, I insist that it
> > should accept also ⩾. And ⊃, because it is the symbol used for superset
> > relations for sets (currently written as >= in Python). And maybe other
> > national or domain specific mathematical symbols. Imagine confusion when
> >   >=, ≥, ⩾ and ⊃ are occurred in the same program.
> >
Hey, we don't have to stop there.  There are lots of Unicode characters Python 
could accept to make it "easier".  How about › and ‹ and  ⁄  and ‒ and –  and   
͢and ﴾ and ﴿ and ۔.  (No, these are not ASCII characters)

--Edwin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YYENCSOZO44KWTWWNRG4APESL6T47DGU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[MRAB]

On 2020-05-21 16:48, Serhiy Storchaka wrote:

21.05.20 16:45, Alex Hall пише:
≥ instead of >= might be an improvement because that's a 
symbol learned in school, but ultimately the student still needs to 
learn what `>=` means as it will be used most of the time.


But in my school I learned ⩾, not ≥. It was used in USSR and I believe
in other European countries (maybe it is French or Germany tradition?).


⩾ is also what I learned here in the UK. ≥ _is_ clearer on-screen, though.


If Python will become accepting ≥ as an alias of >=, I insist that it
should accept also ⩾. And ⊃, because it is the symbol used for superset
relations for sets (currently written as >= in Python). And maybe other
national or domain specific mathematical symbols. Imagine confusion when
  >=, ≥, ⩾ and ⊃ are occurred in the same program.


___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2MBAML6L7QQFBVODPSFVU2ZH2LU53U7G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Serhiy Storchaka]

21.05.20 16:45, Alex Hall пише:
≥ instead of >= might be an improvement because that's a 
symbol learned in school, but ultimately the student still needs to 
learn what `>=` means as it will be used most of the time.


But in my school I learned ⩾, not ≥. It was used in USSR and I believe 
in other European countries (maybe it is French or Germany tradition?).


If Python will become accepting ≥ as an alias of >=, I insist that it 
should accept also ⩾. And ⊃, because it is the symbol used for superset 
relations for sets (currently written as >= in Python). And maybe other 
national or domain specific mathematical symbols. Imagine confusion when 
>=, ≥, ⩾ and ⊃ are occurred in the same program.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DDUWEK5VU3RKLD5PZMQ2FUSP2R5GA7BU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Alex Hall]

On Thu, May 21, 2020 at 4:36 PM Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:

> > Again, if I saw a unicode arrow used as syntax on GitHub or something in
> the wild right now, I would think it's an error, which incidentally would
> be correct. Wouldn't you?
>
> yes, like I would have taken a walrus operator for a syntax error just a
> couple years ago maybe; things change..


I think you make a good point, but it's not quite the same.

If I see:

```
if (match := re.match(...)):
   x = match.group(1)
```

and I don't know what `:=` means, I pretty much have to Google it, guess,
or otherwise learn. I'm not going to think that a colon was accidentally
added to `match = re.match(...)` because that's not valid syntax either. I
*might* think it's supposed to be `match == re.match(...)`, but that would
just raise more questions - `match` is an undefined variable, and you don't
compare match objects. Besides, how did this mistake happen? Didn't this
person run their code?

If I see:

```
def foo() → Bar:
 ```

I'm going to think that either:

1. Some fancy rendering is going on, like the ligatures some have been
talking about. Right *now*, that's probably the most likely hypothesis,
considering that some people do this in their editors. If it was actually
valid syntax, I'd be surprised when that reasonable guess turned out wrong,
especially if I paste it somewhere and get a SyntaxError with my slightly
outdated Python. Which leads me to the next guess...
2. In the process of transferring from the editor to a
blog/email/document/etc the code has been mangled. I don't know exactly
how, but someone was complaining on this list recently that plain ASCII
quotes had turned into fancy matching quotes which lead to a confusing
error message. So it seems plausible that `->` got transformed somehow.
It's not similarly plausible that `==` randomly became `:=`.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GEHCJV7CF4D5CILMITVFU62D7432OPQP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Edwin Zimmerman]

On Thursday, May 21, 2020 9:20 AM Joao S. O. Bueno 
[mailto:jsbu...@python.org.br] wrote
> On Thu, 21 May 2020 at 10:06, Thierry Parmentelat
>  wrote:
> >
> >
> >
> > > On 21 May 2020, at 14:48, Joao S. O. Bueno  wrote:
> > >
> > >  (I had a coleague once which did
> > > set a special VIM config to display "!=" as
> > > "[can't type, math 'different' sign from here]"
> > > and even that was mostly a toy than anything
> > > really useful.
> >
> > I guess that is my point exactly: the main reason why this person has been 
> > unable to make anything useful out of that otherwise
> perfectly sound idea is that it is not allowed in the language, so people 
> need to mess with solutions on the outside sphere - editors,
> IDE’s, documentation post-processing - that essentially have no chance to be 
> sustainable, and/as it causes extra burden for everybody
> >
> > We should allow code to be natively pretty, and not rely on other tools to 
> > do the prettifying job - or not
> >
> And then, suppose you can "solve" this chicken and egg problem
> by allowing it on the language. Get 2 or 3 years for people to
> catch on the language version that accepts it (how much
> code out there using 1_000_000 numric spacing already?) -
> then, supposing tools evolve along with it, ok, maybe in 4 years I
> can fire-up a "visual studio code" with a setup that allows
> me to hold a modifier key and pops-up  a floating virtual
> keyboard with the unicode operators and type it almost
> seamlessly - how would that help me to type code snippets
> in e-mails or web-forms???

It wouldn't.  No matter how slick of a Unicode operator insertion setup you 
have, it still is quicker and easier to type ->.  I fail to understand how 
suggesting that all new python programmers use a slower, more complex entry 
method can be perceived as more "user-friendly".  Especially since they have to 
learn what -> means anyway.

Not only that, not all fonts support all Unicode characters.  There would need 
to be a FAQ section in the docs on fonts that work with Python.

--Edwin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YSOY56QYM5V6IDAWJ53VLJEHURKF7EIL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 21 May 2020, at 16:18, Alex Hall  wrote:
> 
>  What I mean is that they would only have seen ASCII symbols used for Python 
> syntax i.e. not counting the contents of strings.

and identifiers

> Currently that's the experience of 100% of all Python coders. That percentage 
> will drop a little if and when this feature is announced, but not much, and 
> from there it can only decrease gradually.
> 
> Again, if I saw a unicode arrow used as syntax on GitHub or something in the 
> wild right now, I would think it's an error, which incidentally would be 
> correct. Wouldn't you?

yes, like I would have taken a walrus operator for a syntax error just a couple 
years ago maybe; things change..

> That will be the experience of anyone who sees this before learning about it, 
> and that will always include some beginners.

the only thing that beginners know is: they don’t know much, I don’t see them 
necessarily jumping to conclusions
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C43VRRRPW6IYRWPSE5OJOLC5KHODGVME/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Paul Sokolovsky]

Hello,

On Thu, 21 May 2020 13:26:32 +0200
Thierry Parmentelat  wrote:

[]

> Do we want to get stuck in the 20th century just because everything
> is not yet perfect in a non-purely ASCII world ?

Short answer: yes. Long answer: ASCII was defined in 1963 and hasn't
won over yet, e.g. EBCDIC is alive and kicking:
https://en.wikipedia.org/wiki/EBCDIC . Ergo, 50 years isn't enough for
a character encoding to become truly pervasive. I suggest we wait and
see whether 100 years makes a difference, which in the case of Unicode
means: let's talk again closer to 22th century.

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7H3UD77TZNQZXUT6CQG5QXEOSNFBTERF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rhodri James]

On 21/05/2020 15:29, Thierry Parmentelat wrote:



On 21/05/2020 15:09, Thierry Parmentelat wrote:

clearly the experienced Python programmers are not the main target here
our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and 
this is Europe, not China, so...


You say that, but it is a source of endless annoyance to me that the Linux UK 
Keyboard doesn't offer AltGr shortcuts for a c-cedilla.  It makes addressing my 
colleague François quite a pain :-/


Yeah well, if the whole english-speaking keyboard industry shares the feelings 
expressed on this thread, it’s no wonder ;-)

I suggest you take a look at the US-international (not sure there is a 
UK-international) input method,
that I think is available on all 3 OSes in one form or another, and that is 
cool for that sort of things
(the keyboard I am using right now is a regular qwerty keyboard with no alt-gr 
modifier)

and the other way around I can assure you that coding with a regular French 
keyboard - the infamous AZERTY thingy - is something you don’t want to have to 
do; you’d need alt-gr to enter a mere { - and digits come through shift- !


Oh, I have had to use AZERTY, while I was on holiday in Quebec.  I quite 
agree!


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZSXRVR46BEZFWQVEKRPYRGJ6IFIAO25N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 21/05/2020 15:09, Thierry Parmentelat wrote:
>> clearly the experienced Python programmers are not the main target here
>> our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and 
>> this is Europe, not China, so...
> 
> You say that, but it is a source of endless annoyance to me that the Linux UK 
> Keyboard doesn't offer AltGr shortcuts for a c-cedilla.  It makes addressing 
> my colleague François quite a pain :-/

Yeah well, if the whole english-speaking keyboard industry shares the feelings 
expressed on this thread, it’s no wonder ;-)

I suggest you take a look at the US-international (not sure there is a 
UK-international) input method, 
that I think is available on all 3 OSes in one form or another, and that is 
cool for that sort of things
(the keyboard I am using right now is a regular qwerty keyboard with no alt-gr 
modifier)

and the other way around I can assure you that coding with a regular French 
keyboard - the infamous AZERTY thingy - is something you don’t want to have to 
do; you’d need alt-gr to enter a mere { - and digits come through shift- !

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DBVDHO6X5FOAUA4RYMDNPLVW77NRMODH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Alex Hall]

On Thu, May 21, 2020 at 4:09 PM Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:

>
>
> > On 21 May 2020, at 15:45, Alex Hall  wrote:
> >
> > Many (probably most) people are going to come across a unicode symbol
> having previously only encountered ASCII symbols and probably thinking that
> was the only option. That includes all currently experienced Python
> programmers who aren't up to date on the latest news, and all beginners who
> learned using anything but the most up to date material. Even after this
> feature has been around for a while, many (most?) new learning materials
> will not include unicode symbols because authors don't want to go through
> the extra effort to write those symbols.
>
> I’m having a hard time with statements like
> > Many (probably most) people are going to come across a unicode symbol
> having previously only encountered ASCII symbols
>
> clearly the experienced Python programmers are not the main target here
> our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s,
> and this is Europe, not China, so...
>
> what was the point of defining unicode in the first place then ?


 What I mean is that they would only have seen ASCII symbols used for
Python syntax i.e. not counting the contents of strings. Currently that's
the experience of 100% of all Python coders. That percentage will drop a
little if and when this feature is announced, but not much, and from there
it can only decrease gradually.

Again, if I saw a unicode arrow used as syntax on GitHub or something in
the wild right now, I would think it's an error, which incidentally would
be correct. Wouldn't you? That will be the experience of anyone who sees
this before learning about it, and that will always include some beginners.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MAPKMBCIO72ZSME2WWI22K3POSRF4Y2J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Rhodri James]

On 21/05/2020 15:09, Thierry Parmentelat wrote:

clearly the experienced Python programmers are not the main target here
our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and 
this is Europe, not China, so...


You say that, but it is a source of endless annoyance to me that the 
Linux UK Keyboard doesn't offer AltGr shortcuts for a c-cedilla.  It 
makes addressing my colleague François quite a pain :-/


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OG7NLD4NRUMRZGEV7RBJEZ4GFL4M7B2F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 21 May 2020, at 15:45, Alex Hall  wrote:
> 
> Many (probably most) people are going to come across a unicode symbol having 
> previously only encountered ASCII symbols and probably thinking that was the 
> only option. That includes all currently experienced Python programmers who 
> aren't up to date on the latest news, and all beginners who learned using 
> anything but the most up to date material. Even after this feature has been 
> around for a while, many (most?) new learning materials will not include 
> unicode symbols because authors don't want to go through the extra effort to 
> write those symbols.

I’m having a hard time with statements like 
> Many (probably most) people are going to come across a unicode symbol having 
> previously only encountered ASCII symbols

clearly the experienced Python programmers are not the main target here
our 7-year old schoolboys are used to typing é's and ç and ü’s and À’s, and 
this is Europe, not China, so...

what was the point of defining unicode in the first place then ?

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XGR2S56YB6JCZ7LE5PBGWFBZAN62HDKP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 21 May 2020, at 15:19, Joao S. O. Bueno  wrote:
> 
> That is, if you answered the question about
> which right arrow to use, asked above)

that’s an easy one, see the OP
In [1]: print("\u2192”)
→


for all the rest, I am sorry, all the arguments about people having trouble 
inputing those characters are not relevant, it’s not as if using unicode 
characters was mandatory

arguments about some people not seeing such code properly are of course much 
more valid
but you seem to forget that using unicode characters is already possible in 
strings, and identifiers even
so somebody else opened that box already … And if IDLE can’t do it, it’s a 
problem already

I am convinced this will happen, one day or another, with or without Python, 
only question is when, not if
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FU2MLRR363THHB4IRMQQ4F4DRNLV325Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Alex Hall]

On Wed, May 20, 2020 at 8:36 AM Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:

> Plus, it’s not only IDE’s, I’m prominently concerned by beginners and
> students, who start reading code on sources like github, or teaching
> websites, or notebooks; one cannot expect all these stacks to go this extra
> mile, that is just not right IMHO
>

This seems to be the main (only?) argument beyond it being pretty - that
it's somehow easier for beginners to deal with. I think it's the opposite.

Many (probably most) people are going to come across a unicode symbol
having previously only encountered ASCII symbols and probably thinking that
was the only option. That includes all currently experienced Python
programmers who aren't up to date on the latest news, and all beginners who
learned using anything but the most up to date material. Even after this
feature has been around for a while, many (most?) new learning materials
will not include unicode symbols because authors don't want to go through
the extra effort to write those symbols.

And if you think Python is ASCII only, then when you see unicode, you'll
think something is wrong. Someone's editor magically transformed `->` or
the website has some overly clever rendering or something. That would be my
reaction if I saw such code now. Indeed, if I copied the code and ran it
with the wrong version of Python, I'd get the expected SyntaxError. Overall
it just creates confusion.

If you try to teach people from the beginning that both options exist, then
that just slows down learning. Learning coding is hard enough for most
people without being distracted by minor details about syntax.

If someone thinks that special unicode symbols are the only option, or if
they know they're optional but get the impression that they're preferred
and feel pressure to use them, then typing code becomes a pain. In
particular beginners often start coding with a basic editor such as notepad
so that they aren't distracted by unneeded features or reliant on tools
which do too much work for them that they need to learn on their own (
https://cseducators.stackexchange.com/a/634). So they won't have fancy IDEs
to insert symbols for them, and must rely on their OS.

Finally, in what way does it make it easier for beginners? `->` is pretty
clearly meant to represent an arrow, but beyond that an arrow is not
particularly informative. The student would still need to learn that → in
that particular context is a type hint for the return value, which is not
immediately obvious. Whatever difficulties they may have learning that
concept, the symbol used is not going to make much difference. ≥ instead of
>= might be an improvement because that's a symbol learned in school, but
ultimately the student still needs to learn what `>=` means as it will be
used most of the time.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NTMRUQWS5IG2IV34B7TWVRDGYLLHCL35/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Dan Sommers]

On Thursday, May 21, 2020, at  8:48, Joao S. O. Bueno wrote:

> On Wed, 20 May 2020 at 17:17, Mike Miller  wrote:
>>
>>
>> On 2020-05-20 00:44, Chris Angelico wrote:
>> > If you think that a keyboard with fancy arrows on it will take off any
>> > quicker, you're extremely hopeful.
>>
>> While I'm not sure how useful this is in the long run, the oft mentioned
>> drawback of "hard to type/view" Unicode chars isn't as insurmountable as 
>> some think:
>>
>> - Word processors have had a palette to insert symbols for decades.
>> - Editors have had "snippets" for perhaps almost as long.
>> - Code formatters such as "go fmt", yapf, black, etc could update them.
>> - All maintained OSs support a great majority of Unicode, with font support.
>> - AltGr and Compose keys are available.
>>
>> I've been using Unicode everywhere for about a decade—it's time to retire the
>> argument that input is still hard or rare.  Dedicated keys are not really 
>> necessary.

> Input _is_ hard or rare. Deal with it.

[...]

> It seems that the only sane thing to do is to use a baseline of well
> established symbols on source code [...]

According to https://en.wikipedia.org/wiki/Digraphs_and_trigraphs,
Python is already on thin ice by using the full set of ASCII characters.
I wonder how many non-native English speakers have given up on Python
because of that.

I'm old enough to remember terminals that didn't support lower case
letters, let alone "curly braces," and to have used dozens of different
keybpards with all sorts of "common" symbols (e.g., [, {, /, \, <) in
all sorts of different places.  I had a customer who was old enough to
use upper case letter O for zero and lower case letter l for 1 because
she was old enough to have learned to type before typewriters had number
keys; that made a real mess of sorting street addresses.

But I digress.  Sort of.

Yes, some characters are harder to enter for some people at some times.
We're all different, and so are our computing tools.  Imagine that.

When I studied Koine Greek in school (c. 2003 or 2004), I learned what I
had to to type up my homework.  Was I fast?  No, not really.  Was I fast
enough?  Yep.

I'm not for full blown, use every Unicode character we can, but I'm not
against using characters outside the ISO 646 invariant character set,
either.

Using π or ϖ as an alias for math.pi?  Not too bad.  Matched pairs of
left/right quotation marks?  Maybe, but not without a lot more thought.
Different right arrows for different operations?  That's asking for
trouble.

-- 
“Atoms are not things.” – Werner Heisenberg
Dan Sommers, http://www.tombstonezero.net/dan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4QXJRU4HMS522MXTFFA2JA7GUGZP6RN6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Joao S. O. Bueno]

On Thu, 21 May 2020 at 10:06, Thierry Parmentelat
 wrote:
>
>
>
> > On 21 May 2020, at 14:48, Joao S. O. Bueno  wrote:
> >
> >  (I had a coleague once which did
> > set a special VIM config to display "!=" as
> > "[can't type, math 'different' sign from here]"
> > and even that was mostly a toy than anything
> > really useful.
>
> I guess that is my point exactly: the main reason why this person has been 
> unable to make anything useful out of that otherwise perfectly sound idea is 
> that it is not allowed in the language, so people need to mess with solutions 
> on the outside sphere - editors, IDE’s, documentation post-processing - that 
> essentially have no chance to be sustainable, and/as it causes extra burden 
> for everybody
>
> We should allow code to be natively pretty, and not rely on other tools to do 
> the prettifying job - or not
>
And then, suppose you can "solve" this chicken and egg problem
by allowing it on the language. Get 2 or 3 years for people to
catch on the language version that accepts it (how much
code out there using 1_000_000 numric spacing already?) -
then, supposing tools evolve along with it, ok, maybe in 4 years I
can fire-up a "visual studio code" with a setup that allows
me to hold a modifier key and pops-up  a floating virtual
keyboard with the unicode operators and type it almost
seamlessly - how would that help me to type code snippets
in e-mails or web-forms???

That is effectivelly locking people out of
the language unless they have a "proper coding tool" -
which likely would also be needed to display code properly.

(may I remind you that some of these symbols are not even
on the basic BMP so it is not feasible to use
them in idle. That is, if you answered the question about
which right arrow to use, asked above)

Whereas the same effort for a 'magic symbol palette'
plugin for vscode, pycharm or whatever is the IDE of
the moment can support displaying the ASCII
operators as unicode, in the way it is already possible
with VI - while keeping the source code
editable when I ssh into a docker container with
misconfigured keyboard settings.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ENI7PUQMUDXWKBGFBIQSJO6LWVD4CSA3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 21 May 2020, at 14:48, Joao S. O. Bueno  wrote:
> 
>  (I had a coleague once which did
> set a special VIM config to display "!=" as
> "[can't type, math 'different' sign from here]"
> and even that was mostly a toy than anything
> really useful.

I guess that is my point exactly: the main reason why this person has been 
unable to make anything useful out of that otherwise perfectly sound idea is 
that it is not allowed in the language, so people need to mess with solutions 
on the outside sphere - editors, IDE’s, documentation post-processing - that 
essentially have no chance to be sustainable, and/as it causes extra burden for 
everybody

We should allow code to be natively pretty, and not rely on other tools to do 
the prettifying job - or not
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KF5VK56JN422L4ICK7AQHKILT6BFKK5M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Joao S. O. Bueno]

On Wed, 20 May 2020 at 17:17, Mike Miller  wrote:
>
>
> On 2020-05-20 00:44, Chris Angelico wrote:
> > If you think that a keyboard with fancy arrows on it will take off any
> > quicker, you're extremely hopeful.
>
> While I'm not sure how useful this is in the long run, the oft mentioned
> drawback of "hard to type/view" Unicode chars isn't as insurmountable as some 
> think:
>
> - Word processors have had a palette to insert symbols for decades.
> - Editors have had "snippets" for perhaps almost as long.
> - Code formatters such as "go fmt", yapf, black, etc could update them.
> - All maintained OSs support a great majority of Unicode, with font support.
> - AltGr and Compose keys are available.
>
> I've been using Unicode everywhere for about a decade—it's time to retire the
> argument that input is still hard or rare.  Dedicated keys are not really 
> necessary.

Input _is_ hard or rare. Deal with it.
Even the font is not uniformily configured across systems, and  a glyph  one
does see here may not show properly on the terminal, or other
editing environment.

I see absolutely no gain of using optional arcane symbols in soruce code.
Of course documentation derived from annotations can be as prettified
as one want.

It seems that the only sane thing to do
is to use a baseline of well established  symbols on source code,
and anyone can have a customized editor to render (or input)
those as they see fit - and even thought that always
have been a possibility, very few people
does so. (I had a coleague once which did
set a special VIM config to display "!=" as
"[can't type, math 'different' sign from here]"
and even that was mostly a toy than anything
really useful.

>
> -Mike
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/OD4CI5WCB3YBGAWLT6WCHK3ZVATYID6O/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LSJWZQ2IVPTYUG4FHWEWJUGCQ2INCVR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 20 May 2020, at 23:56, Steven D'Aprano  wrote:
> 
>> I've been using Unicode everywhere for about a decade—it's time to retire 
>> the argument that input is still hard or rare.
> 
> I can sincerely say that I am very happy that your experience is so 
> good, but I'm also exceedingly jealous of it. I don't think your 
> experience scales to the majority of people.

I guess we’re getting to the gist of it
I was not proposing that everybody MUST enter → 
I was suggesting that some people MAY want to do that so their code looks 
prettier in contexts where no additional intelligence is available to embellish 
things

Do we want to get stuck in the 20th century just because everything is not yet 
perfect in a non-purely ASCII world ?



___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5YHKZMHXB7QEYF7OITSQIAEEQPWZF6F5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Steven D'Aprano]

On Wed, May 20, 2020 at 01:13:10PM -0700, Mike Miller wrote:
> 
> On 2020-05-20 00:44, Chris Angelico wrote:
> >If you think that a keyboard with fancy arrows on it will take off any
> >quicker, you're extremely hopeful.
> 
> While I'm not sure how useful this is in the long run, the oft mentioned 
> drawback of "hard to type/view" Unicode chars isn't as insurmountable as 
> some think:
> 
> - Word processors have had a palette to insert symbols for decades.

Not everyone is programming in a GUI environment all the time, and even 
when they are, GUI "insert symbol palettes" are of greatly variable 
quality.


> - Editors have had "snippets" for perhaps almost as long.

Sure, but like the "insert symbol" command, needing to use a snippet 
adds friction. Even in the best case, think of the difference between:

* type a minus sign `-`

* use a snippet or symbol palette to find and insert a `→` symbol.


> - Code formatters such as "go fmt", yapf, black, etc could update them.
> - All maintained OSs support a great majority of Unicode, with font support.

Which is still patchy, but getting better. I still come across 
monospaced fonts where certain symbols have annoying "off by one pixel" 
display bugs, or are missing the exact symbol you need.

I use a lot of arrows in my maths equations, and they are invariably too 
small, too big or placed too close to the baseline, depending on the 
font. At smaller font sizes, the arrow head tends to look like "grit on 
the monitor". In a word processor, I can manually tweak that, but in a 
programming environment using a text editor, there's not much I can do 
except search for that One Perfect Font.

Still not found it after decades of searching.


> - AltGr and Compose keys are available.

And require the editor or OS to support it, a keyboard to have the right 
compose key, and most importantly of all, for the user to remember a 
bunch of esoteric key codes to get the symbol needed.

I can remember Win key .. to give MIDDLE DOT · but it's the wrong dot, I 
need DOT PRODUCT ⋅ (which unfortunately is displayed as a missing- 
character glyph in my email client and editor). But I have no idea what 
key combination I need to press to get DOT PRODUCT.

Last night I had one of my students ask me how they are supposed to type 
maths symbols during an online test if they can't google for it and copy 
it from some website. I didn't have an answer.

So what is the key code for the → symbol?


> I've been using Unicode everywhere for about a decade—it's time to retire 
> the argument that input is still hard or rare.

I can sincerely say that I am very happy that your experience is so 
good, but I'm also exceedingly jealous of it. I don't think your 
experience scales to the majority of people.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C3GEUDZ7KAQKYHA345MGQJAXVHEZP4FY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Steven D'Aprano]

On Thu, May 21, 2020 at 01:58:29AM +1000, Chris Angelico wrote:
> On Thu, May 21, 2020 at 1:48 AM Ethan Furman  wrote:

> > > If you think that a keyboard with fancy arrows on it will take off any
> > > quicker, you're extremely hopeful.
> >
> > I wouldn't be surprised if it did, although a standard set of keyboard
> > shortcuts is more likely.
> 
> I'm pretty doubtful. Keyboards seem to be LOSING keys, not gaining
> them. Which is a trend that I deplore (where are my F1-F12 keys?? and
> I doubt I'll ever see F13-F16), but I still cling to the hope that not
> ALL keyboards are going that way.

Indeed. The ultimate expression of this trend is, of course, the 
smartphone, where you have no physical keyboard at all.

Even if people don't do their for-real development on their smartphone, 
they will insist on replying to emails, messages, Stackoverflow 
questions etc on them, and they won't necessarily have [insert name of 
app here]. So unless the symbol shows up on the smartphone's native 
keyboard emulator people won't be able to use it at least part of the 
time.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4PS3SCZBEIWT4CJEA3PTJDG5YHXZRTLT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Mike Miller]

On 2020-05-20 00:44, Chris Angelico wrote:

If you think that a keyboard with fancy arrows on it will take off any
quicker, you're extremely hopeful.


While I'm not sure how useful this is in the long run, the oft mentioned 
drawback of "hard to type/view" Unicode chars isn't as insurmountable as some think:


- Word processors have had a palette to insert symbols for decades.
- Editors have had "snippets" for perhaps almost as long.
- Code formatters such as "go fmt", yapf, black, etc could update them.
- All maintained OSs support a great majority of Unicode, with font support.
- AltGr and Compose keys are available.

I've been using Unicode everywhere for about a decade—it's time to retire the 
argument that input is still hard or rare.  Dedicated keys are not really necessary.


-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OD4CI5WCB3YBGAWLT6WCHK3ZVATYID6O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Chris Angelico]

On Thu, May 21, 2020 at 1:48 AM Ethan Furman  wrote:
>
> On 05/20/2020 12:44 AM, Chris Angelico wrote:
> > On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote:
>
> >> I also reckon it is still cumbersome to simply enter Unicode characters
> >>  from a keyboard sometimes; I guess if the big players were located in
> >>  other countries that would maybe be different.But that will change
> >>  over time, no matter the speed, some day that will be for granted.So
> >> again maybe 2020 is the right time to break that barrier ?
> >
> > The Dvorak keyboard was invented nearly a hundred years ago. How's it
> > looking as a viable alternative?
>
> Well, 25 years ago I had to write my own Dvorak device driver for use with
> MS-DOS, now it's included in at least Windows and Linux (a Dvorak mapping,
> not my device driver).
>
> So much more viable.  :)
>
> > If you think that a keyboard with fancy arrows on it will take off any
> > quicker, you're extremely hopeful.
>
> I wouldn't be surprised if it did, although a standard set of keyboard
> shortcuts is more likely.

I'm pretty doubtful. Keyboards seem to be LOSING keys, not gaining
them. Which is a trend that I deplore (where are my F1-F12 keys?? and
I doubt I'll ever see F13-F16), but I still cling to the hope that not
ALL keyboards are going that way.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EVTELEZWVETEFZ2GPCRTVBDI2SKWQKGT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Ethan Furman]

On 05/20/2020 12:44 AM, Chris Angelico wrote:

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote:



I also reckon it is still cumbersome to simply enter Unicode characters
 from a keyboard sometimes; I guess if the big players were located in
 other countries that would maybe be different.But that will change
 over time, no matter the speed, some day that will be for granted.So
again maybe 2020 is the right time to break that barrier ?


The Dvorak keyboard was invented nearly a hundred years ago. How's it
looking as a viable alternative?


Well, 25 years ago I had to write my own Dvorak device driver for use with
MS-DOS, now it's included in at least Windows and Linux (a Dvorak mapping,
not my device driver).

So much more viable.  :)


If you think that a keyboard with fancy arrows on it will take off any
quicker, you're extremely hopeful.


I wouldn't be surprised if it did, although a standard set of keyboard
shortcuts is more likely.


MUCH more practical will be to use vim conceal etc, leave your source
code unchanged, and just change the way it looks to you. There are
similar features available in a number of editors.


I'll have to look into that.

--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DWAN3GPO5HWNCGWEZFTNGSDRTIFLTY3U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Serhiy Storchaka]

17.05.20 13:47, Thierry Parmentelat пише:

well it’s all in the title

the specific character that I am referring to is this one

In [1]: print("\u2192”)
→

https://unicode-table.com/en/2192/

——

just curious about how people would feel about taking better advantage 
of non-ascii characters when that seems to make sense


There are a lot of right arrows in Unicode.

>>> print(*[c for c in map(chr, range(0x2)) if 
unicodedata.category(c) in ('Sm', 'So') for n in [unicodedata.name(c, 
'')] if 'RIGHT' in n and 'ARROW' in n])
→ ↔ ↛ ↝ ↠ ↣ ↦ ↪ ↬ ↭ ↮ ↱ ↳ ↴ ↹ ⇄ ⇆ ⇉ ⇎ ⇏ ⇒ ⇔ ⇛ ⇝ ⇢ ⇥ ⇨ ⇰ ⇴ ⇶ ⇸ ⇹ ⇻ ⇼ ⇾ ⇿ 
⍈ ⍼ ➔ ➙ ➛ ➜ ➝ ➞ ➟ ➠ ➡ ➢ ➣ ➤ ➥ ➦ ➧ ➨ ➩ ➪ ➫ ➬ ➭ ➮ ➯ ➱ ➲ ➳ ➵ ➸ ➺ ➻ ➼ ➽ ➾ ⟴ 
⟶ ⟷ ⟹ ⟺ ⟼ ⟾ ⟿ ⤀ ⤁ ⤃ ⤄ ⤅ ⤇ ⤍ ⤏ ⤐ ⤑ ⤔ ⤕ ⤖ ⤗ ⤘ ⤚ ⤜ ⤞ ⤠ ⤳ ⤴ ⤵ ⤷ ⤸ ⤾ ⥂ ⥃ ⥄ ⥅ 
⥇ ⥈ ⥰ ⥱ ⥲ ⥴ ⥵ ⥸ ⥹ ⦨ ⦪ ⦬ ⦮ ⦳ ⬄ ⬌ ⬎ ⬏ ⭃ ⭄ ⭆ ⭇ ⭈ ⭌ ⭢ ⭤ ⭬ ⭲ ⭼ ⮀ ⮂ ⮆ ⮊ ⮌ ⮕ ⮙ 
⮚ ⮞ ⮡ ⮣ ⮥ ⮧ ⮩ ⮫ ⮭ ⮯ ⮱ ⮳ ⮵ ⮷ ⯮ ￫ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ 
﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ 
﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸ ﮸


What of them do you want to accept as an alias of ->? And how would you 
distinguish similarly looking arrows (for example →, ➙, ➞, ⟶, ⭢)?

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X5BINYPWL6JYMOU4VDKRRMH3TNCODX43/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Chris Angelico]

On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat
 wrote:
> I also reckon it is still cumbersome to simply enter Unicode characters from 
> a keyboard sometimes; I guess if the big players were located in other 
> countries that would maybe be different
> But that will change over time, no matter the speed, some day that will be 
> for granted
> So again maybe 2020 is the right time to break that barrier ?
>

The Dvorak keyboard was invented nearly a hundred years ago. How's it
looking as a viable alternative?

If you think that a keyboard with fancy arrows on it will take off any
quicker, you're extremely hopeful.

MUCH more practical will be to use vim conceal etc, leave your source
code unchanged, and just change the way it looks to you. There are
similar features available in a number of editors.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QLYP2KLIGRBWAJ6IKEQ2BFRPBSQGXIO7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 19 May 2020, at 20:27, Brett Cannon  wrote:
> 
> I'm going to ask that people please try to keep this thread on-topic to the 
> question of using Unicode characters directly for things that we currently 
> use two ASCII characters to represent. Other ideas that spring up from this 
> question are totally welcome to be done as new threads of discussion.

Thank you for re-focusing the discussion

I’d like to express the strong opinion that anything related to a particular 
IDE is not the right answer
I’m not going to switch to jetbrains just to get ligatures or fancy rendering, 
am I ? would you ?

Plus, it’s not only IDE’s, I’m prominently concerned by beginners and students, 
who start reading code on sources like github, or teaching websites, or 
notebooks; one cannot expect all these stacks to go this extra mile, that is 
just not right IMHO


back to the point as phrased by Brett:

I reckon the languages communities have mostly so far stuck to ASCII, probably 
for good reasons, 
but the thing is Unicode has been around for quite some time now, and can be 
deemed generally available
so why not take full advantage of it ? 
It is my feeling that part of the awkwardness of the typing annotations, 
rightfully outlined above, is due to the narrow set of characters at our 
disposal, hence the awkward Iterable[] (this one at least clearly deserves 
better IMHO), and Dict[,] likewise
There has to be nicer and more legible ways to express all these

I tend to start the discussion on typing annotations because they are more 
recent, and clearly more in need of improvement
however like Alex Hall pointed out, using dedicated symbols like 
> quoting   ≤ instead of <=, ≥ instead of >=, ≠ instead of !=,
would make a lot of sense as well 


I also reckon it is still cumbersome to simply enter Unicode characters from a 
keyboard sometimes; I guess if the big players were located in other countries 
that would maybe be different
But that will change over time, no matter the speed, some day that will be for 
granted
So again maybe 2020 is the right time to break that barrier ?


===
PS. it looks like one reasonable thread to spawn off from the earlier exchanges 
here 
is about the definition of an arrow operator for defining function types
I’ll leave it to the person who originally extended the discussion in that 
direction :)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U3PAVI4QT7LXJKT2MNP7PJ4T6DO7LUQZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Christopher Barker]

On Tue, May 19, 2020 at 11:31 AM Brett Cannon  wrote:

> I'm going to ask that people please try to keep this thread on-topic to
> the question of using Unicode characters directly for things that we
> currently use two ASCII characters to represent.
>

Indeed -- and also: please refer to earlier conversations on this list and
elsewhere -- this is NOT a new idea!

I'd suggest also that the question at hand be more global: Should Python be
extended to allow non-ascii characters in syntax? Rather than one or two
specific ones.

ON a related note, another way to get "Nicer" multi-character operatores is
lignatures. Jet BRains has put out a font with a pretty full set:

https://www.jetbrains.com/lp/mono/#ligatures

(you can use that font with most Editors / IDEs -- works great with
Sublime, for instance)

That way, it's still two ascii characters, but it looks like one nifty
symbol in your editor.

Maybe no need to complicate Python? ;-)

-CHB



-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/G2RJ2F2X6X5KGUONSQACXCFRQEDQRGHC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Brett Cannon]

I'm going to ask that people please try to keep this thread on-topic to the
question of using Unicode characters directly for things that we currently
use two ASCII characters to represent. Other ideas that spring up from this
question are totally welcome to be done as new threads of discussion.

On Sun, May 17, 2020 at 6:42 PM MRAB  wrote:

> On 2020-05-18 02:25, Greg Ewing wrote:
> > On 18/05/20 1:59 am, Paul Sokolovsky wrote:
> >> But even
> >> {(int): str} is a better type annotation for a function than
> >> Callable[[int], str].
> >
> > I don't agree -- it looks more like some kind of dict type, and
> > would be better reserved for that purpose.
> >
> >> And if we e.g. talk about making "->" a special operator which would
> >> allow it to appear in other contexts
> >
> > Or maybe we could leverage the new walrus operator and write
> >
> >   str := (int)
> >
> It would be closer to the existing annotation if we could write:
>
>  [int] -> str
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/77OWDBQPQKDDQ3CGHUC4PY6ODI3LUBY3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BWFXZOADEX2ZEBJHOHHZIBX2LFR5AFBG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[MRAB]

On 2020-05-18 02:25, Greg Ewing wrote:

On 18/05/20 1:59 am, Paul Sokolovsky wrote:

But even
{(int): str} is a better type annotation for a function than
Callable[[int], str].


I don't agree -- it looks more like some kind of dict type, and
would be better reserved for that purpose.


And if we e.g. talk about making "->" a special operator which would
allow it to appear in other contexts


Or maybe we could leverage the new walrus operator and write

  str := (int)


It would be closer to the existing annotation if we could write:

[int] -> str
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/77OWDBQPQKDDQ3CGHUC4PY6ODI3LUBY3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Greg Ewing]

On 18/05/20 1:59 am, Paul Sokolovsky wrote:

But even
{(int): str} is a better type annotation for a function than
Callable[[int], str].


I don't agree -- it looks more like some kind of dict type, and
would be better reserved for that purpose.


And if we e.g. talk about making "->" a special operator which would
allow it to appear in other contexts


Or maybe we could leverage the new walrus operator and write

str := (int)

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZWUTXNFIA5RRIBJQM2BDGAKMJZ33NIJG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Henk-Jaap Wagenaar]

On Sun, 17 May 2020 at 15:45, Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:

>
>
> > On 17 May 2020, at 16:31, Bernardo Sulzbach <
> berna...@bernardosulzbach.com> wrote:
> >
> > I would like to comment that the graphical presentation, at least in
> IDEs/where the font can be controlled, can be achieved using fonts:
> >
> > Precisely. Nicer than the arrow symbol, it would be to type "-" + ">"
> and get an arrow visually. The same can be done about getting >= as a
> single symbol and == and === and <=> as single symbols. It seems like a
> matter of code presentation, not code itself.
>
> well, I'd find it very confusing to not be able to tell visually whether
> my code contains `→` or `->’
> so this really is the last thing I’d want to do, personnally at least
>
>
>
The '→' is not going to come of nowhere, secondly, your IDE will be quite
unhappy when you introduce invalid syntax and it will tell you about it, so
you will able to "tell visually"
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BBBFUJ37APTZ2CQLINGHNBFMJMB3AZW2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> Before this goes too a big shaky bikeshed over almost nothing, let me
> point out that if you're looking to improve something in type
> annotations, I would suggest to look for true ugliness there.
> Something like Callable[[Dict[str, int], Sequence[Foo]],
> Dict[PrimaryKey, List[int]]]. That's rather unreadable.

totally agree on the awkwardness :-)

> Actually, let me just quote
> https://docs.python.org/3/library/typing.html#typing.Callable
> 
>> Callable type; Callable[[int], str] is a function of (int) -> str.
> 
> Lolwhat? If it's a function of "(int) -> str", then it should be
> written just about like that. With
> https://www.python.org/dev/peps/pep-0563/ , a lot of things which
> weren't previously possible, are now possible. Somebody should start
> thinking how to take advantage of that, up to allowing "(int) ->
> str”.

would be nice too - although this is orthogonal to my initial proposal, right ?

> Which is apparently not possible currently, as while "evaluation" is
> postponed, it still should parse eagerly as Python syntax. But even
> {(int): str} is a better type annotation for a function than
> Callable[[int], str].

well, {(int): str} already means something; are you suggesting that an 
expression like this could have different meanings whether it’s in an 
annotation or not ? that sounds scary ...

> And if we e.g. talk about making "->" a special operator which would
> allow it to appear in other contexts than function definition,
> "(int) -> str" (and other interesting annotation syntaxes) would be
> possible.

again, that’s be quite cool for typing function parameters :)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XT4VZTLLFUT45DOI5MRZPZAMDPBA6IVJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Thierry Parmentelat]

> On 17 May 2020, at 16:31, Bernardo Sulzbach  
> wrote:
> 
> I would like to comment that the graphical presentation, at least in 
> IDEs/where the font can be controlled, can be achieved using fonts:
> 
> Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and get 
> an arrow visually. The same can be done about getting >= as a single symbol 
> and == and === and <=> as single symbols. It seems like a matter of code 
> presentation, not code itself.

well, I'd find it very confusing to not be able to tell visually whether my 
code contains `→` or `->’
so this really is the last thing I’d want to do, personnally at least 

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F2U76QZOUPX47WGN3M5LBL7SPOEBLIR7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Bernardo Sulzbach]

>
> I would like to comment that the graphical presentation, at least in
> IDEs/where the font can be controlled, can be achieved using fonts:
>

Precisely. Nicer than the arrow symbol, it would be to type "-" + ">" and
get an arrow visually. The same can be done about getting >= as a single
symbol and == and === and <=> as single symbols. It seems like a matter of
code presentation, not code itself.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EGNUQPQRONDFJ7SLCOP6CCMLTVH4OJYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Paul Sokolovsky]

Hello,

On Sun, 17 May 2020 14:31:34 +0200
Alex Hall  wrote:

[]

> If we consider the arrow, what about ≤ instead of <=, ≥ instead of
> >=, ≠ instead of !=, × instead of `*`, and math.π instead of math.pi?

Before this goes too a big shaky bikeshed over almost nothing, let me
point out that if you're looking to improve something in type
annotations, I would suggest to look for true ugliness there.
Something like Callable[[Dict[str, int], Sequence[Foo]],
Dict[PrimaryKey, List[int]]]. That's rather unreadable.

Actually, let me just quote
https://docs.python.org/3/library/typing.html#typing.Callable

> Callable type; Callable[[int], str] is a function of (int) -> str.

Lolwhat? If it's a function of "(int) -> str", then it should be
written just about like that. With
https://www.python.org/dev/peps/pep-0563/ , a lot of things which
weren't previously possible, are now possible. Somebody should start
thinking how to take advantage of that, up to allowing "(int) ->
str".

Which is apparently not possible currently, as while "evaluation" is
postponed, it still should parse eagerly as Python syntax. But even
{(int): str} is a better type annotation for a function than
Callable[[int], str].

And if we e.g. talk about making "->" a special operator which would
allow it to appear in other contexts than function definition,
"(int) -> str" (and other interesting annotation syntaxes) would be
possible.


-- 
Best  regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CTS42YQ6N3Q44WHY2Y4CRAF6NISQNZUW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Henk-Jaap Wagenaar]

I would like to comment that the graphical presentation, at least in
IDEs/where the font can be controlled, can be achieved using fonts:

https://stackoverflow.com/questions/41774046/enabling-intellijs-fancy-%E2%89%A0-not-equal-to-operator

On Sun, 17 May 2020 at 13:26, Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:

> well it’s all in the title
>
> the specific character that I am referring to is this one
>
> In [1]: print("\u2192”)
> →
>
> https://unicode-table.com/en/2192/
>
> ——
>
> just curious about how people would feel about taking better advantage of
> non-ascii characters when that seems to make sense
>
>
> fyi here’s how both options appear in a markdown-based website
>
>
>
> thanks !
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/AWXLKPUXSWUXEHMI3FCIJUK25IBPQMGT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TICG3HM7HBIKN7S5E6MPFYCVO5NWQSBT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Holly Short]

> math.π instead of math.pi

That is already possible, just not done in the standard library, no? Your
point still stands, but it's rather different to your other examples, which
are actual changes to syntax.

With regards to the actual proposal, I quite like the idea of being able to
use them, but I don't think it's worth portability issues - style guides
would just end up forbidding it anyway. They're also hard to type, and of
course,
> There should be one-- and preferably only one --obvious way to do it.

On Sun, 17 May 2020 at 13:32, Alex Hall  wrote:

> On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat <
> thierry.parmente...@inria.fr> wrote:
>
>> well it’s all in the title
>>
>> the specific character that I am referring to is this one
>>
>> In [1]: print("\u2192”)
>> →
>>
>> https://unicode-table.com/en/2192/
>>
>> ——
>>
>> just curious about how people would feel about taking better advantage of
>> non-ascii characters when that seems to make sense
>>
>>
>> fyi here’s how both options appear in a markdown-based website
>>
>>
> I'm not a fan of the idea, just in case the code ends up being copied
> somewhere it can't be rendered properly.
>
> If we consider the arrow, what about ≤ instead of <=, ≥ instead of >=, ≠
> instead of !=, × instead of `*`, and math.π instead of math.pi?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/EKQ4WJDWE2TVCE5SRMOTVW3DC6DNXMLD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5MFTCANQYPRA7VFLAAIKBDWZQTVFB6YF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

[Alex Hall]

On Sun, May 17, 2020 at 2:24 PM Thierry Parmentelat <
thierry.parmente...@inria.fr> wrote:

> well it’s all in the title
>
> the specific character that I am referring to is this one
>
> In [1]: print("\u2192”)
> →
>
> https://unicode-table.com/en/2192/
>
> ——
>
> just curious about how people would feel about taking better advantage of
> non-ascii characters when that seems to make sense
>
>
> fyi here’s how both options appear in a markdown-based website
>
>
I'm not a fan of the idea, just in case the code ends up being copied
somewhere it can't be rendered properly.

If we consider the arrow, what about ≤ instead of <=, ≥ instead of >=, ≠
instead of !=, × instead of `*`, and math.π instead of math.pi?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EKQ4WJDWE2TVCE5SRMOTVW3DC6DNXMLD/
Code of Conduct: http://python.org/psf/codeofconduct/