Re: [Python-Dev] PEP process entry point and ill fated initiatives
Reading the defect, I find people being unnecessarily obstructive. Closing the ticket, twice, is a rude, and unnecessary action. How about acknowledging that these waters are dark and murky and help making things better? Surely, documenting processes can only be an improvement? A lot has changed in open source development in the last 10 years. The processes we have are starting to have the air of cathedral around them. K From: Python-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Guido van Rossum Sent: 28. nóvember 2013 18:40 To: anatoly techtonik Cc: python-dev Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives Anatoly, the Python community is a lot more diverse than you think. Pull requests (whatever that means) are not the way to start a PEP. You should start by focusing on the contents, and the mechanics of editing it and getting it formatted properly are secondary. The process is explained in PEP one. Your bug report would have gotten a much better response if you had simply asked what is the process, I can't figure it out from the repo's README rather that (again) complaining that the core developers don't care. Offending people is not the way to get them to help you. ___ 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] PEP process entry point and ill fated initiatives
On Thu, Nov 28, 2013 at 9:39 PM, Guido van Rossum gu...@python.org wrote: Anatoly, the Python community is a lot more diverse than you think. Pull requests (whatever that means) are not the way to start a PEP. You should start by focusing on the contents, and the mechanics of editing it and getting it formatted properly are secondary. The process is explained in PEP one. Your bug report would have gotten a much better response if you had simply asked what is the process, I can't figure it out from the repo's README rather that (again) complaining that the core developers don't care. Offending people is not the way to get them to help you. Sorry, I didn't mean to offend anyone. It never was my goal. Everybody knows that I personally can easily find information about how to start new PEP - like this one - http://www.python.org/dev/peps/pep-0001/ I am not sure it is _the entry point_ I am looking for, because it may happen that there is a more up-to-date chapter about this in devguide. That's why I didn't paste any links - PEP list subscribers know a lot better about the process than I am. But the issue is - if my point of entry is PEP repo, and the first thing I do is reading the README, I expect it to contain the link to the PEP process, and this link is missing. It is not that I can't figure out something, it is that people need more time than necessary to find required info, and the time is the most valuable resource. Now there is a huge part about community process vision, complains, analysis, request to resume CLArification work, and generic stuff about experience. It is not obligatory to read. About ill fated initiatives. I don't like when people prematurely close tickets without waiting for the mutual agreement that the problem is solved. Perhaps trackers should have personal agree/disagree/meh flags to help other people state their opinions, but until then the lack of time will always lead to the same communication problems. I value contributions people made for Python, even if I am not expressive about it, I do realize that without all these people it won't be possible. I can only regret that people can't self-sustain the feeling that they are important and that they take offence instead. Perhaps this offence is that makes them closing tickets without waiting for reply. Reply is not be required to close ticket for valid reason, but the point of conflict is that I don't like when tickets are prematurely closed under the reason of you. do it right instead of let's make it better. Both right and better are subjective, but there is a big difference. better can be discussed, and right is not. I don't think it's ok. I understand that people don't have time to waste in chit chatting, but so do I, and everybody else out there. I am disrespectful to policies, that's right. I believe that policies need to be revised every couple of years, but nobody do this. Rules that work for folks that were present at the time the consensus is reached need to be explained to those who came later, and still you can't expect them to comply. Just because they don't have choice, they may choose to ignore, and community loses another contributor. I again complain, because I see many things that don't move and it doesn't make me happy. I can not be polite if I am not happy. From one side it's my own problem and I know about. Another aspect is that I won't have motivation to write if I am unhappy and polite - it is depressive. From the other side there is also a point of conflict that can not be ignored. People who signed CLA do not understand my position that CLA is harmful. They think that if I didn't sign it then I am just trolling and exclude me. I won't send patches until CLA is clear for every contributor and not like common, just sign it, I am not a lawyer, but they know it is good. This probably make people upset, and they try to help you, so you have to maintain a sane amount of dignity to resist the pressure. People afraid to accept patches even when I *explicitly* give my permission to use them. I tired of writing patches that can not be accepted even with my explicit permission - permission in which I understand what I am giving out. But apparently there is something wrong with my permission - it is not incomplete, because if something was missing - people would tell me about it. But people don't understand what is missing. They say you, do it right, CLA is the right way. I ask why, and there is silence. No, I've been given a lot of complicated books about lawyership, stuff that was written before I was born. I don't get it. That's my ill fated initiative to clarify the CLA and make Python contribution process free from FUD. People do it right and force other people to do it right as I see it. That's a natural process, but it can be constructive if the meaning of what is right is discussed and changed if necessary. Otherwise Python development becomes an exclusive privilege for those who comply or
Re: [Python-Dev] PEP process entry point and ill fated initiatives
On Fri, Nov 29, 2013 at 10:08 PM, anatoly techtonik techto...@gmail.com wrote: About ill fated initiatives. I don't like when people prematurely close tickets without waiting for the mutual agreement that the problem is solved. Perhaps trackers should have personal agree/disagree/meh flags to help other people state their opinions... Perhaps this offence is that makes them closing tickets without waiting for reply. Reply is not be required to close ticket for valid reason, but the point of conflict is that I don't like when tickets are prematurely closed under the reason of you. do it right instead of let's make it better... I am disrespectful to policies, that's right. I believe that policies need to be revised every couple of years, but nobody do this. Rules that work for folks that were present at the time the consensus is reached need to be explained to those who came later, and still you can't expect them to comply. Why do you feel that Python is (or ought to be) democratic? It isn't, and it should not be. Your opinion is, I am sure, given weight when decisions are made, but ultimately those decisions are not a matter of consensus. Why should the policies be revised? Because some people are coming in who don't like them? Poor reason. Being impolite will tend to reduce the weight your words are given. Demanding change is usually unsuccessful unless you can demonstrate a good reason for that change to happen, and I don't just mean I hate your policies and I think it's time you reviewed them. ChrisA ___ 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] Track ResourceWarning warnings with tracemalloc
Hi,
I'm trying to write an example of usage of the new
tracemalloc.get_object_traceback() function. Last month I proposed to
use it to give the traceback where a file/socket was allocated on
ResourceWarning:
https://mail.python.org/pipermail/python-dev/2013-October/129923.html
I found a working solution using monkey patching of the socket, _pyio
and builtins modules:
https://bitbucket.org/haypo/misc/src/tip/python/res_warn.py
This hack uses tracemalloc to retrieve the traceback where the
file/socket was allocated, but you can do the same using
traceback.extract_stack() for older Python version. So it's just an
example to show how tracemalloc can be used.
Example with test_poplib (without res_warn.py):
[1/1] test_poplib
/home/haypo/prog/python/default/Lib/test/support/__init__.py:1331:
ResourceWarning: unclosed ssl.SSLSocket fd=5,
family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('127.0.0.1',
45747), raddr=('127.0.0.1', 48933)
gc.collect()
Ok, you now that the socket was destroyed be the garbage collector...
But which test created this socket???
Example of res_warn.py with test_poplib:
[1/1] test_poplib
/home/haypo/prog/python/default/Lib/test/support/__init__.py:1331:
ResourceWarning: unclosed ssl.SSLSocket fd=5,
family=AddressFamily.AF_INET, type=2049, proto=6, laddr=('127.0.0.1',
49715), raddr=('127.0.0.1', 43904)
gc.collect()
Allocation traceback (most recent first):
File '/home/haypo/prog/python/default/Lib/ssl.py', line 340
_context=self)
File '/home/haypo/prog/python/default/Lib/poplib.py', line 390
self.sock = context.wrap_socket(self.sock)
File '/home/haypo/prog/python/default/Lib/test/test_poplib.py', line 407
self.client.stls()
File '/home/haypo/prog/python/default/Lib/unittest/case.py', line 567
self.setUp()
File '/home/haypo/prog/python/default/Lib/unittest/case.py', line 610
return self.run(*args, **kwds)
(...)
You can see that the socket was created by test_poplib at line 407
TestPOP3_TLSClass.setUp). It's more useful than the previous warning
:-)
I found two issues in _pyio and tracemalloc modules. These issues
should be fixed to use res_warn.py on text or buffered files and use
it during Python shutdown:
http://bugs.python.org/issue19831
http://bugs.python.org/issue19829
Victor
___
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] PEP process entry point and ill fated initiatives
On Fri, 29 Nov 2013 09:16:38 + Kristján Valur Jónsson krist...@ccpgames.com wrote: Closing the ticket, twice, is a rude, and unnecessary action. Closing the ticket means we don't believe there is an issue, or we don't think it would be reasonable to fix it. If that's our judgement on the issue, how is it rude to close it? How about acknowledging that these waters are dark and murky and help making things better? Well, how about? If Anatoly has a concrete proposal, surely he can propose a patch to make things better. If you want to contribute, you know how to do it! Regards Antoine. ___ 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] Track ResourceWarning warnings with tracemalloc
29.11.13 14:12, Victor Stinner написав(ла): You can see that the socket was created by test_poplib at line 407 TestPOP3_TLSClass.setUp). It's more useful than the previous warning :-) Great! ___ 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] PEP process entry point and ill fated initiatives
-Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou Sent: 29. nóvember 2013 14:58 To: python-dev@python.org Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives On Fri, 29 Nov 2013 09:16:38 + Kristján Valur Jónsson krist...@ccpgames.com wrote: Closing the ticket, twice, is a rude, and unnecessary action. Closing the ticket means we don't believe there is an issue, or we don't think it would be reasonable to fix it. If that's our judgement on the issue, how is it rude to close it? Also, this attitude. Who are the we in this case? And why send messages to people by shutting doors? How about acknowledging that these waters are dark and murky and help making things better? Well, how about? If Anatoly has a concrete proposal, surely he can propose a patch to make things better. Which is what he did. And instead of helpful ideas on how to improve his patch, the issue is closed. The acolytes have spoken. I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in. Cheers, K ___ 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] PEP process entry point and ill fated initiatives
On Fri, 29 Nov 2013 15:25:14 + Kristján Valur Jónsson krist...@ccpgames.com wrote: -Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou Sent: 29. nóvember 2013 14:58 To: python-dev@python.org Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives On Fri, 29 Nov 2013 09:16:38 + Kristján Valur Jónsson krist...@ccpgames.com wrote: Closing the ticket, twice, is a rude, and unnecessary action. Closing the ticket means we don't believe there is an issue, or we don't think it would be reasonable to fix it. If that's our judgement on the issue, how is it rude to close it? Also, this attitude. Who are the we in this case? We = core developers who are active on the tracker. Regards Antoine. ___ 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 (2013-11-22 - 2013-11-29) 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: open4317 (+37) closed 27289 (+83) total 31606 (+120) Open issues with patches: 1981 Issues opened (78) == #19352: unittest loader barfs on symlinks http://bugs.python.org/issue19352 reopened by doko #19579: test_asyncio: test__run_once timings should be relaxed http://bugs.python.org/issue19579 reopened by haypo #19638: dtoa: conversion from '__int64' to 'int', possible loss of dat http://bugs.python.org/issue19638 reopened by mark.dickinson #19715: test_touch_common failure under Windows http://bugs.python.org/issue19715 opened by pitrou #19717: resolve() fails when the path doesn't exist http://bugs.python.org/issue19717 opened by pitrou #19719: add importlib.abc.SpecLoader and SpecFinder http://bugs.python.org/issue19719 opened by brett.cannon #19720: suppress context for some exceptions in importlib? http://bugs.python.org/issue19720 opened by eric.snow #19721: Move all test_importlib utility code into test_importlib.util http://bugs.python.org/issue19721 opened by brett.cannon #19723: Argument Clinic should add markers for humans http://bugs.python.org/issue19723 opened by pitrou #19725: Richer stat object http://bugs.python.org/issue19725 opened by pjenvey #19726: BaseProtocol is not an ABC http://bugs.python.org/issue19726 opened by pitrou #19728: PEP 453: enable pip by default in the Windows binary installer http://bugs.python.org/issue19728 opened by ncoghlan #19731: Fix copyright footer http://bugs.python.org/issue19731 opened by pitrou #19732: python fails to build when configured with --with-system-libmp http://bugs.python.org/issue19732 opened by doko #19733: Setting image parameter of a button crashes with Cocoa Tk http://bugs.python.org/issue19733 opened by serhiy.storchaka #19734: venv and ensurepip are affected by pip environment variable se http://bugs.python.org/issue19734 opened by haypo #19736: posixmodule.c: Add flags for statvfs.f_flag to constant list http://bugs.python.org/issue19736 opened by doko #19737: Documentation of globals() and locals() should be improved http://bugs.python.org/issue19737 opened by Zahari.Dim #19738: pytime.c loses precision under Windows http://bugs.python.org/issue19738 opened by pitrou #19741: tracemalloc: tracemalloc_log_alloc() doesn't check _Py_HASHTAB http://bugs.python.org/issue19741 opened by haypo #19743: test_gdb failures http://bugs.python.org/issue19743 opened by larry #19744: ensurepip should refuse to install pip if SSL/TLS is not avail http://bugs.python.org/issue19744 opened by tim.peters #19745: TEST_DATA_DIR for out-of-tree builds http://bugs.python.org/issue19745 opened by christian.heimes #19746: No introspective way to detect ModuleImportFailure in unittest http://bugs.python.org/issue19746 opened by rbcollins #19748: test_time failures on AIX http://bugs.python.org/issue19748 opened by haypo #19749: test_venv failure on AIX: 'module' object has no attribute 'O_ http://bugs.python.org/issue19749 opened by haypo #19750: test_asyncio.test_unix_events constructor failures on AIX http://bugs.python.org/issue19750 opened by haypo #19751: test_sys: sys.hash_info.algorithm failure on SPARC Solaris bui http://bugs.python.org/issue19751 opened by haypo #19753: test_gdb failure on SystemZ buildbot http://bugs.python.org/issue19753 opened by haypo #19754: pickletools.optimize doesn't reframe correctly http://bugs.python.org/issue19754 opened by pitrou #19756: test_nntplib: sporadic failures, network isses? server down? http://bugs.python.org/issue19756 opened by haypo #19757: _tracemalloc.c: compiler warning with gil_state http://bugs.python.org/issue19757 opened by haypo #19758: Warnings in tests http://bugs.python.org/issue19758 opened by serhiy.storchaka #19761: test_tk fails on OS X with multiple test case failures with bo http://bugs.python.org/issue19761 opened by ned.deily #19763: Make it easier to backport statistics to 2.7 http://bugs.python.org/issue19763 opened by christian.heimes #19764: subprocess: use PROC_THREAD_ATTRIBUTE_HANDLE_LIST with STARTUP http://bugs.python.org/issue19764 opened by haypo #19766: test_venv: test_with_pip() failed on AMD64 Fedora without thr http://bugs.python.org/issue19766 opened by haypo #19767: pathlib: iterfiles() and iterdirs() http://bugs.python.org/issue19767 opened by jonash #19768: Not so correct error message when giving incorrect type to max http://bugs.python.org/issue19768 opened by vajrasky #19769: test_venv: test_with_pip() failure on AMD64 Windows Server 20 http://bugs.python.org/issue19769 opened by haypo #19770: NNTP.post broken http://bugs.python.org/issue19770 opened by sobczyk #19771: runpy should check ImportError.name before wrapping it
Re: [Python-Dev] PEP process entry point and ill fated initiatives
On 29/11/2013 15:25, Kristján Valur Jónsson wrote: I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in. I entirely agree, the development community is getting to the stage where it stinks. Consider Issue 19755. It was a low priority admittedly, but it took them 17 minutes and 47 seconds to action it, what is the world coming to? :) -- Python is the second best programming language in the world. But the best has yet to be invented. Christian Tismer 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] PEP process entry point and ill fated initiatives
Am 29.11.2013 10:16, schrieb Kristján Valur Jónsson: Reading the defect, I find people being unnecessarily obstructive. Closing the ticket, twice, is a rude, and unnecessary action. How about acknowledging that these waters are dark and murky and help making things better? Surely, documenting processes can only be an improvement? A lot has changed in open source development in the last 10 years. The processes we have are starting to have the air of cathedral around them. First, please note that many of Anatoly's tickets are not closed out of hand, because they represent a valid issue. In this specific case, the fact is simply that the PEP process has hardly anything at all to do with the peps repository, and therefore looking for PEP process info in its README.txt is irrelevant. Yes, documenting processes is good, and that's what the devguide is for. The PEP process is all about discussion. New developers who propose a PEP typically do not submit a PEP directly but are encouraged to discuss their idea first on python-ideas or python-dev. There is no entry point problem at all since they are then pointed to mail their draft to p...@python.org. This is also why it does not make sense to open pull requests against the repository (this may be what you allude to with your changes in 10 years). The PEP repo is handled by the PEP editors (and other core committers). New PEPs are checked for format and readability by the editors. In short, this issue tries to address a problem where none exists, and that is why it was closed. I cannot see why you would call that unnecessary, because I hope you don't think that the more open issues are languishing in the tracker the better :) cheers, Georg ___ 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] PEP process entry point and ill fated initiatives
On Fri, Nov 29, 2013 at 10:25 AM, Kristján Valur Jónsson krist...@ccpgames.com wrote: -Original Message- From: Python-Dev [mailto:python-dev- bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou Sent: 29. nóvember 2013 14:58 To: python-dev@python.org Subject: Re: [Python-Dev] PEP process entry point and ill fated initiatives On Fri, 29 Nov 2013 09:16:38 + Kristján Valur Jónsson krist...@ccpgames.com wrote: Closing the ticket, twice, is a rude, and unnecessary action. Closing the ticket means we don't believe there is an issue, or we don't think it would be reasonable to fix it. If that's our judgement on the issue, how is it rude to close it? Also, this attitude. Who are the we in this case? And why send messages to people by shutting doors? How about acknowledging that these waters are dark and murky and help making things better? Well, how about? If Anatoly has a concrete proposal, surely he can propose a patch to make things better. Which is what he did. And instead of helpful ideas on how to improve his patch, the issue is closed. The acolytes have spoken. But we can't accept his patches because he actively and vocally refuses to sign the CLA. It's a form of protest and he knows full well that we can't accept the patches without him signing the CLA or a legal change in how the license is handled, neither of which are about to happen. ___ 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] PEP process entry point and ill fated initiatives
On 29.11.2013 16:25, Kristján Valur Jónsson wrote: How about acknowledging that these waters are dark and murky and help making things better? Well, how about? If Anatoly has a concrete proposal, surely he can propose a patch to make things better. Which is what he did. And instead of helpful ideas on how to improve his patch, the issue is closed. The acolytes have spoken. I'm not sure we're talking about the same issue item. Anatoly did not present a patch which could have been improved: http://bugs.python.org/issue19822 Anatoly refuses to sign the Python CLA, so it's not surprising that he didn't provide a patch. His only contribution was a step-by-step process he put in the ticket description which doesn't represent the PEP process. Christian pointed him to the correct process, but he unfortunately just ignored this. I'm afraid there's nothing much we can do to make ends meet. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 29 2013) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] PEP process entry point and ill fated initiatives
On Fri, Nov 29, 2013 at 03:25:14PM +, Kristján Valur Jónsson wrote about the PEP process: How about acknowledging that these waters are dark and murky and help making things better? Well, how about? If Anatoly has a concrete proposal, surely he can propose a patch to make things better. Which is what he did. And instead of helpful ideas on how to improve his patch, the issue is closed. The acolytes have spoken. As the first-time author of a PEP (450), I did not find that the waters were dark and murky, and I certainly did not feel that the acolytes tried to shut me out, or shut themselves in as you suggest. Nobody held my hand through the process of writing the PEP, but people pointed me in the right direction and were tolerant of my newbie mistakes. The PEP process is quite well documented in the PEPs themselves, for somebody who is willing to do a bit of reading. Could the process be more clear? Could the existing docs be improved? Of course the answers to these questions are Yes, nothing is perfect. But overall, I found the PEP process to be less painful than I had feared. -- Steven ___ 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] Track ResourceWarning warnings with tracemalloc
On 29 November 2013 22:12, Victor Stinner victor.stin...@gmail.com wrote: You can see that the socket was created by test_poplib at line 407 TestPOP3_TLSClass.setUp). It's more useful than the previous warning :-) Excellent! I was hoping tracemalloc would make it practical to track some of those down :) Cheers, 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] PEP process entry point and ill fated initiatives
On 30 November 2013 01:25, Kristján Valur Jónsson krist...@ccpgames.com wrote: I know that Anatoly himself is a subject of long history here, but I myself have felt lessening affinity to the dev community in recent years. It feels like it is increasingly shutting itself in. Are you sure it isn't just that the focus of development has shifted to matters that aren't of interest or relevance to you? Many (perhaps even most) problems in Python don't require changes at the language or standard library level. We have cycle times measured in months, and impact times measured in years (especially since core development switched to Python 3 only mode for feature development). That's not typically something that is useful in day-to-day development tasks - it's only ever relevant in strategic terms. One thing that has changed for me personally, is that I've become far more blunt about refusing to respect those that explicitly (and vocally) refuse to respect us, yet seem to want to participate in core development anyway, and that's directly caused by Anatoly. He's still the only person who has been proposed for a permanent ban from all python.org controlled communication channels. That was averted after he voluntarily stopped annoying people for a while, but now he's back and I think the matter needs to be reconsidered. He refuses to sign the CLA that would allow him to contribute directly, yet still wants people to fix things for him. He refuses to read design documentation, yet still wants people to listen to his ideas. He refuses to care about other people's use cases, yet still wants people to care about his. As a case in point, Anatoly recently suggested that more diagrams in the documentation would be a good thing (http://bugs.python.org/issue19608). That's not an objectively bad idea, but producing and maintaining good diagrams is a high overhead activity, so we generally don't bother. When I suggested drawing some and sending a patch (I had forgotten about the CLA problem), Anatoly's response was that he's not a designer. So I countered with a suggestion that he explore what would be involved in adding the seqdiag and blockdiag sphinx extensions to our docs build process, since having those available would drastically lower the barrier to including and maintaining reasonable diagrams in the documentation, increasing the chance of such diagrams being included in the future. Silence. Hey some diagrams would be helpful! is not a useful contribution, it's stating the bleeding obvious. Even nominating some *specific* parts of the guide where a diagram would have helped Anatoly personally would have been useful. The technical change I suggested about figuring out what we'd need to change to enable those extensions would *definitely* have been useful. Another couple of incidents recently occurred on distutils-sig, where Anatoly started second guessing the decision to work on PyPI 2 as a test-driven-development-from-day-one incrementally developed and released system, rather than trying to update the existing fragile PyPI code base directly, as well as complaining about the not-accessible-to-end-users design docs for the proposed end-to-end security model for PyPI. It would be one thing if he was voicing those concerns on his own blog (it's a free internet, he can do what he likes anywhere else). It's a problem when he's doing it on distutils-sig and the project issue trackers. This isn't a matter of a naive newcomer that doesn't know any better. This is someone who has had PSF board members sit down with them at PyCon US to explain the CLA and why it is the way it is, who has had core developers offer them direct advice on how to propose suggestions in a way that is more likely to get people to listen, and when major issues have occurred in the past, we've even gone hunting for people to talk to him in his native language to make sure it wasn't a language barrier that was the root cause of the problem. *None* of it has resulted in any signficant improvement in his behaviour. Contributor time and emotional energy are the most precious resources an open source project has, and Anatoly is recklessly wasteful of both. We've spent years trying to coach him on being an effective collaborator and contributor, and it hasn't worked. This isn't a democracy, and neither is it a place for arbitrary people to get therapy on their inability to have any empathy for another person's point of view - in the end, passion for the language isn't enough, people have to demonstrate an ability to learn and be respectful of other people's time and energy, and Anatoly has well and truly proven he doesn't have either of those. Anatoly has the entire rest of the internet to play in, we shouldn't have to put up with his disruptions when we're actually trying to get stuff done. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing
