Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

(sorry if you get this twice, I dropped python-dev by mistake) On 07/05/2016 07:02 PM, Steven D'Aprano wrote: > On Tue, Jul 05, 2016 at 09:53:24AM +0200, Petr Viktorin wrote: > >> While we're on the subject, I'd like to offer another point for >> consideration: not all impleme

Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On 07/05/2016 10:05 AM, Chris Angelico wrote: > On Tue, Jul 5, 2016 at 5:53 PM, Petr Viktorin <encu...@gmail.com> wrote: >> If packages had a way to opt-out of needing the whole standard library, >> and instead specify the stdlib subset they need, answering questions >>

[Python-Dev] Breaking up the stdlib (Was: release cadence)

On 07/04/2016 12:19 AM, Steve Dower wrote: > My thinking on this issue was that some/most packages from the stdlib > would move into site-packages. Certainly I'd expect asyncio to be in > this category, and probably typing. Even going as far as email and > urllib would potentially be beneficial

Re: [Python-Dev] When should pathlib stop being provisional?

On 04/06/2016 08:53 AM, Nathaniel Smith wrote: > On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan wrote: >> On 6 April 2016 at 15:57, Serhiy Storchaka wrote: >>> On 06.04.16 05:44, Nick Coghlan wrote: The most promising option for that is probably

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On 02/11/2016 11:07 AM, Nick Coghlan wrote: > On 11 February 2016 at 19:59, Victor Stinner wrote: >> 2016-02-11 9:11 GMT+01:00 Georg Brandl : >>> On 02/11/2016 12:04 AM, Victor Stinner wrote: It looks like the implementation

Re: [Python-Dev] Reference cycle on the module dict (globals())

On 01/19/2016 10:42 AM, Victor Stinner wrote: > Hi, > > While working on my FAT Python optimizer project, I found an annoying > bug in my code. When at least one guard is created with a reference to > the global namespace (globals(), the module dictionary), objects of > the module are no more

Re: [Python-Dev] Discussion related to memory leaks requested

On 01/14/2016 10:45 AM, Nick Coghlan wrote: > On 14 January 2016 at 15:42, Benjamin Peterson wrote: >> This is a "well-known" issue. Parts of the interpreter (and especially, >> extension modules) cheerfully stash objects in global variables with no >> way to clean them up.

Re: [Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc

On Mon, Jun 1, 2015 at 6:00 PM, Antoine Pitrou solip...@pitrou.net wrote: [...] I think we have been laxist with additions to the stable ABI: apparently, they should be conditioned on the API version requested by the user. For example, in pystate.h: #if !defined(Py_LIMITED_API) ||

Re: [Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc

On Mon, Jun 1, 2015 at 5:33 PM, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 1 Jun 2015 16:38:35 +0200 Petr Viktorin encu...@gmail.com wrote: [...] 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

[Python-Dev] Avoiding reference leaks in heap types with custom tp_dealloc

Hello, 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

Re: [Python-Dev] Accepting PEP 489 (Multi-phase extension module initialization)

On Fri, May 22, 2015 at 11:44 PM, Eric Snow ericsnowcurren...@gmail.com wrote: Hi all, After extended discussion over the last several months on import-sig, the resulting proposal for multi-phase (PEP 451) extension module initialization has finalized. The resulting PEP provides a clean,

Re: [Python-Dev] A macro for easier rich comparisons

On Tue, Apr 28, 2015 at 11:13 AM, Victor Stinner victor.stin...@gmail.com wrote: Hi, 2015-04-27 16:02 GMT+02:00 Petr Viktorin encu...@gmail.com: A macro like this would reduce boilerplate in stdlib and third-party C extensions. It would ease porting C extensions to Python 3, where rich

Re: [Python-Dev] A macro for easier rich comparisons

On Tue, Apr 28, 2015 at 4:59 PM, Barry Warsaw ba...@python.org wrote: On Apr 28, 2015, at 11:13 AM, Victor Stinner wrote: It would be nice to have a six module for C extensions. I'm quite sure that many projects are already full of #ifdef PYTHON3 ... #else ... #endif macros. Maybe

[Python-Dev] A macro for easier rich comparisons

It seems the discussion on python-ideas, and also the patch review, died down. So I'm posting to python-dev. A macro like this would reduce boilerplate in stdlib and third-party C extensions. It would ease porting C extensions to Python 3, where rich comparison is mandatory. #define

[Python-Dev] Changing PyModuleDef.m_reload to m_slots

Hello, PEP 489, Redesigning extension module loading [0], is currently discussed on import-sig, but one question calls for a wider audience. As a background, the PyModuleDef structure [1] is currently: struct PyModuleDef{ PyModuleDef_Base m_base; const char* m_name;

[Python-Dev] PEP 489: Redesigning extension module loading

: Redesigning extension module loading Version: $Revision$ Last-Modified: $Date$ Author: Petr Viktorin encu...@gmail.com, Stefan Behnel stefan...@behnel.de, Nick Coghlan ncogh...@gmail.com Discussions-To: import-...@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst

Re: [Python-Dev] PEP 489: Redesigning extension module loading

On Mon, Mar 16, 2015 at 4:42 PM, Jim J. Jewett jimjjew...@gmail.com wrote: On 16 March 2015 Petr Viktorin wrote: If PyModuleCreate is not defined, PyModuleExec is expected to operate on any Python object for which attributes can be added by PyObject_GetAttr* and retrieved by PyObject_SetAttr

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On Wed, Feb 18, 2015 at 10:16 PM, Paul Moore p.f.mo...@gmail.com wrote: On 18 February 2015 at 20:48, Jim J. Jewett jimjjew...@gmail.com wrote: Barry Warsaw wrote: I don't know exactly what the procedure would be to claim .pyz for *nix, e.g. updating /etc/mime.types, but I think the PEP should

Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows

On Mon, Feb 16, 2015 at 12:00 AM, Chris Angelico ros...@gmail.com wrote: On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan ncogh...@gmail.com wrote: OTOH, it may be time to reconsider our recommendation to distros as well, suggesting that for Python 3.5+, we will consider it appropriate to have

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore p.f.mo...@gmail.com wrote: So the usage would be something like python -m zipapp [options] dir_to_zip Options: -p interpreterThe interpreter to use on the shebang line (defaulting to /usr/bin/env python) On many systems this default

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On Sun, Feb 15, 2015 at 5:43 PM, Paul Moore p.f.mo...@gmail.com wrote: On 15 February 2015 at 16:15, Petr Viktorin encu...@gmail.com wrote: On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore p.f.mo...@gmail.com wrote: So the usage would be something like python -m zipapp [options] dir_to_zip

Re: [Python-Dev] Any grammar experts?

On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman et...@stoneleaf.us wrote: On 01/26/2015 11:24 AM, Barry Warsaw wrote: On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote: In the your example from_env = {'a': 12} from_config = {'a': 13} f(**from_env, **from_config) I would think 'a' should

Re: [Python-Dev] Disassembly of generated comprehensions

On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar mistersh...@gmail.com wrote: How do I disassemble a generated comprehension? For example, I am trying to debug the following: dis.dis('{**{} for x in [{1:2}]}') 1 0 LOAD_CONST 0 (code object dictcomp at 0x10160b7c0,

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

On Sun, Dec 14, 2014 at 1:14 AM, Nick Coghlan ncogh...@gmail.com wrote: [...] Barry, Petr, any of the other folks working on distro level C extension ports, perhaps one of you would be willing to consider an update to the C extension porting guide to be more in line with Brett's latest version

Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition

Also keep in mind that not all Python libraries are on PyPI. For non-Python projects with Python bindings (think video players, OpenCV, systemd, Samba), distribution via PyPI doesn't make much sense. And since the Python bindings are usually second-class citizens, the porting doesn't have a high

Re: [Python-Dev] advice needed: best approach to enabling metamodules?

On Sat, Nov 29, 2014 at 8:37 PM, Nathaniel Smith n...@pobox.com wrote: [...] The python-ideas thread did also consider several methods of implementing strategy (c), but they're messy enough that I left them out here. The problem is that somehow we have to execute code to create the new subtype

Re: [Python-Dev] advice needed: best approach to enabling metamodules?

On Sun, Nov 30, 2014 at 12:05 AM, Steven D'Aprano st...@pearwood.info wrote: On Sun, Nov 30, 2014 at 11:07:57AM +1300, Greg Ewing wrote: Nathaniel Smith wrote: So pkgname/__new__.py might look like: import sys from pkgname._metamodule import MyModuleSubtype

Re: [Python-Dev] Please reconsider PEP 479.

On Wed, Nov 26, 2014 at 12:24 PM, Nick Coghlan ncogh...@gmail.com wrote: On 26 November 2014 at 18:30, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Guido van Rossum wrote: Hm, that sounds like you're either being contrarian or Chris and I have explained it even worse than I thought. I'm

<    1   2   3   4