Mailman 3 January 2015 - Python-Dev

How do I ensure that my code is being executed?
by Neil Girdhar 20 Jan '15

20 Jan '15

I get error: TypeError: init_builtin() takes exactly 1 argument (0 given) The only source file that can generate that error is Modules/_ctypes/_ctypes.c, but when I make changes to that file such as: PyErr_Format(PyExc_TypeError, "call takes exactly %d arguments XYZABC (%zd given)", inargs_index, actual_args); I do not see any difference after make clean and a full rebuild. How is this possible? I need to debug the arguments passed. Best, Neil

5 10

[PyPI] Why are some packages on pypi.python.org/simple, but have no page?
by Martin Thoma 18 Jan '15

18 Jan '15

Hello Python developers, Could anybody please answer the following question? (I have asked it on http://stackoverflow.com/q/28010799/562769, but Steve Barnes thinks I should ask it here) I am currently analyzing packages on PyPI. I use https://pypi.python.org/simple/ to get all package names and https://pypi.python.org/pypi/numpy/json and similar to get the metadata. However, there are 514 packages (e.g. abu.rpc, acid, about-pandoc, about-numtest, ...) which do not have the https://pypi.python.org/pypi/ site, but are on https://pypi.python.org/simple/. Why is that the case? Best regards, Martin

2 1

PEP 461 and __imod__
by Ethan Furman 18 Jan '15

18 Jan '15

I have % (__mod__) working for both bytes and bytearray (yay!), but I cannot find nor figure out how to tell the bytearray object that 'xyz' is the __imod__ function. Any pointers? -- ~Ethan~

1 1

PEP 481 - Migrate Some Supporting Repositories to Git and Github
by Donald Stufft 17 Jan '15

17 Jan '15

As promised in the "Move selected documentation repos to PSF BitBucket account?" thread I've written up a PEP for moving selected repositories from hg.python.org to Github. You can see this PEP online at: https://www.python.org/dev/peps/pep-0481/ I've also reproduced the PEP below for inline discussion. ----------------------- Abstract ======== This PEP proposes migrating to Git and Github for certain supporting repositories (such as the repository for Python Enhancement Proposals) in a way that is more accessible to new contributors, and easier to manage for core developers. This is offered as an alternative to PEP 474 which aims to achieve the same overall benefits but while continuing to use the Mercurial DVCS and without relying on a commerical entity. In particular this PEP proposes changes to the following repositories: * https://hg.python.org/devguide/ * https://hg.python.org/devinabox/ * https://hg.python.org/peps/ This PEP does not propose any changes to the core development workflow for CPython itself. Rationale ========= As PEP 474 mentions, there are currently a number of repositories hosted on hg.python.org which are not directly used for the development of CPython but instead are supporting or ancillary repositories. These supporting repositories do not typically have complex workflows or often branches at all other than the primary integration branch. This simplicity makes them very good targets for the "Pull Request" workflow that is commonly found on sites like Github. However where PEP 474 wants to continue to use Mercurial and wishes to use an OSS and self-hosted and therefore restricts itself to only those solutions this PEP expands the scope of that to include migrating to Git and using Github. The existing method of contributing to these repositories generally includes generating a patch and either uploading them to bugs.python.org or emailing them to peps(a)python.org. This process is unfriendly towards non-comitter contributors as well as making the process harder than it needs to be for comitters to accept the patches sent by users. In addition to the benefits in the pull request workflow itself, this style of workflow also enables non techincal contributors, especially those who do not know their way around the DVCS of choice, to contribute using the web based editor. On the committer side the Pull Requests enable them to tell, before merging, whether or not a particular Pull Request will break anything. It also enables them to do a simple "push button" merge which does not require them to check out the changes locally. Another such feature that is useful in particular for docs, is the ability to view a "prose" diff. This Github specific feature enables a committer to view a diff of the rendered output which will hide things like reformatting a paragraph and show you what the actual "meat" of the change actually is. Why Git? -------- Looking at the variety of DVCS which are available today it becomes fairly clear that git has gotten the vast mindshare of people who are currently using it. The Open Hub (Previously Ohloh) statistics [#openhub-stats]_ show that currently 37% of the repositories Open Hub is indexing is using git which is second only to SVN (which has 48%) while Mercurial has just 2% of the indexed repositories (beating only bazaar which has 1%). In additon to the Open Hub statistics a look at the top 100 projects on PyPI (ordered by total download counts) shows us that within the Python space itself there is a majority of projects using git: === ========= ========== ====== === ==== Git Mercurial Subversion Bazaar CVS None === ========= ========== ====== === ==== 62 22 7 4 1 1 === ========= ========== ====== === ==== Chosing a DVCS which has the larger mindshare will make it more likely that any particular person who has experience with DVCS at all will be able to meaningfully use the DVCS that we have chosen without having to learn a new tool. In addition to simply making it more likely that any individual will already know how to use git, the number of projects and people using it means that the resources for learning the tool are likely to be more fully fleshed out and when you run into problems the liklihood that someone else had that problem and posted a question and recieved an answer is also far likelier. Thirdly by using a more popular tool you also increase your options for tooling *around* the DVCS itself. Looking at the various options for hosting repositories it's extremely rare to find a hosting solution (whether OSS or commerical) that supports Mercurial but does not support Git, on the flip side there are a number of tools which support Git but do not support Mercurial. Therefore the popularity of git increases the flexibility of our options going into the future for what toolchain these projects use. Also by moving to the more popular DVCS we increase the likelhood that the knowledge that the person has learned in contributing to these support repositories will transfer to projects outside of the immediate CPython project such as to the larger Python community which is primarily using Git hosted on Github. In previous years there was concern about how well supported git was on Windows in comparison to Mercurial. However git has grown to support Windows as a first class citizen. In addition to that, for Windows users who are not well aquanted with the Windows command line there are GUI options as well. On a techincal level git and Mercurial are fairly similar, however the git branching model is signifcantly better than Mercurial "Named Branches" for non-comitter contributors. Mercurial does have a "Bookmarks" extension however this isn't quite as good as git's branching model. All bookmarks live in the same namespace so it requires individual users to ensure that they namespace the branchnames themselves lest the risk collision. It also is an extension which requires new users to first discover they need an extension at all and then figure out what they need to do in order to enable that extension. Since it is an extension it also means that in general support for them outside of Mercurial core is going to be less than 100% in comparison to git where the feature is built in and core to using git at all. Finally users who are not used to Mercurial are unlikely to discover bookmarks on their own, instead they will likely attempt to use Mercurial's "Named Branches" which, given the fact they live "forever", are not often what a project wants their contributors to use. Why Github? ----------- There are a number of software projects or web services which offer functionality similar to that of Github. These range from commerical web services such as a Bitbucket to self-hosted OSS solutions such as Kallithea or Gitlab. This PEP proposes that we move these repositories to Github. There are two primary reasons for selecting Github: Popularity and Quality/Polish. Github is currently the most popular hosted repository hosting according to Alexa where it currently has a global rank of 121. Much like for Git itself by choosing the most popular tool we gain benefits in increasing the likelhood that a new contributor will have already experienced the toolchain, the quality and availablity of the help, more and better tooling being built around it, and the knowledge transfer to other projects. A look again at the top 100 projects by download counts on PyPI shows the following hosting locations: ====== ========= =========== ========= =========== ========== GitHub BitBucket Google Code Launchpad SourceForge Other/Self ====== ========= =========== ========= =========== ========== 62 18 6 4 3 7 ====== ========= =========== ========= =========== ========== In addition to all of those reasons, Github also has the benefit that while many of the options have similar features when you look at them in a feature matrix the Github version of each of those features tend to work better and be far more polished. This is hard to quantify objectively however it is a fairly common sentiment if you go around and ask people who are using these services often. Finally a reason to choose a web service at all over something that is self-hosted is to be able to more efficiently use volunteer time and donated resources. Every additional service hosted on the PSF infrastruture by the PSF infrastructure team further spreads out the amount of time that the volunteers on that team have to spend and uses some chunk of resources that could potentionally be used for something where there is no free or affordable hosted solution available. One concern that people do have with using a hosted service is that there is a lack of control and that at some point in the future the service may no longer be suitable. It is the opinion of this PEP that Github does not currently and has not in the past engaged in any attempts to lock people into their platform and that if at some point in the future Github is no longer suitable for one reason or another than at that point we can look at migrating away from Github onto a different solution. In other words, we'll cross that bridge if and when we come to it. Example: Scientific Python -------------------------- One of the key ideas behind the move to both git and Github is that a feature of a DVCS, the repository hosting, and the workflow used is the social network and size of the community using said tools. We can see this is true by looking at an example from a sub-community of the Python community: The Scientific Python community. They have already migrated most of the key pieces of the SciPy stack onto Github using the Pull Request based workflow starting with IPython and as more projects moved over it became a natural default for new projects. They claim to have seen a great benefit from this move, where it enables casual contributors to easily move between different projects within their sub-community without having to learn a special, bespoke workflow and a different toolchain for each project. They've found that when people can use their limited time on actually contributing instead of learning the different tools and workflows that not only do they contribute more to one project, that they also expand out and contribute to other projects. This move is also attributed to making it commonplace for members of that community to go so far as publishing their research and educational materials on Github as well. This showcases the real power behind moving to a highly popular toolchain and workflow, as each variance introduces yet another hurdle for new and casual contributors to get past and it makes the time spent learning that workflow less reusable with other projects. Migration ========= Through the use of hg-git [#hg-git]_ we can easily convert a Mercurial repository to a Git repository by simply pushing the Mercurial repository to the Git repository. People who wish to continue to use Mercurual locally can then use hg-git going into the future using the new Github URL, however they will need to re-clone their repositories as using Git as the server seems to trigger a one time change of the changeset ids. As none of the selected repositories have any tags, branches, or bookmarks other than the ``default`` branch the migration will simply map the ``default`` branch in Mercurial to the ``master`` branch in git. In addition since none of the selected projects have any great need of a complex bug tracker, they will also migrate their issue handling to using the GitHub issues. In addition to the migration of the repository hosting itself there are a number of locations for each particular repository which will require updating. The bulk of these will simply be changing commands from the hg equivilant to the git equivilant. In particular this will include: * Updating www.python.org to generate PEPs using a git clone and link to Github. * Updating docs.python.org to pull from Github instead of hg.python.org for the devguide. * Enabling the ability to send an email to python-checkins(a)python.org for each push. * Enabling the ability to send an IRC message to #python-dev on Freenode for each push. * Migrate any issues for these projects to their respective bug tracker on Github. This will restore these repositories to similar functionality as they currently have. In addition to this the migration will also include enabling testing for each pull request using Travis CI [#travisci]_ where possible to ensure that a new PR does not break the ability to render the documentation or PEPs. User Access =========== Moving to Github would involve adding an additional user account that will need to be managed, however it also offers finer grained control, allowing the ability to grant someone access to only one particular repository instead of the coarser grained ACLs available on hg.python.org. References ========== .. [#openhub-stats] `Open Hub Statistics <https://www.openhub.net/repositories/compare>` .. [#hg-git] `hg-git <https://hg-git.github.io/>` .. [#travisci] `Travis CI <https://travis-ci.org/>` --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

32 140

Summary of Python tracker Issues
by Python tracker 16 Jan '15

16 Jan '15

ACTIVITY SUMMARY (2015-01-09 - 2015-01-16) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 4736 (+10) closed 30277 (+33) total 35013 (+43) Open issues with patches: 2220 Issues opened (32) ================== #22038: Implement atomic operations on non-x86 platforms http://bugs.python.org/issue22038 reopened by haypo #23211: test.test_logging.SMTPHandlerTest failing on Snow Leopard http://bugs.python.org/issue23211 opened by geoffreyspear #23212: Update Windows and OS X installer copies of OpenSSL to 1.0.1k http://bugs.python.org/issue23212 opened by ned.deily #23213: subprocess communicate() hangs when stderr isn't closed http://bugs.python.org/issue23213 opened by whissi #23214: BufferedReader.read1(size) signature incompatible with Buffere http://bugs.python.org/issue23214 opened by vadmium #23215: MemoryError with custom error handlers and multibyte codecs http://bugs.python.org/issue23215 opened by alexer #23216: IDLE grep/find/replace source code needs docstrings http://bugs.python.org/issue23216 opened by Al.Sweigart #23217: help() function incorrectly captures comment preceding a neste http://bugs.python.org/issue23217 opened by rhettinger #23218: Modernize the IDLE Find/Replace/Find in Files dialogs http://bugs.python.org/issue23218 opened by Al.Sweigart #23220: IDLE does not display \b backspace correctly. http://bugs.python.org/issue23220 opened by Al.Sweigart #23224: LZMADecompressor object is only initialized in __init__ http://bugs.python.org/issue23224 opened by vadmium #23226: Add float linspace recipe to docs http://bugs.python.org/issue23226 opened by abarnert #23227: Generator's finally block not run if close() called before fir http://bugs.python.org/issue23227 opened by sjdrake #23228: Crashes when tarfile contains a symlink and unpack directory c http://bugs.python.org/issue23228 opened by mvo #23229: add inf, nan, infj, nanj to cmath module http://bugs.python.org/issue23229 opened by mark.dickinson #23231: Fix codecs.iterencode/decode() by allowing data parameter to b http://bugs.python.org/issue23231 opened by vadmium #23232: 'codecs' module functionality + its docs -- concerning custom http://bugs.python.org/issue23232 opened by zuo #23233: TypeError in ./setup.py http://bugs.python.org/issue23233 opened by serhiy.storchaka #23235: run_tests.py doesn't set test.support.verbose correctly http://bugs.python.org/issue23235 opened by berker.peksag #23236: asyncio: add timeout to StreamReader read methods http://bugs.python.org/issue23236 opened by haypo #23237: Interrupts are lost during readline PyOS_InputHook processing http://bugs.python.org/issue23237 opened by Michiel.de.Hoon #23238: http.server failed to decode '+' to ' ' when calling cgi scrip http://bugs.python.org/issue23238 opened by memkmemk #23239: SSL match_hostname does not accept IP Address http://bugs.python.org/issue23239 opened by Ádám.Zsigmond #23241: shutil should accept pathlib types http://bugs.python.org/issue23241 opened by mkesper #23243: asyncio: emit ResourceWarning warnings if transports/event loo http://bugs.python.org/issue23243 opened by haypo #23245: urllib2: urlopen() gets exception(kwargs bug?) http://bugs.python.org/issue23245 opened by Douman #23246: distutils fails to locate vcvarsall with Visual C++ Compiler f http://bugs.python.org/issue23246 opened by Gregory.Szorc #23247: Multibyte codec StreamWriter.reset() crashes http://bugs.python.org/issue23247 opened by vadmium #23248: Update ssl data http://bugs.python.org/issue23248 opened by pitrou #23249: test_win32 fails on aarch64 http://bugs.python.org/issue23249 opened by rkuska #23250: http.cookies HttpOnly attribute does not use suggested case-st http://bugs.python.org/issue23250 opened by jdufresne #23251: mention in time.sleep() docs that it does not block other Pyth http://bugs.python.org/issue23251 opened by akira Most recent 15 issues with no replies (15) ========================================== #23251: mention in time.sleep() docs that it does not block other Pyth http://bugs.python.org/issue23251 #23250: http.cookies HttpOnly attribute does not use suggested case-st http://bugs.python.org/issue23250 #23249: test_win32 fails on aarch64 http://bugs.python.org/issue23249 #23248: Update ssl data http://bugs.python.org/issue23248 #23247: Multibyte codec StreamWriter.reset() crashes http://bugs.python.org/issue23247 #23227: Generator's finally block not run if close() called before fir http://bugs.python.org/issue23227 #23218: Modernize the IDLE Find/Replace/Find in Files dialogs http://bugs.python.org/issue23218 #23217: help() function incorrectly captures comment preceding a neste http://bugs.python.org/issue23217 #23216: IDLE grep/find/replace source code needs docstrings http://bugs.python.org/issue23216 #23215: MemoryError with custom error handlers and multibyte codecs http://bugs.python.org/issue23215 #23207: logging.basicConfig does not validate keyword arguments http://bugs.python.org/issue23207 #23202: pyvenv does not fail like documented when a venv already exist http://bugs.python.org/issue23202 #23183: timeit CLI best of 3: undocumented output format http://bugs.python.org/issue23183 #23182: Update grammar tests to use new style for annotated function d http://bugs.python.org/issue23182 #23169: Reflect that PreReq and BuildPreReq are deprecated in the late http://bugs.python.org/issue23169 Most recent 15 issues waiting for review (15) ============================================= #23251: mention in time.sleep() docs that it does not block other Pyth http://bugs.python.org/issue23251 #23250: http.cookies HttpOnly attribute does not use suggested case-st http://bugs.python.org/issue23250 #23249: test_win32 fails on aarch64 http://bugs.python.org/issue23249 #23248: Update ssl data http://bugs.python.org/issue23248 #23243: asyncio: emit ResourceWarning warnings if transports/event loo http://bugs.python.org/issue23243 #23236: asyncio: add timeout to StreamReader read methods http://bugs.python.org/issue23236 #23235: run_tests.py doesn't set test.support.verbose correctly http://bugs.python.org/issue23235 #23233: TypeError in ./setup.py http://bugs.python.org/issue23233 #23231: Fix codecs.iterencode/decode() by allowing data parameter to b http://bugs.python.org/issue23231 #23228: Crashes when tarfile contains a symlink and unpack directory c http://bugs.python.org/issue23228 #23226: Add float linspace recipe to docs http://bugs.python.org/issue23226 #23218: Modernize the IDLE Find/Replace/Find in Files dialogs http://bugs.python.org/issue23218 #23216: IDLE grep/find/replace source code needs docstrings http://bugs.python.org/issue23216 #23215: MemoryError with custom error handlers and multibyte codecs http://bugs.python.org/issue23215 #23211: test.test_logging.SMTPHandlerTest failing on Snow Leopard http://bugs.python.org/issue23211 Top 10 most discussed issues (10) ================================= #23229: add inf, nan, infj, nanj to cmath module http://bugs.python.org/issue23229 20 msgs #22038: Implement atomic operations on non-x86 platforms http://bugs.python.org/issue22038 13 msgs #22932: email.utils.formatdate uses unreliable time.timezone constant http://bugs.python.org/issue22932 8 msgs #23193: Please support "numeric_owner" in tarfile http://bugs.python.org/issue23193 6 msgs #23245: urllib2: urlopen() gets exception(kwargs bug?) http://bugs.python.org/issue23245 6 msgs #1602: windows console doesn't print or input Unicode http://bugs.python.org/issue1602 5 msgs #13881: Stream encoder for zlib_codec doesn't use the incremental enco http://bugs.python.org/issue13881 5 msgs #14014: codecs.StreamWriter.reset contract not fulfilled http://bugs.python.org/issue14014 5 msgs #20132: Many incremental codecs don’t handle fragmented data http://bugs.python.org/issue20132 5 msgs #23201: Decimal(0)**0 is an error, 0**0 is 1, but Decimal(0) == 0 http://bugs.python.org/issue23201 5 msgs Issues closed (33) ================== #11835: python (x64) ctypes incorrectly pass structures parameter http://bugs.python.org/issue11835 closed by berker.peksag #19777: Provide a home() classmethod on Path objects http://bugs.python.org/issue19777 closed by pitrou #20467: Confusing wording about __init__ http://bugs.python.org/issue20467 closed by ethan.furman #21581: Consider dropping importlib.abc.Loader.create_module() http://bugs.python.org/issue21581 closed by brett.cannon #21896: Unexpected ConnectionResetError in urllib.request against a va http://bugs.python.org/issue21896 closed by ned.deily #21902: Docstring of math.acosh, asinh, and atanh http://bugs.python.org/issue21902 closed by mark.dickinson #22560: New SSL implementation based on ssl.MemoryBIO http://bugs.python.org/issue22560 closed by haypo #22952: multiprocessing doc introduction not in affirmative tone http://bugs.python.org/issue22952 closed by pitrou #22988: No error when yielding from `finally` http://bugs.python.org/issue22988 closed by ethan.furman #22997: Minor improvements to "Functional API" section of Enum documen http://bugs.python.org/issue22997 closed by ethan.furman #23013: Tweak wording for importlib.util.LazyLoader in regards to Load http://bugs.python.org/issue23013 closed by brett.cannon #23018: Add version info to python http://bugs.python.org/issue23018 closed by steve.dower #23063: `python setup.py check --restructuredtext --strict --metadata` http://bugs.python.org/issue23063 closed by python-dev #23160: Respect the environment variable SVNROOT in external-common.ba http://bugs.python.org/issue23160 closed by python-dev #23173: asyncio: kill the subprocess if the creation failed http://bugs.python.org/issue23173 closed by haypo #23181: Unicode "code point" should be two words in documentation http://bugs.python.org/issue23181 closed by python-dev #23185: add inf and nan to math module http://bugs.python.org/issue23185 closed by mark.dickinson #23189: Set docstrings to empty string when optimizing with -OO. http://bugs.python.org/issue23189 closed by rhettinger #23197: asyncio: check if a future is cancelled before calling set_res http://bugs.python.org/issue23197 closed by haypo #23198: asyncio: refactor StreamReader http://bugs.python.org/issue23198 closed by haypo #23206: json.dumps(ensure_ascii=False) is ~10x slower than json.dumps( http://bugs.python.org/issue23206 closed by pitrou #23209: asyncio: break some cycles http://bugs.python.org/issue23209 closed by haypo #23210: remove the word "virtual" from help(range) http://bugs.python.org/issue23210 closed by python-dev #23219: asyncio: cancelling wait_for(task, timeout) must also cancel t http://bugs.python.org/issue23219 closed by python-dev #23221: "a(n) the", "the a(n)" typos http://bugs.python.org/issue23221 closed by python-dev #23222: open doesn't provide traceback for int argument http://bugs.python.org/issue23222 closed by SilentGhost #23223: subprocess32 unable to be installed via pip http://bugs.python.org/issue23223 closed by haypo #23225: selectors: raise an exception if the selector is closed http://bugs.python.org/issue23225 closed by haypo #23230: Bug parsing integers with zero padding http://bugs.python.org/issue23230 closed by r.david.murray #23234: refactor subprocess: use new OSError exceptions, factorize std http://bugs.python.org/issue23234 closed by haypo #23240: pip 6.0.6- pip install command is broken http://bugs.python.org/issue23240 closed by brett.cannon #23242: asyncio: Process must close the transport when the process exi http://bugs.python.org/issue23242 closed by haypo #23244: doc typo in 'Glossary': 'generator' http://bugs.python.org/issue23244 closed by python-dev

1 0

Compile Python on Windows (OpenSSL)
by Victor Stinner 15 Jan '15

15 Jan '15

Hi, To compile Python on Windows, there are a few information in the Developer Guide: https://docs.python.org/devguide/setup.html#windows-compiling Python 3.5 now requires Visual Studio 2010 *SP1*, or newer Visual Studio: http://bugs.python.org/issue22919#msg233637 I found PCbuild\readme.txt which is not mentionned in the devguide :-/ https://hg.python.org/cpython/file/56f717235c45/PCbuild/readme.txt (at least not on the Windows section of the setup page) I found some clues to build OpenSSL to be able to build the Python ssl module, but I still have issues. Is there a more complete documentation? I found how to install svn.exe, perl.exe and nasm.exe, but not how to install nmake.exe. I don't know the command to build OpenSSL. I don't care of building OpenSSL, my goal is only to build the Python ssl module. Is there a way to install a development version of OpenSSL (.lib files if I remember correctly) from an installer/binary? My draft notes: +Compile CPython on Windows +========================== + +To build the Python ssl extension: + +Need: + +* Visual Studio 2010 SP1 or newer +* CPython source code (default branch: 3.5) +* perl binary: ActivePerl +* svn binary, ex: SilkSVN +* nasm and nmake binaries: compile NASM (install the binary doesn't install nmake) + +Read PCbuild/readme.txt. + +* Build Python (in debug mode) +* Type: PCbuild\get_externals.bat +* Type: PCbuild\win32\python_d.exe PCbuild\prepare_ssl.py externals\openssl-1.0.1j Victor

8 23

Schedule for 3.4.3, revised schedule for 3.5.0a1
by Larry Hastings 15 Jan '15

15 Jan '15

Python 3.5.0a1 is currently scheduled to be released February 1. Since I'll be on the road that day, the 3.5 team has agreed to push the release back a week. 3.5.0a1 will be tagged Saturday February 7 and released Sunday February 8. This doesn't change any of the other release dates for 3.5.. Since it's about time for a 3.4.3 anyway, we're going to push that out at the same time. 3.4.3rc1 will be tagged Saturday February 7 and released Sunday February 8. 3.4.3 final will follow two weeks later, tagged Saturday February 21 and released Sunday February 22. Get your bug fixes (3.4) and crazy new functionality (3.5) in now! //arry/

1 0

Re: [Python-Dev] Overriding stdlib http package
by Demian Brecht 14 Jan '15

14 Jan '15

I had considered that but thought that dev might be more appropriate as it's related to overriding a stdlib module in order to work on that module out of band with cpython (with the intention of merging back upstream). I would imagine those on the dev list may be better suited to answer. On Wed, Jan 14, 2015, 08:37 Ian Cordasco <graffatcolmingov(a)gmail.com> wrote: I think this belongs on python-list, not python-dev.

1 0

Overriding stdlib http package
by Demian Brecht 14 Jan '15

14 Jan '15

Hi all, As part of the work I'm doing on httplib3 (now that I've actually gotten a bit of time), one of the things I'm trying to get done is injection of httplib3 over http in order to not have to modify all import paths in modules and such. Here's the gist of what I have so far: https://gist.github.com/demianbrecht/bc6530a40718e4fcbf90. It's greatly simplified over importlib2's inject mechanism, but I'm assuming that's largely due to requirements of that package (i.e. Python 2) in contrast to this one. My question is: Does this look sane? Is there anything that I might be not accounting for? It /does/ seem to work as expected when running tests, but I'm curious if there's anything that I might be missing that might jump out at someone more intimately familiar with the mechanics of importlib. Thanks, Demian

1 1

Fix for `python setup.py check --restructuredtext`
by Marc Abramowitz 14 Jan '15

14 Jan '15

Looking for a core developer who can review a distutils change -- it's a very small change: http://bugs.python.org/issue23063 Let me know how I can help (e.g.: if I can review or test something to offset time spent). Cheers, Marc

1 0