[Python-ideas] Allow additional separator character in variables

Stephan Houben stephanh42 at gmail.com
Sun Nov 19 05:20:05 EST 2017

There is an unfortunate ambiguity in using a character that means "not" as
a word separator:


"But... I called the method which explicitly did *not* launch the nuke!"


Op 19 nov. 2017 11:05 schreef "Steve Barnes" <gadgetsteve at live.co.uk>:

On 19/11/2017 05:01, Nick Timkovich wrote:
> Python does not use U+2010 HYPHEN for the minus operator, it uses the
> U+002D (-) HYPHEN-MINUS.
> In some monospace fonts, there is a subtle difference between U+002D,
> U+2013 EN DASH, and U+2014 EM DASH, but it's usually hard to tell them
> *all* apart.
> If you want to make a proposal, I'd suggest that you limit it to
> allowing the U+2010 HYPHEN to be used for names. U+002D simply cannot be
> changed because it would break billions of lines of code.
> On Sat, Nov 18, 2017 at 10:44 PM, Mikhail V <mikhailwas at gmail.com
> <mailto:mikhailwas at gmail.com>> wrote:
>     On Sun, Nov 19, 2017 at 3:42 AM, Nick Coghlan <ncoghlan at gmail.com
>     <mailto:ncoghlan at gmail.com>> wrote:
>     > For anyone tempted to suggest "What about multiple underscores
>     > indicating continuation of the variable name?", that's still a
>     > compatibility problem due to the unary minus operator:
>     >
>     >     >>> my--variable
>     >     2
>     >     >>> my---variable
>     >     0
>     That seems to be another showcase of misfotune that Python
>     uses hyphen for minus operator. I know it is not language designer's
>     fault, because basic ASCII simply did not not include minus character.
>     But do you realise that the **current** problem you are adressing is
>     that
>     font designers forgot to make the minus character (in monospaced font)
>     distinctive from the hyphen character?
>     Well, what can I say, I just think it should be a reason to make a
>     collective complain to font providers, but not that you should
>     accept this and adopt the language design to someone's sloppy font
>     design.
>     As an aid for monospace die-hards, to minimise the confusion one could
>     publish a style-guide that recommends to disclose the minus operator
>     (currently
>     hyphen char)  in spaces, like a - b, and probably disallow the new
>     proposed
>     hyphen character in the beginning of the identifiers.
>     That would still leave potential for confusion because you cant'
>     force everyone
>     to follow style-guides, but one should struggle to break from this
>     cycle anyway.
>     >
>     > Would hyphens in variable names improve readability sometimes?
>     For reading code, indeed, always and very much. Of course not in case
>     I would be forced
>     to use monospaced font with a similar minus and hyphen. But
>     in that case I am already accepting the level of readability of
>     12th century, so this would not make things much worse, and I
>     would simply put spaces around the minus operator and try to highlight
>     it with some strong color.
How about allowing ¬, (ASCII 172, U+00ac, NOT sign), in variable names
as in my¬variable - it has the advantages that:

  - it is visually distinguishable even in mono-spaced fonts,
(personally I use mono-spaced all of the time when programming but I
know that I am a dinosaur),
  - is actually on many keyboards as a single character, (I don't know
of any which actually produce different characters for minus on the
numeric keypad and hyphen elsewhere), so can be typed as a single key press,
  - Is generally unused AFAIK other than in papers about logic,
  - It is currently unused in the Python language.

This might upset some who would like use it to replace the unary not
operator but I suspect that it would be far fewer people than the
potential breakages discussed so far.

Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.

This email has been checked for viruses by AVG.

Python-ideas mailing list
Python-ideas at python.org
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171119/84b9e2f7/attachment.html>

More information about the Python-ideas mailing list