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
actual location of the Python version they need.
Maybe I'm more
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
Paul Moore wrote:
On 12 February 2015 at 15:37, Steve Dower steve.do...@microsoft.com 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 is file associations
-dev@python.org
Subject: Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
On 10 February 2015 at 14:13, Steve Dower steve.do...@microsoft.com wrote:
The installer will also need some changes to add it to PATH, which should be
fairly straightforward, but ping me if you need/want
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. IIUC, you aren't really
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
Paul Moore wrote:
On 10 February 2015 at 20:50, Paul Moore p.f.mo...@gmail.com wrote:
On 10 February 2015 at 17:45, Steve Dower steve.do...@microsoft.com wrote:
This is yet another attempt to try and change user behaviour, which I'm not
thrilled
about, but I'm really starting to feel
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
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 khalidmailto:sy...@pacificloud.com
Sent:
Victor Stinner wrote:
2015-01-15 22:39 GMT+01:00 Ryan Gonzalez rym...@gmail.com:
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
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 upgrade install first uninstalls
Victor Stinner wrote:
2015-01-13 23:18 GMT+01:00 Steve Dower steve.do...@microsoft.com:
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
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
Victor Stinner wrote:
2015-01-13 23:46 GMT+01:00 M.-A. Lemburg m...@egenix.com:
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
On Sat, Jan 10, 2015 at 3:28 AM, Nick Coghlan ncogh...@gmail.com 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
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 files - it
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
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 a
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
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? Suppose someone installs 3.5 globally, then
installs
3.6
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
Chris Angelico wrote:
On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower steve.do...@microsoft.com 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.5 vs 3.6 should
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
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's
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 Warsawmailto:ba...@python.org
Sent: 12/13/2014 7:19
To:
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
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
*
Antoine Pitrou wrote:
On Fri, 21 Nov 2014 13:29:11 +
Brett Cannon br...@python.org 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
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 Goldenmailto:m...@timgolden.me.uk
Sent: 11/14/2014 7:11
To: Shorya
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
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
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
David Bolen wrote:
Steve Dower steve.do...@microsoft.com 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 add
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.
Python is
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 with Windows
Antoine Pitrou wrote:
On Wed, 29 Oct 2014 11:07:53 -0400
Tres Seaver tsea...@palladion.com 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
Express and
everything just works.
I would suggest
- where to get these packages
Conceded. Working out how to point people at stuff on MSDN is a
challenge, things seem to move around. Maybe Steve Dower could help
here with canonical URLs for some of them (IIRC, he provided one for
the VS
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,
Paul Moore wrote:
On 27 October 2014 20:45, Greg Ewing greg.ew...@canterbury.ac.nz 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
Ray Donnelly wrote:
On Sat, Oct 25, 2014 at 11:44 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 25 October 2014 23:22, Chris Angelico ros...@gmail.com wrote:
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
My point is that your Windows build would not have the same
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 Bolenmailto:db3l@gmail.com
(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)
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
Ray Donnelly wrote:
On Sun, Oct 26, 2014 at 1:45 AM, Steve Dower steve.do...@microsoft.com
wrote:
Ray Donnelly wrote:
Also, where are the publicly accessible specifications and other technical
descriptions that MinGW-w64 would need to implement strong binary
compatibility with MSVC
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
from my Windows Phone
From: Sturla Moldenmailto:sturla.mol...@gmail.com
Sent: 10/11/2014 9:59
To: python-dev@python.orgmailto:python-dev@python.org
Subject: Re: [Python-Dev] Status of C compilers for Python on Windows
Steve Dower steve.do...@microsoft.com wrote
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
/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 easy and also covers Python 2.6 and 3.3.
The compiler installer can't set the keys that distutils
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 blist
: Christian Heimesmailto:christ...@python.org
Sent: 9/27/2014 7:19
To: python-dev@python.orgmailto: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 advance notice since people on this list
-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 steve.do...@microsoft.com wrote:
Hi all,
(This is advance notice since people on this list will be interested.
Official announcements are coming when setuptools
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
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
Chris Angelico wrote:
On Thu, Sep 25, 2014 at 6:50 AM, Steve Dower steve.do...@microsoft.com
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
(assuming you have
them
Paul Moore wrote:
On 25 September 2014 17:05, Steve Dower steve.do...@microsoft.com 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 access to that directory because
Paul Moore wrote:
On 24 September 2014 14:16, Mike Miller python-...@mgmiller.net 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
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 to
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 for credit
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 editions
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 month
...@gmail.commailto:ncogh...@gmail.com wrote:
On 24 September 2014 03:05, Steve Dower
steve.do...@microsoft.commailto:steve.do...@microsoft.com wrote:
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
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).
It
Victor Stinner wrote:
2014-07-20 18:50 GMT+02:00 Antoine Pitrou anto...@python.org:
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,
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 compile
those
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
, schrieb Steve Dower:
You'll only need to rebuild the _ssl and _hashlib extension modules
with the new OpenSSL version. The easiest way to do this is to build
from source (which has already been updated for 1.0.1h if you use the
externals scripts in Tools\buildbot), and you should just be able
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
at
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 Ewingmailto:greg.ew...@canterbury.ac.nz
Sent: 6/14/2014 16:19
To:
To: Steve Dowermailto:steve.do...@microsoft.com
Cc: Greg Ewingmailto:greg.ew...@canterbury.ac.nz;
python-dev@python.orgmailto:python-dev@python.org
Subject: Re: [Python-Dev] Criticism of execfile() removal in Python3
On 15 Jun 2014 09:37, Steve Dower
steve.do...@microsoft.commailto:steve.do
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
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 on pybench.py and 10% size reduction in
python35.dll
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.py and 10% size
reduction in python35.dll. I'm
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
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 a
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 real
Stefan Krah wrote:
Stefan Krah ste...@bytereef.org 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
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com 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!! Actually
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
side-by-side on the
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
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 incorrect?
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 list
...@pitrou.net;
python-dev@python.orgmailto:python-dev@python.org
Subject: Re: [Python-Dev] devguide: Add myself to developer log and as a
Windows expert.
I don't think you meant me for helping to build Windows binaries. :)
On Sunday, May 11, 2014 9:58:16 AM, Steve Dower
steve.do
expert.
On Sun, 11 May 2014 06:04:56 +0200 (CEST)
steve.dower python-check...@python.org wrote:
http://hg.python.org/devguide/rev/8d5d1f2c7378
changeset: 698:8d5d1f2c7378
user:Steve Dower steve.do...@microsoft.com
date:Sat May 10 21:01:39 2014 -0700
summary:
Add myself
Brian Curtin wrote:
On Fri, May 9, 2014 at 12:00 PM, Zachary Ware
zachary.ware+py...@gmail.com wrote:
On Thu, May 8, 2014 at 4:20 PM, Zachary Ware
zachary.ware+py...@gmail.com wrote:
I updated the 2.7 buildbot scripts to pull in Tcl/Tk 8.5.15 a couple
of weeks ago (see
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
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 an
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
about an installer default, a setting that would still
/CPython, this is so untrue that it looks to me like an excuse to take
without giving back. This might be 'unfair and incorrect', but it is my
perception.
On 4/14/2014 11:32 AM, Steve Dower wrote:
[...]
However unfair
and incorrect it may be, there is a perception in some
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
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
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
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
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
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
that
call os.dup(fd), PyNumber_AsSsize_t
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 be more of a
feature than we'd want
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 (majority?) of packages
with extension modules
some macros may also have to become exported
functions. After that I don't think there are any ways to accidentally cause
issues; you'd really have to be doing strange things (such as passing pointers
to CRT types between extensions via capsules).
I've cc'ed Steve Dower directly, as he's the best
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 from
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
From: Steven D'Aprano
On Fri, Sep 13, 2013 at 04:26:06AM +, Steve Dower wrote:
Last I checked, looking up in the instance dict us exactly what it
does. Even the example you posted is doing that.
The example from the PEP shows:
return cls.__dict__[name]
not self.__dict__[name
601 - 700 of 715 matches
Mail list logo
