[Python-Dev] Winding down 3.4
We of the core dev community commit to supporting Python releases for five years. Releases get eighteen months of active bug fixes, followed by three and a half years of security fixes. Python 3.4 turns 5 next March--at which point we'll stop supporting it, and I'll retire as 3.4 release manager. My plan is to make one final release on or around its fifth birthday containing the last round of security fixes. That's about seven months from now. Nothing has been merged since the releases of 3.4.9 and 3.5.6 last week, and there are no open PRs against either of those releases. But! There are still a couple languishing "critical" bugs: "shutil copy* unsafe on POSIX - they preserve setuid/setgit bits" https://bugs.python.org/issue17180 "XML vulnerabilities in Python" https://bugs.python.org/issue17239 "fflush called on pointer to potentially closed file" (Windows only) https://bugs.python.org/issue19050 It'd be nice to resolve all those issues, one way or another, before we retire 3.4. See you next March, //arry/ ___ 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] [python-committers] Winding down 3.4
Le 13/08/2018 à 11:49, Larry Hastings a écrit : > > > We of the core dev community commit to supporting Python releases for > five years. Releases get eighteen months of active bug fixes, followed > by three and a half years of security fixes. Python 3.4 turns 5 next > March--at which point we'll stop supporting it, and I'll retire as 3.4 > release manager. > > My plan is to make one final release on or around its fifth birthday > containing the last round of security fixes. That's about seven months > from now. Nothing has been merged since the releases of 3.4.9 and 3.5.6 > last week, and there are no open PRs against either of those releases. > > But! There are still a couple languishing "critical" bugs: > > "shutil copy* unsafe on POSIX - they preserve setuid/setgit bits" > https://bugs.python.org/issue17180 > > "XML vulnerabilities in Python" > https://bugs.python.org/issue17239 > > "fflush called on pointer to potentially closed file" (Windows only) > https://bugs.python.org/issue19050 > > It'd be nice to resolve all those issues, one way or another, before we > retire 3.4. So that 3.4 dies in good health? Regards Antoine. ___ 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] A Subtle Bug in Class Initializations
On Fri, Aug 10, 2018 at 6:49 PM Steve Dower wrote: > > On 10Aug2018 0354, Erik Bray wrote: > > Thanks! I'm not sure what you mean by "on other OS's" though. Do you > > mean other OS's that happen to use Windows-style PE/COFF binaries? > > Because other than Windows I'm not sure what we care about there. > > > > For ELF binaries, at least on Linux (and probably elsewhere) it the > > runtime loader can perform more sophisticated relocations when loading > > a binary into memory, including relocating pointers in the binary's > > .data section. This allows it to initialize data in one executable > > "A" with pointers to data in another library "B" *before* "A" is > > considered fully loaded and executable. > > > > So this problem never arises, at least on Linux. > > That's exactly what I meant. I simply didn't know how/whether other > loaders handled this case :) I recognise it's nothing to do with the > binary format and everything to do with whether the loader knows what to > do or not. Ah, that's not exactly what *I* meant, but you are also right: In principle it shouldn't have anything to do with the binary formation. You could stuff a more sophisticated dynamic relocation section into a PE/COFF binary too but Windows wouldn't know what to do with it. So you're right that this kind of problem could affect other OSes, I just have no idea if it does. > >>> So I'm +1 for requiring passing NULL to PyVarObject_HEAD_INIT, > >>> requiring PyType_Ready with an explicit base type argument, and maybe > >>> (eventually) making PyVarObject_HEAD_INIT argumentless. > >> > >> Since PyVarObject_HEAD_INIT currently requires PyType_Ready() in > >> extension modules already, then don't we just need to fix the built-in > >> types? > >> > >> As far as the "eventually" case, I'd hope that eventually extension > >> modules are all using PyType_FromSpec() :) > > > > +1 :) > > Is that just a +1 for PyType_FromSpec(), or are you agreeing that we > only need to fix the built-in types? Both! I think we should fix the built-in types, but it would be nice if more extension modules used PyType_FromSpec, if nothing else because I find it much more readable, and (I'm guessing) it's better from the perspective of Victor's C-API work. But I admit I'm not fully versed in the downsides (if there are any). ___ 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] Can we split PEP 489 (extension module init) ?
On Sun, 12 Aug 2018 at 00:50, Stefan Behnel wrote: > > Petr Viktorin schrieb am 10.08.2018 um 13:48: > > Would this be better than a flag + raising an error on init? > > Ok, I've implemented this in Cython for now, to finally move the PEP-489 > support forward. The somewhat annoying drawback is that module reloading > previously *seemed* to work, simply because it didn't actually do anything. > Now, people will get an exception in cases that previously worked silently. > An exception would probably have been better from the beginning, because it > clearly tells people that what they are trying is not supported. Now it's a > bit of a breaking change. I'll see what it gives. If the breakage turns out to cause problems, some potential ways to mitigate it would be: 1. Emulate the old "extension modules are singletons" behaviour in the module creation slot, and only emit a deprecation warning when it gets called multiple times rather than failing outright. 2. As for 1, but error out when the active interpreter changes (that will let a module support reloading, while explicitly erroring out if you attempt to load it from multiple subinterpreters) Both of those would need some level of PEP 3121 support to clear out the singleton state when the module gets outright destroyed, but they'd still provide a middle ground between the ill-defined behaviour of single-phase initialisation and full-fledged support multiple concurrently loaded independent copies of the same extension module. Under that interpretation, the required clarification in PEP 489 would be to replace the term "supports" with "has clearly defined and documented behaviour", and then make it clear that that defined behaviour is allowed to be "Fails with an exception explaining the limitation", or "manages some internal state as a process-level singleton". Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] [python-committers] Winding down 3.4
“So that 3.4 dies in good health?” More like getting all its evil deeds off its chest on the death bed, I think :) Top-posted from my Windows 10 phone From: Antoine Pitrou Sent: Monday, 13 August 2018 2:59 To: Larry Hastings; python-committers; Python-Dev Subject: Re: [python-committers] Winding down 3.4 Le 13/08/2018 à 11:49, Larry Hastings a écrit : > > > We of the core dev community commit to supporting Python releases for > five years. Releases get eighteen months of active bug fixes, followed > by three and a half years of security fixes. Python 3.4 turns 5 next > March--at which point we'll stop supporting it, and I'll retire as 3.4 > release manager. > > My plan is to make one final release on or around its fifth birthday > containing the last round of security fixes. That's about seven months > from now. Nothing has been merged since the releases of 3.4.9 and 3.5.6 > last week, and there are no open PRs against either of those releases. > > But! There are still a couple languishing "critical" bugs: > > "shutil copy* unsafe on POSIX - they preserve setuid/setgit bits" > https://bugs.python.org/issue17180 > > "XML vulnerabilities in Python" > https://bugs.python.org/issue17239 > > "fflush called on pointer to potentially closed file" (Windows only) > https://bugs.python.org/issue19050 > > It'd be nice to resolve all those issues, one way or another, before we > retire 3.4. So that 3.4 dies in good health? Regards Antoine. ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ 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
