[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-02-03 16:44, Antoine Pitrou wrote: On Mon, 3 Feb 2020 13:18:46 +0100 Petr Viktorin wrote: I agree with the sentiment that gradual deprecations are more easily managed, this statement about Python 3.0 is not true. The unicode transition was never thought to be small, and that's *why

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-02-03 12:55, Thomas Wouters wrote: On Mon, Feb 3, 2020 at 10:53 AM Petr Viktorin <mailto:encu...@gmail.com>> wrote: On 2020-01-31 19:47, Mike Miller wrote: > > On 2020-01-23 07:20, Victor Stinner wrote: >  > Python 3.9 introduces many small

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-01-31 19:47, Mike Miller wrote: On 2020-01-23 07:20, Victor Stinner wrote: > Python 3.9 introduces many small incompatible changes which broke tons There's a well-known and established way of signaling breaking changes in software platforms—it is to increment the major version

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 2020-01-30 07:12, Dima Tisnek wrote: On Fri, 24 Jan 2020 at 00:27, Victor Stinner wrote: Miro and me consider that Python 3.9 is pushing too much pressure on projects maintainers to either abandon Python 2.7 right now... Let's not conflate py2 EOL with what-should-go-into-py39.

[Python-Dev] Re: Last call for comments on PEP 573 (Module State Access from C Extension Methods)

On 2019-11-25 13:15, Stefan Behnel wrote: Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original proposal and went through several iterations

[Python-Dev] Re: extern "C" { ... } in Include/cpython/*.h

On 2020-01-27 21:42, Skip Montanaro wrote: (Apologies. Not sure where to ask this, and I'm not much of a C++ programmer. Maybe I should have just added a comment to the still-open issue.) I just noticed that Nick migrated the guts of Include/frameobject.h to include/cpython/frameobject.h. It's

[Python-Dev] Re: Last call for comments on PEP 573 (Module State Access from C Extension Methods)

On 2020-01-03 14:36, Petr Viktorin wrote: On 2019-11-25 13:15, Stefan Behnel wrote: Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original

[Python-Dev] Re: Why doesn't venv also install python3*-config?

On 2020-01-08 17:53, Victor Stinner wrote: Hi, I dislike python-config for multiple reasons You may get the wrong information if you pick the wrong python-config script :-( IMHO we should add a new module (problem: how should it be called? pyconfig?) which could be used using "python3 -m

[Python-Dev] Re: Last call for comments on PEP 573 (Module State Access from C Extension Methods)

On 2019-11-25 13:15, Stefan Behnel wrote: Hi all, I think that PEP 573 is ready to be accepted, to greatly improve the state of extension modules in CPython 3.9. https://www.python.org/dev/peps/pep-0573/ It has come a long way since the original proposal and went through several iterations

[Python-Dev] Re: Python Documentation and AIX specifics - how to proceed?

On 2019-12-26 14:35, Michael wrote: First - best wishes all for a happy and healthy 2020! As my nickname implies - my primary means to contribute to Python is with regard to AIX. One of the things I recently came across is Misc/README.AIX which was last updated sometime between 2010 and 2014. I

[Python-Dev] Re: Adding a scarier warning to object.__del__?

Could there be a clearer separation between the language semantics and current CPython behavior? On 2020-01-02 03:53, Yonatan Zunger wrote: Oh, I'm absolutely thinking about clarity. Something like: This method is called when the instance is about to be destroyed. Because it may be

[Python-Dev] Re: Should set objects maintain insertion order too?

On 2019-12-16 06:00, Larry Hastings wrote: [...] These are all performance concerns.  As I mentioned previously in this thread, in my opinion we should figure out what semantics we want for the object, then implement those, and only after that should we worry about performance.  I think we

[Python-Dev] Re: Python 3.8 error?

I'm quite interested in the rest of the story here. PySide is probably the biggest open-source user of the limited API, so IMO it is relevant to this list. On 2019-12-11 23:48, Christian Tismer wrote: Hi all, Sorry for the noise, I was wrong, and I retract. I was somehow mislead and hunted a

[Python-Dev] Re: Why limit coroutines?

On 2019-12-11 22:45, Antoine Pitrou wrote: On Mon, 9 Dec 2019 21:42:36 -0500 Kyle Stanley wrote: (b) Why limit coroutines? It's just another Python object and has no operating resources associated with it. Perhaps your definition of coroutine is different, and you are thinking of OS threads?

[Python-Dev] Re: Pass the Python thread state to internal C functions

On 2019-11-12 23:03, Victor Stinner wrote: Hi, Are you ok to modify internal C functions to pass explicitly tstate? In short, yes, but: - don't make things slower :) - don't break the public API or the stable ABI I'm a fan of explicitly passing state everywhere, rather than keeping it in

[Python-Dev] Belatedly accepting PEP 579 (design discussion leading to vectorcall)

I approve [PEP 579], with the understanding that acceptance of an Informational PEP doesn't really mean that much. PEP 579 charts the design issues addressed in PEP 575, PEP 580, PEP 590 (and hopefully more upcoming proposals). As noted in PEP 1: Informational PEPs do not necessarily

[Python-Dev] Re: Steering Council Update (July through October)

[PEP 484](https://www.python.org/dev/peps/pep-0484/) policy for inclusion of stubs in typeshed was discussed and the [PR](https://github.com/python/peps/pull/1218/) around it. It was decided that a sentence would be changed to make type stubs an opt-out situation and not opt-in.  - [PEP

[Python-Dev] Re: Getting function arguments of PyCFunctionObject

On 2019-10-19 00:31, Sümer Cip wrote: Hi everyone, I have been working on some feature of a deterministic profiler(github.com/sumerc/yappi ). The feature is about getting arguments for a given set of function names. For example: you can define something like

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 2019-09-30 00:33, Nick Coghlan wrote: [...] We'll never change the size of the config structs (or any other public struct) in a maintenance branch But we *will* change it in alphas/betas, and then we will ask people to try their software out with these. Of course, there are no actual

[Python-Dev] Re: What to do about invalid escape sequences

On 8/15/19 10:40 AM, Greg Ewing wrote: If we want a truly raw string format that allows all characters, including any kind of quote, we could take a tip from Fortran:     s = 31HThis is a "totally raw" string! Or from Rust: let s = r"Here's a raw string"; let s = r#"Here's a raw string with

[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

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

[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

[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

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. For static

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

[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) discussion

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 Sta

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

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 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] 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

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

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. A

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

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

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 backwards

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 rationale

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 between PEP 580

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

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_OFFSET

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

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 PEP 580

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 -

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

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

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,

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 the PEP

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

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 years

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

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

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 main Python

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] 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

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] 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

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

for 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] 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

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] 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.

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

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] 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] 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 reference

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] 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

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

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

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

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] 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

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?

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] 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/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

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

]: https://github.com/python/peps/pull/630 On 04/26/18 19:21, Ben Finney wrote: Petr Viktorin <encu...@gmail.com> 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 draw th

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 <ben+pyt...@benfinney.id.au> writes: Petr Viktorin <encu...@gmail.com> writes: […] we feel that the only way to *enforce* that guidelines is to provide environments where the `python` command does not work (unless explicitly insta

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

[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

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 t

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/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

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 <encu...@gmail.com> 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

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

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

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

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

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

Re: [Python-Dev] Impact of Namedtuple on startup time

On 07/17/2017 10:31 PM, Giampaolo Rodola' wrote: I completely agree. I love namedtuples but I've never been too happy about the additional overhead vs. plain tuples (both for creation and attribute access times), to the point that I explicitly avoid to use them in certain circumstances (e.g. a

Re: [Python-Dev] Snap Python for simple distribution across multiple Linux distros

On 05/23/2017 01:34 AM, Brett Cannon wrote: On Tue, 16 May 2017 at 08:08 Martin Wimpress > wrote: Hi all, I work at Canonical as part of the engineering team developing Ubuntu and Snapcraft [1] and I'm a long

Re: [Python-Dev] What version is an extension module binary compatible with

On 03/30/2017 06:31 AM, Nick Coghlan wrote: On 29 March 2017 at 02:18, Paul Moore wrote: On 28 March 2017 at 12:24, Miro Hrončok wrote: I'd like some clarification on what ABI compatibility we can expect. * Should the ABI be stable across patch

Re: [Python-Dev] Py 3.6 on Ubuntu Zesty

On 02/07/2017 11:38 PM, Barry Warsaw wrote: On Feb 07, 2017, at 02:15 PM, Mike Miller wrote: Does anyone know why Python 3.6 is not the default Python 3 under the upcoming Ubuntu Zesty, or what may be holding it back? I guess that would be me. :) Thank for the in-depth explanation! The

Re: [Python-Dev] Drastically improving list.sort() for lists of strings/ints

On 09/11/2016 10:48 PM, Terry Reedy wrote: [...] Second, with respect to timsort in particular: timsort is designed to exploit structure and run faster than O(n*logn) in special cases. If a list is already sorted, timsort will do one O(n) scan and stop. Any radix sort will take several times

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

On 07/06/2016 05:11 AM, Steven D'Aprano wrote: > On Tue, Jul 05, 2016 at 08:01:43PM +0200, Petr Viktorin wrote: > >> In the tkinter case, compiling for source is easy on a developer's >> computer, but doing that on a headless server brings in devel files for >> the enti

<    1   2   3   4   >