[python-committers] Enabling depreciation warnings feature code cutoff
On 2017-11-06, Nick Coghlan wrote: > Gah, seven years on from Python 2.7's release, I still get caught by > that. I'm tempted to propose we reverse that decision and go back to > enabling them by default :P Either enable them by default or make them really easy to enable for development evironments. I think some setting of the PYTHONWARNINGS evironment variable should do it. It is not obvious to me how to do it though. Maybe there should be an environment variable that does it more directly. E.g. PYTHONWARNDEPRECATED=1 Another idea is to have venv to turn them on by default or, based on a command-line option, do it. Or, maybe the unit testing frameworks should turn on the warnings when they run. The current "disabled by default" behavior is obviously not working very well. I had them turned on for a while and found quite a number of warnings in what are otherwise high-quality Python packages. Obviously the vast majority of developers don't have them turned on. Regards, Neil ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Enabling depreciation warnings feature code cutoff
On 2017-11-06, R. David Murray wrote: > I'm curious which ones you are seeing it in? It could be we are > operating in different problem spaces :) In the last few months: Pillow, docutils, dateutil. Some of them could have been PendingDeprecationWarning, I'm not sure. I had that enabled as well. So, maybe the warnings would have been fixed once they became DeprecationWarning. The fact that unittest enables the warnings should help a lot. Regards, Neil ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Transfer of power
On 2018-07-12, Yury Selivanov wrote: > One way would be to re-elect them every 5 or so years. Essentially, > an N-virate is a dictator-like entity for a few years. Modeling the body after a supreme court seems like a good idea. They don't have to make day-to-day decisions, only settle disputes that cannot be resolved by normal processes. Having an N-virate entity would diffuse some of the criticism they will almost certainly receive for their decisions. Having them serve for multiple years will provide more consistency of direction. Having multiple members will allow members to be replaced without too much disruption. The most important decision is what will we call this entity? ;-P I'm sure Barry will have a good idea. Is a "cabal" the correct term? Cheers, Neil ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] possible future PEP discussion format [was: Transfer of power]
On 2018-07-13, Ethan Furman wrote: > I stopped reading the PEP 572 threads once it was painfully > obvious that almost all new replies were just saying the same > things over and over and over... Perhaps this can be seen as a kind of economic problem. What is the cost of posting to a PEP discussion thread vs the cost of everyone reading that post? Or, what is the value of the comment vs what is cost for everyone to read it? With the current discussion method, the costs are often disproportionate. You have hundreds of people reading the thread. So that cost is pretty high. Posting a half-baked comment is too easy. Starting a new thread with a new subject line is too easy. One idea is to have a list dedicated to PEP discussions. We could establish a set of rules (cultural norms) for discussion on that list. E.g. - do your background research before posting: read PEP in its entirety, read complete PEP discussion thread - make high quality posts: ensure your points are truly bringing new ideas forth, present them clearly and succinctly - lay down rules for subject lines of posts, when you can start a new thread. Off topic discussion should go back to python-ideas. python-ideas can remain a free-wheeling wild west. Make the PEP discussion list a formal discussion forum. If people don't follow the rules, warn them and ultimately ban them from the list. Thinking about subject line rules, it would be helpful to organize threads by PEP, by topic and sub-topic. E.g. PEP 572: R: informal educator feedback PEP 572: S: comprehension scope PEP 572: S: operator precedence of := Possible topic abbreviations: R: Rationale S: Syntax and semantics E: Examples Regards, Neil ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Would anyone STOP contributing to Python if we used GitHub?
On 2015-12-15, Vinay Sajip wrote: > Brett Cannon python.org> writes: > > Also realize that anyone who says they will walk away will be held to > > their word; if we still choose to switch to GitHub I will expect you to > > no longer contribute to Python and will personally hold you to your word > > seems a little strong. Even principled people can change their minds about > things, can't they? To me, this does come across like an ultimatum (Stefan's > word) or a threat (your word) I agree this is too strong. If people don't want to use GitHub, they can clone from a different repos, maybe PSF can even provide one. Patches can be sent using the 'git am' command. I don't see why not using GitHub means you can't contribute to Python. We would be rejecting valuable contributions for no good reason. You could say something like "you will not get commit access through GitHub". I.e. you will have to get someone else to commit or pull your changes. Regards, Neil ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers
[python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit
On 2017-01-21, Brett Cannon wrote: > So the common theme here regardless of whether you agree with Raymond or > Victor's approach to development is that we are not getting enough code > reviews to go around. To me that's what the systemic issue is that this > email is bringing up. I think there is another issue. What pace of evolution is appropriate for Python 3.x? Python 2.7.x represents an extreme position: bug fixes only. Evolution for 3.x is too fast for some users. It is natural that as Python matures the average user is more interested in a stable langage than in bleeding-edge features. Python 3.x should be compelling to those users if we want to smoothly end-of-life 2.x. If 3.x looks like a "change treadmill" then 2.7 will have a long life. I don't know how to solve that. Having experimental and stable forks of 3.x seems bad. Incompatible language versions are a drain on the ecosystem. However, a total block of language evolution is also no good. Maybe we could emulate the Linux kernel releases. I.e. have relatively fast moving development but also choose releases to give long maintenance cycles. Ideally the long term releases would be synchronized with OS distribitions (e.g. Red Hat, Debian, Ubuntu). The Linux kernel has a strict policy of not breaking user space programs. For Python, a similar rule would be not breaking Python programs. Until 2.x has finally died out, I think we should have an extra conservative policy on incompatible language changes. Lack of patch reviewers is a major problem. Linux seems to have an advantage of more contributors and that many are paid to work on Linux. As far as I'm aware, there is no core Python developer who works mostly on Python and gets paid for it. So, we have to work with what we have or figure out some way to get people funded. BTW, thanks for working on the GitHub migration Brett. I think it will help. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit
On 2017-01-24, Victor Stinner wrote: > You should take a look at this old deferred PEP: > https://www.python.org/dev/peps/pep-0407/ Thanks, that's very close to what I was thinking. I would still add that we should be extra careful about incompatible language features until 2.7.x usage has mostly died off. That isn't logically part of the PEP but a general development philosophy I think we should adopt. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Pace of change for Python 3.x
On 2017-01-25, A.M. Kuchling wrote: > I think this is the next frontier for Python maintenance; we need > full-time core maintainers, no third parties are funding any such > developers, and the PSF doesn't seem interested in pursuing that. IMHO, the PSF should be doing it. I don't know exactly how the Linux Foundation works but my superficial understanding is that the LF gets funding mostly from big companies and then directly pays some Linux developers. Most notable, Linus is paid by the LF. Probably it is hard to attract and retrain top talent with a Patreon-like donation system. Software hackers are an eclectic group so some of them would prefer that system. However, I would guess the majority would prefer more stable employment. Regarding PEP 407, I agree the LTS periods need to be longer. Certainly we can't force core developers into doing maintenance. However, there should be a process for an officially blessed LTS release. As a project, we should decide that it is worthwhile and figure out how to help make it happen. I guess we could decide that we don't want to do LTS releases. I would accept that. Personally I think it would be a huge mistake, especially at this point. Python 2.7 is poised to become the ultimate LTS release of Python. I fear if we can't get more people to upgrade in the next few years, Python will be forever fractured into two communities. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
