Re: [Python-Dev] Dash
Serhiy Storchaka storch...@gmail.com writes: What type of dash is preferable in the documentation? The en dash (–) or the em dash (—)? They have different purposes; use whichever is appropriate for the context. This isn't an official Python developer position. But all of ‘-’, ‘–’, ‘—’, ‘−’, etc. have distinct and common meanings in English text. So it's a mistaken idea to think of “which dash is preferable” since they are *all* preferable for their distinct uses. -- \“Science doesn't work by vote and it doesn't work by | `\authority.” —Richard Dawkins, _Big Mistake_ (The Guardian, | _o__) 2006-12-27) | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
On 19 July 2013 17:25, Ben Finney ben+pyt...@benfinney.id.au wrote: Serhiy Storchaka storch...@gmail.com writes: What type of dash is preferable in the documentation? The en dash (-) or the em dash (--)? They have different purposes; use whichever is appropriate for the context. This isn't an official Python developer position. But all of '-', '-', '--', '-', etc. have distinct and common meanings in English text. So it's a mistaken idea to think of which dash is preferable since they are *all* preferable for their distinct uses. I don't know about common. I had no idea there were 3 dash types until a couple of weeks ago. I thought there were only two (short/hyphen/minus-sign and long/em-dash). I still don't really know what the difference is between the two long ones (en-dash vs em-dash). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
Le Fri, 19 Jul 2013 18:38:05 +1000, Nick Coghlan ncogh...@gmail.com a écrit : On 19 July 2013 17:25, Ben Finney ben+pyt...@benfinney.id.au wrote: Serhiy Storchaka storch...@gmail.com writes: What type of dash is preferable in the documentation? The en dash (-) or the em dash (--)? They have different purposes; use whichever is appropriate for the context. This isn't an official Python developer position. But all of '-', '-', '--', '-', etc. have distinct and common meanings in English text. So it's a mistaken idea to think of which dash is preferable since they are *all* preferable for their distinct uses. I don't know about common. I had no idea there were 3 dash types until a couple of weeks ago. I thought there were only two (short/hyphen/minus-sign and long/em-dash). I still don't really know what the difference is between the two long ones (en-dash vs em-dash). But there aren't 3 dash types. There are at least 5 of them! https://en.wikipedia.org/wiki/Dash#Common_dashes (not to mention that Twisted has/had its own dash, IIRC) cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
On 19/07/13 18:38, Nick Coghlan wrote: I don't know about common. I had no idea there were 3 dash types *Way* more than three. hyphen minus sign (not the same as a hyphen!) en-dash em-dash two-em-dash three-em-dash figure dash horizontal bar swung dash plus another half-dozen or so non-English hyphens, all of which have different typographic (and sometimes grammatical) purposes. Wikipedia has a good description: https://en.wikipedia.org/wiki/Dash but a brief summary is: – hyphen - is the smallest and is used for compound words like out-tray; – minus sign − is normally raised compared to the others; – en-dash – should be the width of n and is used for ranges, like Mon–Fri; – em-dash — should be the width of m and is used for a break stronger than a comma but weaker than a full stop; – horizontal bar ― should be longer than the em-dash and is used for quotations in some European languages; – swung dash ⁓ is normally found in dictionaries (paper, not Python) to stand in for the word being defined. But of course different fonts follow these rules to a greater or lesser degree. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
18.07.13 21:54, Brian Curtin написав(ла): Besides visual consistency in a couple of places, is there a reason to care enough to make a wholesale change? Single hyphen instead of a dash just looks too ugly to me. Trying to fix this I noticed that the documentation is inconsistent regarding the dash. Sometimes en and em dashes meet in the same line and in the same sentence. I.e.: The :mod:`weakref` module also allows creating proxy objects which behave like weak references --- an object referenced only by proxy objects is deallocated -- but instead of requiring an explicit call to retrieve the object, the proxy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
18.07.13 21:55, Guido van Rossum написав(ла): On Thu, Jul 18, 2013 at 11:46 AM, Serhiy Storchaka storch...@gmail.com wrote: Or we should replace a half-dozen of em-dashes found in Python documentation to en-dashes? If my theory is right that makes sense. Especially if it's only a half-dozen. I'm sorry, I were wrong. Actually em-dash used much more then en-dash in Python documentation. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
19.07.13 00:49, Ezio Melotti написав(ла): On Thu, Jul 18, 2013 at 7:38 PM, Serhiy Storchaka storch...@gmail.com wrote: What type of dash is preferable in the documentation? The en dash (–) or the em dash (—)? Both should be used where appropriate [0]. Of course I looked in Wikipedia before asking on this list. And I were surprised that en-dash allowed in same places as em-dashes: Either version may be used to denote a break in a sentence or to set off parenthetical statements, although writers are generally cautioned to use a single form consistently within their work. In this function, en dashes are used with spaces and em dashes are used without them:[1] [Em dash:] In matters of grave importance, style—not sincerity—is the vital thing. [En dash:] In matters of grave importance, style – not sincerity – is the vital thing. I'm asking only about this case, when the dash is used to denote a break in a sentence or to set off parenthetical statements. Currently Python documentation uses fourth variants: 1. A single hyphen - surrounded with spaces. In matters of grave importance, style - not sincerity - is the vital thing. I think this case should be converted to one of followed, but to what of them? 2. A double hyphen -- (converted to en-dash) surrounded with spaces. In matters of grave importance, style -- not sincerity -- is the vital thing. 3. A triple hyphen --- (converted to em-dash) surrounded with spaces. In matters of grave importance, style --- not sincerity --- is the vital thing. 4. A triple hyphen --- (converted to em-dash) which isn't surrounded with spaces. In matters of grave importance, style---not sincerity---is the vital thing. The em dash is more common, however -- (commonly used to indicate the em dash in e.g. emails) gets converted to an en dash by Sphinx [1]. I noticed this a while ago, and I started using --- in the documentation whenever I wanted an em dash. This is common in TeX. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
19.07.13 07:51, Steven D'Aprano написав(ла):
Optimistically, I think it would probably be safe[1] to replace --
or --- in text with \N{THIN SPACE}\N{EM DASH}\N{THIN SPACE} (or
\N{HAIR SPACE} if you prefer) without human review, but for any other
changes, I wouldn't even try to automate it.
No, it is not safe. -- used in code examples in which it doesn't
converted to en-dash. Also we should correct tables and underlines in
titles.
I have a manually written and multiple times checked patch (modifies
about 640 lines) which safely replaces -- with --- but I doubt
what actually should be a preferable dash.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2013-07-12 - 2013-07-19)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4092 (+25)
closed 26185 (+45)
total 30277 (+70)
Open issues with patches: 1846
Issues opened (46)
==
#18436: Add mapping of symbol to function to operator module
http://bugs.python.org/issue18436 opened by zach.ware
#18438: Obsolete url in comment inside decimal module
http://bugs.python.org/issue18438 opened by vajrasky
#18439: Patchcheck for ACKS, NEWS does not work on Windows.
http://bugs.python.org/issue18439 opened by terry.reedy
#18441: Idle: Make test.support.requires('gui') skip when it should.
http://bugs.python.org/issue18441 opened by terry.reedy
#18443: Misc/Readme still documents TextMate
http://bugs.python.org/issue18443 opened by iwontbecreative
#18444: IDLE: Mac OS X pressing ctrl-A in Python shell moved cursor be
http://bugs.python.org/issue18444 opened by Todd.Rovito
#18445: Tools/Script/Readme is outdated
http://bugs.python.org/issue18445 opened by iwontbecreative
#18451: Omit test files in devinabox coverage run
http://bugs.python.org/issue18451 opened by brett.cannon
#18453: There are unused variables inside DateTimeTestCase class in te
http://bugs.python.org/issue18453 opened by vajrasky
#18454: distutils crashes when uploading to PyPI having only the usern
http://bugs.python.org/issue18454 opened by jgehrcke
#18456: Documentation for PyDict_Update is incorrect
http://bugs.python.org/issue18456 opened by ncoghlan
#18458: libedit history offset workaround
http://bugs.python.org/issue18458 opened by ronaldoussoren
#18459: readline: libedit support on non-apple platforms
http://bugs.python.org/issue18459 opened by ronaldoussoren
#18460: .chm documentation files advertised in download.html but not t
http://bugs.python.org/issue18460 opened by iwontbecreative
#18461: X Error in tkinter
http://bugs.python.org/issue18461 opened by serhiy.storchaka
#18465: There are unused variables and unused import in Lib/test/test_
http://bugs.python.org/issue18465 opened by vajrasky
#18466: Spelling mistakes in various code comments.
http://bugs.python.org/issue18466 opened by iwontbecreative
#18467: argparse - problematic 'default' behavior
http://bugs.python.org/issue18467 opened by matej.tyc
#18468: re.group() should never return a bytearray
http://bugs.python.org/issue18468 opened by gvanrossum
#18472: PEP 8 updates - internal interfaces and import *
http://bugs.python.org/issue18472 opened by ncoghlan
#18473: some objects pickled by Python 3.x are not unpicklable in Pyth
http://bugs.python.org/issue18473 opened by kmike
#18476: No way to pass custom arguments for loggers and formatters.
http://bugs.python.org/issue18476 opened by piotr.dobrogost
#18477: fix_import (2to3 fixer) is not case-sensitive
http://bugs.python.org/issue18477 opened by Valentin.Lorentz
#18478: Class bodies: when does a name become local?
http://bugs.python.org/issue18478 opened by terry.reedy
#18481: lcov report
http://bugs.python.org/issue18481 opened by christian.heimes
#18483: Add hour-24 type of time to test_http2time_formats in test_htt
http://bugs.python.org/issue18483 opened by vajrasky
#18484: No unit test for iso2time function from http.cookiejar module
http://bugs.python.org/issue18484 opened by vajrasky
#18485: mingw: configure for shared build
http://bugs.python.org/issue18485 opened by rpetrov
#18486: mingw: dynamic loading support
http://bugs.python.org/issue18486 opened by rpetrov
#18487: mingw implement exec prefix
http://bugs.python.org/issue18487 opened by rpetrov
#18488: sqlite: finalize() method of user function may be called with
http://bugs.python.org/issue18488 opened by haypo
#18489: IDLE Unit test for SearchEngine.py
http://bugs.python.org/issue18489 opened by philwebster
#18491: Add exe wrapper functionality to Windows launcher
http://bugs.python.org/issue18491 opened by pmoore
#18492: Add test.support.regrtest_run flag, simplify support.requires
http://bugs.python.org/issue18492 opened by zach.ware
#18493: make profile-opt fails with pre-existing python2.7 in path
http://bugs.python.org/issue18493 opened by Claudio.Freire
#18494: PyType_GenericSet/GetDict functions misnamed in docs?
http://bugs.python.org/issue18494 opened by Wolf.Ihlenfeldt
#18495: mingw: ignore main program for frozen scripts
http://bugs.python.org/issue18495 opened by rpetrov
#18496: mingw: setup exclude termios module
http://bugs.python.org/issue18496 opened by rpetrov
#18497: mingw: setup _multiprocessing module
http://bugs.python.org/issue18497 opened by rpetrov
#18498: mingw: setup select module
http://bugs.python.org/issue18498 opened by rpetrov
#18499: mingw: setup _ctypes module with system libffi
http://bugs.python.org/issue18499 opened by rpetrov
#18500: mingw: defect winsock2 and setup
Re: [Python-Dev] Dash
Serhiy Storchaka storch...@gmail.com writes: 19.07.13 10:25, Ben Finney написав(ла): Serhiy Storchaka storch...@gmail.com writes: What type of dash is preferable in the documentation? The en dash (–) or the em dash (—)? They have different purposes; use whichever is appropriate for the context. I mean only a context where a dash is used to denote a break in a sentence or to set off parenthetical statements. Yes, and both of those are used for different purposes, so “what type is preferable (for all the purposes you mention)” is a poor way of looking at it, IMO. Local style guides have rules about when and how to use the different dashes for specific contexts. (For myself, I prefer parenthetic dashes to be en dashes ‘–’, and a break in a sentence to be marked by an em dash ‘—’. But I also prefer to surround the dash with space for the latter purpose, so my preference isn't universal.) Wikipedia's article (already referred) discusses the matter fairly well URL:https://en.wikipedia.org/wiki/Dashes. Currently Python documentation uses four different variants (see my answer to Ezio). I'd recommend that the Python documentation BDFL should choose and dictate an existing well-groomed style guide for Python documentation, preferably one which explicitly talks about when to use each of the commonly-used dashes. -- \“If you have the facts on your side, pound the facts. If you | `\ have the law on your side, pound the law. If you have neither | _o__) on your side, pound the table.” —anonymous | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
Serhiy Storchaka storch...@gmail.com writes: I'm sorry, I were wrong. Actually em-dash used much more then en-dash in Python documentation. But, as you've also discovered, many authors will type two hyphens “--” when they want an em dash “—”, yet this is rendered to an en dash “–”. So the prevalence of the latter in the documentation probably does not reflect the preferences of the authors. -- \ “Nature hath given men one tongue but two ears, that we may | `\ hear from others twice as much as we speak.” —Epictetus, | _o__) _Fragments_ | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dash
Serhiy Storchaka storch...@gmail.com writes: I'm asking only about this case, when the dash is used to denote a break in a sentence or to set off parenthetical statements. That's two separate cases: * denote a break in a sentence * set off parenthetical statements In my experience, an em dash is commonly used for the former, and en dashes commonly used for the latter. Using the same dash for both is unusual (and IMO needlessly ambiguous to the reader). Currently Python documentation uses fourth variants: All your examples are only for parenthetical statements. Can you find examples of the former, where a break (not parenthetical) in the sentence is intended? -- \ “When I was a kid I used to pray every night for a new bicycle. | `\Then I realised that the Lord doesn't work that way so I stole | _o__) one and asked Him to forgive me.” —Emo Philips | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] dict __contains__ raises TypeError on unhashable input
While working on issue #18508 I stumbled across this: Traceback (most recent call last): ... File /usr/local/lib/python3.4/enum.py, line 417, in __new__ if value in cls._value2member_map: TypeError: unhashable type: 'list' I'll wrap it in a try-except block, but I must admit I was surprised the answer wasn't False. After all, if the input is unhashable then obviously it's not in the dict; furthermore, if I were to compare the number 5 with a set() I would get False, not a TypeMismatch error, and dict keys are basically done by equality, the hash is just (?) a speed-up. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dict __contains__ raises TypeError on unhashable input
http://bugs.python.org/issue18510 Commenting further: some_key in dict is conceptually the same as some_key in dict.keys() which /would/ return False for an unhashable key -- at least it did in 2.x; for 3.x you have to say some_key in list(dict.keys()) which seems like a step backwards. Is it worth changing __contains__ and keys() to be in line with equality? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dict __contains__ raises TypeError on unhashable input
unhashable key doesn't make sense to me. If it's a key, it has to be hashable, and I'd think it'd often be a sign of a bug if you were trying to do unhashable_value in mapping, so to me it seems good that it raises a TypeError. It totally depends on what's on the RHS of the in -- for instance, you get a TypeError if you do: 42 in 'xyz' Whereas by your reasoning, it should return False, because the integer 42 can never be in that string. But really you want the TypeError, because that's a bug waiting to happen. This is something of an aside, but I like the fact that Python is (relatively) strongly typed, and I think this is an example of that. Just the other day I was surprised to learn that in both Java and C# you can do: foo + 3 + 4 And get foo34 without any compile-time or run-time error (in a statically typed language like Java or C# I would have expected a compile-time error). A friend had written code equivalent to that, except with the 3 and 4 being integer variables. He was expecting to see foo7 because that was his intent, but then realized what was going on -- numbers are automatically converted to strings in this context, and the + operators are applied left-to-right. Whereas if you try that in Python, bomp -- TypeError: cannot concatenate 'str' and 'int' objects! -Ben On Sat, Jul 20, 2013 at 1:30 PM, Ethan Furman et...@stoneleaf.us wrote: http://bugs.python.org/**issue18510 http://bugs.python.org/issue18510 Commenting further: some_key in dict is conceptually the same as some_key in dict.keys() which /would/ return False for an unhashable key -- at least it did in 2.x; for 3.x you have to say some_key in list(dict.keys()) which seems like a step backwards. Is it worth changing __contains__ and keys() to be in line with equality? -- ~Ethan~ __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** benhoyt%40gmail.comhttp://mail.python.org/mailman/options/python-dev/benhoyt%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
