Start recommending curly quotes or start using automatic quote conversion

[flying-sheep]

Typography experts agree: Typewriter quotes in non-code text bodies are wrong.^{1, 2}

I gather that PEP editors might not be willing to learn how to input typographically correct quotes.

If this is case, I propose to start using smartypants or similar code to automatically convert typewriter quotes and apostrophes into curly ones. Smartypants works on HTML and skips <code/>, <pre/> and other literal tags.

I would prefer to directly have curly quotes in the rST document, as “direct” is more readable than “escaped”, while explicit is better than implicit (and smartypants could find false positives, although unlikely).

[gvanrossum]

I have a typography expert in my family, and he agrees, but I don't think this is an important issue, and I would be reluctant to complexificate our toolchain for this purpose. Curiously, the opposite thing bugs me much more: using curly quotes instead of straight quotes in program text (things like Word and PowerPoint do this by default).

[brettcannon]

I agree that this isn't worth complicating the toolchain (and I agree with Guido that curly quotes in code bugs me while the lack of curly quotes in text doesn't really bother me).

[flying-sheep]

Merry Christmas everyone!

Could you elaborate why this would complicate the toolchain noticeably?

This would be a 2-line change in pep2html.py and would make me and typography-minded people very happy:

+from smartypants import smartypants
 ...
-outfile.write(output.decode('utf-8'))
+outfile.write(smartypants(output.decode('utf-8')))

[ned-deily]

@flying-sheep Please stop pursuing this. There is sufficient explanation above.

[flying-sheep]

Hi Ned, I don’t think so 😉 And me commenting above is proof of that. I wouldn’t have commented if I felt the assessment was right, and I proved that (given I understand Guido’s argument correctly) there isn’t a significant cost.

Guido implied this would make the toolchain more complex and that this cost would be too much for the little gain. Brett agreed that given there really is a significant cost, it wouldn’t be worth the gain. I hope I got this right! If not, don’t hesitate to correct me 😄

I argue that the added complexity is neglegible:

1. Our implementation’s complexity increases by no more than one added function call(!)
2. The added library is far less complex than docutils and modifies the HTML code in a very predictable way – replacing typewriter quotes and ~ apostrophes with their curly equivalent when outside of some blacklisted tags.

Why are you so fast to shut down this innocent idea? I just want our PEPs to be a bit prettier 🙁

---

Since this is the second time this happened when I suggested a change here:

Please, please stop reprimanding me and please don’t tell me to stop.

I may like discussions a bit too much, but I always try see the other people‘s side and to get to the bottom of the argument. If you have an opinion conflicting with mine, please give my ideas a chance or at least defend yours or find someone to do it for you. I really don’t try to waste your time and just want to help make things more useful, pretty, fast, or otherwise better! Please trust me here and give me a chance! ☹️

[ned-deily]

The problem is that, by prolonging this, you are wasting everyone's time and you risk appearing to be disrespectful of the project and its core contributors. When two of the most senior contributors say it is not going to happen (including the BDFL himself), please accept their judgement and recognize that they also have only so much bandwidth and can't afford time re-justifying their decisions especially on fairly trivial matters. They know from experience (as do I and I concur) that it's almost never a matter of just a two-line change. In this case, it would also involve updating our website toolchains, requiring the involvement of infrastructure teams, it would require testing to ensure that existing peps aren't affected, etc etc. And all of the people involved are volunteers. We all have better ways to spend our limited time and the consensus is that the change isn't worth it at this point.

[flying-sheep]

Oh, maybe in time you’ll learn in time that you can trust my (technical) judgement, but obviously that’ll never happen if I don’t get a chance to prove it.

they also have only so much bandwidth and can't afford time re-justifying their decisions especially on fairly trivial matters

I understand that! 😃 That’s why I start discussing in the first place: Because I doubt they were in possession of all the facts when they made their judgement. I also mentioned that they can delegate if their time is too limited to devote it to this issue. I have less demand for my time, but I hope I’ll always be able to judge something thoroughly myself or delegate a diligent judgement to someone. “I don’t really know but no” is just rude towards someone who invested their time.

Usually project leads or maintainers “@”-mention people with experience in using a certain subsystem here on GitHub when they need assessment. E.g. Guido could have said “I feel that’s too much added complexity for too little gain. @guy-who-wrote-that-script do you agree?”

It’s also OK to not do that while being open to have an initial feeling-based assessment challenged, like I did. But I feel disrespected if I make the effort to get an understanding on something before proposing a change, then get a judgement without explicit reasoning, and then finally get told off when I try to discuss.

In this case, it would also involve updating our website toolchains,

I did my homework! This is wrong 😉 I analysed that here. The website works by having this repo (python/peps) cloned somewhere, pointing a env variable to that location, running pep2html.py, and then running generate_pep_pages.py, which transforms the HTML emitted by pep2html.py. 2-line change (if we only do it for rST PEPS. A few more if also for txt PEPs. 2 lines again if we do it in generate_pep_pages.py)

requiring the involvement of infrastructure teams, it would require testing to ensure that existing peps aren't affected

I’ll do it. I’ll diff the HTML output before and after the change, and include all necessary changes to the PEPs (if, any which I doubt) in the PR.

[zware]

I believe Sphinx does curly quotes, so this is rather moot in light of issue #2.

[gvanrossum]

@flying-sheep You are wearing out your welcome by continuing to discuss issues where you have been asked to stop. This is not the first time. You are risking being banned.

[flying-sheep]

I believe Sphinx does curly quotes, so this is rather moot in light of issue #2.

Ah good point! Then I’ll just wait for #2 to happen (or will help making it happen), thanks!

---

@gvanrossum I’m sad that you see it that way. Telling someone to get lost isn’t a respectful attitude, especially if that someone nicely presents new evidence in which light to reconsider a decision. I’m a scientist, new evidence is always worth it IMHO.

I don’t tell people behaving like myself to stop, I convince them to. I only tell people to stop who are obnoxious and stubborn. Does anyone here see me as such a person? Why? I’m treating everyone here with respect… I generally give every person and every idea a chance, don’t you think that’s a good attitude to have?

[brettcannon]

I have now locked this thread to prevent it from spiraling out of control any more than it already has. I will try one more time to explain why everyone is disagreeing with your approach, @flying-sheep , but I'm afraid if this doesn't work then you do run the risk of violating the CoC in the future and being banned having now been warned.

To start, you didn't ask us why we didn't use curly quotes. Instead you opened by saying we "PEP editors might not be willing to learn" which can come off as insulting, like we're somehow lazy or something. I don't think you meant it that way, but the opening tone of this issue automatically puts us on the defensive as the amount of abuse we deal with on a semi-regular basis means we can't always assume people have good intentions when we are spoken to that way.

Second, two editors agreed that there was too much technical cost to adding a small typological tweak to the PEPs that we have lived without happily for years. We might not have elided every details as to why, but our answers were not given flippantly or without some thought on our end (we could have just said "no" and closed the issue but we chose to give you more detail). But we do have issues beyond this one and this repo to attend to so listing how every step of the process to go from PEP to website and everyone involved and the unspoken thing involved isn't the best use of our time. You see a simple 2-line change, I see having to work with the infrastructure team to be ready in case something breaks (who are already stretched thin), pulling in another dependency for generating PEPs, and wasted cost tweaking our custom build system when we should instead be working towards #2 as @zware pointed out.

But you didn't accept our answer. You asked for clarification which is fine, but you did it by then showing the change as if you're saying "You're wrong because I can do it in two lines!" You are asking us to give you the benefit of the doubt but your response doesn't pay us the same respect you are demanding. You basically are making us regret not flat-out saying "no" and leaving out justifications to prevent an argument with you which has now come up every time you have proposed changing our workflow.

Third, you eventually became blatantly disrespectful. To Ned you said "I don’t think so" which is rather rude even if you followed it with a winky face when you don't know Ned personally. But then following up that assessment by saying essentially @gvanrossum was wrong and you were demonstrably right, which is rather pompous and unnecessarily aggressive. You might think it's an "innocent idea", but Guido and I both said upfront there was complexity costs to tweaking things and you chose to ignore our informed response simply because we didn't give you enough details to make you happy.

This is why Guido responded as he did. While you claim you presented your case nicely, three of us directly disagree with that assessment. So to answer your own question, yes, you are being viewed as "obnoxious and stubborn".