Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

Could we perhaps redefine bytes paths on Windows as utf8 and use Unicode everywhere internally? I really don't like the idea of not being able to use bytes in cross platform code. Unless it's become feasible to use Unicode for lossless filenames on Linux - last I heard it wasn't. Top-posted fr

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

On 09Feb2016 1801, Andrew Barnert wrote: On Feb 9, 2016, at 17:37, Steve Dower mailto:pyt...@stevedower.id.au>> wrote: Could we perhaps redefine bytes paths on Windows as utf8 and use Unicode everywhere internally? When you receive bytes from argv, stdin, a text file, a GUI, a name

Re: [Python-Dev] Windows: Remove support of bytes filenames in theos module?

On 09Feb2016 2017, Stephen J. Turnbull wrote: > The problem here is the protocol that Python uses to return bytes paths, > and that protocol is inconsistent between APIs and information is lost. No, the problem is that the necessary information simply isn't always available. Not even today:

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

On 11Feb2016 0651, Barry Warsaw wrote: On Feb 11, 2016, at 09:22 AM, Georg Brandl wrote: based on the feedback so far, I revised the PEP. There is now a much simpler rule for allowed underscores, with no exceptions. This made the grammar simpler as well. I'd be +1, but there's something miss

Re: [Python-Dev] RE 25939 - _ssl.enum_certificates broken on Windows

I think the test is blocked on my question of whether we are allowed to rely on ctypes in the test suite. If so, it's fine as I recall. Fairly sure it's a Windows-specific test anyway, so ctypes can basically be assumed for all Windows platforms we currently care about. Top-posted from my Wind

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

Hi Mathieu I just want to say that we are very aware of the concerns and issues faced here and people (including myself) are actively working to resolve them. For example, I am working with the Visual C++ team to encourage and support work such as https://blogs.msdn.microsoft.com/vcblog/201

Re: [Python-Dev] Python should be easily compilable on Windows withMinGW

Yep, that link is part of what I was talking about, though really it's one of a few experiments we're working on right now for making the build tools more accessible. I'm not sure it is currently sufficient for building CPython, but that's why I'm working with the team on these - what is eventua

Re: [Python-Dev] PEP 514: Python environment registration in the Windows Registry

On 01Mar2016 0524, Paul Moore wrote: On 1 March 2016 at 11:37, David Cournapeau wrote: I am not clear about 3., especially on what should be changed. I know that for 2.7, we need to change PC\getpathp.c for sys.path, but are there any other places where the registry is used by python itself ?

Re: [Python-Dev] PEP 514: Python environment registration in the Windows Registry

On 01Mar2016 1137, David Cournapeau wrote: If you want to patch your own distribution to move the paths you are welcome to do that - there is only one string literal in getpathp.c that needs to be updated - but it's not a requirement and I deliberately avoided making a recommendat

Re: [Python-Dev] Bug in build system for cross-platform builds

Simply removing them would break the Windows build, and it may not be easily fixable as the dependency system we use doesn't allow building a project twice. Currently we fail the build if a generated file changes and then the user has to trigger a second build with the new file, but typically t

Re: [Python-Dev] runtime dlls on Windows

On 25May2016 1229, Chris Barker wrote: Hi folks, The standard build of Py3.5 for Windows is built with VS2015 (correct??) And it includes the runtime dlls it needs. However, we've found that wxPython wheels for win32 (not sure about win64) also need: MSVCP140.DLL There are two different vers

Re: [Python-Dev] runtime dlls on Windows

On 26May2016 0942, Chris Barker wrote: An alternative approach would be to stick MSVCP140.DLL into a tiny shim wheel and upload that to PyPI, and then wxPython and matplotlib's windows wheels could declare a dependency on this msvcp410 wheel. Basically this is the idea of my pyna

Re: [Python-Dev] runtime dlls on Windows

On 26May2016 1453, Sebastian Krause wrote: Chris Angelico wrote: BUT -- Steve Dower seems to have identified that the wonders of dll hell never cease, and this isn't possible anyway. Oh well. I'm not entirely grasping what's happening here. There are multiple versions

Re: [Python-Dev] runtime dlls on Windows

On 26May2016 1601, Glenn Linderman wrote: On 5/26/2016 3:18 PM, Steve Dower wrote: This has been deprecated. It sounded like a great idea at the time (~8 years ago) but caused more problems than it solved. Somehow I missed the announcement of the deprecation. The feature itself probably

Re: [Python-Dev] runtime dlls on Windows

esolve for Python's incredibly diverse user base. Top-posted from my Windows Phone -Original Message- From: "Chris Angelico" Sent: ‎5/‎26/‎2016 17:04 Cc: "python-dev" Subject: Re: [Python-Dev] runtime dlls on Windows On Fri, May 27, 2016 at 5:13 AM, Steve Dower wro

Re: [Python-Dev] Adding NewType() to PEP 484

Did anyone suggest "distinct type alias"? Regardless of what name, I'm fairly sure people will call it whatever the function to create it is called. So if the function is typings.distinguish_type(...), then distinguished will stick. Top-posted from my Windows Phone -Original Message- F

Re: [Python-Dev] NTPath or WindowsPath?

Sounds good to me. NT is already an obsolete term - Win32 would be more accurate - but WinRT hasn't changed the path format, so WindowsPath will be accurate for the foreseeable future. Cheers, Steve Top posted from my Windows Phone From: Benjamin Peterson

Re: [Python-Dev] PEP 0404 and VS 2010

of MSVC, provided they are "safe", and the build will fail if they aren't. There are still some ways the differing CRTs can cause issues - alloc/free pairing, for example - so some macros may also have to become exported functions. After that I don't think there are any ways

Re: [Python-Dev] PEP 0404 and VS 2010

Nick Coghlan wrote: > For 2.7.7, I think some combination of the two following ideas would be worth > pursuing: > - a C runtime independent API flag (set by default on Windows when building > with > a compiler other than VS2008). This would largely be a backport of some of the > stable ABI work fr

Re: [Python-Dev] PEP 0404 and VS 2010

Martin v. Löwis wrote: > Am 22.11.13 01:58, schrieb Steve Dower: > >> I'm happy to work on a PEP and changes for what I described above, if >> there's enough interest? I can also update distutils to detect and >> build with any available compiler, though this may

Re: [Python-Dev] PEP 0404 and VS 2010

> Martin v. Löwis wrote: > Am 22.11.13 19:10, schrieb Steve Dower: >> I'd really want to update distutils.msvc9compiler to detect later >> versions as well, since that would make 'pip install' work properly >> for a large (majority?) of users for a large (m

Re: [Python-Dev] PEP 0404 and VS 2010

Steve Dower wrote: > The advice I've been given on FILE* is that there's probably no way to make it > work correctly due to its internal buffering. Unfortunately, there are more > places where this leaks through than just the APIs using them - extensions >

Re: [Python-Dev] .clinic.c vs .c.clinic

Visual Studio will try to compile them if they end with .c, though this can be disabled on a per-file basis in the project file. Files ending in .h won't be compiled, though changes should be detected and cause the .c files that include them to be recompiled. .inl is also sometimes used as an e

[Python-Dev] Issue 20891 - PyGILState_Ensure on non-Python thread causes fatal error

Hi python-dev Just wanted to draw some attention to http://bugs.python.org/issue20891, which I just created. (I hope I got the right people on the nosy list, but going broad just to be safe.) Details and the discussion can go on there, but the basic gist is that C threads can't safely call PyG

Re: [Python-Dev] Windows installers and OpenSSL

I'm willing to embark on migrating the entire installer to WiX, which doesn't directly fix any particular issue, but could significantly reduce the overhead of building and maintaining the Windows installers. Martin - are you at PyCon today? Can we chat to figure out what how much of the work y

Re: [Python-Dev] 2.7 Windows installers (Was: death to 2.7; long live 2.7)

I replied to the other email before I saw this one. Consider this my self-nomination to take over, pending a quick email to Microsoft's lawyers to make sure it's okay (it should be, but IANAL and they wrote the policy). My plan would be to rewrite the installer using WiX but retaining compatibi

[Python-Dev] Python "2migr8"

Just in case there's anyone out there who isn't yet sick of discussing how to proceed with Python 2.7, I have some more inputs to contribute. To put it up front, I'm totally against "CPython 2.8" ever becoming a real thing. Anything that comes out should be seen as a migration path, not an upg

Re: [Python-Dev] Python "2migr8"

. > A reasonable request of pydev would be for python-coded stdlib modules to be > updated as much as possible, if that has not already been done. No 'apply', > no 'except SomeException, e'. I think it was addressed later, but this only really helps those who c

Re: [Python-Dev] Python 2.7.7. on Windows

Mike Miller wrote: > I thought this might be a good time to make a final plea to fix a > long-standing security issue in the installer on Windows. By default it > installs > Python to the root folder, thereby bypassing filesystem permissions: > >http://bugs.python.org/issue1284316 This would be a

Re: [Python-Dev] Python 2.7.7. on Windows

> Mike Miller wrote: > On 04/29/2014 05:12 AM, Steve Dower wrote: >> This would be an incredibly painful change that would surprise and >> hurt a lot of people. > > Hi, I think "incredibly painful" is overstating the case a bit. ;) We're > talking &g

Re: [Python-Dev] Python 2.7.7. on Windows

Mike Miller wrote: > Every change has pluses and minuses. I can't guarantee 100% benefits, only > trying to make the case that the benefits here outweigh them. If this is your case about the benefits, it's a weak case. Feel free to blog about how to secure a Python installation in multi-user envi

Re: [Python-Dev] Tix version needed to build 2.7 Windows installer?

Brian Curtin wrote: > On Fri, May 9, 2014 at 12:00 PM, Zachary Ware > wrote: >> On Thu, May 8, 2014 at 4:20 PM, Zachary Ware >> wrote: >>> I updated the 2.7 buildbot scripts to pull in Tcl/Tk 8.5.15 a couple >>> of weeks ago (see http://bugs.python.org/issue21303), but hadn't >>> gotten anything

Re: [Python-Dev] devguide: Add myself to developer log and as a Windows expert.

log and as a Windows expert. On Sun, 11 May 2014 06:04:56 +0200 (CEST) steve.dower wrote: > http://hg.python.org/devguide/rev/8d5d1f2c7378 > changeset: 698:8d5d1f2c7378 > user:Steve Dower > date:Sat May 10 21:01:39 2014 -0700 > summary: > Add myself

Re: [Python-Dev] devguide: Add myself to developer log and as a Windows expert.

No, apologies for that. As Nick pointed out, I meant the *other* B.C. :) Top-posted from my Windows Phone From: Dr. Brett Cannon<mailto:bcan...@gmail.com> Sent: ‎5/‎17/‎2014 18:26 To: Steve Dower<mailto:steve.do...@microsoft.com>; solip...@pitrou.net&

Re: [Python-Dev] Internal representation of strings and Micropython

I'm agree with Daniel. Directly indexing into text suggests an attempted optimization that is likely to be incorrect for a set of strings. Splitting, regex, concatenation and formatting are really the main operations that matter, and MicroPython can optimize their implementation of these easily

Re: [Python-Dev] Internal representation of strings and Micropython

Steven D'Aprano wrote: > The language semantics says that a string is an array of code points. Every > index relates to a single code point, no code point extends over two or more > indexes. > There's a 1:1 relationship between code points and indexes. How is direct > indexing "likely to be incorre

Re: [Python-Dev] Internal representation of strings and Micropython

Paul Sokolovsky wrote: > You just shouldn't write inefficient programs, voila. But if you want, you > can keep writing inefficient programs, they just will be inefficient. Peace. Can I nominate this for QOTD? :) Cheers, Steve ___ Python-Dev mailing lis

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

Hi all I would like to propose moving Python 3.5 to use Visual C++ 14.0 as the main compiler. The first CTP of Visual Studio "14" was released earlier this week: http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx The major feature of interest in this version of MSVC is

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

dw+python-...@hmmz.org wrote: > Speaking as a third party who aims to provide binary distributions for recent > Python releases on Windows, every new compiler introduces a licensing and > configuration headache. So I guess the questions are: > > * Does the ABI stability address some historical rea

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

Stefan Krah wrote: >Stefan Krah wrote: >> > * Will VS 14 be golden prior to Python 3.5's release? It would suck to >> > rely on a beta compiler.. :) >> >> This is my only concern, too. Otherwise, +1 for the switch. > >One more thing: Will the SDK 64-bit tools be available for the Express >Vers

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

Chris Angelico wrote: > On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower wrote: >> What this means for Python is that C extensions for Python 3.5 and later can >> be built using any version of MSVC from 14.0 and later. > > Oh, if only this had been available for 2.7!! Actual

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

Martin v. Löwis wrote: > Am 06.06.14 22:13, schrieb Paul Moore: >> From >> http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs >> >> """ >> Currently, Visual Studio "14" CTPs have known compatibility issues >> with previous releases of Visual Studio and should not be installed >> si

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

For anyone who is interested in more details on the CRT changes, there's a blog post from my colleague who worked on most of them at http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx I wanted to call out one section and add some details: In order to unify thes

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

Yates, Andy (CS Houston, TX) wrote: > Python Dev, > Andy here. I have a Windows product based on Python and I'm getting hammered > to > release a version that includes the fix in OpenSSL 1.0.1h. My product is built > on a Windows system using Python installed from the standard Python installer >

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

mar...@v.loewis.de> Sent: ‎6/‎18/‎2014 2:46 To: Steve Dower<mailto:steve.do...@microsoft.com>; Yates, Andy (CS Houston, TX)<mailto:aya...@hp.com>; Python-Dev@python.org<mailto:Python-Dev@python.org> Subject: Re: [Python-Dev] Issue 21671: CVE-2014-0224 OpenSSL upgrade to 1.0.1h on Windo

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

Now that it's a done deal, I am closely reviewing the semantics section of PEP 572. (I had expected one more posting of the final PEP, but it seems the acceptance came somewhere in a thread that was already muted.) Since there has been no final posting that I'm aware of, I'm referring to https://w

Re: [Python-Dev] PEP 572 semantics

On 04Jul2018 1021, Tim Peters wrote: Same as now, `i` is local to the synthetic nested function created for the genexp.  The scope of `a` is determined by pretending the assignment occurred in the block containing the outermost (textually - static analysis) comprehension.  In this case, `a = an

Re: [Python-Dev] PEP 572 semantics

On 04Jul2018 1518, Tim Peters wrote: > The only new thing is specifying the scope of `a`, where "local to f" > means exactly the same thing as for any other name local to a function > today.  So far as the PEP semantics go, it doesn't even matter whether > an implementation _does_ implement some fo

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

There has been off-list discussion with the authors, for sure. But most of the recent threads are disputes and not useful. At this point, if you're not helping clarify what’s in the PEP, you’re not helping by posting an opinion. But since we can’t possibly convince everyone not to post their op

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

On 09Jul2018 0803, Cosimo Lupo wrote: If one goes to httWhps://www.python.org/downloads  from a Windows browser, the default download URL is for the 32-bit installer instead of the 64-bit one. I wonder why is this still the case? Shouldn't we encourage new Wind

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] [Windows] how to prevent the wrong version of zlib1.dll to be used by lib-dynload modules

In general, if the dependent DLL is in the same directory as the module loading it (the .pyd or .exe), then it should be loaded first. If it's alongside the .exe, it should be loaded before any of the other search paths. If it's being loaded directly from Python, your best option is to resolve

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

On 29Jul2018 0958, Tim Golden wrote: In the interests of trying to keep a focus to the changes I'm making, I propose to start again by, as you suggest, making use of test.support.unlink where it's not currently used. From the evidence I don't believe that will solve every problem I'm seeing but

Re: [Python-Dev] Testing C API

On 29Jul2018 1253, Serhiy Storchaka wrote: The benefit is that it will be easier to run all C API tests at once, and only them, and it will be clearer what C API is covered by tests. The disadvantage is that you will need to run several files for testing marshal for example. Can we make the r

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] A Subtle Bug in Class Initializations

On 09Aug2018 0818, Erik Bray wrote: On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo wrote: 3) Special case the initialization of PyType_Type and PyBaseObject_Type within PyType_Ready to now make all calls to PyVarObject_HEAD_INIT use NULL. To enable this a small change within PyType_Ready is ne

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

On 10Aug2018 0354, Erik Bray wrote: Thanks! I'm not sure what you mean by "on other OS's" though. Do you mean other OS's that happen to use Windows-style PE/COFF binaries? Because other than Windows I'm not sure what we care about there. For ELF binaries, at least on Linux (and probably elsewh

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)

On 06Sep2018 0758, Victor Stinner wrote: Are you volunteer to fix the XML modules? If Christian is not able to keep maintaining the defused* packages, then I may take a look at this next week at the sprints. The built-in XML packages actually don't meet Microsoft's internal security requireme

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

I investigated this thoroughly some time ago (when the MSVC flags became available) and determined (with the help of some of the original Spectre/Meltdown investigation team) that there is no significant value in enabling these flags for Python. It boiled down to: * Python allows arbitrary cod

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?

On 18Sep2018 1057, Carl Shapiro wrote: On Tue, Sep 18, 2018 at 5:55 AM, Fabio Zadrozny > wrote: During the import process, Python can already deal with folders and .zip files in sys.path... now, instead of having special handling for a new concept with a cus

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

On 20Oct2018 0901, Stefan Behnel wrote: I'd be happy to get rid of it. But regarding the use under Windows, I wonder if there's interest in keeping it as a special Windows-only feature, e.g. to speed up the data exchange with the Win32 APIs. I guess it would have to provide a visible (performance

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

On 22Oct2018 0413, Victor Stinner wrote: For code like "for name in os.listdir(): open(name): " (replace listdir with scandir if you want to get file metadata), the cache is useless, since the fresh string has to be converted to wchar_t* anyway, and the cache is destroyed at the end of the lo

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

On 22Oct2018 0928, Victor Stinner wrote: Also, I'm proposing keeping the 'kind' as UCS-2 when the string is created from UCS-2 data that is likely to be used as UCS-2. Oh. That's a major change in the PEP 393 design. You would have to modify many functions in CPython. Currently, the PEP 393 req

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?

On 24Oct2018 0435, Antoine Pitrou wrote: On Wed, 24 Oct 2018 08:05:21 +0200 Stephane Wirtel wrote: 1. Add the 'deprecated' directive in the doc 2. Use subprocess for these references What is your opinion? I don't think it's useful to deprecate something that works fine for the intended purpo

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

On 24Oct2018 0934, Calvin Spealman wrote: In the spirit of "There should be one-- and preferably only one --obvious way to do it." this makes perfect sense. To do what? There is one obvious way to run a system command, and one obvious way to manage subprocesses. There are also many non-obvious

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

On 29Oct2018 1709, Nathaniel Smith wrote: > I also wonder if it would be useful to give pdb the ability to break > when an exception is *raised*, rather than when it's caught? This is basically the first feature I implemented as an intern at Microsoft back in 2011 :) (for Visual Studio's Python de

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

I assume the redundancy was there to handle the naming collision problem, but a better way to do that is to have only header files that users should ever use in "include/", and put the rest inside "include/python/" and "include/internal/" (and if possible, we don't distribute the internal direc

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. Cheers, Steve On 03N

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

On 04Nov2018 0718, Chris Angelico wrote: On Mon, Nov 5, 2018 at 2:11 AM Julien Palard via Python-Dev wrote: Considering feedback from Ned, what about building this as an independent service? We don't really need to interface with python.org at all, we just need some hardware, a domain, some

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

On 04Nov2018 0812, Julien Palard wrote: I can trivially attach the built docs as a ZIP file to the Azure Pipelines build, though that doesn't help the "preview on my phone" So one can build an HTTP server that gathers doc builds from Azure and expose them? Either that, or Azure can push it d

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.python.org/issue34532

Re: [Python-Dev] C API changes

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 performance if you consider to use the old C API. This is one of the things that makes me think your plan is

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?

On 29Nov2018 0254, Antoine Pitrou wrote: I'd like to point the discussion is asymmetric here. On the one hand, people who don't have access to PyPI would _really_ benefit from a larger stdlib with more batteries included. On the other hand, people who have access to PyPI _don't_ benefit from ha

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

On 29Nov2018 0923, Antoine Pitrou wrote: I think the whole argument amounts to hand waving anyway. You are inventing an extended distribution which doesn't exist (except as Anaconda) to justify that we shouldn't accept more modules in the stdlib. But obviously maintaining an extended distributi

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

On 29Nov2018 1020, Antoine Pitrou wrote: It's just _hard_ and an awful lot of work, and apparently you're not volunteering to start it. So saying "we should make an extended distribution" if you're just waiting for others to do the job doesn't sound convincing to me, it just feels like you are d

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

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 CPy

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

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

s to > "Add Windows App Store package": > > "Release Windows Store app containing Python" > https://bugs.python.org/issue34977 > > These changes broke all Windows buildbots: > > "Almost all Windows buildbots are failing to compile" > https:

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

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

<    1   2   3   4   5   6   7   8   >