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

On Wed, Nov 26, 2014 at 12:24 PM, Nick Coghlan wrote: > On 26 November 2014 at 18:30, Greg Ewing 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 not trying to be contrary, I jus

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

On Sat, Nov 29, 2014 at 8:37 PM, Nathaniel Smith 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 *before* w

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

On Sun, Nov 30, 2014 at 12:05 AM, Steven D'Aprano 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 >> >sys.modules[__name__]

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 pr

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

On Sun, Dec 14, 2014 at 1:14 AM, Nick Coghlan 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 of > the Python

Re: [Python-Dev] Disassembly of generated comprehensions

On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar 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 ( at > 0x10160b7c0, file "", line 1>) >

Re: [Python-Dev] Any grammar experts?

On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman 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

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

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

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

On Sun, Feb 15, 2015 at 5:43 PM, Paul Moore wrote: > On 15 February 2015 at 16:15, Petr Viktorin wrote: >> On Sun, Feb 15, 2015 at 2:21 PM, Paul Moore wrote: >>> So the usage would be something like >>> >>> python -m zipapp [options] dir_to_zip

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

On Mon, Feb 16, 2015 at 12:00 AM, Chris Angelico wrote: > On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan 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 the >> "python" symlink refer to

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

On Wed, Feb 18, 2015 at 10:16 PM, Paul Moore wrote: > On 18 February 2015 at 20:48, Jim J. Jewett 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 at least mention this.

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

== PEP: 489 Title: Redesigning extension module loading Version: $Revision$ Last-Modified: $Date$ Author: Petr Viktorin , Stefan Behnel , Nick Coghlan Discussions-To: import-...@python.org Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Aug-2013 Py

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

On Mon, Mar 16, 2015 at 4:42 PM, Jim J. Jewett 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

[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; cons

[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 Py_RETURN_RIC

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

On Tue, Apr 28, 2015 at 11:13 AM, Victor Stinner wrote: > Hi, > > 2015-04-27 16:02 GMT+02:00 Petr Viktorin : >> 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

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

On Tue, Apr 28, 2015 at 4:59 PM, Barry Warsaw 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 encapsulating some

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On 11/07/2017 09:00 AM, Wolfgang wrote: [...] Also it is fine to teach people that dict (Mapping) is not ordered but CPython has an implementation detail and it is ordered. But if you want the guarantee use OrderedDict. I don't think that is fine. When I explained this in 3.5, dicts rearranging

Re: [Python-Dev] Removing files from the repository

On 11/29/2017 07:26 PM, Serhiy Storchaka wrote: [...] Perhaps it is worth to track all removals in a special file, so if later you will find that the removed file can be useful you could restore it instead of recreating its functionality from zero in the case if you even don't know that simil

Re: [Python-Dev] PEP 554 v4 (new interpreters module)

On 12/06/2017 03:51 AM, Eric Snow wrote: Hi all, I've finally updated PEP 554. Feedback would be most welcome. The PEP is in a pretty good place now and I hope to we're close to a decision to accept it. :) [...] C-extension opt-in/opt-out -- By using the ``PyModuleD

Re: [Python-Dev] PEP 489: module m_traverse called with NULL module state

On 12/14/2017 12:00 PM, Antoine Pitrou wrote: On Thu, 14 Dec 2017 17:00:10 +1000 Nick Coghlan wrote: On 14 Dec. 2017 9:19 am, "Antoine Pitrou" wrote: Hello, After debugging a crash on AppVeyor for a submitter's PR (see https://github.com/python/cpython/pull/4611 ), I came to the following d

Re: [Python-Dev] PEP 489: module m_traverse called with NULL module state

On Thu, Dec 14, 2017 at 12:00 PM, Antoine Pitrou wrote: > On Thu, 14 Dec 2017 17:00:10 +1000 > Nick Coghlan wrote: >> On 14 Dec. 2017 9:19 am, "Antoine Pitrou" wrote: >> >> >> Hello, >> >> After debugging a crash on AppVeyor for a submitter's PR >> (see https://github.com/python/cpython/pull/461

Re: [Python-Dev] PEP 489: module m_traverse called with NULL module state

On 12/19/2017 04:19 PM, Antoine Pitrou wrote: On Tue, 19 Dec 2017 16:10:06 +0100 Petr Viktorin wrote: Speaking of which, the doc is not very clear: is PEP 489 required for multi-interpreter support or is PyModule_GetState() sufficient? Yes, it is possible to have proper subinterpreter

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 04/23/18 14:04, Jeroen Demeyer wrote: Hello, I just saw this PEP. There is a bit of overlap between PEP 573 and PEP 575 since these both change the calling convention for built-in methods. In particular, PEP 575 also proposes to add a "defining class" member (for different reasons). In PEP

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 04/24/18 13:12, Jeroen Demeyer wrote: On 2018-04-24 16:34, Jeroen Demeyer wrote: On the other hand, if you are passing the function object, then you can get __self__ from it (unless it's an unbound method: in that case __self__ is NULL and self is really args[0]). So there wouldn't be a need

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 04/25/18 14:46, Jeroen Demeyer wrote: On 2018-04-25 20:33, Petr Viktorin wrote: Perhaps "m_objclass" could point to the module in this case That was exactly my idea also today. Instead of treating m_objclass as the defining class, we should generalize it to be the "

[Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

Hello, In Fedora, I found that PEP 394's strict recommendation that `python` points to `python2` is holding us back. From discussions on Zulip and elsewhere it's clear that this recommendation is not changing any time soon, but I would like to officially relax it in several cases. The problem

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 04/26/18 09:32, Thomas Wouters wrote: Thanks for working on this, Marcel (and Petr). This looks like an ambitious intern project :) Couple of questions and comments in-line. Indeed, but also a multi-year one. Sometimes it seems like Python is moving too fast under us! Specifically, PEP

Re: [Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

On 04/27/18 02:03, Ben Finney wrote: Ben Finney writes: Petr Viktorin writes: […] we feel that the only way to *enforce* that guidelines is to provide environments where the `python` command does not work (unless explicitly installed). Yes. The ‘python’ command is confusing, for the

[Python-Dev] PEP 394: Allow the `python` command to not be installed (and other minor edits)

ent. [Pull Request]: https://github.com/python/peps/pull/630 On 04/26/18 19:21, Ben Finney wrote: Petr Viktorin writes: In Fedora, I found that PEP 394's strict recommendation that `python` points to `python2` is holding us back. I have read the message, but I don't see how you

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/05/18 04:55, Jeroen Demeyer wrote: Hello all, I have updated PEP 575 in response to some posts on this mailing list and to some discussions in person with the core Cython developers. See https://www.python.org/dev/peps/pep-0575/ The main differences with respect to the previous version

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/05/18 04:55, Jeroen Demeyer wrote: Hello all, I have updated PEP 575 in response to some posts on this mailing list and to some discussions in person with the core Cython developers. See https://www.python.org/dev/peps/pep-0575/ The main differences with respect to the previous version

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/15/18 05:15, Jeroen Demeyer wrote: On 2018-05-14 19:56, Petr Viktorin wrote: It does quite a lot of things, and the changes are all intertwined, which will make it hard to get reviewed and accepted. The problem is that many things *are* already intertwined currently. You cannot deal

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/15/18 17:55, Jeroen Demeyer wrote: On 2018-05-15 18:36, Petr Viktorin wrote: Naturally, large-scale changes have less of a chance there. Does it really matter that much how large the change is? I think you are focusing too much on the change instead of the end result. As I said in my

Re: [Python-Dev] the new(-ish) dict ordering vs hash randomization

On 06/18/18 15:13, Ethan Furman wrote: I'm sure we've already had this conversation, but my google-fu is failing me. Can someone provide a link to a discussion explaining why the new ordering of dictionaries does not defeat the hash-randomization non-ordering we added a few versions ago? Hi

Re: [Python-Dev] Policy on refactoring/clean up

On 06/26/18 14:13, Jeroen Demeyer wrote: On 2018-06-26 13:54, Ivan Pozdeev via Python-Dev wrote: This is exactly what that the YAGNI principle is about, and Inada was right to point to it. Until you have an immediate practical need for something, you don't really know the shape and form for it t

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

On Fri, May 22, 2015 at 11:44 PM, Eric Snow 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, > straight-forward, and ba

[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 dire

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

On Mon, Jun 1, 2015 at 5:33 PM, Antoine Pitrou wrote: > On Mon, 1 Jun 2015 16:38:35 +0200 > Petr Viktorin 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 (the >> former

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

On Mon, Jun 1, 2015 at 6:00 PM, Antoine Pitrou 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) || Py_LIMITED_API+0 >= 0x030

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. Fixing this is a large

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 remo

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 https://bugs.python.org/issue26331 only changes the Python pars

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 "getattr(path, 'path', path)", since

Re: [Python-Dev] Failing tests (on a Linux distro)

On 07/02/18 00:59, Miro Hrončok wrote: On 1.7.2018 23:48, Matěj Cepl wrote: On 2018-06-28, 00:58 GMT, Ned Deily wrote: On behalf of the Python development community and the Python 3.7 release team, we are pleased to announce the availability of Python 3.7.0. I am working on updating openSUSE

Re: [Python-Dev] Comparing PEP 576 and PEP 580

On 07/05/18 13:59, Jeroen Demeyer wrote: On 2018-07-05 13:32, INADA Naoki wrote: Core devs interested in this area is limited resource. I know and unfortunately there is nothing that I can do about that. It would be a pity that PEP 580 (or a variant like PEP 576) is not accepted simply becau

Re: [Python-Dev] Can we split PEP 489 (extension module init) ?

On 08/10/18 11:21, Stefan Behnel wrote: Hi, coming back to PEP 489 [1], the multi-phase extension module initialization. We originally designed it as an "all or nothing" feature, but as it turns out, the "all" part is so difficult to achieve that most potential users end up with "nothing". So, m

Re: [Python-Dev] Can we split PEP 489 (extension module init) ?

On 08/10/18 12:21, Stefan Behnel wrote: Petr Viktorin schrieb am 10.08.2018 um 11:51: On 08/10/18 11:21, Stefan Behnel wrote: coming back to PEP 489 [1], the multi-phase extension module initialization. We originally designed it as an "all or nothing" feature, but as it turns out

Re: [Python-Dev] bpo-34595: How to format a type name?

if we can add something to get the "fully qualified name" (FQN) of a type, ex "datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name). I proposed a second pull request to add %t (short) in addition to %T (FQN). But then Petr Viktorin asked me

Re: [Python-Dev] bpo-34595: How to format a type name?

if we can add something to get the "fully qualified name" (FQN) of a type, ex "datetime.timedelta" (FQN) vs "timedelta" (what I call "short" name). I proposed a second pull request to add %t (short) in addition to %T (FQN). But then Petr Viktorin asked me

Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

On 06/20/18 01:53, Jeroen Demeyer wrote: Hello, Let me present PEP 579 and PEP 580. PEP 579 is an informational meta-PEP, listing some of the issues with functions/methods implemented in C. The idea is to create several PEPs each fix some part of the issues mentioned in PEP 579. PEP 580 is

Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods

On 09/13/18 02:22, Jeroen Demeyer wrote: On 2018-09-13 02:26, Petr Viktorin wrote: The reference to PEP 573 is premature. It seems to me that PEP 580 helps with the use case of PEP 573. In fact, it implements part of what PEP 573 proposes. So I don't see the problem with the referen

Re: [Python-Dev] bpo-34595: How to format a type name?

On 09/13/18 14:08, Victor Stinner wrote: Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit : * Add !t conversion to format string I'm strongly opposed to this. This !t conversion would not be widely applicable enough to be generally useful, and would need to be exposed in the f-string and

Re: [Python-Dev] Heap-allocated StructSequences

On 09/13/18 23:34, Neil Schemenauer wrote: On 2018-09-04, Eddie Elizondo wrote: Solution: * Fix the implementation of PyStructSequence_NewType: The best solution would be to fix the implementation of this function. This can easily be done by dynamically creating a PyType_Spec and calling

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

On 10/3/18 2:12 PM, Jeroen Demeyer wrote: Hello, I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, titled "The C call protocol". He has co-authored several PEPs (PEP 394, PEP 489, PEP 534, PEP 547, PEP 573), several of which involve extension modules. Petr has

Re: [Python-Dev] dear core-devs

On 10/4/18 9:34 AM, Victor Stinner wrote: Hi, If IBM wants a better Python support, it would help a lot if IBM pays for this development. With money, you can easily find core dev contractors. Antoine Pitrou has been paid in the past to enhance Python support in Solaris and it worked well. M

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

On 10/4/18 1:38 PM, Łukasz Langa wrote: On 3 Oct 2018, at 23:10, Terry Reedy <mailto:tjre...@udel.edu>> wrote: On 10/3/2018 8:12 AM, Jeroen Demeyer wrote: Hello, I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, titled "The C call protocol". He has co-au

Re: [Python-Dev] wininst-*.exe files in Lib/distutils/command

On 10/18/18 4:40 PM, Zachary Ware wrote: On Thu, Oct 18, 2018 at 9:09 AM VanL wrote: Hi all, I am looking into an issue associated with the wininst-*.exe files in the distutils/command subdirectory. It looks like these are the executable stubs used to create self-extracting zips for installa

Re: [Python-Dev] wininst-*.exe files in Lib/distutils/command

another day. Also I am not sure that bug report applies to 3.5/3.6/3.7. It does. On Thu, Oct 18, 2018 at 11:26 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 10/18/18 4:40 PM, Zachary Ware wrote: > On Thu, Oct 18, 2018 at 9:09 AM VanL mailto:van.lindb...@gmail

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 11/19/18 12:14 PM, Victor Stinner wrote: To design a new C API, I see 3 options: (1) add more functions to the existing Py_LIMITED_API (2) "fork" the current public C API: remove functions and hide as much implementation details as possible (3) write a new C API from scratch, based on the cur

Re: [Python-Dev] Missing functions [Was: Re: Experiment an opt-in new C API for Python? (leave current API unchanged)]

On 11/21/18 4:11 PM, Matěj Cepl wrote: On 2018-11-21, 14:54 GMT, Benjamin Peterson wrote: In Python 3, there is no underlying FILE* because the io module is implemented using fds directly rather than C stdio. OK, so the proper solution is to kill all functions which expect FILE Indeed. This

Re: [Python-Dev] Sub-interpreters: importing numpy causes hang

On 1/23/19 3:33 AM, Stephan Reiter wrote: Thanks for the answers so far. I appreciate them! Nathaniel, I'd like to allow Python plugins in my application. A plugin should be allowed to bring its own modules along (i.e. plugin-specific subdir is in sys.path when the plugin is active) and hence so

Re: [Python-Dev] [RELEASE] Python 3.8.0a1 is now available for testing

On 2/6/19 8:43 AM, Stephane Wirtel wrote: On 02/05, Barry Warsaw wrote: On Feb 5, 2019, at 02:24, Stephane Wirtel wrote: You’re welcome!  I just pushed an update to add 3.8.0a1 to the set of Python’s (including git head).  Do you think there’s a better way to publicize these images? I know

Re: [Python-Dev] [RELEASE] Python 3.8.0a1 is now available for testing

On 2/6/19 2:26 PM, Matthias Klose wrote: On 06.02.19 13:23, Petr Viktorin wrote: FWIW, we're preparing to rebuild all Fedora packages with the 3.8 alphas/betas, so everything's tested when 3.8.0 is released: https://fedoraproject.org/wiki/Changes/Python3.8 That should cover the m

Re: [Python-Dev] [RELEASE] Python 3.8.0a1 is now available for testing

On 2/7/19 5:16 PM, Stephane Wirtel wrote: On 02/06, Petr Viktorin wrote: On 2/6/19 8:43 AM, Stephane Wirtel wrote: On 02/05, Barry Warsaw wrote: On Feb 5, 2019, at 02:24, Stephane Wirtel wrote: You’re welcome!  I just pushed an update to add 3.8.0a1 to the set of Python’s (including git

[Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

PEP 394 says: > This recommendation will be periodically reviewed over the next few > years, and updated when the core development team judges it > appropriate. As a point of reference, regular maintenance releases > for the Python 2.7 series will continue until at least 2020. I think it's time

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 2/13/19 4:46 PM, Antoine Pitrou wrote: On Wed, 13 Feb 2019 16:24:48 +0100 Petr Viktorin wrote: PEP 394 says: > This recommendation will be periodically reviewed over the next few > years, and updated when the core development team judges it > appropriate. As a point of

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 2/13/19 4:24 PM, Petr Viktorin wrote: I think it's time for another review. [...] Please see this PR for details and a suggested change: https://github.com/python/peps/pull/893 Summary of the thread so far. Antoine Pitrou noted that the PEP should acknowledge that there are now yea

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 2/13/19 5:45 PM, Victor Stinner wrote: Some more context about Petr's change, Fedora, RHEL and Red Hat. [...] Fedora could switch "python" to Python 3 now*, if the PEP changes to allow it. * "now" has a release date of around October 2019. The next release after that should then be aroun

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 2/14/19 9:56 AM, Petr Viktorin wrote: On 2/13/19 4:24 PM, Petr Viktorin wrote: I think it's time for another review. [...] Please see this PR for details and a suggested change: https://github.com/python/peps/pull/893 Summary of the thread so far. Antoine Pitrou noted that th

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On 2/26/19 6:54 PM, Barry Warsaw wrote: There haven't been many new ideas since this summary – mostly it was explaining and re-hashing what's been mentioned before. Thanks for the summary Petr. Here’s another way to think about the problem. I know Nick and I have talked about this before, b

Re: [Python-Dev] Compile-time resolution of packages [Was: Another update for PEP 394...]

On 2/28/19 6:56 PM, Gregory P. Smith wrote: On Wed, Feb 27, 2019 at 5:12 PM Toshio Kuratomi > wrote: On Tue, Feb 26, 2019 at 2:07 PM Neil Schemenauer mailto:nas-pyt...@arctrix.com>> wrote: On 2019-02-26, Gregory P. Smith wrote: > On Tue, Fe

Re: [Python-Dev] BDFL-Delegate appointments for several PEPs

On Sun, Mar 24, 2019 at 4:22 PM Mark Shannon wrote: > > Hi Petr, > > Regarding PEPs 576 and 580. > Over the new year, I did a thorough analysis of possible approaches to > possible calling conventions for use in the CPython ecosystems and came > up with a new PEP. > The draft can be found here: >

Re: [Python-Dev] PEP 590 discussion

On 3/30/19 11:36 PM, Jeroen Demeyer wrote: On 2019-03-30 17:30, Mark Shannon wrote: 2. The claim that PEP 580 allows "certain optimizations because other code can make assumptions" is flawed. In general, the caller cannot make assumptions about the callee or vice-versa. Python is a dynamic langu

Re: [Python-Dev] PEP 590 discussion

Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! Overall, I like PEP 590's direction. I'd now describe the fundamental difference between PEP 580 and PEP 590 as: - PEP 580 tries to optimize all existing calling conventions - P

Re: [Python-Dev] PEP 590 discussion

On 4/11/19 1:05 AM, Jeroen Demeyer wrote: On 2019-04-10 18:25, Petr Viktorin wrote: Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! And thank you for the review! One general note: I am not (yet) choosing between PE

Re: [Python-Dev] Update PEP 394: Distributions can choose what does python command mean

On 4/12/19 4:53 PM, Miro Hrončok wrote: Hello. Based on discussions in [1], Petr Viktorin and me have drafted a new update [2] to the PEP 394 (The "python" Command on Unix-Like Systems). The update gives distributors the opportunity to decide where does the "python" comm

Re: [Python-Dev] PEP 590 discussion

Hi Mark! See my more general reply; here I'll just tie loose ends with a few +1s. On 4/14/19 7:30 AM, Mark Shannon wrote: On 10/04/2019 5:25 pm, Petr Viktorin wrote: [...] PEP 590 is built on a simple idea, formalizing fastcall. But it is complicated by PY_VECTORCALL_ARGUMENTS_OFFSE

[Python-Dev] PEP 580/590 discussion

So, I spent another day pondering the PEPs. I love PEP 590's simplicity and PEP 580's extensibility. As I hinted before, I hope they can they be combined, and I believe we can achieve that by having PEP 590's (o+offset) point not just to function pointer, but to a {function pointer; flags} str

Re: [Python-Dev] PEP 590 discussion

On 4/10/19 7:05 PM, Jeroen Demeyer wrote: On 2019-04-10 18:25, Petr Viktorin wrote: Hello! I've had time for a more thorough reading of PEP 590 and the reference implementation. Thank you for the work! And thank you for the review! I'd now describe the fundamental difference betwe

Re: [Python-Dev] PEP 580/590 discussion

On 4/25/19 10:42 AM, Jeroen Demeyer wrote: On 2019-04-25 00:24, Petr Viktorin wrote: I believe we can achieve that by having PEP 590's (o+offset) point not just to function pointer, but to a {function pointer; flags} struct with flags defined for two optimizations: What's the rat

Re: [Python-Dev] PEP 590 discussion

On 4/25/19 5:12 AM, Jeroen Demeyer wrote: On 2019-04-25 00:24, Petr Viktorin wrote: PEP 590 defines a new simple/fast protocol for its users, and instead of making existing complexity faster and easier to use, it's left to be deprecated/phased out (or kept in existing classes for back

Re: [Python-Dev] PEP 580/590 discussion

Hello! Sorry for the delay; PyCon is keeping me busy. On the other hand, I did get to talk to a lot of smart people here! I'm leaning toward accepting PEP 590 (with some changes still). Let's start focusing on it. As for the changes, I have these 4 points: I feel that the API needs some contact w

Re: [Python-Dev] PEP 580/590 discussion

On 5/6/19 4:24 AM, Jeroen Demeyer wrote: Hello Petr, Thanks for your time. I suggest you (or somebody else) to officially reject PEP 580. I'll do that shortly. I hope that you are not taking this personally. PEP 580 is a good design. PEP 590 even says that it's built on your ideas. I start

Re: [Python-Dev] PEP 580/590 discussion

On 5/6/19 3:43 AM, Jeroen Demeyer wrote: On 2019-05-06 00:04, Petr Viktorin wrote: - Single bound method class for all kinds of function classes: This would be a cleaner design, yes, but I don't see a pressing need. As PEP 579 says, "this is a compounding issue", not a goal. As

Re: [Python-Dev] Hello

On 5/7/19 9:08 PM, Ben Kane wrote: Sorry Victor, I must have misinterpreted this snippet from the mailbot. Maybe it would be a good idea to re-word it? I'll be happy to open an issue for that in an appropriate mailing list if you think that would help. > Welcome to the Python-Dev@python.org <

Re: [Python-Dev] PEP 580/590 discussion

PEP 590 is on its way to be accepted, with some details still to be discussed. I've rejected PEP 580 so we can focus on one place. Here are things we discussed on GitHub but now seem to agree on: * The vectorcall function's kwname argument can be NULL. * Let's use `vectorcallfunc`, not `vectorcal

Re: [Python-Dev] PEP 580/590 discussion

On 5/9/19 5:33 PM, Jeroen Demeyer wrote: On 2019-05-09 20:30, Petr Viktorin wrote: The underlying C function should not need to know how to extract "self" from the function object, or how to handle the argument offsetting. Those should be implementation details. Maybe you misund

Re: [Python-Dev] bpo-36829: Add sys.unraisablehook()

On 5/16/19 3:23 AM, Victor Stinner wrote: [...] I modified my API to create an object to pack arguments. The new API becomes sys.unraisablehook(unraisable) where unraisable has 4 fields: exc_type, exc_value, exc_tb, obj. [...] I always thought the classic (exc_type, exc_value, exc_tb) triple is

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On 5/21/19 12:06 PM, Christian Heimes wrote: On 21/05/2019 11.49, Nathaniel Smith wrote: On Tue, May 21, 2019 at 2:40 AM Walter Dörwald wrote: On 20 May 2019, at 22:15, Christian Heimes wrote: Hi, here is the first version of my PEP 594 to deprecate and eventually remove modules from the s

Re: [Python-Dev] PEP 590 (Vectorcall) discussion

allow changes in Python 3.9) * https://github.com/python/peps/pull/1066 (Use size_t for "number of arguments + flag") The resulting text, for reference: PEP: 590 Title: Vectorcall: a fast calling protocol for CPython Author: Mark Shannon , Jeroen Demeyer BDFL-Delegate: Petr Viktorin

[Python-Dev] Accepting PEP 590 (Vectorcall)

As BDFL-Delegate, I am accepting PEP 590 -- Vectorcall: a fast calling protocol for CPython. https://www.python.org/dev/peps/pep-0590/ There was a major last-minute change to the text (though one that was discussed since PyCon US): The API is not finalized yet, and it's provided using private

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 5/29/19 2:25 PM, Jeroen Demeyer wrote: Hello, I have one implementation question about vectorcall which is not specified in PEP 590: what should happen if a type implements vectorcall (i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't set tp_call (i.e. tp_call == NULL)? I see the follow

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 5/29/19 3:36 PM, Jeroen Demeyer wrote: On 2019-05-29 15:29, Petr Viktorin wrote: That sounds like a good idea for PyType_FromSpec. I don't think we're planning to support vectorcall in PyType_FromSpec for now. That's maybe for 3.9 when vectorcall is no longer provisional

[Python-Dev] Expected stability of PyCode_New() and types.CodeType() signatures

Hello, PEP 570 (Positional-Only Parameters) changed the signatures of PyCode_New() and types.CodeType(), adding a new argument for "posargcount". Our policy for such changes seems to be fragmented tribal knowledge. I'm writing to check if my understanding is reasonable, so I can apply it and do

[Python-Dev] Re: Expected stability of PyCode_New() and types.CodeType() signatures

On 6/12/19 7:40 AM, Stefan Behnel wrote: Victor Stinner schrieb am 12.06.19 um 00:09: So yeah, the PyCode_New() change is very annoying in practical, since every single project using Cython requires a new release in practice. I think Cython's deal with regard to this is: """ If you use Cyt

[Python-Dev] Re: EuroPython 2019 sprints

Hello, I'll be at the EuroPython CPython sprints too, happy to help out. On Thu, Jun 13, 2019 at 6:36 PM Steve Dower wrote: > Just letting everyone know that I signed up any core devs who are going > to be at EuroPython to run sprints :) (including myself, since I'll be > there) FWIW, I read th

[Python-Dev] Re: Comparing dict.values()

On 7/25/19 2:25 AM, David Mertz wrote: Exactly! that was my thought that the exception message could hint at likely approaches. The NumPy example seems to have a good pattern: arr1 == arr2 |ValueError:Thetruth value of an array withmore than one element |isambiguous. |Usea.any()ora.all().|

[Python-Dev] Re: typing: how to use names in result-tuples?

On 7/29/19 4:36 PM, Christian Tismer wrote: Hi friends, I am meanwhile the PySide maintainer at The Qt Company, and we are trying to make the mapping from Qt functions to Python functions as comparable as possible. One problem are primitive pointer variables: In Qt, it is natural to use "somety

[Python-Dev] Re: Speeding up CPython

Let me explain an impression I'm getting. It is *just one aspect* of my opinion, one that doesn't make sense to me. Please tell me where it is wrong. In the C API, there's a somewhat controversial refactoring going on, which involves passing around tstate arguments. I'm not saying [the first

  1   2   3   4   >