On 26 June 2014 23:59, Ben Hoyt wrote:
> Would love feedback on the PEP, but also of course on the proposal itself.
A solid +1 from me.
Some specific points:
- I'm in favour of it being in the os module. It's more discoverable
there, as well as the other reasons mentioned.
- I prefer scandir as
On 29 June 2014 12:08, Nick Coghlan wrote:
> This is what makes me wary of including lstat, even though Windows
> offers it without the extra stat call. Caching behaviour is *really*
> hard to make intuitive, especially when it *sometimes* returns data
> that looks fresh (as it on first call on PO
On 1 July 2014 14:00, Ben Hoyt wrote:
> 2) Nick Coghlan's proposal on the previous thread
> (https://mail.python.org/pipermail/python-dev/2014-June/135261.html)
> suggesting an ensure_lstat keyword param to scandir if you need the
> lstat_result value
>
> I would make one small tweak to Nick Coghl
tl;dr - I agree with your points and think that the original PEP 471
proposal is fine. The details here are just clarification of why my
proposal wasn't just "use PEP 471 as written" in the first place...
On 2 July 2014 13:41, Ben Hoyt wrote:
> 1) It's a nasty API to actually write code with. If
On 9 July 2014 02:08, Ben Hoyt wrote:
> Comments and votes, please!
+1 on option 1 (current PEP approach) at the moment, but I would like
to see how the error handling would look (suppose the function logs
files that can't be statted, and assumes a size of 0 for them). The
idea of a multi-level e
On 9 July 2014 13:48, Ben Hoyt wrote:
> Okay folks -- please respond: option #1 as per the current PEP 471, or
> option #2 with Ethan's multi-level thing tweaks as per the above?
I'm probably about 50/50 at the moment. What will swing it for me is
likely error handling, so let's try both approach
On 9 July 2014 14:22, Ben Hoyt wrote:
>> So maybe the onerror function should also receive the DirEntry object
>> - which will only have the name and full_name attributes, but that's
>> all that is needed.
>
> That's an interesting idea -- though enough of a deviation from
> os.walk()'s onerror th
On 9 July 2014 16:05, Victor Stinner wrote:
> The PEP says that DirEntry should mimic pathlib.Path, so I think that
> DirEntry.is_dir() should work as os.path.isir(): if the entry is a
> symbolic link, you should follow the symlink to get the status of the
> linked file with os.stat().
Would this
On 9 July 2014 14:22, Ben Hoyt wrote:
> One issue with option #2 that I just realized -- does scandir yield
> the entry at all if there's a stat error? It can't really, because the
> caller will except the .lstat attribute to be set (assuming he asked
> for type='lstat') but it won't be. Is effect
On 9 July 2014 17:35, Ethan Furman wrote:
> More specifically, if we go with choice 1 (no built-in error handling, no
> mutable DirEntry), how would I implement choice 2? Would I have to write my
> own CustomDirEntry object?
Having built-in error handling is, I think, a key point. That's where
#
On 9 July 2014 21:24, Victor Stinner wrote:
> Example where you may sometimes need is_dir(), but not always
> ---
> for entry in os.scandir(path):
> if ignore_entry(entry.name):
> # this entry is not interesting, lstat_result is useless here
> continue
> if entry.is_dir(): # fetch r
On 10 July 2014 01:23, Victor Stinner wrote:
>> As a Windows user with only a superficial understanding of how
>> symlinks should behave, (...)
>
> FYI Windows also supports symbolic links since Windows Vista. The
> feature is unknown because it is restricted to the administrator
> account. Try th
On 15 July 2014 13:19, Ben Hoyt wrote:
> Hmmm, perhaps. You suggest .full_name implies it's the absolute path,
> which isn't true. I don't mind .path, but it kind of sounds like "the
> Path object associated with this entry". I think "full_name" is fine
> -- it's not "abs_name".
Interesting. I ha
On 1 August 2014 02:54, Glenn Linderman wrote:
> I've no idea what you mean by "userland" in your suggestions above or below,
> but doesn't the Android environment qualify as a (multi-versioned) platform
> independently of its host OS? Seems I've read about an Android
> reimplementation for Window
On 7 August 2014 02:55, Antoine Pitrou wrote:
> pathlib is generally concerned with filesystem operations written in Python,
> not arbitrary third-party tools. Also it is probably easy to append the
> trailing slash in your command-line invocation, if so desired.
I had a use case where I wanted t
On 9 August 2014 06:08, Steven D'Aprano wrote:
> py> with Stopwatch():
> ... sum(carray) # carray is a numpy array of 7500 floats.
> ...
> 11250.0
> time taken: 52.659770 seconds
> py> with Stopwatch():
> ... numpy.sum(carray)
> ...
> 11250.0
> time taken: 0.161263 seconds
>
>
On 20 August 2014 07:53, Ben Finney wrote:
> "Stephen J. Turnbull" writes:
>
>> Marko Rauhamaa writes:
>> > Unix programmers, though, shouldn't be shielded from bytes.
>>
>> Nobody's trying to do that. But Python users should be shielded from
>> Unix programmers.
>
> +1 QotW
That quote is actu
On 21 August 2014 23:27, Cameron Simpson wrote:
> That's not "ASCII compatible". That's "not all byte codes can be freely used
> without thought", and any multibyte coding will have to consider such things
> when embedding itself in another coding scheme.
I wonder how badly a Unix system would br
On 23 August 2014 16:15, Oleg Broytman wrote:
> On Sat, Aug 23, 2014 at 06:02:06PM +0900, "Stephen J. Turnbull"
> wrote:
>> And that's the big problem with Oleg's complaint, too. It's not at
>> all clear what he wants
>
>The first thing is I want to understand why people continue to refer
>
On 23 August 2014 19:37, Oleg Broytman wrote:
> Unix takes the idea that everything is text and a stream of bytes to
> its extreme.
I don't really understand the idea of "text and a stream of bytes".
The two are fundamentally different in my view. But I guess that's why
we have to agree to differ
On 24 August 2014 04:27, Nick Coghlan wrote:
> One of those areas is the fact that we still use the old 8-bit APIs to
> interact with the Windows console. Those are just as broken in a
> multilingual world as the other Windows 8-bit APIs, so Drekin came up
> with a project to expose the Windows co
On 27 August 2014 09:09, Nick Coghlan wrote:
> There are two links to CPython issues from the project description:
>
> http://bugs.python.org/issue1602
> http://bugs.python.org/issue17620
>
> Part of the feedback on those was that as much as possible should be
> made available as a third party mod
On 27 August 2014 13:58, Neal Becker wrote:
> At least, pip should have the ability to alert the user to potential updates,
>
> pip update
>
> could list which packages need updating, and offer to perform the update. I
> think this would go a long way to helping with this problem.
Do you mean so
On 27 August 2014 14:46, Skip Montanaro wrote:
> it would be great if there was a way for it to tell me where on my
> system it found outdated package X. The --verbose flag tells me all
> sorts of other stuff I'm not really interested in, but not the
> installed location of the outdated package.
On 27 August 2014 10:46, Paul Moore wrote:
> If I come up with anything worth commenting on, I will do so (I assume
> that comments of the form "+1 me too!" are not needed ;-))
Nevertheless, here's a "Me, too". I've just been writing some PyPI
interrogatio
30 August 2014 03:44, Alex Gaynor wrote:
> Discussion points:
>
> * Disabling verification entirely externally to the program, through a CLI
> flag
> or environment variable. I'm pretty down on this idea, the problem you hit
> is
> that it's a pretty blunt instrument to swing, and it's almo
On 30 August 2014 16:22, Alex Gaynor wrote:
> The Windows certificate store is used by ``load_default_certs`
Cool, in which case this sounds like a good plan. I have no particular
opinion on whether there should be a global Python-level "don't check
certificates" option, but I would suggest that
On 31 August 2014 17:27, Christian Heimes wrote:
> It's very simple to trust a self-signed certificate: just download it
> and stuff it into the trust store.
"Stuff it into the trust store" is the hard bit, though. I have
honestly no idea how to do that. Or if it's temporary (which it likely
is)
On 31 August 2014 18:29, Antoine Pitrou wrote:
> If an application has special needs that require trusting a self-signed
> certificate, then it should expose a configuration setting to let users
> specify the cert's location.
I can't see how that would be something the application would know.
For
On 31 August 2014 19:37, Antoine Pitrou wrote:
> Well, it's certainly pip's responsibility more than Python's. What would
> Python do? Provide a setting that would blindly add a cert for all uses of
> httplib?
That's more or less my point, pip doesn't have that much better idea
than Python. I was
On 31 August 2014 21:15, Antoine Pitrou wrote:
> What do you call your local cert store?
I was referring to Christian's comment
> It's very simple to trust a self-signed certificate: just download it and
> stuff it into the trust store.
>From his recent response, I guess he meant the system sto
On 31 August 2014 23:10, Nick Coghlan wrote:
> Assuming sslcustomize was in site-packages rather than the standard library
> directories, you would also be able to use virtual environments with an
> appropriate sslcustomize module to disable cert checking even if the
> application you were running
On 31 August 2014 22:38, Victor Stinner wrote:
> This case is described as the use case #2 in the PEP, so it is supported. As
> written in the PEP, if you want to be notified of the signal, set a signal
> handler which raises an exception. For example the default signal handler
> for SIGINT raises
On 6 September 2014 13:47, Skip Montanaro wrote:
> Based on the comment in the second issue, it doesn't appear this will
> be resolved until 1.7 at the earliest.
The second issue is specific to setuptools, where we have some very
unpleasant hacks to deal with the setuptools/distribute mess.
Havi
On 24 September 2014 06:13, Tim Golden wrote:
> My only real misgiving here is that, for a few years, we'll need *three*
> versions installed to build the active branches: 2008 for 2.7; 2010 for 3.4;
> and 2014 for 3.5. Am I wrong?
Also, will 2014 express edition be able to fully build extensions
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
> right now. I can vouch for
On 24 September 2014 22:29, Steve Dower wrote:
>> In my experience pip --user works just fine also. We use it on our unmanned
>> media players successfully.
>
> This is good to know. Maybe we aren't as far away as we think.
Indeed. Moving towards having --user as the norm is definitely
something
On 25 September 2014 02:08, Antoine Pitrou wrote:
>> Indeed. Moving towards having --user as the norm is definitely
>> something we want to look at for pip. One of the biggest concerns is
>> how well-exercised the whole user site directory area is in practice.
>
> What do you mean by well-exercise
On 25 September 2014 16:43, Donald Stufft wrote:
> Basically people have Python in a ton of different configurations and it’s
> hard to figure out if —user will work out of the box in all of them or not.
I guess that "Using the python.org Python installer on Windows" is a
limited enough subset th
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 access to that directory because you're not admin or because
> it's on
On 25 September 2014 18:13, Steve Dower wrote:
> Again, this isn't trivial to get right. The design for the elevation model
> seems to have focused mainly on GUI rather than console, probably assuming
> that people who need to elevate from the console will elevate the shell
> itself (this is a
On 26 September 2014 01:38, Donald Stufft wrote:
> Either way I'm fairly commited to making --user the default, the only
> question
> on my mind is what exactly does that look like (e.g. does root get --user by
> default?) and how we get from where we are now to that point. I think that
> raising
On 26 September 2014 14:31, Donald Stufft wrote:
> Yea, I think we throw an error when you use —user inside a virtual
> environment.
So if --user became the default, what would happen? I'd like pip
inside a virtualenv to install into the environment without needing a
--system flag. Is that th
On 26 September 2014 19:01, Steve Dower wrote:
> Microsoft has released a compiler package targeting Python 2.7 (i.e. VC9).
> We've produced this package to help library developers build wheels for
> Windows, but also to help users unblock themselves when they need to build C
> extensions thems
On 27 September 2014 06:08, Terry Reedy wrote:
> Pip on Windows should act like a normal Windows program. If I install
> Python for all users, I expect pipped packages to be installed for all users
> too, unless I specify otherwise. If installation (for all users) requires
> admin privileges, I
On 27 September 2014 14:01, Nick Coghlan wrote:
> I personally believe we should treat handling both this and the SDK
> compilers properly as a platform-enablement bug for distutils and
> ensure they work properly with the currently maintained branches
> (including 2.7).
+1
__
On 26 September 2014 19:01, Steve Dower wrote:
> You can install the package without requiring administrative privileges and,
> with the latest version of setuptools (when it releases), use tools such as
> pip, wheel, or a setup.py file to produce binaries on Windows.
>From the setuptools chang
On 10 October 2014 01:29, Victor Stinner wrote:
> What about the Python stable ABI? Would it be broken if we use a
> different compiler?
>
> What about third party Python extensions?
>
> What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.?
The key point for me is that any supp
On 10 October 2014 10:50, Victor Stinner wrote:
> Is MinGW fully compatible with MSVS ABI? I read that it reuses the
> MSVCRT, but I don't know if it's enough. I guess that a full ABI
> compatibility means more than just using the C library, calling
> convention and much more.
MinGW can be made t
On 10 October 2014 15:36, Tres Seaver wrote:
> On 10/10/2014 05:26 AM, Larry Hastings wrote:
>> IMO the benefit from supporting other compilers on Windows is
>> negligible
>
> Did you miss the OP's point that OpenBLAS cannot be compiled with MSVC,
> raising the priority of mingw-buildable extensio
On 10 October 2014 17:28, Mark Lawrence wrote:
> There are 55 open issues on the bug tracker with mingw in the title.
It's not easy to tell, but on a spot check a fair proportion of them
seem to be about distutils/extension builds. And a lot of the rest are
related to http://bugs.python.org/issue
On 11 October 2014 19:32, Nathaniel Smith wrote:
> The bigger problem is that getting a usable DLL at all is a serious
> challenge. Some of the issues we deal with: (a) the classic, stable mingw
> has no 64-bit support, (b) the only portable way to compile fortran (f2c)
> only works for the ancien
On 25 October 2014 21:50, Steve Dower wrote:
> 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 MSV
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 build, and so testing it with it would not
>> certify that your code would actually be
On 26 October 2014 13:12, Tony Kelman wrote:
> Only cross-compilation and the build system in the above list are relevant
> to CPython, but I hope I have convinced you, Paul Moore, etc. that there are
> real reasons for some groups of users and developers to prefer MinGW-w64
> ove
On 26 October 2014 17:59, Tony Kelman wrote:
> Ensuring compatibility with CPython's
> chosen msvcrt has made that work even more difficult for them.
Ensuring compatibility with CPython's msvcrt is mandatory unless you
want to create a split in the community over which extensions work
with which
On 26 October 2014 14:28, Ray Donnelly wrote:
> I like this idea. To reduce the workload, we should probably pick
> Python3 (at least initially)?
Aren't the existing patches on the tracker already for Python 3.5+?
They should be, as that's the only version that's likely to be a
possible target (u
On 26 October 2014 23:24, Tony Kelman wrote:
> I want, and in many places *need*, an all-MinGW stack.
OK, I'm willing to accept that statement. But I don't understand it,
and I don't think you've explained why you *need* your CPython
interpreter to be compiled with mingw (as opposed to a number o
On 26 October 2014 23:11, Ray Donnelly wrote:
> I don't know where this "ABI compatible" thing came into being;
Simple. If a mingw-built CPython doesn't work with the same extensions
as a MSVC-built CPython, then the community gets fragmented (because
you can only use the extensions built for you
On 27 October 2014 12:30, Nick Coghlan wrote:
>> OK, I'm willing to accept that statement. But I don't understand it,
>> and I don't think you've explained why you *need* your CPython
>> interpreter to be compiled with mingw (as opposed to a number of other
>> things you might need around building
On 26 October 2014 01:05, Ray Donnelly wrote:
> Download and run:
> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-x86_64-20141003.exe/download
Sending this offline because I really don't want to start up another
extended debate, but is there a version of this that I can use that
_
Please ignore this. I hit the wrong button.
On 27 October 2014 14:18, Paul Moore wrote:
> On 26 October 2014 01:05, Ray Donnelly wrote:
>> Download and run:
>> http://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-x86_64-20141003.exe/download
>
> Sending this off
On 26 October 2014 23:44, Paul Moore wrote:
> On 26 October 2014 23:11, Ray Donnelly wrote:
>> I don't know where this "ABI compatible" thing came into being;
>
> Simple. If a mingw-built CPython doesn't work with the same extensions
> as a MSVC-built CPyth
On 27 October 2014 18:47, Case Van Horsen wrote:
> I've managed to build gmpy2 (which requires GMP, MPFR, and MPC
> libraries) using msys2. I've detailed the steps (hacking) at:
>
> https://code.google.com/p/gmpy/source/browse/trunk/msys2_build.txt
Thanks for this. I don't have the time to read y
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 CPython
> itself to be built in a
On 27 October 2014 21:19, Steve Dower wrote:
>> No, we've been trying to establish whether the patches to build with mingw
>> were
>> intended to produce such a compatible build. It's not clear, but so far it
>> seems
>> that apparently that is *not* the intent (and worse, mingw-w64 may not even
On 28 October 2014 14:46, Tony Kelman wrote:
> Patches should be done well and accompanied with proper documentation
> so new functionality is fully reproducible. If that's what's holding
> up review, comments in the bug threads indicating as much would be
> helpful.
Typically that tends to be ex
On 29 October 2014 15:31, Nathaniel Smith wrote:
>> You can use Express editions of Visual Studio.
>
> IIUC, the express edition compilers are 32-bit only, and what you actually
> want are the "SDK compilers":
> https://github.com/cython/cython/wiki/64BitCythonExtensionsOnWindows
>
> These are fre
On 29 October 2014 20:26, Donald Stufft wrote:
> This sounds like something good for packaging.python.org
Yeah, I wondered about that. I'll work up a patch for that. But the
more I think about it, it really is trivial:
- For non-free MSVC, install the appropriate version, and everything just wor
On 29 October 2014 22:19, Ethan Furman wrote:
>> Yeah, I wondered about that. I'll work up a patch for that. But the
>> more I think about it, it really is trivial:
>
> I am reminded of an interview question I was once asked which was prefaced
> with: "Here's an easy one..."
>
> My reply was, if y
On 29 October 2014 23:02, Ethan Furman wrote:
> On 10/29/2014 03:46 PM, Paul Moore wrote:
>>
>> On 29 October 2014 22:19, Ethan Furman wrote:
>>>
>>>
>>>- where one should be at when one starts the compile process
>>
>>
>> I don&#
On 29 October 2014 23:22, Nathaniel Smith wrote:
>> Yeah, I know what you mean. My take on this is that I agree it's not
>> easy if you don't know and can't get access to the information, but if
>> you can, there's very little to it.
>
> That's great, but yeah. In case it helps as a data point, I
On 29 October 2014 23:49, Steve Dower wrote:
> "For the paid versions, I'm going to assume that anyone who paid for a
> compiler and doesn't know where their copy is, probably can't be
> helped ;-)"
>
> You could link to visualstudio.com for the trial versions, and maybe to a
> page/post about the
On 15 November 2014 00:12, Vincent Povirk wrote:
> My end goal is to be able to package a Python application such that an
> end-user on Windows (who doesn't know anything about Python) can
> easily install it, without either of us having to think about how all
> the dependencies are going to get t
On 15 November 2014 10:54, Nathaniel Smith wrote:
> On 15 Nov 2014 10:10, "Paul Moore" wrote:
>>
>> > Incidentally, it would be really useful if python.org provided stable
>> > url's that always redirected to the latest .msi installers, for
>> >
On 15 November 2014 15:17, Benjamin Peterson wrote:
> On Sat, Nov 15, 2014, at 05:54, Nathaniel Smith wrote:
>> On 15 Nov 2014 10:10, "Paul Moore" wrote:
>> >
>> > > Incidentally, it would be really useful if python.org provided stable
>> >
On 15 November 2014 15:40, Paul Moore wrote:
> On 15 November 2014 15:17, Benjamin Peterson wrote:
>> On Sat, Nov 15, 2014, at 05:54, Nathaniel Smith wrote:
>>> On 15 Nov 2014 10:10, "Paul Moore" wrote:
>>> >
>>> > > Incidentally,
On 17 November 2014 19:23, Ned Deily wrote:
> Paul Moore wrote:
>> I don't know if this got lost in the other messages in this thread,
>> but *is* there a stable URL for "the latest Python 3.4 MSI for Windows
>> amd64" (or similar)?
>
> AFAIK, no,
On 21 November 2014 13:53, Chris Angelico wrote:
> On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
> wrote:
>> Also, the proposal breaks a reasonably useful pattern of calling
>> next(subiterator) inside a generator and letting the generator terminate
>> when the data stream ends. Here is a
On 21 November 2014 15:58, Steven D'Aprano wrote:
>> > def izip(iterable1, iterable2):
>> > it1 = iter(iterable1)
>> > it2 = iter(iterable2)
>> > while True:
>> > v1 = next(it1)
>> > v2 = next(it2)
>> > yield v1, v2
>>
>> Is it obviou
On 23 November 2014 at 15:25, Chris Angelico wrote:
> Thank you, it's nice to have a successful one to counterbalance the
> "failure" of PEP 463. (Which, incidentally, never actually got a
> resolution. It's still showing up as 'Draft' status.)
I think it's worth pointing out that both this and P
On 24 November 2014 at 10:20, Nick Coghlan wrote:
> Another aspect that can be somewhat annoying is the terminology
> conflict between branches in the git sense and bookmarks vs named
> branches in the Mercurial sense.
This is probably the thing that hurts me most in git/hg translation.
In git, I
On 26 November 2014 at 16:24, Isaac Schwabacher wrote:
> This actually leads to a good example of why the PEP is necessary:
[...]
Oh! If that's the current behaviour, then it probably needs to go into
the PEP as a motivating example. It's far more convincing than most of
the other arguments I've
On 26 November 2014 at 17:19, Guido van Rossum wrote:
> It's hard to use as an example because the behavior of contextlib is an
> integral part of it -- currently for me the example boils down to "there is
> a bug in contextlib"
Hmm, fair point. I was assuming that the bug in contextlib can't be
On 29 November 2014 at 23:27, Donald Stufft wrote:
> In previous years there was concern about how well supported git was on
> Windows
> in comparison to Mercurial. However git has grown to support Windows as a
> first
> class citizen. In addition to that, for Windows users who are not well
> a
On 30 November 2014 at 16:08, Donald Stufft wrote:
>> On Nov 30, 2014, at 7:31 AM, Paul Moore wrote:
>>
>> On 29 November 2014 at 23:27, Donald Stufft wrote:
>>> In previous years there was concern about how well supported git was on
>>> Windows
>>>
On 19 December 2014 at 08:26, Maciej Fijalkowski wrote:
> I would like to add that "not doing anything" is not a good strategy
> either, because you accumulate bugs that get fixed upstream (I'm
> pretty sure all the problems from cpython got fixed in upstream
> libffi, but not all libffi fixes mad
On 3 January 2015 at 23:34, Steve Dower wrote:
> 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-installe
On 4 January 2015 at 22:56, Steve Dower wrote:
>> Also, what happens now with setting PATH? Is Python (and the scripts
>> directory) added to PATH by default? If so, what happens when you
>> install 2 versions of Python?
>
> Yes, and in general the later installed version will win and system-wide
On 5 January 2015 at 01:20, Steve Dower wrote:
> I think this means the best way to make multiple versions work properly is to
> rename python.exe to python3.5.exe, then install the launcher as python.exe
> and python3.exe (with some logic to look at its own name) so it can resolve
> the right
On 5 January 2015 at 08:40, Donald Stufft wrote:
>> The biggest problem here is that py.exe doesn't help in the slightest
>> with script wrappers like pip.exe, virtualenv.exe, py.test.exe,
>> ipython.exe ... I've actually drifted away from using py.exe because
>> of this. Having just the interpret
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.
On 5 January 2015 at 17:09, Steve Dower wrote:
> Paul Moore wrote:
>> Steve is in essence s
On 5 January 2015 at 21:47, Steve Dower wrote:
> 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 wh
On 6 January 2015 at 13:56, Nick Coghlan wrote:
>> If we can't get PATH sorted out, we need to do something about this,
>> IMO. I don't know what (believe me, I tried to find a solution)
>> unfortunately.
>
> I personally believe we should aim to make the "Windows" section in
> the above link univ
On 15 January 2015 at 22:26, Zachary Ware wrote:
> Extension building in general is still a mess on Windows, I hope the
> links above are enough to get you going again!
For building extensions, I have a powershell script that, starting
with a clean machine, downloads and installs everything neede
On 26 January 2015 at 18:12, Antoine Pitrou wrote:
> I have to agree with Barry. While the following is obvious even without
> having ever used it:
>
> a, b, *c = range(5)
>
> the following makes me scratch my head and I can't seem to guess what
> the *intent* is - which is very problematic when
On 10 February 2015 at 00:29, Neil Girdhar wrote:
>> > function(**kw_arguments, **more_arguments)
>> If the key "key1" is in both dictionaries, more_arguments wins, right?
>
>
> There was some debate and it was decided that duplicate keyword arguments
> would remain an error (for now at least). I
On 10 February 2015 at 01:48, Donald Stufft wrote:
> I am really really -1 on the comprehension syntax.
[... omitting because gmail seems to have messed up the quoting ...]
> I don’t think * means “loop” anywhere else in Python and I would never
> “guess” that [*item for item in iterable] meant
tl;dr - Having a shared per-user scripts directory on Windows
(%APPDATA%/Python/Scripts) causes a number of potential issues when
users install the same package in multiple Python versions. I'd like
to suggest that this be changed to a versioned directory
(%APPDATA%/PythonXY/Scripts) to match all o
On 10 February 2015 at 13:34, Nick Coghlan wrote:
> I was actually surprised it didn't already work that way, given that almost
> everything else on Windows is version specific.
That's actually a point I missed making. While I wouldn't class myself
as "typical", when I went looking for the user-s
1 - 100 of 1862 matches
Mail list logo
