Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

One more possible concern that I just thought of is the availability of the build tools on Windows Vista and Windows 7 RTM (that is, without SP1). I'd have to check, but I don't believe anything after VS 2012 is supported on Vista and it's entirely possible that installation is blocked. This

[Python-Dev] Python 3.5 on VC14 - update

ded it doesn't break anything. (Interestingly, PGO decided that only 1% of functions needed to be compiled for speed. Not sure if I can find out which ones those are but if anyone's interested I can give it a shot?) Cheers, Steve ___ Python

Re: [Python-Dev] Python 3.5 on VC14 - update

> Antoine Pitrou wrote: > Le 10/06/2014 12:30, Steve Dower a écrit : >> >> I ran a quick test with profile-guided optimization (PGO, pronounced >> "pogo"), which has supposedly been improved since VC9, and saw a very >> unscientific 20% speed improvement

Re: [Python-Dev] Python 3.5 on VC14 - update

Martin v. Löwis wrote: > Am 10.06.14 18:30, schrieb Steve Dower: >> I ran a quick test with profile-guided optimization (PGO, pronounced >> "pogo"), which has supposedly been improved since VC9, and saw a very >> unscientific 20% speed improvement on pybench.

Re: [Python-Dev] Criticism of execfile() removal in Python3

I think the point is that the encoding may be embedded in the file as a coding comment and there's no obvious way to deal with that. Top-posted from my Windows Phone From: Greg Ewing Sent: ‎6/‎14/‎2014 16:19 To: python-dev@pytho

Re: [Python-Dev] Criticism of execfile() removal in Python3

‎2014 18:31 To: Steve Dower<mailto:steve.do...@microsoft.com> Cc: Greg Ewing<mailto:greg.ew...@canterbury.ac.nz>; python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Criticism of execfile() removal in Python3 On 15 Jun 2014 09:37, "Steve Dower&

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

e: I wonder if it's worth changing to dynamically linking to OpenSSL? It would make this kind of in-place upgrade easier when people need to do it. Any thoughts? (Does OpenSSL even support it?) Cheers, Steve > Thanks! > Andy Yates ___ P

Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windows required

Yeah, the fact that it really has to be our own copy of the DLL negates the advantage. If someone can rebuild that, they could rebuild the modules that statically link it. Cheers, Steve Top-posted from my Windows Phone From: Martin v. Löwis<mailto:

Re: [Python-Dev] Python 2.7 patch levels turning two digit

We can always lie about the version in sys.version. Existing code is unaffected and new code will have to use version_info (Windows developers will know that Windows pulls tricks like this every other version... doesn't make it a great idea, but it works). Changing compiler without changing at

[Python-Dev] PEP 572 semantics

be more precise. And for specification's sake, does "not supported" mean "is a syntax error"? The "equivalent needs extra parentheses" examples add two sets of extra parentheses. Are both required? Or just the innermost set? --- Apologies for the lack of cont

Re: [Python-Dev] PEP 572 semantics

ance, as far as I'm concerned. (Same for the frame lifetime discussion, which I snipped). Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572 semantics

xError: no binding for nonlocal 'A' found Is this the equivalent behaviour you want? Or do you want an UnboundLocalError when calling f(0)? Or do you want the global A to be returned? How should we approach decision making about these cases as we implement this? The PEP does not pr

Re: [Python-Dev] A "day of silence" on PEP 572?

On Sat, Jul 7, 2018 at 12:18 AM, Ryan Gonzalez wrote: > On July 6, 2018 5:04:05 PM Antoine Pitrou wrote: > > >> (or contact the PEP's authors >> privately). >> >> > Hoenstly, this feels like a recipe for a disaster... > > ​Many of the people who have strong opinions in this know the PEP authors

Re: [Python-Dev] A "day of silence" on PEP 572?

their opinions, perhaps all the rest of us (especially the PEP authors!) should abandon the list for a few days and let them shout it out :) Top-posted from my Windows 10 phone From: Steve Holden Sent: Friday, July 6, 2018 16:30 To: Ryan Gonzalez Cc: Antoine Pitrou; Python-Dev@Python. Org Subjec

Re: [Python-Dev] Call for prudence about PEP-572

On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' wrote: > ​[...] > I find that (space between the parentheses of a function call statement) > too unnatural as a place where to put an assignment. It is not even > "guarded" by a keyword like "if" or "while" which can help as indicators > that an

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

ut I don't actually think it's that big a problem to deserve that much effort as a solution. Perhaps we should add non-button text below the button saying "Get the 64-bit version"? Cheers, Steve ___ Python-Dev mailing list Pyth

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

On 09Jul2018 0927, Ivan Pozdeev via Python-Dev wrote: On 09.07.2018 19:01, Steve Dower wrote: Perhaps we should add non-button text below the button saying "Get the 64-bit version"? Maybe infer the bitness from User-Agent instead. This seems to be the trend among official sites

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

On 09Jul2018 0922, Antoine Pitrou wrote: On Mon, 9 Jul 2018 09:01:00 -0700 Steve Dower wrote: I've thought a bit about making a single installer that can offer the option of 32-bit/64-bit at install time, but I don't actually think it's that big a problem to deserve that m

Re: [Python-Dev] Can I make marshal.dumps() slower but stabler?

only one floating-point zero. Steve Holden On Thu, Jul 12, 2018 at 9:55 AM, Alex Walters wrote: > > > > -Original Message- > > From: Python-Dev > list=sdamon@python.org> On Behalf Of Victor Stinner > > Sent: Thursday, July 12, 2018 4:01 AM > >

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 12, 2018 at 6:21 PM, Barry Warsaw wrote: > ​[...] > > I was -1 as well, but I’d say I’m a firm +0 now[*]. I like how many of > the problematic syntactic and semantic issues have been narrowed and > prohibited, and I can see myself using this sparingly. > ​[...] I think experienc

Re: [Python-Dev] Fuzzing the Python standard library

On Tue, Jul 17, 2018 at 11:44 PM, Paul G wrote: > In many languages numeric types can't hold arbitrarily large values, and I > for one hadn't really previously recognized that if you read in a numeric > value with an exponent that it would be represented *exactly* in memory > (and thus one object

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

On Sun, Jul 22, 2018 at 12:14 AM, Guido van Rossum wrote: > ​[...] > The new BDFL may be less demanding though. :=) > ​I sincerely hope not. regards Steve​ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman

Re: [Python-Dev] [Windows] how to prevent the wrong version of zlib1.dll to be used by lib-dynload modules

advice is pretty useless to you. There are also significant parts of both zlib and openssl available in a normal Python install on Windows, so perhaps you don't need to include alternate copies of those with your package? Are there particular features or APIs missing that you need? Cheers

Re: [Python-Dev] Tests failing on Windows with TESTFN

blem I'm seeing but it should certainly reduce them. One additional thing that may help (if support.unlink doesn't already do it) is to rename the file before deleting it. Renames are always possible even with open handles, and then you can create a new file at the origi

Re: [Python-Dev] Testing C API

ntent, but also think that's quite a disadvantage. It would be good to avoid it. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/opt

Re: [Python-Dev] Tests failing on Windows with TESTFN

From: eryk sun Sent: Sunday, 29 July 2018 15:28 To: python-dev@python.org Subject: Re: [Python-Dev] Tests failing on Windows with TESTFN On Sun, Jul 29, 2018 at 12:35 PM, Steve Dower wrote: > > One additional thing that may help (if support.unlink doesn't already do it) > is to ren

Re: [Python-Dev] Using Cython for the stdlib (was: Let's change to CAPI!)

I don’t think there would be any trouble linking in the generated C files. The built in modules like this just have their *_init() functions called at startup, so possibly nothing would even change. Top-posted from my Windows 10 phone From: Brett Cannon Sent: Wednesday, 1 August 2018 17:20 To:

Re: [Python-Dev] Refactor __get_builtin_constructor on hasklib.py

irly well-scrutinised, and as PEP 8 reminds us, change made for purely stylistic reasons threatens to introduce new bugs. It's not obvious how much of the developer documentation you've seen, so it might be worth mentioning https://devguide.python.org/ as a good starting point for anyone

Re: [Python-Dev] A Subtle Bug in Class Initializations

argument, and maybe (eventually) making PyVarObject_HEAD_INIT argumentless. Since PyVarObject_HEAD_INIT currently requires PyType_Ready() in extension modules already, then don't we just need to fix the built-in types? As far as the "eventually" case, I'd hope tha

Re: [Python-Dev] A Subtle Bug in Class Initializations

AD_INIT currently requires PyType_Ready() in extension modules already, then don't we just need to fix the built-in types? As far as the "eventually" case, I'd hope that eventually extension modules are all using PyType_FromSpec() :) +1 :) Is that just a +1

Re: [Python-Dev] [python-committers] Winding down 3.4

“So that 3.4 dies in good health?” More like getting all its evil deeds off its chest on the death bed, I think :) Top-posted from my Windows 10 phone From: Antoine Pitrou Sent: Monday, 13 August 2018 2:59 To: Larry Hastings; python-committers; Python-Dev Subject: Re: [python-committers] Winding

Re: [Python-Dev] We cannot fix all issues: let's close XML security issues (not fix them)

there is no penalty for something sitting in there for a long time. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does the Contributor Agreement need my address?

I suggest you direct the question instead to the Python > > Software Foundation, which deals with the project's legalities: > > > > p...@python.org > > Thanks, this is useful information. > > <https://mail.python.org/mailman/options/python

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

r own analysis. I'm only talking about CPython here.) Cheers, Steve On 16Sep2018 0707, Wes Turner wrote: Should Python builds add `-mindirect-branch=thunk -mindirect-branch-register` to CFLAGS? Where would this be to be added in the build scripts with which architectures? /QSpectre is the

Re: [Python-Dev] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register

On 17Sep2018 1158, Wes Turner wrote: On Monday, September 17, 2018, Steve Dower <mailto:steve.do...@python.org>> wrote: I investigated this thoroughly some time ago (when the MSVC flags became available) and determined (with the help of some of the original Spectre

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

hich has to take more use cases into account. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [help] where to learn how to upgrade from 2.7 to 3

You can find information about python-list at https://mail.python.org/mailman/listinfo/python-list regards Steve Holden On Tue, Sep 18, 2018 at 4:28 AM Ryan Gonzalez wrote: > Python-dev is for development *of* Python, not *in* Python! You want > python-list instead. > > Also, m

Re: [Python-Dev] Questions about signal handling.

I'm afraid Kristjan left CCP some time ago, and may not subscribe to this list any more. Steve Holden On Tue, Sep 25, 2018 at 4:23 PM Antoine Pitrou wrote: > On Tue, 25 Sep 2018 09:09:26 -0600 > Eric Snow wrote: > > On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner > wrote

Re: [Python-Dev] Some PRs to merge?

This is terrific work. We all know that the best way to encourage contributors is to use their usable contributions. Thank you very much, Stephane and Victor (again)! Steve Holden On Sat, Oct 20, 2018 at 10:32 AM, Stephane Wirtel wrote: > On 10/20, Victor Stinner wrote: > >> Le

Re: [Python-Dev] The future of the wchar_t cache

changed it to UCS-1. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The future of the wchar_t cache

I think that it is mostly useless, but if we can transparently keep many strings "native" size, that will handle many of the useful cases such as the single-use pass-through scenario like above. Cheers, Steve ___ Python-Dev mailing list

Re: [Python-Dev] The future of the wchar_t cache

On 22Oct2018 0913, Victor Stinner wrote: Le lun. 22 oct. 2018 à 15:08, Steve Dower a écrit : Agreed the cache is useless here, but since the listdir() result came in as wchar_t we could keep it that way (assuming we'd only be changing it to char), and then there wouldn't ha

Re: [Python-Dev] The future of the wchar_t cache

the nature of this problem - guessing that it *won't* be used as UCS-2 later on is also a guess. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The future of the wchar_t cache

On 22Oct2018 1007, Serhiy Storchaka wrote: 22.10.18 16:24, Steve Dower пише: Yes, that's true. But "should reduce ... footprint" is also an optimisation that deserves a benchmark by that standard. Also, I'm proposing keeping the 'kind' as UCS-2 when the string is

Re: [Python-Dev] The future of the wchar_t cache

On 22Oct2018 1047, Steve Dower wrote: On 22Oct2018 1007, Serhiy Storchaka wrote: 22.10.18 16:24, Steve Dower пише: Yes, that's true. But "should reduce ... footprint" is also an optimisation that deserves a benchmark by that standard. Also, I'm proposing keeping the 

Re: [Python-Dev] "Deprecation" of os.system in favor of subprocess?

s changing *some* of the other references in the docs, then I'm okay with that. But both uses are valid, so it's really more about being clear who the function is intended for. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] "Deprecation" of os.system in favor of subprocess?

by remaining it must be considered redundant. You have not shown this. Posting quotes followed by an unrelated conclusion isn't a very compelling form of argument :) Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyth

Re: [Python-Dev] Python Language Governance Proposals

PSF to manage such activity. Following the debate with interest, but mostly lurking due to my usual absence of skin in the game. Bonne chance! regards Steve Steve Holden On Fri, Oct 26, 2018 at 6:17 PM, Brett Cannon wrote: > > > On Tue, 23 Oct 2018 at 13:20, Jeroen Demeyer wrote:

Re: [Python-Dev] short-circuiting runtime errors/exceptions in python debugger.

dlers on the stack is nearly impossible. We got close enough with looking at the AST of each caller that we didn't try any harder than that. If you know *where* you're expecting the exception, you could even filter on line number and then break when that line is on the stack but b

Re: [Python-Dev] Rename Include/internals/ to Include/pycore/

st, while #include looks at search paths first, which should be able to deal with collisions). Any change here is an improvement, though. I'll be happy for Py_BUILD_CORE to go away (or at least only imply -Iinclude/internal, rather than actual preprocessor work), no matter where files land

Re: [Python-Dev] windows compiler list missing 3.7 details on wiki

Yes. Visual Studio 2015 or later can be used (and as this is the only way to get the compiler right now, I think it's fine to list that as the requirement - note that the "Visual Studio Build Tools" installer doesn't include the IDE itself). Feel free to update the wiki

Re: [Python-Dev] Get a running instance of the doc for a PR.

s practically anywhere. Pushing them to a git repo based on the PR name is easy, and presumably it can be a single repo with directories for different PRs? It might need a separate job to periodically clean it up, but this seems very doable. Cheers, Steve ___

Re: [Python-Dev] Get a running instance of the doc for a PR.

iest option, as those are already there.) Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bpo-34532 status

It's merged now. Sorry for not seeing the update (I get far too many github notifications/emails to be able to pay attention to them - pinging on the issue tracker generally works best). Cheers, Steve On 20Nov2018 1002, Brett Cannon wrote: To provide context, https://bugs.pytho

Re: [Python-Dev] C API changes

have been better off leaving the API alone and not changing anything. But this is great discussion. Looking forward to seeing some of it turn into reality :) Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mai

Re: [Python-Dev] C API changes

On 28Nov2018 2208, Armin Rigo wrote: Hi Steve, On Tue, 27 Nov 2018 at 19:14, Steve Dower wrote: On 27Nov2018 0609, Victor Stinner wrote: Note: Again, in my plan, the new C API would be an opt-in API. The old C API would remain unchanged and fully supported. So there is no impact on

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

dard distribution that bundles many of these libraries by default (Anaconda style), as well as a minimal one that is a better starting point for low-footprint systems (Miniconda style) or embedding into other apps. Cheers, Steve ___ Python

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

aining 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. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.

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

to use any packages at all on Windows". Please don't accuse me of throwing out ideas in this area without doing any work. When the discussion is about getting Python modules onto people's machines, discussing ways to get Python modules onto people's machines is actually keeping

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,

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. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-

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] 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] C API changes

in ways the plain-old C++ ABI does not. So we wouldn't necessarily have to design a new C-based ABI for this, we could adopt an existing one that is already proven and already has supporting tools. Cheers, Steve ___ Python-Dev mailing list

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 https://mail.python.org/ma

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

be even more strident when a library module is a basic version, not to be used for production purposes. This inevitably means, however, that there will be lag in the documentation, which generally speaking lags current best practices. Steve Holden * I am not a significant contributor to the code

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

at https://github.com/python/cpython/pull/11027 and https://github.com/python/cpython/pull/11028 with fixes for the one issue that Victor couldn't investigate. If someone can get a Windows buildbot to run against them that would be great (not you Zach - your buildbots were fine :) ). Cheers, Ste

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

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 i

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

o the Steering Council, and so are the ones who elect them. (Note that I've carefully used "core committer" and "core developer" above. I believe it's very important to distinguish between "write access on GitHu

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,

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

Eryk 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

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

s in the stable API, but when we found lots of existing inconsistencies we couldn't agree on how to deal with them). Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubs

Re: [Python-Dev] Lost sight

ython to date. Kind regards Steve On Sat, Jan 19, 2019 at 10:14 AM Serhiy Storchaka wrote: > I have virtually completely lost the sight of my right eye (and the loss > is quickly progresses) and the sight of my left eye is weak. That is why > my activity as a core developer

Re: [Python-Dev] How about updating OrderedDict in csv and configparser to regular dict?

rties. regards Steve Holden On Thu, Jan 31, 2019 at 7:55 AM INADA Naoki wrote: > Hi, > > csv.DictReader uses OrderedDict by default, from Python 3.6. > But it doesn't make sense anymore, like namedtuple._asdict(). > How about changing default dict type back to regular dict. >

[Python-Dev] Fwd: How about updating OrderedDict in csv and configparser to regular dict?

-- Forwarded message - From: Steve Holden Date: Thu, Jan 31, 2019 at 11:05 AM Subject: Re: [Python-Dev] How about updating OrderedDict in csv and configparser to regular dict? To: INADA Naoki And I see that such a patch is now merged. Thanks, Raymond

Re: [Python-Dev] CPython on Windows ARM32

I'll do a big part of the reviewing then. Cheers, Steve On 05Feb.2019 1709, Paul Monson via Python-Dev wrote: > Hi Python Developers, > > I'm Paul Monson, I've spent about 20 years working with embedded > software.  Since 2010 I've worked for Microsoft as a develo

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

components and not a lot of information about how they interact and overlap. A good start would be to identify the likely overlap of this work to see where they can build upon each other rather than competing, as well as estimating the long-term burden of standardising.

Re: [Python-Dev] CPython on Windows ARM32

There's also an option to create an ARM-specific pyconfig.h if necessary, but I don't believe it will be. I created https://bugs.python.org/issue35920 for this work. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https

Re: [Python-Dev] CPython on Windows ARM32

phers removed. I would prefer to stay on 1.1.0 for 3.7, but it's up to the release manager. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.o

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

r docs should describe the recommended workaround in any places people are likely to first encounter it (tutorial, sys.executable, etc.) (And maybe this isn't currently how things are done, but I'd rather hold up an ideal than pretend that the s

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

te the documentation to make it more about how this value should be used rather than where it comes from. Any objections or concerns? Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

n use to make this easier. Really, none of us should be having to decide "how am I going to use a temporary location on the file system in my test", because we should have one obvious (and easy!) way to do it. But please, don't keep reinventing the functions we alr

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

27;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? Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/l

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 alwa

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

IVE_DANGEROUSLY?). I like that we're taking (small) steps to reduce the size of our API. It helps balance out the growth and leaves us with a chance of one day being able to have an extension model that isn't as tied to C's ABI. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

e for this case when it's going to break the 90%+ of people who don't recompile everything all the time. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 si

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

t; was only a little bit tongue-in-cheek :) Maybe there's a good Monty Python reference we can use here? "Py_ITS_JUST_A_FLESH_WOUND" or "Py_THEN_WE_JUMP_OUT_OF_THE_RABBIT" Cheers, Steve ___ Python-Dev mailing list Python-Dev@py

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

Python without things breaking than they are about runtime performance. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 th

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

discussion. Otherwise, go straight to distutils-sig (just don't be too surprised if you don't seem to get much traction there or if someone restarts the discussion on Discourse for you). Cheers, Steve On 19Feb2019 1341, Brett Cannon wrote: Unfortunately you're still posted to

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

me easier. I'm always in favor of cleaning up inactionable bugs (as much as I'm in favor of keeping actionable-but-low-priority bugs open, which causes quite a few conflicts at work...) That said, maybe it makes sense to wait until 2.7's EOL and do them all at once? Cheers, Steve

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

ther an outline draft by email first, as I want to discuss the ideas right now rather than the grammar. Hopefully later this morning (next 3-4 hours). python-dev can expect (hope for) an informational PEP to return. If you're not currently on capi-sig, you can join it at https://mail.python

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

the process even easier (too easy?). It's spelled `python -m reportabug` ;) https://pypi.org/project/reportabug/ https://github.com/zooba/reportabug Example: https://github.com/zooba/reportabug/issues/1 Cheers, Steve ___ Python-Dev mailing list P

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

e 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 to change from this process? Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://

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

rtable with trying to also hide them from first time contributors. Either way, I'll keep marking issues as Easy when I think they are good first contributions. Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

have contributors). So I'm in favour of making this easy (since I'm already having to deal with it being difficult ;) ), as it's extremely valuable for security-conscious deployments as well as the distro package cases mentioned by Gregory. Cheers, Steve

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

While these are interesting ideas, wouldn't it be better to leave this kind of packaging to snap and similar utilities that bundle the language support and libraries to allow simple isolated installation. Kind regards Steve Holden On Tue, Feb 26, 2019 at 10:05 PM Neil Schemenauer wrote:

Re: [Python-Dev] datetime.timedelta total_microseconds

preferable? Kind regards Steve Holden On Wed, Feb 27, 2019 at 3:13 PM Paul Ganssle wrote: > > On 2/26/19 7:03 PM, Chris Barker via Python-Dev wrote: > > This thread petered out, seemingly with a consensus that we should update > the docs -- is anyone doing that? > > I don&#x

<    1   2   3   4   5   6   7   8   9   10   >