Re: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
> On Dec 18, 2016, at 9:26 PM, Larry Hastings wrote: > > So, if you have an opinion, please vote for one of these three options: > • Don't slip 3.5.3. and 3.4.6. > • Slip 3.5.3 and 3.4.6 by two weeks to match 3.6.0. > • Slip 3.5.3 and 3.4.6 by a whole month, to give 3.6.0 the ability to > slip again without us having to change the release. I vote for not slipping. 2.7.13 is out. 3.6.0 is almost out. And it would be nice to have the others done as well. That way, we know the whole source tree is open and can start moving forward without reservations. Also, I would like the 3.6.0 announcement to not get drowned-out or attenuated by other announcements around older releases (i.e. it would be nice if 3.6.0 was the actual latest release of any version for a while). Raymond ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Constifying C API
2016-12-18 9:31 GMT+01:00 Serhiy Storchaka : > Originally C API didn't use the const qualifier. Over few last years the > const qualifier was added to C API if that preserved backward compatibility. > For example input "char *" parameters were changed to "const char *". This > makes C API compatible with C++, eliminates C compiler warnings, and helps > to found possible errors. Since the "const" keyword does not impact the stable *ABI*, I think that it's fine to add use it in more places. In the worst case, if an extension chose to be compiled with -Werror (convert warnings into errors), the maintainer will have to fix conversion warnings in the code. But it's easy to write C code which works with and without const (old and new Python *API*), using explicit cast (to const char* for example). In the common case, it will just be a warning and nobody will notice it since more and more people use pip which compiles C extensions in the background and doesn't show GCC output anymore. I agree that it can help to find real bugs. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cleanup of abstract.h header
2016-12-16 11:24 GMT+01:00 Antoine Pitrou : > Since you are cleaning up, you could remove the whole "PROPOSAL: A > Generic Python Object Interface for Python C Modules" introduction, > which isn't very interesting to read today. Done: hg.python.org/cpython/rev/3ab0a6692e25 Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
On 12/19/2016 12:26 AM, Larry Hastings wrote: Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and 3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle" around the release. I expect a flood of adoption of 3.6, and people switching will find bugs, and maybe those bugs are in 3.5 or 3.4. So it just seemed sensible. 3.6 just slipped by two weeks. So now there's less than two weeks between 3.6.0 final shipping and tagging the release canddiates for 3.5.3 and 3.4.6. This isn't as much time as I'd like. If I had total freedom to do as I liked, I'd slip my releases by two weeks to match 3.6. But there might be people planning around 3.5.3 and 3.4.6--like Guido was waiting for 3.5.3 for something iirc. So, if you have an opinion, please vote for one of these three options: * Don't slip 3.5.3. and 3.4.6. I am mildly in favor of this. There are already known bugs in 3.5 that will not get fixed, no matter how long you delay the final maintenance release. There are even bugs left in 2.7 after 6 years of fixing. In the meanwhile, it is a mild nuisance to have 3 3.x maintenance branches open. I don't know when Brett will move us to GIT and how that might impact the timing. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should I delay 3.5.3 and 3.4.6 by two weeks?
On Mon, 19 Dec 2016 at 06:29 Terry Reedy wrote: > On 12/19/2016 12:26 AM, Larry Hastings wrote: > > > > > > Python 3.6.0 final just slipped by two weeks. I scheduled 3.5.3 and > > 3.4.6 to ship about a month after 3.6.0 did, to "let the dust settle" > > around the release. I expect a flood of adoption of 3.6, and people > > switching will find bugs, and maybe those bugs are in 3.5 or 3.4. So it > > just seemed sensible. > > > > 3.6 just slipped by two weeks. So now there's less than two weeks > > between 3.6.0 final shipping and tagging the release canddiates for > > 3.5.3 and 3.4.6. This isn't as much time as I'd like. > > > > If I had total freedom to do as I liked, I'd slip my releases by two > > weeks to match 3.6. But there might be people planning around 3.5.3 and > > 3.4.6--like Guido was waiting for 3.5.3 for something iirc. > > > > So, if you have an opinion, please vote for one of these three options: > > > > * Don't slip 3.5.3. and 3.4.6. > > I am mildly in favor of this. There are already known bugs in 3.5 that > will not get fixed, no matter how long you delay the final maintenance > release. There are even bugs left in 2.7 after 6 years of fixing. In > the meanwhile, it is a mild nuisance to have 3 3.x maintenance branches > open. > > I don't know when Brett will move us to GIT and how that might impact > the timing. > Slipping doesn't affect me yet as all the pieces are still not quite in place. So a shift in release just shifts the blackout period for the week prior to the 3.5.3 release. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?
On 2016-12-16, 23:59 GMT, Guido van Rossum wrote: > No need to get all bent out of shape. My proposal is to simply > add a note to the docs recommending against using this. > I wouldn't change any code, not even a silent deprecation > warning. (Also, read the rest of the thread to learn why this > is not the best practice for writing Python 2/3 straddling > code.) Oh, that sounds a way better. Thank you. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: [email protected] GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If Patrick Henry thought that taxation without representation was bad, he should see how bad it is with representation. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?
Please don't get rid of unicode+literals -- I don't even think we should depreciate it as a recommendation or discourage it. Maybe a note or two added as to where issues may arise would be good. I've found importing unicode_literals to be an excellent way to write py2/3 code. And I have never found a problem. I'm also hoping that my py2/3 compatible code will someday be py3 only -- and then I'll be really glad that I don't have all those u" all over the place. Also it does "automagically" do the right thing with, for instance passing a literal to the file handling functions in the os module -- so that's pretty nice. The number of times you need to add a b"" is FAR fewer than "text" string literals. Let's keep it. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
