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

> Antoine Pitrou wrote: > Le 23/06/2014 15:27, M.-A. Lemburg a écrit : >> >> Not sure what you mean. We've had binary wininst distributions for >> Windows for more than a decade, and egg and msi distributions for 8 >> years :-) >> >> But without access to the VS 2008 compiler that is needed to co

Re: [Python-Dev] Remaining decisions on PEP 471 -- os.scandir()

Victor Stinner wrote: > 2014-07-20 18:50 GMT+02:00 Antoine Pitrou : >> Have you tried modifying importlib's _bootstrap.py to use scandir() >> instead of listdir() + stat()? > > IMO the current os.scandir() API does not fit importlib requirements. > importlib usually wants fresh data, whereas DirEn

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

This sounds great, but the disable switch worries me if it's an ENVVAR=1 kind of deal. Those switches have a tendency on Windows of becoming "well known tricks" and they get set globally and permanently, often by application installers or sysadmins (PYTHONPATH suffers the exact same problem). I

Re: [Python-Dev] 3.5 release schedule PEP

Larry Hastings wrote: > > On 09/19/2014 03:31 PM, Barry Warsaw wrote: > I think we need a Python 3.5 Release Schedule PEP. > > Just checked it in as PEP 478.  It should show up here in a few minutes: > http://legacy.python.org/dev/peps/pep-0478/ > > Key facts: > . Beta 1 is May 24th 2015, about a

Re: [Python-Dev] 3.5 release schedule PEP

From: Donald Stufft<mailto:don...@stufft.io> Sent: ‎9/‎23/‎2014 18:50 To: Nick Coghlan<mailto:ncogh...@gmail.com> Cc: Steve Dower<mailto:steve.do...@microsoft.com>; python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev]

Re: [Python-Dev] 3.5 release schedule PEP

> Paul Moore wrote: > On 24 September 2014 14:16, Mike Miller wrote: >> It has been a supported option for just shy of 15 years on 2.X... >> most if not all the bugs (setuptools) were fixed a decade ago, and >> right now thousands, if not millions of people are running it under >> Program Files ri

Re: [Python-Dev] 3.5 release schedule PEP

Donald Stufft wrote: > One thing about *nix is even though you can’t write to your normal Python > install location without root, invoking pip with permissions (assuming you > have > them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows > have > an equivalent or do you need t

Re: [Python-Dev] 3.5 release schedule PEP

> Mike Miller wrote: > Paul Moore wrote: >>> One thing that I presume would be an issue. Isn't Program Files >>> protected in newer versions of Windows? > > Yes, that's the feature that protects from malicious users/code editing > "import > os" to run "format c:\", spam your address book, or look

Re: [Python-Dev] 3.5 release schedule PEP

M.-A. Lemburg wrote: > > I'd rather be conservative here and wait for another Python release before > switching VC versions. There are a few important questions that need answers > before we can consider a new VC version: > > * Will there be free versions available ? > > * Will those free editio

Re: [Python-Dev] 3.5 release schedule PEP

Chris Angelico wrote: > On Thu, Sep 25, 2014 at 6:50 AM, Steve Dower > wrote: >> Donald Stufft wrote: >>> One thing about *nix is even though you can’t write to your normal >>> Python install location without root, invoking pip with permissions >>> (as

Re: [Python-Dev] 3.5 release schedule PEP

> Paul Moore wrote: > On 25 September 2014 17:05, Steve Dower wrote: >> So yes, pip can certainly do this, and if it's already running >> elevated then it shouldn't reprompt, but it's not entirely trivial to >> get this right ("are you denied write ac

[Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

Hi all, (This is advance notice since people on this list will be interested. Official announcements are coming when setuptools makes their next release.) Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9). We've produced this package to help library developers build whee

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

__ From: Christian Heimes<mailto:christ...@python.org> Sent: ‎9/‎27/‎2014 7:19 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7 On 26.09.2014 20:01, Steve Dower wrote: > Hi all, > > (This is

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

Sent: ‎9/‎27/‎2014 5:13 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7 On Fri, 26 Sep 2014 18:01:31 + Steve Dower wrote: > Hi all, > > (This is advance notice since people on this list will be interested.

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

The SDK compilers are not easily fixable (I've tried). The installation is basically corrupt as far as the non-x86 compilers are concerned. The package we just put out is exactly the same files as the SDK with those issues fixed. There's no reason to encourage the SDK at all now (which was the

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

Paul Moore wrote: > File "C:\Apps\Python27\Lib\distutils\msvc9compiler.py", line 299, in > query_vcvarsall > > raise ValueError(str(list(result.keys( > > ValueError: [u'path', u'include', u'lib'] > > > Failed building wheel for blist > Failed to build

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

VC"? (That is what I did.) cheers, Georg On 09/27/2014 05:16 PM, Steve Dower wrote: > Plain distutils won't detect it. It would be easy enough to fix 2.7.9, but > "update Python" is a big/impossible ask for a lot of people, whereas "update > setuptools" is e

Re: [Python-Dev] Status of C compilers for Python on Windows

>From Victor Stinner: > I know that it's hard to replace Visual Studio. I don't want to do it right > now, but I would like to discuss that with you. I have read the rest of the thread, but I want to start from this point. I'm probably going to run off in random directions since there are a lot

Re: [Python-Dev] Status of C compilers for Python on Windows

Is there some reason the Fortran part can't be separated out into a DLL? That's the C ABI Antoine was referring to, and most compilers can generate import libraries from binaries, even if the original compiler produced then in a different format. Top-posted from my Windows Phone ___

Re: [Python-Dev] Status of C compilers for Python on Windows

to. Top-posted from my Windows Phone From: Sturla Molden<mailto:sturla.mol...@gmail.com> Sent: ‎10/‎11/‎2014 9:59 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] Status of C compilers for Python on Windows Steve Dow

Re: [Python-Dev] XP buildbot problem cloning from hg.python.org

I was seeing this recently and had to run recover on my repo (not sure what the command line is for that - TortoiseHg had a menu). YMMV, but the symptoms sound the same. Cheers, Steve Top-posted from my Windows Phone From: David Bolen

Re: [Python-Dev] Status of C compilers for Python on Windows

(Apologies for the short reply, posting from my phone.) "MSVC can continue to be the default compiler used for Python on Windows, none of Roumen's patches change that. They would merely open up the choice for packagers and users to build CPython (and extension modules, thanks to separate patches)

Re: [Python-Dev] Status of C compilers for Python on Windows

Ray Donnelly wrote: > What is it that you > are afraid of if CPython can be compiled out of the box using > mingw/MinGW-w64? Why are you fighting so hard against having option. I'm afraid of users having numpy crash because they're using an MSVC CPython instead of a mingw CPython. I'm afraid of u

Re: [Python-Dev] Status of C compilers for Python on Windows

Ray Donnelly wrote: > On Sun, Oct 26, 2014 at 1:45 AM, Steve Dower > wrote: >> Ray Donnelly wrote: >>> Also, where are the publicly accessible specifications and other technical >>> descriptions that MinGW-w64 would need to implement strong binary >>> compa

Re: [Python-Dev] Status of C compilers for Python on Windows

Ray Donnelly wrote: > On Sat, Oct 25, 2014 at 11:44 PM, Paul Moore wrote: >> On 25 October 2014 23:22, Chris Angelico wrote: >>> On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote: My point is that your "Windows build" would not have the same behaviour as a MSVC-produced Windows bui

Re: [Python-Dev] Status of C compilers for Python on Windows

Greg Ewing wrote: > Nick Coghlan wrote: >> That assumption will allow MinGW-w64 to link with the appropriate >> MSVCRT versions for extention building without anything breaking. > > If that works, then the same technique should allow CPython itself to be built > in a VS-compatible way with mingw, s

Re: [Python-Dev] Status of C compilers for Python on Windows

> Paul Moore wrote: > On 27 October 2014 20:45, Greg Ewing wrote: >> Nick Coghlan wrote: >>> >>> That assumption will allow MinGW-w64 to link with the appropriate >>> MSVCRT versions for extention building without anything breaking. >> >> >> If that works, then the same technique should allow CPyt

Re: [Python-Dev] Status of C compilers for Python on Windows

"You might want to interact with Steve Dower off-list" FWIW, I'm happy to talk specifics off list, and have already been involved in a number of discussions with the numpy and Scipy guys wrt figuring out specific technical challenges or clarifying non obvious parts of dealing wit

Re: [Python-Dev] Status of C compilers for Python on Windows

Antoine Pitrou wrote: > On Wed, 29 Oct 2014 11:07:53 -0400 > Tres Seaver wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 10/29/2014 10:31 AM, R. David Murray wrote: >> >> > If you are writing code targeted for Windows, I think you are very >> > likely to have an MSDN subscri

Re: [Python-Dev] Status of C compilers for Python on Windows

press and >> everything just works. >> - For 64 bit Python 3.2-3.4, install the SDK, set some environment >> variables, and everything just works. >> - For Python 3.5+, install the current Visual Studion Express and >> everything just works. > > > I would suggest

Re: [Python-Dev] Impact of Windows PowerShell OneGet ?

>> Most likely, OneGet won't replace pip/PyPI, any more than apt or yum >> does; but it may be worth having Python itself available that way. >> That might simply mean having someone package up Python and put it on >> an appropriate server, or maybe python.org could end up hosting a >> repo. > > P

[Python-Dev] Who's using VS/Windows to work on Python?

Just wondering who is regularly/occasionally using VS 2010 to work on Python? Also, who currently owns the Windows buildbots and are you willing/able to add a VS 2015 Preview installation (or give me access so I can do it)? I can also set up a VS 2015 buildbot, but the old ones will break if the

Re: [Python-Dev] Who's using VS/Windows to work on Python?

Tim Golden wrote: > Are the changes for VS2015 likely to hamper a build against VS2010? I hadn't tried it, but it looks like it works fine with VS2010 (with a few extra warnings, but nothing fatal as far as the build is concerned). I'm a little surprised, tbh, but not overly upset :) Guess I ca

Re: [Python-Dev] Who's using VS/Windows to work on Python?

David Bolen wrote: > Steve Dower writes: > >> Also, who currently owns the Windows buildbots and are you >> willing/able to add a VS 2015 Preview installation (or give me access >> so I can do it)? (...) > > I've got several of the Windows buildbots, and could

Re: [Python-Dev] Windows Dedicated Mailing List

I'd like to keep development *of* Python here, regardless of platform. Otherwise all the Linux and Mac people might forget about us :) Top-posted from my Windows Phone From: Tim Golden Sent: ‎11/‎14/‎2014 7:11 To: Shorya Raj

Re: [Python-Dev] Who's using VS/Windows to work on Python?

Nick Coghlan wrote: > With the recent (excellent) announcements around switching from the current > Visual Studio Express model to the far more full featured Visual Studio > Community approach, what will the situation be in relation to using Visual > Studio Community edition to work on CPython? It

Re: [Python-Dev] Move selected documentation repos to PSF BitBucket account?

> Antoine Pitrou wrote: > On Fri, 21 Nov 2014 13:29:11 + > Brett Cannon wrote: >>> If that "must be self-hosted" constraint is removed, then the >>> obvious candidate for Mercurial hosting that supports online editing >>> + pull requests is the PSF's BitBucket account. >>> >> >> There's also C

[Python-Dev] PCBuild project updates

​Hi all Just attracting some attention to http://bugs.python.org/issue22919 for those of us who build Python out of the PCBuild folder. More details/patches there, but the tl;dr is * Still works with VS 2010 (and now VS 2013 and VS 2015 too) * Build time should be reduced * Tools\buildbot\*.ba

[Python-Dev] Issue 22919: Update PCBuild for VS 2015

FYI, I've just committed these changes (http://bugs.python.org/issue22919). There shouldn't be any immediate failures, as the updated projects will still build with VS 2010, but our Windows developers/buildbots can migrate onto the later tools as they feel comfortable. I know there are at least

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

This is also my approach, and the one that I'm encouraging throughout Microsoft as we start putting out more Python packages for stuff. Top-posted from my Windows Phone From: Barry Warsaw Sent: ‎12/‎13/‎2014 7:19 To: python-dev@python.org<

Re: [Python-Dev] libffi embedded in CPython

Maciej Fijalkowski wrote: > After reading this http://bugs.python.org/issue23085 and remembering > struggling > having our own patches into cpython's libffi (but not into libffi itself), I > wonder, is there any reason any more for libffi being included in CPython? We use it for ctypes, so there'

[Python-Dev] New Windows installer for Python 3.5

I've put together a short post showing where I've been taking the Windows installer for Python 3.5, since I know there are interested people on this list who will have valuable feedback. http://stevedower.id.au/blog/the-python-3-5-installer/ Nothing is merged in yet and everything can still cha

Re: [Python-Dev] New Windows installer for Python 3.5

Thanks for all the comments. I've responded all at once, since I don't think any of the points raised are going to immediately turn into intense discussion. Feel free to trim the rest of the post if you want to respond to just one of the points. Donald Stufft wrote: > Does signing the .exe’s th

Re: [Python-Dev] New Windows installer for Python 3.5

Chris Angelico wrote: > On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower wrote: >> (Windows will always put per-user PATH entries at the end). The py.exe >> launcher handles this best, and the system version will always be found >> first. >> >> As for versions, 3

Re: [Python-Dev] New Windows installer for Python 3.5

Mark Lawrence wrote: > If I'm reading this correctly it means that py.exe gets picked up from PATH so > it could be 32 or 64 bit. Does this mean that the launcher could be or needs > enhancing so 32 or 64 bit can be selected? I'm not sure if anything can be > done > about pyw.exe, perhaps you (pl

Re: [Python-Dev] New Windows installer for Python 3.5

Ethan Furman: > On 01/04/2015 02:56 PM, Steve Dower wrote: > >> ChrisA wrote: >>> You talk of installing by default into Program Files, and having a >>> separate per-user installation mode. How do these two installation >>> targets interact? Supp

Re: [Python-Dev] New Windows installer for Python 3.5

Paul Moore wrote: > tl;dr We should have "Add this Python to PATH" as a user choice on the initial > installer screen, applicable to whichever install type the user chooses. > Details > as to why are below. I agree. I'll work this up before alpha 1. (FWIW, it defaults to unselected.) Displaying

Re: [Python-Dev] New Windows installer for Python 3.5

David Anthoff wrote: > It would be great if the new installer supported silent, portable installs. > What I have in mind is a silent installation that drops all the necessary > files > for a working python into a folder, but does not put ANY file anywhere else > and > does not register anything a

Re: [Python-Dev] New Windows installer for Python 3.5

David Anthoff wrote: >> I'll look into this, but it probably isn't going to work as part of >> the installer. I have previously looked into being able to install arbitrary >> side-by-side copies of Python, but that's near impossible as well. >> Windows Installer doesn't really let you just copy fil

Re: [Python-Dev] New Windows installer for Python 3.5

> On Sat, Jan 10, 2015 at 3:28 AM, Nick Coghlan wrote: >> For the time being, things like PyInstaller, PyRun, Portable Python, >> etc are going to offer a better solution than anything we provide in >> the standard installers. > > See also Anaconda and Enthought Canopy. I think miniconda, for ins

Re: [Python-Dev] New Windows installer for Python 3.5

Martin v. Löwis wrote: > Am 04.01.15 00:34, schrieb Steve Dower: >> so I'm keen to hear whatever feedback people have. > > One issue that I always wanted to address is patch releases. There are two > aspects I dislike about the current implementation > > a) an upg

Re: [Python-Dev] Compile Python on Windows (OpenSSL)

Victor Stinner wrote: > To compile Python on Windows, there are a few information in the Developer > Guide: > https://docs.python.org/devguide/setup.html#windows-compiling I'm sorry, I've been slack and haven't updated this guide with the new changes. That said, there aren't that many changes to

Re: [Python-Dev] Compile Python on Windows (OpenSSL)

Victor Stinner wrote: > 2015-01-13 23:18 GMT+01:00 Steve Dower : >> Technically, Python 3.5 requires Visual Studio 2015 > > For me, it's *very* difficult to find how to install Visual Studio. > There are many different websites and web pages which mention Visual Studio >

Re: [Python-Dev] Compile Python on Windows (OpenSSL)

Victor Stinner wrote: > 2015-01-13 23:46 GMT+01:00 M.-A. Lemburg : >> Just a note of caution: for older preview releases of VS the only way >> to get back to a clean system was to reinstall Windows. > > Does it mean that it's not possible to have VS 2008 and VS 2015 installed at > the same time?

Re: [Python-Dev] Compile Python on Windows (OpenSSL)

Victor Stinner wrote: > 2015-01-15 22:39 GMT+01:00 Ryan Gonzalez : > > http://www.microsoft.com/en-us/download/details.aspx?id=8279 > > "Microsoft Windows SDK for Windows 7 and .NET Framework 4" > > Are you sure that it is SDK 7.1, and not 7.0? The naming is horrible, and the bugs between VS and

Re: [Python-Dev] Azure event hub network access

This would be much better posted on the github page for the project. I don't have the URL handy, but if you search github for "Python Azure SDK" you'll find it. Cheers, Steve Sent from my Windows Phone From: syed khalid Sent: ‎2/‎5/

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

I was also surprised as I was working on the installer, so +1 on changing it. The installer will also need some changes to add it to PATH, which should be fairly straightforward, but ping me if you need/want pointers. (It's checked in now, so I consider it fair game for anyone who wants to chang

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

ry for anything other than installing scripts. Cheers, Steve Top-posted from my Windows Phone From: Paul Moore<mailto:p.f.mo...@gmail.com> Sent: ‎2/‎10/‎2015 6:41 To: Steve Dower<mailto:steve.do...@microsoft.com> Cc: Nick Coghlan<mailto:nc

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

Martin v. Löwis wrote: > Am 10.02.15 um 16:41 schrieb Steve Dower: >> One of my main engineering concerns is lack of shared knowledge a.k.a. the >> truck factor (not CPython specific, btw, just every project I work on). > > Wrt. the installer, I think this is a lost cause. II

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

So I've enumerated the problems with PATH on Windows before (and my subsequent dislike for modifying it through the installer), but here's the dot-point summary for those who haven't seen it. * System-wide values always precede per-user values * Most-recently-installed values always precede exis

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

Paul Moore wrote: > On 10 February 2015 at 20:50, Paul Moore wrote: >> On 10 February 2015 at 17:45, Steve Dower wrote: >>> This is yet another attempt to try and change user behaviour, which I'm not >>> thrilled >>> about, but I'm really start

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

s directory on Windows Am 10.02.2015 um 18:45 schrieb Steve Dower: > As we've seen from earlier discussions, the main beneficiaries of > having Python on PATH are those using the command-line. Most scripts > are going to make assumptions or work unnecessarily hard to find the > a

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

If venv's activate script sets it, I say go ahead and write it up. If it's just virtualenv, I'd rather not explicitly depend on it, especially since PEP 397's stated aim is file associations and not command line. I've been making changes to py.exe in hg.p.o, so I hope the standalone one is trac

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

Paul Moore wrote: > > On 12 February 2015 at 15:37, Steve Dower wrote: >> If venv's activate script sets it, I say go ahead and write it up. If >> it's just virtualenv, I'd rather not explicitly depend on it, >> especially since PEP 397's stated aim

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

Vinay Sajip wrote: > By the way, although I turned over the standalone launcher to pypa, I forked > that repo, and do development on my fork [1]. I remembered that I added a > feature (with the help of Pawel Jasinski) to allow e.g. py -ipy to pick a > command 'ipy' configured in the .ini file (this

Re: [Python-Dev] PEP 471 (scandir): Poll to choose the implementation (full C or C+Python)

I think posixmodule is a great candidate for splitting up by platform rather than function, as the whole file is packed with ifdef. It's really only lacking a volunteer to do it, but we could start here (ie. make posixmodule_nt.c for the Windows impl, etc.) and progressively move function implem

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

Launching non-Python scripts from py.exe is not going to work as well as you may hope. There will be numerous subtle bugs due to the cmd->py.exe->cmd wrapping (Powershell users would have seen this with some console apps or batch files). I think having a global command to add a particular Python

Re: [Python-Dev] subclassing builtin data structures

"Instead of requiring *every* subclass to override all the methods, couldn't we require the base classes (like int) to assume that the signature is unchanged and call type(self), and leave it up to the subclass to override all the methods *only* if the signature has changed?" I assumed everyone wa

[Python-Dev] Can I replace distutils.msvccompiler?

I'm about to start doing a rework on distutils.msvc[9]compiler.MSVCCompiler for Python 3.5 to be able to handle forward-compatibility better. Right now I've tweaked msvc9compiler enough for VS 2015, but it won't handle later VS versions automatically. Is there any reason to keep the old msvcco

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

ul Moore<mailto:p.f.mo...@gmail.com>; Steve Dower<mailto:steve.do...@microsoft.com>; Python Dev<mailto:python-dev@python.org> Subject: Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support Go ahead, make my pep. I will appreciate seeing it happen. On Feb 15, 20

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

Paul Moore wrote: > On 15 February 2015 at 18:25, Petr Viktorin wrote: >> On POSIXy systems the "python3" symlink is created in all venvs. I >> thought (perhaps naïvely) that Windows doesn't do shebangs natively, >> so there's some Python-specific mechanism around them, which should >> handle "pyt

Re: [Python-Dev] [Python-checkins] cpython: Issue #23152: Implement _Py_fstat() to support files larger than 2 GB on

Agreed. I've made both of these changes. Thanks for the suggestions Cheers, Steve Top-posted from my Windows Phone From: Brett Cannon Sent: ‎2/‎21/‎2015 14:13 To: Ben Hoyt; Python-Dev

Re: [Python-Dev] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat On 21.02.15 20:04, steve.dower wrote: > https://hg.python.org/cpython/rev/307713759a62 > changeset: 94720:307713759a62 > parent: 94718:4f6f4aa0d80f > user:Steve Dower > date:Sat Feb 21 10:04:10 2015

Re: [Python-Dev] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat On 22.02.15 01:26, Steve Dower wrote: > Thanks! Fixed now. Clinic removes the declaration of _Py_time_t_to_FILE_TIME. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/list

Re: [Python-Dev] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat

...@gmail.com> Sent: ‎2/‎22/‎2015 7:29 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] cpython: Issue #23152: Renames attribute_data_to_stat to _Py_attribute_data_to_stat On 22.02.15 16:12, Steve Dower wrote: > Why does it do that? Because it is in the

Re: [Python-Dev] [RELEASED] Python 3.5.0a2 is now available

Thanks for finding this. I'm following up on the issue of anyone else is having the same issue. As an aside, it'd be great to hear if it's worked for anyone at all :) Cheers, Steve Top-posted from my Windows Phone From: Ben Hoyt Sent: ‎

Re: [Python-Dev] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)

Paul Moore wrote: > I just thought I'd give installing Python 3.5 a go on my PC, now that > 3.5a2 has come out. I didn't get very far (see earlier message) but it > prompted > me to think about how I'd use it, and what habits I'd need to change. > > I'd suggest that the "what's new in 3.5" docume

Re: [Python-Dev] Windows installer - File associations in "per user" installs

It's a bug. File and assign to me please. Top-posted from my Windows Phone From: Paul Moore<mailto:p.f.mo...@gmail.com> Sent: ‎3/‎10/‎2015 3:35 To: Steve Dower<mailto:steve.do...@microsoft.com> Cc: Python Dev<mailto:python-dev@python.o

Re: [Python-Dev] libffi embedded in CPython

Zachary Ware wrote: > On Mar 25, 2015 4:22 AM, "Paul Moore" wrote: >> On a related note, is there any information available on how the >> "externals" repo is maintained? In particular, should things in there >> be exact copies of upstream, or is it OK to include extra data (in >> this case, the re

Re: [Python-Dev] Buildbot x86 XP-4 3.x doesn't compile anymore: drop it?

We discussed that a while back and decided the PEP was sufficient, but I'm not entirely opposed to a reminder. Probably best to repurpose this buildbot for 2.7. David has a Windows 8.1 one that should be marked as stable for 3.x (though it's not quite stable yet... AFAIK it's the only machine w

Re: [Python-Dev] Do we need to sign Windows files with GnuPG?

Larry Hastings wrote: > Steve's also changed the authentication process. His new installers rely on a > Windows digital signature technology called Authenticode where the signature > is > built right into the .exe file. Windows platforms will automatically > authenticate executables signed with Au

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

p-posted from my Windows Phone From: M.-A. Lemburg<mailto:m...@egenix.com> Sent: ‎4/‎3/‎2015 10:55 To: Steve Dower<mailto:steve.do...@microsoft.com>; Larry Hastings<mailto:la...@hastings.org>; Python Dev<mailto:python-dev@python.org>; python-commi

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

lto:python-dev@python.org>; python-committers<mailto:python-committ...@python.org>; Larry Hastings<mailto:la...@hastings.org>; Steve Dower<mailto:steve.do...@microsoft.com> Subject: Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG? So, AFAIU

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

At least that's the impression I'm getting, so I hope that helps clarify why I'm still not convinced it's that critical. Cheers, Steve Top-posted from my Windows Phone ____ From: M.-A. Lemburg<mailto:m...@egenix.com> Sent: ‎4/‎3/‎2015 15:38 T

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

igned email. Cheers, Steve Top-posted from my Windows Phone ________ From: Steve Dower<mailto:steve.do...@microsoft.com> Sent: ‎4/‎4/‎2015 7:25 To: Wes Turner<mailto:wes.tur...@gmail.com>; M. -A. Lemburg<mailto:m...@egenix.com> Cc: python-committers<mail

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

.. Top-posted from my Windows Phone From: Barry Warsaw<mailto:ba...@python.org> Sent: ‎4/‎4/‎2015 9:11 To: python-dev@python.org<mailto:python-dev@python.org> Subject: Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG? On Ap

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

Nathaniel Smith wrote: > And I suspect python-dev generally doesn't put much weight on the > extra effort required (release managers have all been using gpg for > decades, it's pretty trivial) I'm aware of this, but still don't see it as a reason to unnecessarily duplicate process. > or see any

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

ilto:robe...@robertcollins.net> Sent: ‎4/‎4/‎2015 21:59 To: Steve Dower<mailto:steve.do...@microsoft.com> Cc: M.-A. Lemburg<mailto:m...@egenix.com>; Larry Hastings<mailto:la...@hastings.org>; Python Dev<mailto:python-dev@python.org>; python-committers<mailto:python-committ

Re: [Python-Dev] Python3 Stable ABI

I don't see any obvious issues, but there may be some that don't need to be marked stable. Given that a mismatch here will cause build errors for users, I'm +1 on checking this in. Cheers, Steve Top-posted from my Windows Phone From: Zachary Ware

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.5.0a4 is now available

Paul Moore wrote: > On 20 April 2015 at 09:16, Larry Hastings wrote: >> There is now a third type of Windows installer for Python 3.5. In addition >> to the conventional installer and the web-based installer, Python 3.5 now >> has an embeddable installer designed to be run as part of a larger >>

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.5.0a4 is now available

Donald Stufft wrote: > Is this version statically linked by any chance? No, there's no change to the compilation process, so you can get exactly the same result by using the regular installer and copying the files around. Not sure if this is what you're referring to, but on Windows DLLs are alwa

Re: [Python-Dev] [python-committers] [RELEASED] Python 3.5.0a4 is now available

files themselves. Cheers, Steve Top-posted from my Windows Phone From: Paul Moore<mailto:p.f.mo...@gmail.com> Sent: ‎4/‎22/‎2015 5:48 To: Steve Dower<mailto:steve.do...@microsoft.com> Cc: Larry Hastings<mailto:la...@hastings.org>; Python Dev<ma

Re: [Python-Dev] PEP 492 quibble and request

The high-level answer to this is, like yield, the function temporarily returns all the way up the stack to the caller who intends to advance the iterator/async function. This is typically the event loop, and the main confusion here comes when the loop is implicit. If you explicitly define an ev

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

On 03Oct2017 0755, Antoine Pitrou wrote: On Tue, 3 Oct 2017 08:36:55 -0600 Eric Snow wrote: On Tue, Oct 3, 2017 at 5:00 AM, Antoine Pitrou wrote: On Mon, 2 Oct 2017 22:15:01 -0400 Eric Snow wrote: I'm still not convinced that sharing synchronization primitives is important enough to be wor

Re: [Python-Dev] Remove typing from the stdlib

On 03Nov2017 0915, Victor Stinner wrote: Hi, 2017-11-03 15:36 GMT+01:00 Guido van Rossum : Maybe we should remove typing from the stdlib? https://github.com/python/typing/issues/495 I'm strongly in favor on such move. I'm torn. If not having typing installed means you can't use "Any" or "O

Re: [Python-Dev] Remove typing from the stdlib

On 03Nov2017 1124, Guido van Rossum wrote: A side note (I'm reading all responses but staying out of the discussion): No static checker should depend on the *contents* of typing.py, since it's just a bunch of runtime gymnastics to allow types to be evaluated at runtime without errors, with a s

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

Since there is voting going on, -1 on changing the guarantees of `dict`. If ordering is important, OrderedDict is more explicit and more obvious to the over reading the code, even if the underlying implementation is identical. Good luck teaching people about why Python went from OrderedDict to

Re: [Python-Dev] Partial support of a platform

On 06Nov2017 0941, Victor Stinner wrote: [SNIP] But the question here is more about "partial" support. While changes are usually short, I dislike applying them to Python 2.7 and/or Python 3.6, until a platform is fully support. I prefer to first see a platform fully supported to see how much ch

Re: [Python-Dev] Python possible vulnerabilities in concurrency

On 15Nov2017 2053, Guido van Rossum wrote: On Wed, Nov 15, 2017 at 6:50 PM, Guido van Rossum > wrote: So far I learned one thing from the report. They use the term "vulnerabilities" liberally, defining it essentially as "bug": All programming languages contain con

Re: [Python-Dev] Python initialization and embedded Python

On 17Nov2017 1601, Victor Stinner wrote: In short, it means that using the "Python runtime" before it's initialized by _PyRuntime_Initialize() is now likely to crash. For example, calling PyMem_RawMalloc(), before calling _PyRuntime_Initialize(), now calls the function NULL: dereference a NULL po

  1   2   3   4   5   6   7   8   >