On 4/14/2014 5:00 PM, Guido van Rossum wrote: > On Mon, Apr 14, 2014 at 3:53 PM, Terry Reedy <tjreedy at udel.edu > <mailto:tjreedy at udel.edu>> wrote: >> If the company is profitable, it could afford >> to fund a half- to full-time developer. By using the vague 'fund' I meant either hire themselves or donate to PSF to somehow 'fund' work. I think we need both. > A few people have made similar suggestions to me at the conference, but > I personally believe that there is a better way. > > I don't think we ought to make companies feel bad about not donating to > the PSF. My only beef is with people who use Python *and* complain about unpaid volunteers not doing the un-fun work they want done that they could do or fund themselves. But that is part of life. The PSF is doing fine, but IMO it shouldn't be in the business > of employing core developers. Being an employer is fraught with > difficulties, and there are serious risks both for the PSF (due to the > rigidity of employment laws, for example) and for the employee (e.g. > benefits, worry about continuity, oversight and direction). I was thinking in terms of contracting rather than employing -- perhaps for working on the backlog of hundreds of doc issues. But even that requires selection, training, and supervision. Perhaps I should write a grant application to pick and supervise one or more college students to work on neglected issues. Then the grants committee volunteers would just have to say yes or no and later continue or stop. > IMO a much better approach would be to convince companies to free up > some of their current employees or new hires to invest e.g. 50% of their > time into core Python development. This would be great, but it is not something I can be very convincing about ;-). I hope you succeed. But I suspect that some of the things I think need to be done will not be done by corporate employees. Hence the 'both' above. ... > (I should say that this is my own situation at Dropbox and previously at > Google, and I personally wouldn't want it any other way.) I think your continued practical experience is good for Python. >> Sounds like they are looking ahead several years and anxious to >> avoid the 'comfortable with XP' trap. > > Ohhh, nice analogy! >>> The two important components of Python 2migr8 would be the ability to >>> disable 2.7-only features, and to do so on a module-by-module basis. >> A reasonable request of pydev would be for python-coded stdlib >> modules to be updated as much as possible, if that has not already >> been done. No 'apply', no 'except SomeException, e'. 'Reasonable request': a request plausible enough that we should discuss it and maybe say yes. I looked and apply is already not hardly used except in lib2to3 and its test in test_builtins. There are hundreds of the old exception form. The re for an re.sub call would have to not match tuple commas, such as in 'except (KeyError, IndexError): > I'm not sure what you're proposing here, Focused, carefully considered, behavior neutral changes that help migration, if indeed there are such, by letting an stdlib module work with an altered 2.7 interpreter. The existence of decent test coverage for a module would be a consideration. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4