[Python-Dev] project culture: take responsibility for your commits
Stefan Behnel writes: > Hi, I'm looking back on a rather unpleasant experience that I > recently had in this developer community. Actually, twice by > now. Here's what I take from it: You should take responsibility for > your commits. I have no clue who you're addressing this advice to. If it's not yourself (from the following, I gather it's not), I think the implication of what you are saying is mistaken. Core devs (by which I mean the high-profile developers who are candidates for PEP delegate) regularly do take responsibility for their commits, just like any other committer, by changing or reverting them. That's visible on this list as well as in the commit logs. > Let's assume these complaints [about the code] are reasonable That's not sufficient. They must also be presented reasonably, by the standards of the community. Not everybody is good at doing that, and those who aren't suffer, as does the project for losing a useful contribution. Unfortunate, but digging out what matters from unclear or high-handed presentations requires an enormous amount of effort, like pyschotherapy. Good psychotherapists bill hundreds of dollars an hour. The very best "pythotherapists" bill nothing, at least not to this community. Regarding the specific core dev behavior that offended you, I can speak from my experience in another project. > What do you do in that case? Do you tell them that what's in is in? I've done that and later reversed my position. In retrospect, I believe I was correct at the time of first approach in the majority of cases, though, on the grounds of the "lesser of two evils" as I understood the issues (or occasionally that the contributor had completely misunderstood the issues). In most cases the original requester never did come up with a coherent argument, just that something unclear to me didn't work for them. Reversal in such cases was due to a third party who was able to explain the requester's requirements, and often contribute (most of) a specification of a complete fix or a good compromise. > Do you tell them that you are a core developer and they are not? I've done that. I don't know if it applies to the cases you have in mind, but invariably that was a last retort when I just wanted to shut down a conversation that had already come back to the same place twice, and polite guidance seemed to be a complete failure. Childish, I guess, but it's been effective. That's not sufficient reason to use it in Python, which has higher standards for courtesy than my other project does. Caveat: as with the next item, I have to wonder if you mistook an explanation that in such disputes, the Python default is to go with the core dev's gut feeling unless there's good reason to do otherwise, and you haven't explained well enough yet for a snotty "I am and you're not, so go away!" > That they can try to do better, and if they are lucky, find someone > else who applies their patch? Definitely, and I would advise any core developer to use exactly that response as soon as they feel the discussion is becoming unprofitable. Of course they should spin it differently, something like Well, I don't agree that reverting my patch is necessary, and something needs to be done to address the issue it handles. You are welcome to propose your own patch, but I suggest you seek out an alternative reviewer as it's hard for me to be objective about my own code once I'm convinced it's correct. Are you *sure* that your phrasing above is what the reviewers wrote, and not merely what you took from their writing? "Insult is far more frequently taken than given." In sum, I don't see what you're complaining about. Sure, you may have been mistreated in the case(s) in question, which sucks, of course. If so, you should provide details, and maybe the particular kind of case would be a lesson to all of us. Or perhaps some core devs systematically abuse their positions (but as Brett says you should be very careful about making that statement in public!) But I don't see evidence that there's a systematic failure to review "core dev" commits, or that "core devs" deny their own fallibility. Nor do I think any of the behaviors you describe *out of context* are always wrong (except "I'm a core dev and you're not" should be avoided even if effective; it's rude and ad hominem). ___ 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] project culture: take responsibility for your commits
On 3 Oct 2013 09:00, "Nick Coghlan" wrote: > > Stefan, > > You blew up a minor design disagreement over the new async parsing API for XML into a huge impending disaster that would destroy the XML library APIs forever. In truth, even if we had left the original commit alone it would, at worst, have resulted in a slightly inconsistent API design. > > I get that you're passionate about the relevant API since you need to replicate it in lxml. I even agree that the API we ended up with after I got involved as a mediator to separate out the legitimate complaints from the hyperbole is better than the one that was originally committed. > > But when your opening gambit is to accuse people of complete incompetence (and you repeat similar accusations multiple times over the course of the disagreement), developers are entirely within their rights to stop listening to the abuse. > > It's important to remember that this is a project staffed by volunteers, and some basic civility and appreciation for those efforts goes a long way in obtaining a more constructive response. In the absence of that, don't be surprised if the reaction is "There may be a valid complaint somewhere in there, but I'm not wading through the vitriol to look for it". I'll also note that the affected developers *didn't* completely ignore the concerns you raised (which would have been an entirely reasonable response), but instead asked me to help out as a neutral mediator. That's an entirely responsible thing for them to do, and one that resulted in the underlying technical concerns being resolved *despite* the unwarranted abuse. Regards, Nick. > > 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] project culture: take responsibility for your commits
Stefan, You blew up a minor design disagreement over the new async parsing API for XML into a huge impending disaster that would destroy the XML library APIs forever. In truth, even if we had left the original commit alone it would, at worst, have resulted in a slightly inconsistent API design. I get that you're passionate about the relevant API since you need to replicate it in lxml. I even agree that the API we ended up with after I got involved as a mediator to separate out the legitimate complaints from the hyperbole is better than the one that was originally committed. But when your opening gambit is to accuse people of complete incompetence (and you repeat similar accusations multiple times over the course of the disagreement), developers are entirely within their rights to stop listening to the abuse. It's important to remember that this is a project staffed by volunteers, and some basic civility and appreciation for those efforts goes a long way in obtaining a more constructive response. In the absence of that, don't be surprised if the reaction is "There may be a valid complaint somewhere in there, but I'm not wading through the vitriol to look for it". 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] PEP-431 non-status
On Wed, Oct 2, 2013 at 9:42 PM, Lennart Regebro wrote: > On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman wrote: >> On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote: >>> If you wonder about the lack of progress reports on pep-431, this is >>> because of a lack of progress. I simply haven't had any time to work >>> on this. I considered make a kickstarter so I could take time off from >>> working, but to be honest, even with that, I still have no time to >>> realistically get this in before beta 1. >> >> Is there a list of stuff that needs to be done? I might be able to help out. > > Yes. > > 1. Implement the PEP. > > :-) > > I looked at it during the PyCon sprint, and I had hoped to be able to > mostly move pytz into datetime, but unfortunately it wasn't that easy, > because of the way datetime normalization works. The pytz > normalization calls methods that would need to call the > normalization... :-) I think the first thing that needs to happen is get the is_dst flag in. Then we can turn pytz into a new, sane API without all that awful normalization stuff :) It doesn't all have to land in the same release. ___ 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] project culture: take responsibility for your commits
On Wed, Oct 2, 2013 at 2:58 PM, Stefan Behnel wrote: > Hi, > > I'm looking back on a rather unpleasant experience that I recently had in > this developer community. Actually, twice by now. Here's what I take from > it: > > You should take responsibility for your commits. > > Sounds like a simple thing - in theory. People make mistakes, that's > normal. You can't always know what others do with your code, and so > something that might sound like a great idea when you come up with it, may > turn out to have a negative impact that you didn't, and sometimes couldn't > possibly, anticipate. > > So, people will come to you and complain. Let's assume these complaints are > reasonable (and they certainly aren't always). What do you do in that case? > > Do you tell them that what's in is in? Do you tell them that you are a core > developer and they are not? That they can try to do better, and if they are > lucky, find someone else who applies their patch? That's what happened to > me recently. > I think a key point in this is what "responsibility" is. There is a constant struggle between open source contributions and volunteering, of taking your time to contribute something for free to the benefit of the world and trying to meet the requests/demands of that world. How far should someone bend over backwards to try and accommodate others in the world when what the core dev has done is viewed by them as reasonable and don't think the requested change is worth their time (assuming it's even appropriate). So are core devs "responsible" for making everyone happy? Where is the line of what is a reasonable request to consider it their responsibility to meet that request? It's all very subjective. When someone becomes a core developer it is because they code well and seem to have the community's interest at heart. This also means they are trusted to make a reasonable call as to what is a responsible response when a request comes in. In this instance, the core dev disagreed with the request but left the door open for another core dev to come in and champion the change; IOW a -0 on the proposed change (full disclaimer to the list: I know what triggered this email). If you disagreed with the decision strongly you can try to convince another core dev or all of python-dev to see if you can get another core dev to step in on your side, but is completely within a core dev's right to say "no" to a request. I think the level of responsibility also varies from project to project as hosted on hg.python.org. For instance, I do not hold devinabox to the same backwards compatibility requirement as CPython. If I change the command-line API of something like build_python.py and someone came to me and said "I disagree with that change" I feel like I have the right to say I disagree as devinabox has no released versions to be compatible against, etc. I really does depend on what your view of "responsibility" is and for what project. It's all very subjective and if you disagree that's fine and you can say so and ask for another opinion. Heck, you can even say you are worried a developer is not taking their responsibility seriously, but that's obviously a major step to not be taken lightly. ___ 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] cpython: Use cached builtins.
I don't remember where, but I remember that I also saw things like "str=str, len=len, ...". So you keep the same name, but you use fast local lookups instead of slow builtin lookups. Victor 2013/10/2 Antoine Pitrou : > On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) > serhiy.storchaka wrote: >> http://hg.python.org/cpython/rev/d48ac94e365f >> changeset: 85931:d48ac94e365f >> user:Serhiy Storchaka >> date:Wed Oct 02 19:15:54 2013 +0300 >> summary: >> Use cached builtins. > > What's the point? I don't think it's a good idea to uglify the code if > there isn't a clear benefit. > > 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/victor.stinner%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] cpython: Use cached builtins.
02.10.13 20:31, Antoine Pitrou написав(ла): On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka wrote: http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user:Serhiy Storchaka date:Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins. What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit. These builtins already were cached. I only change recently added code to use cached values. The point was perhaps that the access to module globals is a little faster than to builtins. Fred Drake was introduced this in changeset 261a70c0aa79. You can open a separate issue for removing this caching or for adding new builtins to this set. ___ 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] cpython: Use cached builtins.
On 10/2/13 1:31 PM, Antoine Pitrou wrote: On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka wrote: http://hg.python.org/cpython/rev/d48ac94e365f changeset: 85931:d48ac94e365f user:Serhiy Storchaka date:Wed Oct 02 19:15:54 2013 +0300 summary: Use cached builtins. What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit. This type of micro-optimization seems especially unnecessary in a module intended for printing. --Ned. 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/ned%40nedbatchelder.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
[Python-Dev] project culture: take responsibility for your commits
Hi, I'm looking back on a rather unpleasant experience that I recently had in this developer community. Actually, twice by now. Here's what I take from it: You should take responsibility for your commits. Sounds like a simple thing - in theory. People make mistakes, that's normal. You can't always know what others do with your code, and so something that might sound like a great idea when you come up with it, may turn out to have a negative impact that you didn't, and sometimes couldn't possibly, anticipate. So, people will come to you and complain. Let's assume these complaints are reasonable (and they certainly aren't always). What do you do in that case? Do you tell them that what's in is in? Do you tell them that you are a core developer and they are not? That they can try to do better, and if they are lucky, find someone else who applies their patch? That's what happened to me recently. Here's what I'd like to see people do instead. 1) You should discuss the issue with them. If their complaints are reasonable, you may simply have been wrong. Or you may have been right, but couldn't know that there was more beyond the visible. Be open. If you're lucky, the discussion will make the problem obvious to someone else, and a patch will come for free. 2) You should invest a reasonable effort to fix the issue yourself. After all, you produced it by changing something, even if you couldn't possibly see it coming. Take responsibility for your commits. 3) If you can't fix your change, consider reverting it. No change is often better than a bad one. Maybe the time wasn't right for it. Maybe there's a better way to do it that isn't obvious yet. Taking a change back is not showing the white feather. It's showing responsibility. I know that these things aren't always easy. Sometimes people come yelling. Sometimes their complaints are plain wrong. Sometimes the huge impact they see is actually minuscule compared to the upsides. And sometimes the real size of the impact may not actually be visible to you. Be open and they will be, too. Stefan ___ 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] cpython: Use cached builtins.
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST) serhiy.storchaka wrote: > http://hg.python.org/cpython/rev/d48ac94e365f > changeset: 85931:d48ac94e365f > user:Serhiy Storchaka > date:Wed Oct 02 19:15:54 2013 +0300 > summary: > Use cached builtins. What's the point? I don't think it's a good idea to uglify the code if there isn't a clear benefit. 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] PEP-431 non-status
That could be a possibility as well. On Wed, Oct 2, 2013 at 6:14 PM, Stuart Bishop wrote: > On Wed, Oct 2, 2013 at 9:42 PM, Lennart Regebro wrote: >> On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman wrote: >>> On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote: If you wonder about the lack of progress reports on pep-431, this is because of a lack of progress. I simply haven't had any time to work on this. I considered make a kickstarter so I could take time off from working, but to be honest, even with that, I still have no time to realistically get this in before beta 1. >>> >>> Is there a list of stuff that needs to be done? I might be able to help out. >> >> Yes. >> >> 1. Implement the PEP. >> >> :-) >> >> I looked at it during the PyCon sprint, and I had hoped to be able to >> mostly move pytz into datetime, but unfortunately it wasn't that easy, >> because of the way datetime normalization works. The pytz >> normalization calls methods that would need to call the >> normalization... :-) > > I think the first thing that needs to happen is get the is_dst flag > in. Then we can turn pytz into a new, sane API without all that awful > normalization stuff :) It doesn't all have to land in the same > release. ___ 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] cpython (2.7): Add fake buildbottouch target.
Am 30.09.13 20:11, schrieb Antoine Pitrou: > On Mon, 30 Sep 2013 16:18:57 +0200 (CEST) > martin.v.loewis wrote: >> http://hg.python.org/cpython/rev/c1a294bbb4fa >> changeset: 85882:c1a294bbb4fa >> branch: 2.7 >> parent: 85877:dd55d54b2a15 >> user:Martin v. Löwis >> date:Mon Sep 30 16:18:31 2013 +0200 >> summary: >> Add fake buildbottouch target. > > "make touch" does exist in 2.7, so was this new target needed? Thanks for pointing this out; I must have missed that. I have now dropped the buildbottouch target again. Regards, Martin ___ 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-431 non-status
On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman wrote: > On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote: >> If you wonder about the lack of progress reports on pep-431, this is >> because of a lack of progress. I simply haven't had any time to work >> on this. I considered make a kickstarter so I could take time off from >> working, but to be honest, even with that, I still have no time to >> realistically get this in before beta 1. > > Is there a list of stuff that needs to be done? I might be able to help out. Yes. 1. Implement the PEP. :-) I looked at it during the PyCon sprint, and I had hoped to be able to mostly move pytz into datetime, but unfortunately it wasn't that easy, because of the way datetime normalization works. The pytz normalization calls methods that would need to call the normalization... :-) //Lennart ___ 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-431 non-status
On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote: > If you wonder about the lack of progress reports on pep-431, this is > because of a lack of progress. I simply haven't had any time to work > on this. I considered make a kickstarter so I could take time off from > working, but to be honest, even with that, I still have no time to > realistically get this in before beta 1. Is there a list of stuff that needs to be done? I might be able to help out. Cheers, Dirkjan ___ 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-431 non-status
That's a shame, but there's always 3.5 and we'll hopefully have an easier path to "pip install pytz" in 3.4 (once I get PEP 453 revised appropriately). Cheers, Nick. On 2 October 2013 22:17, Lennart Regebro wrote: > Hi all! > > If you wonder about the lack of progress reports on pep-431, this is > because of a lack of progress. I simply haven't had any time to work > on this. I considered make a kickstarter so I could take time off from > working, but to be honest, even with that, I still have no time to > realistically get this in before beta 1. > > Sorry about that! > > //Lennart > ___ > 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 -- 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
[Python-Dev] PEP-431 non-status
Hi all! If you wonder about the lack of progress reports on pep-431, this is because of a lack of progress. I simply haven't had any time to work on this. I considered make a kickstarter so I could take time off from working, but to be honest, even with that, I still have no time to realistically get this in before beta 1. Sorry about that! //Lennart ___ 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
