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

On 16May2019 1404, Victor Stinner wrote: Le jeu. 16 mai 2019 à 17:56, Steve Dower a écrit : I really like this API, and I agree with Victor that we don't really need more than the exception info. For future expansion, we can pass in a different exception, no? Sorry, I don't understand. I

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

On 16May2019 0902, Steve Dower wrote: Actually, if the default implementation prints the exception message, how is this different from sys.excepthook? Specifically, from the point of customizing the hooks. If I were going to replace unraisablehook to do something on specific exceptions, I'm

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

On 16May2019 0856, Steve Dower wrote: On 16May2019 0647, Victor Stinner wrote: Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a écrit : For unraisable hook, it's not hard to imagine other useful parameters that can be passed to the hook to provide more context about the exception. For example

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

On 16May2019 0647, Victor Stinner wrote: Le jeu. 16 mai 2019 à 12:57, Serhiy Storchaka a écrit : For unraisable hook, it's not hard to imagine other useful parameters that can be passed to the hook to provide more context about the exception. For example, right now we only pass one object. But

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

On 16May2019 0710, Thomas Wouters wrote: A couple of things are documented as performing pre-initialisation (PyConfig_SetBytesString, PyConfig_SetBytesArgv). I understand why, but I feel like that might be confusing and error-prone. Would it not be better to have them fail if

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

On 15May2019 1610, Victor Stinner wrote: Thanks to the constructive discussions, I enhanced my PEP 587. I don't plan any further change, the PEP is now ready to review (and maybe even for pronouncement, hi Thomas! :-)). My view is that while this is a fantastic PEP and the groundwork that

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 3rd version

Thanks for adding your input, Gregory! It's much appreciated. I'll shuffle your comments around a bit, as I'd rather address the themes than each individual point. On 15May2019 2134, Gregory Szorc wrote: PyPreConfig_INIT and PyConfig_INIT as macros that return a struct feel weird to me.

Re: [Python-Dev] deprecation of abstractstaticmethod and abstractclassmethod

On 15May2019 1248, Nathaniel Smith wrote: I don't care about the deprecation either way. But can we fix the individual decorators so both orders work? Even if it requires a special case in the code, it seems worthwhile to remove a subtle user-visible footgun. The classmethod and staticmethod

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

On 15May2019 0240, Paul Moore wrote: On Wed, 15 May 2019 at 09:51, Antoine Pitrou wrote: On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw wrote: As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of the Steering Council, I hereby Accept this PEP. For future

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 2nd version

On 10May2019 1832, Victor Stinner wrote: I studied code of applications embedding Python. Most of them has to decode bytes strings to get wchar_t* to set home, argv, program name, etc. I'm not sure that they use the "correct" encoding, especially since Python 3.7 got UTF-8 Mode (PEP 540) and C

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 2nd version

people had different opinions. Cheers, Steve On 13May2019 1452, Victor Stinner wrote: )Le lun. 13 mai 2019 à 18:28, Steve Dower a écrit : My take: * all the examples are trying to be isolated from the system Python install (except Vim?) "Isolation" means different things: * ignore

Re: [Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 2nd version

On 10May2019 1832, Victor Stinner wrote: Hi, First of all, I just found an old issue that we will solved by my PEP 587 :-) Add Py_SetFatalErrorAbortFunc: Allow embedding program to handle fatal errors https://bugs.python.org/issue30560 Yes, this should be a feature of any redesigned

Re: [Python-Dev] Location of CI for Windows Embeddable Distro

On 01May2019 1305, Gerald Wiltse wrote: That does help, thanks so much for the fast response!  I now see how it's executed on Azure pipelines also, so that should be enough for me to reverse engineer the rest. Followup questions if you have time: 1. It seems that directory doesn't exist in

Re: [Python-Dev] Location of CI for Windows Embeddable Distro

On 01May2019 1109, Gerald Wiltse wrote: I looked through all the windows builders here and could not find any which generate this package, can anyone tell me where the work happens? I also tried searching looking for scripts and CI files which create the package in all the relevant repos and

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 23Apr2019 0008, Inada Naoki wrote: On Tue, Apr 23, 2019 at 2:54 PM Steve Dower wrote: On 22Apr2019 2143, Inada Naoki wrote: On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote: Or possibly just "dict(existing_dict).update(new_items)". Do you mean .update accepts values tupl

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 23Apr2019 0034, Glenn Linderman wrote: On 4/22/2019 10:59 PM, Steve Dower wrote: On 22Apr2019 2119, Glenn Linderman wrote: While Inada's suggested DictBuilder interface was immediately obvious, I don't get how either copy or update would achieve the goal. Perhaps you could explain

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 22Apr2019 2119, Glenn Linderman wrote: While Inada's suggested DictBuilder interface was immediately obvious, I don't get how either copy or update would achieve the goal. Perhaps you could explain? Particularly, what would be the trigger that would make dict() choose to create a shared key

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 22Apr2019 2143, Inada Naoki wrote: On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote: Or possibly just "dict(existing_dict).update(new_items)". Do you mean .update accepts values tuple? I can't think it's Not sure what you were going to go on to say here, but why not? If

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 22Apr2019 1921, Steve Dower wrote: On 22Apr2019 1822, Glenn Linderman wrote: Inada is now proposing a way to allow the coder to suggest a group of dictionaries that might benefit from the same gains, by preclassifying non-__dict__ slot dictionaries to do similar sharing. CSV reader

Re: [Python-Dev] Proposal: dict.with_values(iterable)

On 22Apr2019 1822, Glenn Linderman wrote: Inada is now proposing a way to allow the coder to suggest a group of dictionaries that might benefit from the same gains, by preclassifying non-__dict__ slot dictionaries to do similar sharing. CSV reader is an exemplary candidate, because it creates

Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm

On 22Apr2019 1521, Andrew Svetlov wrote: I see the chicken and egg problem here. If we are talking about typing module usage -- typeshed is the type hints provider. If PyCharm doesn't want to use it -- it is not CPython problem. I think there is no need to change python code itself but used

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

e) handle/descriptor", so this feels like YAGNI. On 01/04/2019 18.31, Steve Dower wrote: In each case there should be associated audit events for tracking the intent (and interrupting at that point if it doesn't like the intended action), but for the simple case of "let me open this specif

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

On 15Apr2019 1344, Christian Heimes wrote: Hi Steve, (memory dump before I go to bed) Steve Grubb from Red Hat security pointed me to some interesting things [1]. For instance there is some work on a new O_MAYEXEC flag for open(). Steve came to similar conclusions like we, e.g. streaming code

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 12Apr2019 1819, Nathaniel Smith wrote: On Fri, Apr 12, 2019 at 5:05 PM Steve Dower wrote: On 12Apr.2019 1643, Nathaniel Smith wrote: On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote: The very first question I asked was whether this would let us converge the ABIs, and the answer

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 12Apr.2019 1643, Nathaniel Smith wrote: > On Thu, Apr 11, 2019 at 8:26 AM Steve Dower wrote: >> >> On 10Apr2019 1917, Nathaniel Smith wrote: > I don't know how many people use Py_TRACE_REFS, but if we can't find > anyone on python-dev who uses it then it must be prett

Re: [Python-Dev] Removing PID check from signal handler

On 12Apr.2019 0919, Jeroen Demeyer wrote: > The signal handler (that receives signals from the OS) in Python starts > with a check > >     if (getpid() == main_pid) > > Looking at the comments, the intent was to do a check for the main > *thread* but this is checking the *process* id. So this

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 10Apr2019 1917, Nathaniel Smith wrote: It sounds like --with-pydebug has accumulated a big grab bag of unrelated features, mostly stuff that was useful at some point for some CPython dev trying to debug CPython itself? It's clearly not designed with end users as the primary audience, given

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 11Apr2019 0228, Victor Stinner wrote: Le jeu. 11 avr. 2019 à 07:49, Serhiy Storchaka a écrit : 10.04.19 14:01, Victor Stinner пише: Disabling Py_TRACE_REFS by default in debug mode reduces the Python memory footprint. Py_TRACE_REFS costs 2 pointers per PyObject: 16 bytes on 64-bit

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 10Apr2019 1227, Nathaniel Smith wrote: On Wed, Apr 10, 2019, 04:04 Victor Stinner > wrote: I don't think that I ever used sys.getobjects(), whereas many projects use gc.get_objects() which is also available in release builds (not only in debug builds).

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 10Apr2019 1109, Steve Dower wrote: On 10Apr2019 0401, Victor Stinner wrote: I think it's worthwhile if we can really get to debug and non-debug builds being ABI compatible. Getting partway there in this case doesn't seem to offer any benefits. Disabling Py_TRACE_REFS by default in debug

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 10Apr2019 0401, Victor Stinner wrote: Le mar. 9 avr. 2019 à 22:16, Steve Dower a écrit : What are the other changes that would be required? I don't know. And is there another way to get the same functionality without ABI modifications? Py_TRACE_REFS is a double linked list of *all

Re: [Python-Dev] New Python Initialization API

On 05Apr2019 0936, Victor Stinner wrote: For the PyMainConfig structure idea, I cannot comment at this point. I need more time to think about it. About the "path configuration" fields, maybe a first step to enhance the API would be to add the the following function: PyInitError

Re: [Python-Dev] New Python Initialization API

On 05Apr2019 0922, Victor Stinner wrote: While there are supporters of an "isolated Python" (sometimes called "system python"), the fact that it doesn't exist in any Linux distribution nor on any other operating system (Windows, macOS, FreeBSD), whereas it's already doable in Python 3.6 with

Re: [Python-Dev] New Python Initialization API

On 05Apr2019 0912, Victor Stinner wrote: About PyPreConfig and encodings. [...] * ``PyInitError Py_PreInitialize(const PyPreConfig *config)`` * ``PyInitError Py_PreInitializeFromArgs( const PyPreConfig *config, int argc, char **argv)`` * ``PyInitError Py_PreInitializeFromWideArgs( const

Re: [Python-Dev] New Python Initialization API

Thanks for the replies. Anything I don't comment on means that I agree with you :) On 05Apr2019 0900, Victor Stinner wrote: Honestly, I'm not sure that we really have to distinguish "user error" and "internal error". It's an old debate about calling abort()/DebugBreak() or not. It seems like

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

On 09Apr2019 0925, Victor Stinner wrote: This change makes the debug build ABI closer to the release build ABI, but I am not sure how to compare these two ABI. Technically, C extensions still need to be recompiled. What do you think? What are the other changes that would be required? And is

Re: [Python-Dev] PEP-582 and multiple Python installations

On 02Apr2019 0817, Calvin Spealman wrote: (I originally posted this to python-ideas, where I was told none of this PEP's authors subscribe so probably no one will see it there, so I'm posting it here to raise the issue where it can get seen and hopefully discussed) Correct, thanks for

Re: [Python-Dev] how to rerun the job “Azure Pipelines PR”?

On 02Apr2019 0522, Karthikeyan wrote: Closing and re-opening the PR will trigger the CI run again that might help in this case but it will run all the jobs. Yes, I believe this is still the best way to re-run Pipelines jobs. For people with logins (not yet everyone in the GitHub org, but I

Re: [Python-Dev] Strange umask(?)/st_mode issue

On 01Apr2019 1535, Cameron Simpson wrote: On 01Apr2019 09:12, Steve Dower wrote: On 30Mar2019 1130, Gregory P. Smith wrote: I wouldn't expect it to be the case in a CI environment but I believe a umask can be overridden if the filesystem is mounted and configured with acls set?  (oh, hah

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

On 31Mar2019 0538, Christian Heimes wrote: I don't like the fact that the PEP requires users to learn and use an additional layer to handle native code. Although we cannot provide a fully secure hook for native code, we could at least try to provide a best effort hook and document the

Re: [Python-Dev] Strange umask(?)/st_mode issue

On 30Mar2019 1130, Gregory P. Smith wrote: I wouldn't expect it to be the case in a CI environment but I believe a umask can be overridden if the filesystem is mounted and configured with acls set?  (oh, hah, Ivan just said the same thing) Yep, it appears this is the case. The Pipelines team

Re: [Python-Dev] New Python Initialization API

Here is my first review of https://www.python.org/dev/peps/pep-0587/ and in general I think it's very good. There are some things I'd like to consider changing before we embed them permanently in a public API, and as I'm still keen to have the ability to write Python code for configuration (to

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

On 30Mar.2019 0747, Nick Coghlan wrote: > I like this PEP in principle, but the specific "open_for_import" name > bothers me a lot, as it implies that "importing" is the only situation > where a file will be opened for code execution. > > If this part of the API were lower down the stack (e.g. >

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

On 29Mar.2019 2020, Inada Naoki wrote: > I don't like adding more Python callback from low level. > > Python runtime is very complicated already, especially __del__, > shutdown process, and multi threading. Python callback from low level > is source of very difficult bugs always. Asynchronous

Re: [Python-Dev] Strange umask(?)/st_mode issue

On 29Mar.2019 1944, Steve Dower wrote: > On 29Mar.2019 1939, Cameron Simpson wrote: >> Can you get a branch into your pipeline? Then you could just hack the >> tarfile test with something quick and dirty like: >> >>    pid = os.getpid() >>    system("strac

Re: [Python-Dev] Strange umask(?)/st_mode issue

On 29Mar.2019 1939, Cameron Simpson wrote: > Can you get a branch into your pipeline? Then you could just hack the > tarfile test with something quick and dirty like: > >    pid = os.getpid() >    system("strace -p %d 2>/path/to/strace.out &" % pid) >    time.sleep(2)   # get strace heaps of time

Re: [Python-Dev] New Python Initialization API

On 29Mar.2019 1830, Victor Stinner wrote: > The purpose of the PEP 587 is to have a working document so everyone > can look at the proposed API (stay focused to the API rather than > bothering with the implementation). IMHO it's now time to get more > people looking at the Python Initialization. >

Re: [Python-Dev] Strange umask(?)/st_mode issue

On 29Mar.2019 1731, Nathaniel Smith wrote: > That does sound strange. Oh good, it's not just me :) > How easily can you reproduce it? That majorly > effects how I would try to debug something like this... No idea. Looking at the builds on Pipelines again, it seems that all the builds since

[Python-Dev] Strange umask(?)/st_mode issue

Hi I'm trying to track down the cause of the failed Linux tests on this build (it's also been happening on random PR builds for the last day or two, but this is the first I've seen it happen on already merged code): https://dev.azure.com/Python/cpython/_build/results?buildId=40189 One of

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

On 29Mar2019 1218, Christian Heimes wrote: On 28/03/2019 23.35, Steve Dower wrote: The ``importlib.util.open_for_import()`` function is a drop-in replacement for ``open(str(pathlike), 'rb')``. Its default behaviour is to open a file for raw, binary access. To change the behaviour a new handler

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

the definition of that "everything". On 29.03.2019 1:35, Steve Dower wrote: Hi all Time is short, but I'm hoping to get PEP 578 (formerly PEP 551) into Python 3.8. Here's the current text for review and comment before I submit to the Steering Council. The formatted text i

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

Thanks Christian for responding - I endorse and support all your comments. (I'd hoped that by explicitly saying "this is not a sandbox" it would avoid people thinking it was a sandbox, but apparently I would have been better just to avoid the keyword completely...) On 29Mar2019 0324,

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

On 29Mar2019 0334, Christian Heimes wrote: On 28/03/2019 23.35, Steve Dower wrote: Audit Hook -- In order to observe actions taken by the runtime (on behalf of the caller), an API is required to raise messages from within certain operations. These operations are typically deep within

Re: [Python-Dev] PEP 578: Python Runtime Audit Hooks

The implementation can be viewed as a PR at https://github.com/python/cpython/pull/12613 On 28Mar2019 1535, Steve Dower wrote: Hi all Time is short, but I'm hoping to get PEP 578 (formerly PEP 551) into Python 3.8. Here's the current text for review and comment before I submit

[Python-Dev] PEP 578: Python Runtime Audit Hooks

-578-3.7/) is already getting some real use (though this will not be added to 3.7, unless people *really* want it, so the backport is just for reference). Cheers, Steve = PEP: 578 Title: Python Runtime Audit Hooks Version: $Revision$ Last-Modified: $Date$ Author: Steve Dower Status: Draft

Re: [Python-Dev] New Python Initialization API

On 28Mar2019 0703, Victor Stinner wrote: In fact, there is already a PyConfig._init_config flag (currently named _PyCoreConfig._init_main) which only initializes Python up to the "core initialization" if set to 0. This parameter is private since it's unclear to me what should be the exact scope

Re: [Python-Dev] New Python Initialization API

On 27Mar2019 1048, Victor Stinner wrote: Since November 2017, I'm refactoring the Python Initialization code to cleanup the code and prepare a new ("better") API to configure Python Initialization. I just fixed the last issues that Nick Coghlan asked me to fix (add a pre-initialization step:

Re: [Python-Dev] Removing PendingDeprecationWarning

On 27Mar2019 0324, Inada Naoki wrote: On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki wrote: C, Rust, Java, Ruby, PHP, don't have PendingDeprecation. Programmers only need Deprecation. Why programmers need PendingDeprecation only in Python? Any comments about this? I want to document

Re: [Python-Dev] Replacement for array.array('u')?

On 25Mar2019 0812, Martin (gzlist) wrote: On Fri, 22 Mar 2019 at 16:12, Steve Dower wrote: On 22Mar2019 0433, Antoine Pitrou wrote: The question is: why would you use a array.array() with a Windows C API? I started replying to this with a whole lot of examples, and eventually convinced

Re: [Python-Dev] Removing PendingDeprecationWarning

On 22Mar2019 1101, Brett Cannon wrote: On Fri, Mar 22, 2019 at 10:37 AM Inada Naoki > wrote: There might be some small troubles.  But it was small enough for Python minor versions, I think.  I don't think it's worth the cost to users. We can just choose

Re: [Python-Dev] Replacement for array.array('u')?

On 22Mar2019 0433, Antoine Pitrou wrote: The question is: why would you use a array.array() with a Windows C API? I started replying to this with a whole lot of examples, and eventually convinced myself that you wouldn't (or shouldn't). That said, I see value in having a type for

Re: [Python-Dev] configparser: should optionxform be idempotent?

I just have one thing to add to the discussion, which is this: https://youtu.be/hAnCiTpxXPg?t=6339 Yes, people actually read and interpret our documentation :) So discussions like this are probably a good thing in terms of getting the best descriptions in there, but if we use a specific

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

On 05Mar2019 1245, Chris Angelico wrote: How much effort does it take to sponsor a PEP? I'm not a core dev, but I can help someone with the work of writing and publishing. So if, in that hypothetical situation, some (very busy) core dev were willing to say "yeah, go ahead, put my name on it",

Re: [Python-Dev] PEPs from non-core devs now need a sponsor

On 05Mar2019 0620, James Edwards wrote: I have to say, this is sort of surprising for what seems like the first official action of the steering committee.  Are there really /that many /PEPs that a team that is now, what, 5x the size of the BFDL model is worried that they'll be able to keep up? 

Re: [Python-Dev] [RELEASE] Python 2.7.16

he status of python.org 3.x downloads. Since Steve Dower put 3.7 on the Windows store, PSF must now be a known publisher.  Perhaps he can help make 2.7 'known'. SmartScreen should recognize it now that it's been downloaded a few times without reporting, but the real problem is that it hasn't be

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

On 2/26/2019 1:20 PM, Gregory P. Smith wrote: For an OS distro provided interpreter, being able to restrict its use to only OS distro provided software would be ideal (so ideal that people who haven't learned the hard distro maintenance lessons may hate me for it). Such a restriction could be

Re: [Python-Dev] "Good first issues" on the bug tracker

On 21Feb2019 1258, Cheryl Sabella wrote: I agree completely. We normally add the "Easy" or "Easy (C)" keywords to mark these (the latter for issues that involve C code), and these are collected under the "Easy issues" link at the left hand side of the tracker. Any reason

Re: [Python-Dev] "Good first issues" on the bug tracker

On 21Feb2019 0557, Cheryl Sabella wrote: If you find anything you think is suitable, please add a comment with 'good first issue' and nosy me or Mariatta on it.  If you're unsure, then nosy us anyway.  It would be awesome to have too many issues to choose from than not enough.  If an issue

Re: [Python-Dev] Add minimal information with a new issue?

On 21Feb2019 1117, Barry Warsaw wrote: On Feb 21, 2019, at 10:34, Raymond Hettinger wrote: I think that anything that raises the cost of filing a bug report will work to our detriment. Ideally, we want the barriers to reporting to be as low as possible. `python -m reportbug` could make

Re: [Python-Dev] Making PyInterpreterState an opaque type

Just letting everyone know that I'm intending to restart this discussion over in capi-sig, as I feel like I've got an informational-PEP worth of "vision", "ideas" and "direction" and nomenclature for our C API (*not* talking about a rewrite, but the principles we should be following now... and

Re: [Python-Dev] Question - Bug Triage for 3.4 & 3.5

On 20Feb.2019 0711, Stephane Wirtel wrote: > After discussion with Victor, my proposal will generate noise with the > ML, maybe for nothing. > > On 02/20, Stephane Wirtel wrote: >> Hi, >> >> As you know, Python 3.4 and 3.5 are in security mode and the EOL for >> these versions are respectively

Re: [Python-Dev] new binary wheels PEP idea

And for what it's worth, most of the really active contributors from distutils-sig seem to prefer the "Packaging" category at https://discuss.python.org/ If you'd prefer to use Discourse, I'd suggest posting there first and also email distutils-sig with a link to the discussion. Otherwise, go

Re: [Python-Dev] Making PyInterpreterState an opaque type

On 19Feb2019 1141, Barry Warsaw wrote: Steve Dower wrote on 2/16/19 14:34:> This is mostly about being able to assign blame when things break, so I'm totally okay with extension modules that want to play with internals declaring Py_BUILD_CORE to get access to them (though I suspect that wo

Re: [Python-Dev] Making PyInterpreterState an opaque type

On 19Feb2019 1212, Stefan Behnel wrote: So, yeah, I'm happy with the status quo, and a bit worried about all the moving around of declarations and that scent of a sword of Damocles hanging over their potential confinement. IMHO, things should just be public and potentially marked as "unstable"

Re: [Python-Dev] Making PyInterpreterState an opaque type

On 19Feb2019 0555, Nick Coghlan wrote: I really don't want us to ever get into a situation where we're actively encouraging third party projects to define Py_BUILD_CORE. If we decide we do want to go down a path like that, I'd instead prefer to see us define something more like "Py_FRAGILE_API"

Re: [Python-Dev] Making PyInterpreterState an opaque type

On 19Feb2019 0229, Jeroen Demeyer wrote: On 2019-02-19 04:04, Steve Dower wrote: On 18Feb.2019 1324, Jeroen Demeyer wrote: For a very concrete example, was it really necessary to put _PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially given that the very similar

Re: [Python-Dev] Making PyInterpreterState an opaque type

On 18Feb.2019 1324, Jeroen Demeyer wrote: > Still, do we really need so many levels of API: > (1) stable API (with #define Py_LIMITED_API) > (2) public documented API > (3) private undocumented API (the default exposed API) > (4) internal API (with #define Py_BUILD_CORE) > > I would argue to fold

Re: [Python-Dev] Making PyInterpreterState an opaque type

On 16Feb.2019 1332, Antoine Pitrou wrote: > On Sat, 16 Feb 2019 11:15:44 +0100 > Jeroen Demeyer wrote: >> On 2019-02-16 00:37, Eric Snow wrote: >>> One thing that would help simplify changes >>> in this area is if PyInterpreterState were defined in >>> Include/internal. >> >> How would that

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On 16Feb.2019 0831, Nick Coghlan wrote: > On Sat, 16 Feb 2019 at 08:06, Steve Dower wrote: >> I'm inclined to say that nobody but us uses this API :) Does that make >> it seem more okay to "clarify" that it's returning target platform? > > I've always treated the

Re: [Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

On 14Feb2019 1147, Gregory P. Smith wrote: To alleviate confusion long term I'd love it if we could deprecate the unqualified get_platform() API and point people towards always being explicit about get_target_platform() vs get_current_platform(). This is an option too, though it doesn't

Re: [Python-Dev] Adding test.support.safe_rmpath()

On 14Feb.2019 0948, Brett Cannon wrote: > On Thu, Feb 14, 2019 at 7:26 AM Giampaolo Rodola' > wrote: > Extra: an argument in favor of using tempfile.mkdtemp() instead of > TESTFN is parallel testing, but I think we're not using it. > > > With -j you can do

[Python-Dev] Is distutils.util.get_platform() the "current" or the "target" platform

As part of adding ARM32 support for Windows, we need to enable cross-compilation in distutils. This is easy enough, though it requires somehow getting the target platform as well as the current platform. Right now, the change at https://github.com/python/cpython/pull/11774 adds a

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

On 13Feb2019 0820, Victor Stinner wrote: On my Windows VM, "python" is Python 3.7 :-) In virtual environments, "python" can also be Python 3 as well. I recall that I saw commands using "python" rather than "python3" in the *official* Python 3 documentation: see examples below (*). Problem: On

Re: [Python-Dev] CPython on Windows ARM32

On 06Feb2019 1423, Christian Heimes wrote: Do you want to update Python 3.8 (master) only or also 3.7? I'm not strictly against updating 3.7. However we have traditionally kept the OpenSSL version of each branch stable. 1.1.1 comes with new features, stricter security settings and some ciphers

Re: [Python-Dev] CPython on Windows ARM32

On 06Feb2019 0054, Terry Reedy wrote: On 2/5/2019 10:10 PM, Zachary Ware wrote: I'm all for the first two changes (especially the second), and if 10 years of pledged corporate support for a new platform is the price we have to pay for them, I'm ok with that :). I would expect that the main

Re: [Python-Dev] About the future of multi-process Python

On 06Feb2019 0906, Antoine Pitrou wrote: For the record there are number of initiatives currently to boost the usefulness and efficiency of multi-process computation in Python. One of them is PEP 574 (zero-copy pickling with out-of-band buffers), which I'm working on. Another is Pierre

Re: [Python-Dev] CPython on Windows ARM32

Just confirming for the list that I'm aware of this and supportive, but am not the dedicated support for this effort. I also haven't reviewed the changes yet, but provided nobody is strongly opposed to taking on a supported platform (without additional releases on python.org), I expect I'll do a

Re: [Python-Dev] Source of truth for C-API

On 22Jan.2019 1517, Victor Stinner wrote: > I'm not aware of any tool to automatically list the content of the C API. The shell script attached to https://bugs.python.org/issue23903 should be able to do it with different preprocessor values (we originally intended to detect inconsistencies in the

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

Sun's correct and useful answer which I find very disappointing and a great way to discourage contributions. We can, and should, do better, at least by thanking the person for their response before running down a barely related side track. On 17Jan.2019 2209, Steve Dower wrote: > For everyone

Re: [Python-Dev] ctypes: is it intentional that id() is the only way to get the address of an object?

For everyone who managed to reply *hours* after Eryk Sun posted the correct answer and still get it wrong, here it is again in full. As a bonus, here's a link to the place where this answer appears in the documentation: https://docs.python.org/3/library/ctypes.html#ctypes.py_object Cheers, Steve

Re: [Python-Dev] Interested in serving on Steering Council

On 03Jan.2019 0515, Antoine Pitrou wrote: > The primary question I would ask an external candidate is: how is it > that you never became a core developer (which implies some amount of > effort and dedication) but nevertheless would be willing to spend the > effort and dedication needed for serving

Re: [Python-Dev] I reverted "Add Windows App Store package" change

On 07Dec2018 1340, Terry Reedy wrote: Simple bugfix example: Add test to test_mod that fails with TwinkleError. Posted to issue by Joe Blow. Make new test pass using the 'underhand' strategy. The split above is not really necessary, but PR 10245 squashed changes to 52 files of 15 file types

Re: [Python-Dev] I reverted "Add Windows App Store package" change

As a slight aside, 8 out of 8 buildbot messages on the PR look like false positives, and none of the true positives sent a message. What happened there? On 07Dec2018 0716, Steve Dower wrote: > Thanks for fixing up the buildbots, but please be a little more thorough > before making pu

Re: [Python-Dev] I reverted "Add Windows App Store package" change

ot; > https://bugs.python.org/issue34977 > > These changes broke all Windows buildbots: > > "Almost all Windows buildbots are failing to compile" > https://bugs.python.org/issue35437 > > So I reverted these two changes. > > It's a large change which mostly add

Re: [Python-Dev] Standard library vs Standard distribution?

On 30Nov2018 1435, Antoine Pitrou wrote: Sorry. I've been unfair and unduly antagonistic. Apology is totally accepted and all is forgiven. Thank you. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] C API changes

On 30Nov2018 1133, Antoine Pitrou wrote: On Fri, 30 Nov 2018 13:06:11 -0600 Neil Schemenauer wrote: On 2018-11-29, Armin Rigo wrote: ...Also, although I'm discussing it here, I think the whole approach would be better if done as a third-party extension for now, without requiring changes to

Re: [Python-Dev] C API changes

On 29Nov2018 2206, Armin Rigo wrote: On Thu, 29 Nov 2018 at 18:19, Steve Dower wrote: quo. We continue to not be able to change CPython internals at all, since that will break people using option B. No? That will only break users if they only have an option-B ``foo.cpython-318m-x86_64-linux

Re: [Python-Dev] Standard library vs Standard distribution?

On 29Nov2018 1330, Nathaniel Smith wrote: On Thu, Nov 29, 2018 at 10:22 AM Antoine Pitrou wrote: Le 29/11/2018 à 19:07, Steve Dower a écrit : On 29Nov2018 0923, Antoine Pitrou wrote: I think the whole argument amounts to hand waving anyway. You are inventing an extended distribution which

Re: [Python-Dev] Inclusion of lz4 bindings in stdlib?

On 29Nov2018 1230, Gregory P. Smith wrote: On Thu, Nov 29, 2018 at 2:58 AM Andrew Svetlov > wrote: 5 cents about lz4 alternatives: Broli (mentioned above) is widely supported by web.

Re: [Python-Dev] Standard library vs Standard distribution?

On 29Nov2018 1229, Paul Moore wrote: On Thu, 29 Nov 2018 at 18:09, Steve Dower wrote: Maintaining a list of "we recommend these so strongly here's an installer that will give them to you" is a very different kind of burden, and one that is significantly easier to bear. OK, so th

<    1   2   3   4   5   6   7   8   >