Re: [Python-Dev] Windows XP, Python 3.5 and PEP 11
2014-06-17 7:01 GMT+02:00 Tim Golden : > On 17/06/2014 04:08, Zachary Ware wrote: >> This was recently discussed in the "Moving Python 3.5 on Windows to a >> new compiler" thread, where Martin declared XP support to be ended >> [1]. I believe Tim Golden is the only resident Windows dev from whom >> I haven't seen at least implicit agreement that XP doesn't need >> further support, so I'd say our support for XP is well and truly dead >> :) >> >> In any case, surely anyone stuck with XP can be happy with Python 3.4. >> I'm perfectly fine with 3.2 on Win2k! >> > > I think we're justified in dropping XP support, for all the reasons others > have given. Would you be ok to make this official by adding Windows XP explicitly to the PEP 11? (I can do the change, I'm just asking for a confirmation.) > Like most people, I suppose, I'm support WinXP in various ways > (including embedded) because "not supported" != "not working". But those are > all running 2.x versions of Python. I'm ok to provide a best-effort support of Windows XP on Python 2.7 (and maybe also Python 3.4), especially if there are Windows XP buildbots. We can drop Windows XP support in Python 3.5 only. 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
[Python-Dev] Commit "avoid a deadlock with the interpreter head lock and the GIL during finalization"
Hi, I just saw a change in Python finalization related to threads. I'm not sure that it is correct to not call tstate_delete_common(). Is this change related to an issue? I don't see any specific test. --- changeset 91234:5ccb6901cf95 3.4 avoid a deadlock with the interpreter head lock and the GIL during finalization author Benjamin Peterson date Mon, 16 Jun 2014 23:07:49 -0700 (61 minutes ago) parents d1d1ed421717 children 2ed64ea19d81 fceb3a907260 files Python/pystate.c diffstat 1 files changed, 8 insertions(+), 0 deletions(-) [+] http://hg.python.org/cpython/rev/5ccb6901cf95 --- 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] Windows XP, Python 3.5 and PEP 11
On 17/06/2014 08:03, Victor Stinner wrote: 2014-06-17 7:01 GMT+02:00 Tim Golden : On 17/06/2014 04:08, Zachary Ware wrote: This was recently discussed in the "Moving Python 3.5 on Windows to a new compiler" thread, where Martin declared XP support to be ended [1]. I believe Tim Golden is the only resident Windows dev from whom I haven't seen at least implicit agreement that XP doesn't need further support, so I'd say our support for XP is well and truly dead :) In any case, surely anyone stuck with XP can be happy with Python 3.4. I'm perfectly fine with 3.2 on Win2k! I think we're justified in dropping XP support, for all the reasons others have given. Would you be ok to make this official by adding Windows XP explicitly to the PEP 11? (I can do the change, I'm just asking for a confirmation.) From PEP 11 the entire "Microsoft Windows" section. Please see the third paragraph. "Microsoft has established a policy called product support lifecycle [1]. Each product's lifecycle has a mainstream support phase, where the product is generally commercially available, and an extended support phase, where paid support is still available, and certain bug fixes are released (in particular security fixes). Python's Windows support now follows this lifecycle. A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired. Subsequent bug fix releases will support the same Windows releases as the original feature release (even if the extended support phase has ended). Because of this policy, no further Windows releases need to be listed in this PEP. Each feature release is built by a specific version of Microsoft Visual Studio. That version should have mainstream support when the release is made. Developers of extension modules will generally need to use the same Visual Studio release; they are concerned both with the availability of the versions they need to use, and with keeping the zoo of versions small. The Python source tree will keep unmaintained build files for older Visual Studio releases, for which patches will be accepted. Such build files will be removed from the source tree 3 years after the extended support for the compiler has ended (but continue to remain available in revision control)." -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ 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] Criticism of execfile() removal in Python3
On Mon, Jun 16, 2014 at 3:39 PM, Nick Coghlan wrote:
> > FWIW, when I started using python (15?) years ago -- the first thing I
> looked for was a way to "just run a file", at the interactive prompt, like
> I had in MATLAB. I found and used execfile().
>
> Yes, if people are looking for a MATLAB replacement, they want IPython
> rather than the default REPL.
>
I didn't meant o distract the conversation here -- what I meant was that
even before iPython existed, I still dropped using execfile("") it was
hardly ever the right thing.
And for the micropython example, I'm proposing that a micropython
interactive environment would be a really nice thing to build -- and worth
doing, even if execfile() was still there.
By the way: iPython, while coming from, and heavily used by, the
scientific/numeric computing community, is a great tool for all sorts of
other python development as well. But probably too heavyweight for
micropython.
-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
[Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required
Python Dev, Andy here. I have a Windows product based on Python and I'm getting hammered to release a version that includes the fix in OpenSSL 1.0.1h. My product is built on a Windows system using Python installed from the standard Python installer at Python.org. I would be grateful if I could get some advice on my options. Will Python.org be releasing a Windows installer with the fix any time soon or will it be at the next scheduled release in November? If it is November, there's no way I can wait that long. Now what? Would it be best to build my own Python? Is it possible to drop in new OpenSSL versions on Windows without rebuilding Python? Looking for some guidance on how to handle these OpenSSL issues on Windows. Thanks! Andy Yates ___ 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] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required
Yates, Andy (CS Houston, TX) wrote: > Python Dev, > Andy here. I have a Windows product based on Python and I'm getting hammered > to > release a version that includes the fix in OpenSSL 1.0.1h. My product is built > on a Windows system using Python installed from the standard Python installer > at > Python.org. I would be grateful if I could get some advice on my options. Will > Python.org be releasing a Windows installer with the fix any time soon or will > it be at the next scheduled release in November? If it is November, there's no > way I can wait that long. Now what? Would it be best to build my own Python? > Is > it possible to drop in new OpenSSL versions on Windows without rebuilding > Python? Looking for some guidance on how to handle these OpenSSL issues on > Windows. You'll only need to rebuild the _ssl and _hashlib extension modules with the new OpenSSL version. The easiest way to do this is to build from source (which has already been updated for 1.0.1h if you use the externals scripts in Tools\buildbot), and you should just be able to drop _ssl.pyd and _hashlib.pyd on top of a normal install. Aside: I wonder if it's worth changing to dynamically linking to OpenSSL? It would make this kind of in-place upgrade easier when people need to do it. Any thoughts? (Does OpenSSL even support it?) Cheers, Steve > Thanks! > Andy Yates ___ 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] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required
On 17.06.2014 20:27, Steve Dower wrote: > Yates, Andy (CS Houston, TX) wrote: >> Python Dev, >> Andy here. I have a Windows product based on Python and I'm getting hammered >> to >> release a version that includes the fix in OpenSSL 1.0.1h. My product is >> built >> on a Windows system using Python installed from the standard Python >> installer at >> Python.org. I would be grateful if I could get some advice on my options. >> Will >> Python.org be releasing a Windows installer with the fix any time soon or >> will >> it be at the next scheduled release in November? If it is November, there's >> no >> way I can wait that long. Now what? Would it be best to build my own Python? >> Is >> it possible to drop in new OpenSSL versions on Windows without rebuilding >> Python? Looking for some guidance on how to handle these OpenSSL issues on >> Windows. > > You'll only need to rebuild the _ssl and _hashlib extension modules with the > new OpenSSL version. The easiest way to do this is to build from source > (which has already been updated for 1.0.1h if you use the externals scripts > in Tools\buildbot), and you should just be able to drop _ssl.pyd and > _hashlib.pyd on top of a normal install. > > Aside: I wonder if it's worth changing to dynamically linking to OpenSSL? It > would make this kind of in-place upgrade easier when people need to do it. > Any thoughts? (Does OpenSSL even support it?) Yes, no problem at all, but you'd still have to either do a new release every time a new OpenSSL problem is found (don't think that's an option for Python) or provide new compiled versions compatible with the Python modules needing the OpenSSL libs or instructions on how to build these. Note that the hash routines are rarely affected by these OpenSSL bugs. They usually only affect the SSL/TLS protocol parts. Alternatively, you could make use of our pyOpenSSL distribution, which includes pyOpenSSL and the OpenSSL libs (also for Windows): http://www.egenix.com/products/python/pyOpenSSL/ We created this to address the problem of having to update OpenSSL rather often. It doesn't support Python 3 yet, but on the plus side, you do get OpenSSL libs which are compiled with the same compiler versions used for the Python.org installers. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required
In article <81f84430ce0242e5bfa5b2264777d...@blupr03mb389.namprd03.prod.outlook.com >, Steve Dower wrote: > You'll only need to rebuild the _ssl and _hashlib extension modules with the > new OpenSSL version. The easiest way to do this is to build from source > (which has already been updated for 1.0.1h if you use the externals scripts > in Tools\buildbot), and you should just be able to drop _ssl.pyd and > _hashlib.pyd on top of a normal install. Should we consider doing a re-spin of the Windows installers for 2.7.7 with 1.0.1h? Or consider doing a 2.7.8 in the near future to address this and various 2.7.7 regressions that have been identified so far (Issues 21652 and 21672)? > Aside: I wonder if it's worth changing to dynamically linking to OpenSSL? It > would make this kind of in-place upgrade easier when people need to do it. > Any thoughts? (Does OpenSSL even support it?) OpenSSL is often dynamically linked in Python builds on various other platforms, for example, on Linux or OS X. -- Ned Deily, [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
Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required
On Tue, Jun 17, 2014, at 12:03, Ned Deily wrote: > In article > <81f84430ce0242e5bfa5b2264777d...@blupr03mb389.namprd03.prod.outlook.com > >, > Steve Dower wrote: > > You'll only need to rebuild the _ssl and _hashlib extension modules with > > the > > new OpenSSL version. The easiest way to do this is to build from source > > (which has already been updated for 1.0.1h if you use the externals scripts > > in Tools\buildbot), and you should just be able to drop _ssl.pyd and > > _hashlib.pyd on top of a normal install. > > Should we consider doing a re-spin of the Windows installers for 2.7.7 > with 1.0.1h? Or consider doing a 2.7.8 in the near future to address > this and various 2.7.7 regressions that have been identified so far > (Issues 21652 and 21672)? I think we should do a 2.7.8 soon to pick up the openssl upgrade and recent CGI security fix. I would like to see those two regressions fixed first, though. ___ 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] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required
Le 17/06/2014 14:55, M.-A. Lemburg a écrit : Alternatively, you could make use of our pyOpenSSL distribution, which includes pyOpenSSL and the OpenSSL libs (also for Windows): http://www.egenix.com/products/python/pyOpenSSL/ We created this to address the problem of having to update OpenSSL rather often. This is very nice, but does it also upgrade the OpenSSL version used by the _ssl and _hashlib modules? 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] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required
On 17.06.2014 22:36, Antoine Pitrou wrote: > Le 17/06/2014 14:55, M.-A. Lemburg a écrit : >> >> Alternatively, you could make use of our pyOpenSSL distribution, >> which includes pyOpenSSL and the OpenSSL libs (also for Windows): >> >> http://www.egenix.com/products/python/pyOpenSSL/ >> >> We created this to address the problem of having to update >> OpenSSL rather often. > > This is very nice, but does it also upgrade the OpenSSL version used by the > _ssl and _hashlib modules? On Unix, tt will if you load pyOpenSSL before importing _ssl or _hashlib (and those modules are built as shared libs). Alternatively, you can set LD_LIBRARY_PATH to lib/python2.7/OpenSSL to have the system linker use the embedded libs before starting Python. Then it will always use the up-to-date libs. On Windows, this won't work, because _ssl and _hashlib are statically linked against the OpenSSL libs. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 17 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-06-17: Released eGenix PyRun 2.0.0 ... http://egenix.com/go58 2014-06-09: Released eGenix pyOpenSSL 0.13.3 ... http://egenix.com/go57 2014-07-02: Python Meeting Duesseldorf ... 15 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Criticism of execfile() removal in Python3
On 18 Jun 2014 01:59, "Chris Barker" wrote: > > By the way: iPython, while coming from, and heavily used by, the scientific/numeric computing community, is a great tool for all sorts of other python development as well. But probably too heavyweight for micropython. (we're drifting off topic, so this will be my last addition to this subthread) Yes, as great as IPython is, when it's considered out of scope for the standard installers, it's unlikely to be a good fit for a version of Python aimed at running *on* a microcontroller. Running on a Raspberry Pi or remote PC and *talking* to an associated microcontroller is a different story, though. Cheers, Nick. > > -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
