If you have an interest in linking to the Windows builds of Python 2.7 and 3.5+ using mingw, please visit http://bugs.python.org/issue24385
Unless someone can provide me with the One True Way to generate a lib that will work for everyone, I'm going to replace the lib file with instructions on how to generate it with your own tools. I've done enough guessing and need someone who actually uses mingw to step up and help out.
On 06/03/2015 08:56 AM, Antoine Pitrou wrote:
> Le 03/06/2015 14:34, Rose Ames a écrit :
>> On 06/03/2015 04:59 AM, Antoine Pitrou wrote:
>>> On Tue, 02 Jun 2015 21:20:10 +0000
>>> Brett Cannon <brett(a)python.org> wrote:
>>>> I vaguely remember people suggesting writing the minimal zip reading code
>>>> in C but I can't remember why since we have I/O access in importlib through
>>>> _io and thus it's really just the pulling apart of the zip file to get at
>>>> the files to import and thus should be doable in pure Python.
>>> You would need other modules, such as struct and zlib, right?
>> zlib is already required for compressed zips:
> Ah, the C code already importing the zlib module? Then I guess it's fine :-)
>> Do some companies
>> zip the standard library or something?
> I don't know. If they do so, they probably exclude the zlib module in
> some way.
Sounds like I can just add a zipimporter to Lib/importlib/_bootstrap.py
and remove zipimport.c entirely, is that right?
At pycon I talked with a few people about bugs.python.org/issue19699.
The consensus seemed to be that zipimport wants a lot of work, possibly
I'll have some time to work on this over the next couple of months, but
I want to be working on the right thing. Could the people who were
involved in that conversation remind me of their concerns with
zipimport? What exactly would the goal of a rewrite be?
The new test_importlib.extension.test_loader is currently leaking
references, (issue24268). There is a simple hack to stop this, but I'm
inclined to not apply quick hacks and rather dig into the root cause.
(It's a test module, the refleaks are relatively harmless.)
The tests are based directly on the "xxlimited" example,
xxlimited.Xxo, which exhibits the same bug -- it's just not tested.
It's is caused by a combination of a few factors, but I'm not sure
what's a bug and what's just undocumented behavior, so I'm asking for
input to put me on the right track.
As reported in issue16690, heap types with a naïve custom tp_dealloc
leak references to the type when instantiated. According to , it
seems that tp_dealloc should check if it has been overridden, and if
so, decref the type. This needs to be documented (regardless of the
solution to the other problems), and I intend to document it.
We can change xxlimited to do the check and decref, but isn't it too
ugly for a module that showcases the extension module API?
(xxlimited.Xxo can technically skip the check, since it doesn't allow
subclasses, but that would be setting a nasty trap for anyone learning
from that example.)
The nice way out would be taking advantage of PEP 442: xxlimited.Xxo
can ditch tp_dealloc in favor of tp_traverse and tp_finalize (the
former of which it needs anyway to behave correctly). Unfortunately,
tp_finalize is not available in the stable ABI (issue24345). I think
it should be added; is it too late for 3.5?
Another problem is that xxlimited is untested. It's only built for
non-debug builds, because Py_LIMITED_API and Py_DEBUG are
incompatible. Would it make sense to build and test it without
Py_LIMITED_API in debug mode, instead of not building it at all?
On 02.06.15 04:58, ned.deily wrote:
> changeset: 96458:30da21d2fa4f
> branch: 2.7
> parent: 96454:5e8fa1b13516
> user: Ned Deily <nad(a)acm.org>
> date: Mon Jun 01 18:45:49 2015 -0700
> Issue #24357: Change host in socket.getaddrinfo example to one that
> does support IPv6 and IPv4; www.python.org currently does not.
> Doc/library/socket.rst | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
> diff --git a/Doc/library/socket.rst b/Doc/library/socket.rst
> --- a/Doc/library/socket.rst
> +++ b/Doc/library/socket.rst
> @@ -262,12 +262,12 @@
> The following example fetches address information for a hypothetical TCP
> - connection to ``www.python.org`` on port 80 (results may differ on your
> + connection to ``google.com`` on port 80 (results may differ on your
> system if IPv6 isn't enabled)::
example.org does support IPv6 and IPv4 too, and is not commercial name.
On 06/01/2015 11:09 AM, Barry Warsaw wrote:
> Please welcome Ned Deily as RM for Python 3.6.
We're in good hands. For two versions now Benjamin and Ned have been
quietly cleaning up my mistakes after (nearly) every release. My guess
is, Ned won't bother making the mistakes in the first place!
On 31 May 2015 at 19:07, Ludovic Gasc <gmludo(a)gmail.com> wrote:
> About Python 3 migration, I think that one of our best control stick is
> newcomers, and by extension, Python trainers/teachers.
> If newcomers learn first Python 3, when they will start to work
> professionally, they should help to rationalize the Python 3 migration
> inside existing dev teams, especially because they don't have an interest
> conflict based on the fact that they haven't written plenty of code with
> Python 2.
> 2020 is around the corner, 5 years shouldn't be enough to change the
> community mind, I don't know.
The education community started switching a while back - if you watch
Carrie-Anne Philbin's PyCon UK 2014 keynote, one of her requests for
the broader Python community was for everyone else to just catch up
already in order to reduce student's confusion (she phrased it more
politely than that, though). Educators need to tweak examples and
exercises to account for a version switch, but that's substantially
easier than migrating hundreds of thousands or even millions of lines
of production code.
And yes, if you learn Python 3 first, subsequently encountering Python
2's quirks and cruft is likely to encourage folks that know both
versions of the language to start advocating for a version upgrade :)
After accounting for the "Wow, the existing Python 2 install base is
even larger than we realised" factour, the migration is actually in a
pretty good place overall these days. The "enterprise" crowd really
are likely to be the only ones that might need the full remaining 5
years of migration time (and they may potentially have even more time,
if they're relying on a commercial redistributor).
Web frameworks have allowed Python 3 development for a while now, and
with Django switching their tutorial to Python 3 by default, Django
downloads via pip show one of the highest proportions of Python 3
adoption on PyPI. www.python.org itself is now a production Python 3
Django web service, and the next generation of pypi.python.org will be
a Pyramid application that's also running on Python 3.
The dedicated async/await syntax in 3.5 represents a decent carrot to
encourage migration for anyone currently using yield (or yield from)
based coroutines, since the distinct syntax not only allows for easier
local reasoning about whether something is an iterator or a coroutine,
it also provides a much improved user experience for asynchronous
iterators and context managers (including finally handling the
"asynchronous database transaction as a context manager" case, which
previous versions of Python couldn't really do at all).
The matrix multiplication operator is similarly a major improvement
for the science and data analysis part of the Python community.
In terms of reducing *barriers* to adoption, after inviting them to
speak at the 2014 language summit, we spent a fair bit of time with
the Twisted and Mercurial folks over the past year or so working
through "What's still missing from Python 3 for your use cases?", as
Python 3.4 was still missing some features for binary data
manipulation where we'd been a bit too ruthless in pruning back the
binary side of things when deciding what counted as text-only
features, and what was applicable to binary data as well. So 3.5
brings back binary interpolation, adds a hex() method to bytes, and
adds binary data support directly to a couple of standard library
modules (tempfile, difflib).
If I understand the situation correctly, the work Guido et al have
been doing on PEP 484 and type hinting standardisation is also aimed
at reducing barriers to Python 3 adoption, by making it possible to
develop better migration tools that are more semantically aware than
the existing syntax focused tools. The type hinting actually acts as a
carrot as well, since it's a feature that mainly shows its value when
attempting to scale a *team* to larger sizes (as it lets you delegate
more of the code review process to an automated tool, letting the
human reviewers spend more time focusing on higher level semantic
Finally, both Debian/Ubuntu and Fedora are well advanced in their
efforts to replace Python 2 with Python 3 in their respective default
images (but keeping Py2 available in their package repos). That work
is close to finished now (myself, Slavek Kabrda, Barry Warsaw, and
Matthias Klose had some good opportunities to discuss that at PyCon),
although there are still some significant rough edges to figure out
(such as coming up with a coherent cross-platform story for what we're
going to do with the Python symlink), as well as a few more key
projects to either migrate entirely, or at least finish porting to the
source compatible subset of Python 2 & 3 (e.g. Samba).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I'm trying to script a command line uninstall of Python 3.5. The new
installer has a nice well-documented command line interface, but
there's nothing much about how to uninstall.
Looking at the installed products, I see
>get-wmiobject Win32_Product -filter 'name like "Python 3.5.0b2%"' | select Name
Python 3.5.0b2 pip Bootstrap (64-bit)
Python 3.5.0b2 Development Libraries (64-bit)
Python 3.5.0b2 C Runtime (64-bit)
Python 3.5.0b2 Tcl/Tk Support (64-bit)
Python 3.5.0b2 Standard Library (64-bit)
Python 3.5.0b2 Executables (64-bit)
Python 3.5.0b2 Core Interpreter (64-bit)
Python 3.5.0b2 Launcher (32-bit)
Python 3.5.0b2 Documentation (64-bit)
Python 3.5.0b2 Utility Scripts (64-bit)
Python 3.5.0b2 Test Suite (64-bit)
Normally I'd be able to call the Uninstall method on the installed
product, but here, I'm not sure which of the above I'd call
"Uninstall" on (there's only one "Programs and Features" entry for
3.5, and I can't tell which of these is equivalent to it - or if I
need to uninstall each in turn, I don't know what order they need to
be done in).
(get-wmiobject -query 'select * from Win32_Product where name =
"Python 2.7.8 (64-bit)"').Uninstall()
is an automated, command line silent uninstall of Python 2.7.8. What
(if anything) would be the equivalent for 3.5.0b2?