Re: [Python-Dev] documentation / implementation question for subprocess.check_output
On 16/07/2015 16:27, Nick Coghlan wrote: On 16 July 2015 at 20:35, Guido van Rossum gu...@python.org wrote: In which version? I don't see that phrase in the 3.5 docs. The equivalent note in 3.x is Do not use stdout=PIPE or stderr=PIPE with this function. The child process will block if it generates enough output to a pipe to fill up the OS pipe buffer as the pipes are not being read from. I think Chris is right that it's a docs bug - the warning is applicable to subprocess.call and subprocess.check_call (which use Popen.wait), but not to subprocess.check_output (which uses Popen.communicate). Cool, if I get a chance, I'll try and work up a patch, but it's been so long since I last did any core-dev work that I'd need to read up on what current processes are. cheers, Chris ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 17 July 2015 at 09:35, Alexander xr.li...@gmail.com wrote: By the way, I've also been bitten by this several times, so I appreciate the desire to at least warn users (or raise an exception, or whatever). It is not an intention to make tests more robust. It is the implementation, which is questionable at least. I actually still hope that the whole thing is a joke. I do not want to read mistyped code from other developers and try to guess whether it will work properly or not. *Any* operation starting with assret_* on a Mock object will throw AttributeError in 3.5+. The only way to get it to *work* is to spell it properly. The specific typo that is checked is the only one that changes the spelling without also changing the overall length and shape of the word. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 17 July 2015 at 08:30, Ben Finney ben+pyt...@benfinney.id.au wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with assret_*. I still don't know why anyone thinks restoring that would be a worthwhile use of a maintainers' time (or why they thinking arguing in favour of such a capability is a worthwhile use of theirs). None of the perspectives presented in this thread are new, although the apparent obsession over such a minor detail has made it abundantly clear that this kind of helper simply isn't worth the distraction it creates for maintainers, *regardless* of whether or not it helps end users. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote: The specific typo that is checked is the only one that changes the spelling without also changing the overall length and shape of the word. I don't think your comment above is correct. assert = aasert aseert azzert essert assort all have the same overall length and shape. Not all spelling errors are typos (hitting the wrong key). I've seen spelling errors this bad, or worse, from native English writers. Poor spelling, bad keyboards, distraction, and dyslexia can all contribute. And those who aren't fluent in English will make their own spelling errors, and may not even notice if the length of the word changes: assert = asert For those who are dyslexic, there are spelling errors and typos that may be difficult to tell apart even though the shape of the word changes: assert = assery asserh (perhaps -- I'm not dyslexic, I'm just going by what I've read about their experience). In my opinion, this sets a bad precedent for adding special case after special case, and the risk is that people will feel slighted if they are told that their typos aren't important enough to be made a special case too. If Michael wishes to argue that this is a useful feature rather than an ugly DWIM wart, that's his perogative, but the justification that assret is the *only* such plausible typo is just plain wrong. We've already heard from Robert Collins that he found a bunch of silently failing assertions in his mocks, and none of them started with assret. All-spelling-errors-are-deliberate-to-provide-new-and-exciting-ways-to-spell-old-words-ly y'rs, -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2015-07-10 - 2015-07-17) 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: open4947 (+19) closed 31468 (+29) total 36415 (+48) Open issues with patches: 2260 Issues opened (31) == #24612: not operator expression raising a syntax error http://bugs.python.org/issue24612 opened by candide #24613: array.fromstring Use After Free http://bugs.python.org/issue24613 opened by JohnLeitch #24616: 'make install' fails installation of man pages for Python 2.7. http://bugs.python.org/issue24616 opened by ronbarak #24617: os.makedirs()'s [mode] not correct http://bugs.python.org/issue24617 opened by John Jones #24618: Invalid read in PyCode_New http://bugs.python.org/issue24618 opened by blarsen #24619: async/await parser issues http://bugs.python.org/issue24619 opened by skrah #24620: Segfault with nonsensical random state http://bugs.python.org/issue24620 opened by skrah #24621: zipfile.BadZipFile: File is not a zip file http://bugs.python.org/issue24621 opened by Yasar L. Ahmed #24622: tokenize.py: missing EXACT_TOKEN_TYPES http://bugs.python.org/issue24622 opened by skrah #24623: Parser: broken line numbers for triple-quoted strings http://bugs.python.org/issue24623 opened by skrah #24626: please sync cgi.parse document http://bugs.python.org/issue24626 opened by xwhhsprings #24632: Improve documentation about __main__.py http://bugs.python.org/issue24632 opened by ezio.melotti #24633: README file installed into site-packages conflicts with packag http://bugs.python.org/issue24633 opened by Sébastien Celles #24634: Importing uuid should not try to load libc on Windows http://bugs.python.org/issue24634 opened by steve.dower #24635: test_typing is flaky http://bugs.python.org/issue24635 opened by r.david.murray #24637: locals dictionary in PyRun_String http://bugs.python.org/issue24637 opened by Matthew Keeter #24638: asyncio loop argument must agree with future error message c http://bugs.python.org/issue24638 opened by r.david.murray #24640: no ensurepip in embedded Windows distribution http://bugs.python.org/issue24640 opened by chriskrycho #24641: Log type of unserializable value when raising JSON TypeError http://bugs.python.org/issue24641 opened by Madison May #24642: Will there be an MSI installer? http://bugs.python.org/issue24642 opened by tritium #24643: VS 2015 pyconfig.h #define timezone _timezone conflicts with t http://bugs.python.org/issue24643 opened by James Salter #24645: logging.handlers.QueueHandler should not lock when handling a http://bugs.python.org/issue24645 opened by jsbronder #24646: Python accepts SSL certificate that should be rejected on OSX http://bugs.python.org/issue24646 opened by jpakkane #24647: Document argparse.REMAINDER as being equal to ... http://bugs.python.org/issue24647 opened by Antony.Lee #24648: Allocation of values array in split dicts should use small obj http://bugs.python.org/issue24648 opened by Mark.Shannon #24649: python -mtrace --help is wrong http://bugs.python.org/issue24649 opened by Antony.Lee #24650: Error in yield expression documentation http://bugs.python.org/issue24650 opened by swanson #24651: Mock.assert* API is in user namespace http://bugs.python.org/issue24651 opened by rbcollins #24652: C-API Pure Embedding enhancement http://bugs.python.org/issue24652 opened by Justin Huang #24653: Mock.assert_has_calls([]) incorrectly passes http://bugs.python.org/issue24653 opened by rbcollins #24654: PEP 492 - example benchmark doesn't work (TypeError) http://bugs.python.org/issue24654 opened by wodny Most recent 15 issues with no replies (15) == #24654: PEP 492 - example benchmark doesn't work (TypeError) http://bugs.python.org/issue24654 #24652: C-API Pure Embedding enhancement http://bugs.python.org/issue24652 #24651: Mock.assert* API is in user namespace http://bugs.python.org/issue24651 #24650: Error in yield expression documentation http://bugs.python.org/issue24650 #24649: python -mtrace --help is wrong http://bugs.python.org/issue24649 #24647: Document argparse.REMAINDER as being equal to ... http://bugs.python.org/issue24647 #24641: Log type of unserializable value when raising JSON TypeError http://bugs.python.org/issue24641 #24637: locals dictionary in PyRun_String http://bugs.python.org/issue24637 #24626: please sync cgi.parse document http://bugs.python.org/issue24626 #24623: Parser: broken line numbers for triple-quoted strings http://bugs.python.org/issue24623 #24619: async/await parser issues http://bugs.python.org/issue24619 #24618: Invalid read in PyCode_New http://bugs.python.org/issue24618 #24591: offer option to suppress clean --all output relating to none http://bugs.python.org/issue24591 #24577: Document asyncio behavior (logging and call to
Re: [Python-Dev] How far to go with user-friendliness
Nothing huge to add, and I'm not experienced using mock. But the special handling of 'assret' as a misspelling of 'assert' definitely strikes me as a wart also. That sort of thing really has no place in a library itself, but rather only in a linter. On Fri, Jul 17, 2015 at 9:20 AM, Steven D'Aprano st...@pearwood.info wrote: On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote: The specific typo that is checked is the only one that changes the spelling without also changing the overall length and shape of the word. I don't think your comment above is correct. assert = aasert aseert azzert essert assort all have the same overall length and shape. Not all spelling errors are typos (hitting the wrong key). I've seen spelling errors this bad, or worse, from native English writers. Poor spelling, bad keyboards, distraction, and dyslexia can all contribute. And those who aren't fluent in English will make their own spelling errors, and may not even notice if the length of the word changes: assert = asert For those who are dyslexic, there are spelling errors and typos that may be difficult to tell apart even though the shape of the word changes: assert = assery asserh (perhaps -- I'm not dyslexic, I'm just going by what I've read about their experience). In my opinion, this sets a bad precedent for adding special case after special case, and the risk is that people will feel slighted if they are told that their typos aren't important enough to be made a special case too. If Michael wishes to argue that this is a useful feature rather than an ugly DWIM wart, that's his perogative, but the justification that assret is the *only* such plausible typo is just plain wrong. We've already heard from Robert Collins that he found a bunch of silently failing assertions in his mocks, and none of them started with assret. All-spelling-errors-are-deliberate-to-provide-new-and-exciting-ways-to-spell-old-words-ly y'rs, -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 18 Jul 2015 8:13 am, Ethan Furman et...@stoneleaf.us wrote: On 07/16/2015 11:30 PM, Nick Coghlan wrote: On 17 July 2015 at 08:30, Ben Finney wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with assret_*. Why is that surprising? As somebody already mentioned (Terry, I think?) assret is a fine abbreviation, as well as possibly being a foreign word. I still don't know why anyone thinks restoring that would be a worthwhile use of a maintainers' time (or why they thinking arguing in favour of such a capability is a worthwhile use of theirs). 1) Because it shouldn't have been added in the first place. 2) Because DWIM does not belong in Python. Then volunteer to do all of the work to revert the change yourself, or offer to pay someone for it. Do NOT spend days nitpicking tiny details of work that has already been done to the point where people are wondering why they bother giving the gift of their time and contributions to our community. Core committers are core committers because we're willing to trust their judgement in borderline design calls in their areas of expertise - the rest of the role could be automated (and hopefully eventually will be). Once they've made a decision, we have the entire internet to continue to voice our dissatisfaction with the outcome, but incessantly repeating the same points that were already considered in making the original decision constitutes unwelcome noise on the core mailing lists. Regards, Nick. None of the perspectives presented in this thread are new, although the apparent obsession over such a minor detail has made it abundantly clear that this kind of helper simply isn't worth the distraction it creates for maintainers, *regardless* of whether or not it helps end users. To be clear: - those who are upset over assret are not upset over assert - it is not Python's job (nor the stdlib's) to correct spelling errors -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 18 July 2015 at 15:19, Nick Coghlan ncogh...@gmail.com wrote: This change *doesn't really matter* in the grand scheme things, but would require a non-zero amount of time and effort to reverse, so unless you're offering one of the unittest maintainers a contract gig to change it back, let it go. s/unittest/mock :). But yes. Currently only Michael is listed under 'experts' in the devguide for unittest.mock. I've taken up the baton to keep the backport up to date, to keep the ecosystem healthy, but I've no specific plans to hack on mock per se. I think we'd probably benefit from more names there :) I know Kushal and Berker have been doing things in the stdlib. But there's a tonne of important work to do before worrying about tweaking a patch which was peer reviewed and went through the entirely normal development process to address a critical usability issue with mock. Which, judging from this thread, a bunch of folk don't actually understand in the first place. [I mean no disrespect here, but there have been multiple explanations trying to cover the distinction about what is actually going on, and I'm well over them]. So - folk interested in unittest.mock. If you want to help, going through the 200 open issues in https://github.com/testing-cabal/mock, starting with the oldest, assessing whether they are: - still relevant - present only in the backport (leave them where they are) - or in 3.6 as well (in which case open a new ticket at https://bugs.python.org/ linked to the github issue, and either close the github issue or label it upstream (or both)). THAT would be valuable, and improve users experience of unittest.mock [and mock] much more than making a_mock.assret_called_once *not error*. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 18 Jul 2015 10:40 am, Ben Finney ben+pyt...@benfinney.id.au wrote: Nick Coghlan ncogh...@gmail.com writes: On 17 July 2015 at 08:30, Ben Finney ben+pyt...@benfinney.id.au wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with assret_*. You're describing a fait accompli. That doesn't justify the changes to get to that fait. NOTHING new has been added by this discussion - it is merely rehashing arguments that were already considered when the original design decision was made. Attempting to get our way through sheer volume is not acceptable behaviour. Courtesy attempts to explain have been met with endless nitpicking rather than gratitude for explanation of the original decision. I'm with Antoine in wondering why we even bother with contributing when the thanks we can expect is for people to feel entitled to demand we spend hours of our time debating trivial details while huge glaring problems like the startup sequence and the core workflow tooling languish for lack of time to work on them. This change *doesn't really matter* in the grand scheme things, but would require a non-zero amount of time and effort to reverse, so unless you're offering one of the unittest maintainers a contract gig to change it back, let it go. Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
Antoine Pitrou writes: Frankly, this kind of inept discussion, I think you misunderstand what's going on. The people who advocate removal of a gratuitous special case may lack your perspective, but they're not incompetent to understand it. Specifically, you have a senior committer's perspective on practicality. But that's nothing that one imbibes with mother's milk, and worse, it's not the same from project to project. I applaud Nick's attempts to communicate his perspective on Pythonic practicality, both for the feature itself and for changing it *right* now. [...] is amongst the reasons why I'm stopping contributing to CPython. We'll miss your code. But you're only one committer, even if you've contributed more than the average amount. On the other hand, Python needs to *grow* the committer group beyond its current size, and *some* such discussion is necessary for new committers' advancement to benevolent dictator for one PEP level, which is also a pain point IMHO. This particular case is one of the most salient, because it involves the application of one of the most difficult principles: but practicality beats purity. I note that you are responding to Ethan, who recently had a couple of useful PEPs approved and implemented, but it is my impression that he does not yet consider himself a BD1P candidate.[1] Contributers like him should be cultivated and encouraged (even if discussion should be redirected, see below), not stifled, because they are likely to be involved in Python at a higher level in the future. BTW, he's not the only one in that situation (PEP author and/or subproject leader but not quite willing to step up for BD1P) in this thread. Every maintainer or contributor now has an army of voluntary hair-splitters to bother about, I think that's something worth improving. Specifically, I suggest that, just as Guido occasionally invokes cloture[2] on a thread, other senior developers do so too, in their areas of competence. Those areas may need some definition, but clearly in this case Michael is competent to say all right girls and boys, I heard you, I disagree, and it's not going to change. Of course he already did that, which is enough for seasoned committers. What I'm suggesting is that he should add, so please stop discussing the issue, as Guido does. That makes the implication explicit to less-experienced participants, as well as to those who usually know better but are carried away by the momentum of the discussionwink /. It might also be appropriate to offer the option of asking for rationale on core-mentorship, where people who have volunteered to help would-be committers hang out. (I guess that would be expanding the mission of core-mentorship, though, so it's not a no-brainer.) Of course this means that developers with areas of competence need to pay more attention to such threads, and some will resist or not be very good at it. But if most do it, it should do wonders to improve the efficiency of discussion and be a net saving of time for them as well. It would be nice if a few volunteered for these how to Pythonically resolve conflict of principles discussions on core- mentorship, too. As python-ideas is also a list for business discussions, cloture might usefully be applied there, too, although with more caution (more seniority required for invoking[3] cloture?) since the latitude of discussion is intentionally wider there. Footnotes: [1] With apologies to Ethan. I don't speak for him, and my impressions of him have no validity outside of the current context of a discussion about cultivating developers. [2] https://en.wikipedia.org/wiki/Cloture There are alternative spellings in that article. I'm suggesting that if the idea is adopted, one of the traditional spellings and some of the properties of parliamentary cloture be sanctioned as Pythonic. Eg, one aspect of cloture in many parliaments is that it can be proposed by any member. Here the implementation would be a frustrated developer who writes to the responsible committer and requests that he check discussion, and issue a ruling that the thread should end right away. [3] N.B. This wording may be obscure or specific to my dialect. To me, invoking cloture means *imposing an end to discussion*, as opposed to merely *proposing* to end it by force. As in fn [1], anybody can propose to invoke cloture as I see it. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
Frankly, this kind of inept discussion, where a bunch of folks get hung up about an extremely minor design decision (who cares whether assret is being special-cased or not? in the actual world, not the fantasy world of righteous indignation and armchair architects?), is amongst the reasons why I'm stopping contributing to CPython. Keep up the good work, you're making this place totally repulsive to participate in. Every maintainer or contributor now has an army of voluntary hair-splitters to bother about, most of whom probably aren't relying on said functionality to begin with. Regards Antoine. On Fri, 17 Jul 2015 15:11:59 -0700 Ethan Furman et...@stoneleaf.us wrote: On 07/16/2015 11:30 PM, Nick Coghlan wrote: On 17 July 2015 at 08:30, Ben Finney wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with assret_*. Why is that surprising? As somebody already mentioned (Terry, I think?) assret is a fine abbreviation, as well as possibly being a foreign word. I still don't know why anyone thinks restoring that would be a worthwhile use of a maintainers' time (or why they thinking arguing in favour of such a capability is a worthwhile use of theirs). 1) Because it shouldn't have been added in the first place. 2) Because DWIM does not belong in Python. None of the perspectives presented in this thread are new, although the apparent obsession over such a minor detail has made it abundantly clear that this kind of helper simply isn't worth the distraction it creates for maintainers, *regardless* of whether or not it helps end users. To be clear: - those who are upset over assret are not upset over assert - it is not Python's job (nor the stdlib's) to correct spelling errors -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
Nick Coghlan ncogh...@gmail.com writes: On 17 July 2015 at 08:30, Ben Finney ben+pyt...@benfinney.id.au wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with assret_*. You're describing a fait accompli. That doesn't justify the changes to get to that fait. I'm pointing out that what you call a situation to be “restored” is what we've got now, and a change away from that – to add a DWIM alias for one typo, seemingly arbitrary among typos – needs sufficient justification. I'm also pointing out that clarity and similicity of API is sufficiently important that there needs to be a strong benefit to justify moving away from that. I still don't know why anyone thinks restoring that would be a worthwhile use of a maintainers' time (or why they thinking arguing in favour of such a capability is a worthwhile use of theirs). Just as easily, I could express surprise that adding DWIM aliases for some typos and not others has somehow been thought worthwhile of the maintainers's time. But in neither case does that argue for or against, so I don't think that's terribly germane to the discussion. None of the perspectives presented in this thread are new Must they be new? I don't see how that matters. If they haven't been adequately addressed, it shouldn't matter how new they are; they're still salient objections to a change when it is announced. -- \ “In any great organization it is far, far safer to be wrong | `\ with the majority than to be right alone.” —John Kenneth | _o__)Galbraith, 1989-07-28 | Ben Finney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 07/16/2015 11:30 PM, Nick Coghlan wrote: On 17 July 2015 at 08:30, Ben Finney wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with assret_*. Why is that surprising? As somebody already mentioned (Terry, I think?) assret is a fine abbreviation, as well as possibly being a foreign word. I still don't know why anyone thinks restoring that would be a worthwhile use of a maintainers' time (or why they thinking arguing in favour of such a capability is a worthwhile use of theirs). 1) Because it shouldn't have been added in the first place. 2) Because DWIM does not belong in Python. None of the perspectives presented in this thread are new, although the apparent obsession over such a minor detail has made it abundantly clear that this kind of helper simply isn't worth the distraction it creates for maintainers, *regardless* of whether or not it helps end users. To be clear: - those who are upset over assret are not upset over assert - it is not Python's job (nor the stdlib's) to correct spelling errors -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 18/07/2015 01:00, Ryan Gonzalez wrote: I am tempted to reply with a slightly sarcastic message involving a cookie... I'm not tempted, I will ask, what the hell are you on about? On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou solip...@pitrou.net wrote: Frankly, this kind of inept discussion, where a bunch of folks get hung up about an extremely minor design decision (who cares whether assret is being special-cased or not? in the actual world, not the fantasy world of righteous indignation and armchair architects?), is amongst the reasons why I'm stopping contributing to CPython. Keep up the good work, you're making this place totally repulsive to participate in. Every maintainer or contributor now has an army of voluntary hair-splitters to bother about, most of whom probably aren't relying on said functionality to begin with. Regards Antoine. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
On 07/17/2015 05:11 PM, Nick Coghlan wrote: Do NOT spend days nitpicking tiny details of work that has already been done to the point where people are wondering why they bother giving the gift of their time and contributions to our community. You mean like you keep expressing dismay and surprise that people care about the language and don't want warts in it? 'Cause that's a real friendly attitude right there. Don't worry, I'm done with this thread. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How far to go with user-friendliness
I am tempted to reply with a slightly sarcastic message involving a cookie... On July 17, 2015 6:40:21 PM CDT, Antoine Pitrou solip...@pitrou.net wrote: Frankly, this kind of inept discussion, where a bunch of folks get hung up about an extremely minor design decision (who cares whether assret is being special-cased or not? in the actual world, not the fantasy world of righteous indignation and armchair architects?), is amongst the reasons why I'm stopping contributing to CPython. Keep up the good work, you're making this place totally repulsive to participate in. Every maintainer or contributor now has an army of voluntary hair-splitters to bother about, most of whom probably aren't relying on said functionality to begin with. Regards Antoine. On Fri, 17 Jul 2015 15:11:59 -0700 Ethan Furman et...@stoneleaf.us wrote: On 07/16/2015 11:30 PM, Nick Coghlan wrote: On 17 July 2015 at 08:30, Ben Finney wrote: By definition, advocating to not add cruft to an API is going to be in advance of being bitten by those additions. That's not what people are doing. Folks are actually arguing for *restoring* the ability to mock out method names starting with assret_*. Why is that surprising? As somebody already mentioned (Terry, I think?) assret is a fine abbreviation, as well as possibly being a foreign word. I still don't know why anyone thinks restoring that would be a worthwhile use of a maintainers' time (or why they thinking arguing in favour of such a capability is a worthwhile use of theirs). 1) Because it shouldn't have been added in the first place. 2) Because DWIM does not belong in Python. None of the perspectives presented in this thread are new, although the apparent obsession over such a minor detail has made it abundantly clear that this kind of helper simply isn't worth the distraction it creates for maintainers, *regardless* of whether or not it helps end users. To be clear: - those who are upset over assret are not upset over assert - it is not Python's job (nor the stdlib's) to correct spelling errors -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
