Paul Moore added the comment:
One further thought - the installer can't create the user scripts directory if
you're doing an all-users install, that's sort of the point of "all users". It
could do so for a per-user install, but then there would be an inconsistency
tha
Paul Moore added the comment:
Here is a patch to fix the issue.
--
keywords: +patch
Added file: http://bugs.python.org/file38659/addpath.patch
___
Python tracker
<http://bugs.python.org/issue16
Paul Moore added the comment:
Cool. I'll try to set up a test (it's not covered by the testsuite AFAICT) on a
VM or something, just to confirm I haven't broken anything.
--
___
Python tracker
<http://bugs.pyt
Paul Moore added the comment:
One further thought. This is a change in behaviour (albeit to a script in
Tools), so I'm inclined to say it's a new feature for 3.5, rather than a bugfix
to be backported to 2.7 and 3.4.
For users of 2.7/3.4, the workaround is simply to rerun the s
Paul Moore added the comment:
There's actually a bug in the pre-3.5 script beyond the "does the directory
exist" check. The code is
if hasattr(site, "USER_SITE"):
userpath = site.USER_SITE.replace(appdata, "%APPDATA%")
userscripts = os.pa
Paul Moore added the comment:
I think the main (only?) user of having sys.path entries in the registry is
pywin32. It might be worth asking them if they can switch to a more mainstream
approach, and then maybe the whole registry finder thing can be removed
completely.
--
nosy
Paul Moore added the comment:
The correct solution to this issue now is to install the Microsoft supplied
"Visual C++ Compiler for Python 2.7" package (available as a free download from
MSDN). That has all the components needed to build 32 and 64-bit extensions.
Your setup.py ne
Paul Moore added the comment:
I believe it's the way it is because Python follows the Standard Decimal
Specification, which includes tests for conformance to the current formatting
behaviour.
--
nosy: +paul.moore
___
Python tracker
Paul Moore added the comment:
It returns True.
--
___
Python tracker
<http://bugs.python.org/issue23808>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue14243>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
The patch looks good to me.
rhettinger: I'm not sure I see a problem with the doc changes in the latest
patch - noting that commonprefix may return an invalid path is fine, and what
the current docs say. Directing people to commonpath if they don't wa
Paul Moore added the comment:
Assuming new code should be using pathlib, I agree this should probably be
closed now as obsolete.
One proviso - pathlib objects don't take a bytestring path in the constructor.
If there's a need for a low-level splitpath taking bytes objects, there may
Paul Moore added the comment:
A few minor review comments. Nothing substantial, tbh. Looks good.
--
___
Python tracker
<http://bugs.python.org/issue23731>
___
___
Paul Moore added the comment:
On Windows, subprocess.Popen has to convert an argument list to a command line
(because that's what the OS expects for CreateProcess). It does so internally,
using subprocess.list2cmdline, which follows the quoting rules for the MS C
runtime (because that&#
Paul Moore added the comment:
Presumably this would just be a case of moving "activate" from
venv/scripts/posix to venv/scripts/common? I don't think including csh or fish
scripts on Windows is worthwhile...
Attached is a patch on that basis. I didn't see any tests for
Paul Moore added the comment:
Doh. That latter approach (a RawIOBase implementation) is *precisely* what
win_unicode_console does for stdout (using utf16le rather than utf8 as that's
the native Windows encoding used by WriteConsole). So (a) yes it would work,
and (b) it has al
New submission from Paul Moore:
Console code page issues are a consistent source of problems on Windows. It
would be nice, given that the Windows console has Unicode support, if Python
could write the full range of Unicode to the console by default.
The MSVC runtime appears to have a flag
Paul Moore added the comment:
Generally, my understanding is that the console does pretty badly at supporting
Unicode via the normal WriteFile APIs and the "code page" support (mainly
because support for the UTF8 code page is rubbish). But the WriteConsole API
does, I believe, h
Paul Moore added the comment:
My proof-of-concept attempt to use _O_U8TEXT resulted in some very bizarre
behaviour - odd buffering of the interactive interpreter output and what appear
to be Chinese characters being displayed for normal (ASCII) interactions.
I suspect there is some oddity
Paul Moore added the comment:
Hmm, I thought everyone was too scared to change distutils. Brave man :-)
More seriously, I'm not sure I can comment usefully, I don't really understand
any of this code, and the changes are pretty big. I guess the biggest risk is
that someone directly
Paul Moore added the comment:
Sounds fair enough to me. I guess you have most of the bases covered, and
AFAIK, we've never actually supported building extensions with anything other
than the compiler python.org uses, so that seems a reasonable view to take.
Apart from the numpy/scipy
Paul Moore added the comment:
Is it not reasonable to simply say that implementations of numbers.Rational
which allow the numerator and denominator to have types for which true division
doesn't return a float, have to provide their own implementation of __float__()?
It's cert
Paul Moore added the comment:
Alternatively, return int(self.numerator) / int(self.denominator). After all, a
fraction whose numerator can't be represented as a Python (unlimited precision)
integer is a pretty odd sort of fraction...
--
___
P
Paul Moore added the comment:
Link to the SO answer? Does it explain *why* this is a requirement?
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue24
Paul Moore added the comment:
That seems to merely be saying that each threading.local() object is distinct,
so if you want to share threadlocal data between workers, creating local
objects won't work.
I think I see what the confusion is (although I can't quite explain it yet,
I&
Paul Moore added the comment:
I should also say, I'll try to work up a doc patch for this, once I've got my
head round how to explain it :-)
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
You're right, the SO answer is simply wrong. I've posted a (hopefully clearer)
answer. If anyone wants to check it for accuracy, that'd be great.
Agreed this can probably be closed as "not a bug". On first reading, I thought
the docs co
Paul Moore added the comment:
On 21 April 2015 at 23:11, Ethan Furman wrote:
> Hmmm... could my problem be that even though function locals are thread-safe,
> the globals are not, so trying to create a threading.local via a global
> statement was clobbering other threading.local
Paul Moore added the comment:
As described. this seems to be a Windows-only feature (it's replacing a
registry lookup with a config file alongside the Python DLL).
So I'm not sure I understand Nick's comment - Nick, are you suggesting this
should be a cross-platform feature? If
Paul Moore added the comment:
I think the documentation is fine:
"""
The key corresponding to each item in the list is calculated once and then used
for the entire sorting process.
"""
This corresponds with the standard "decorate-sort-undecorate" appr
Paul Moore added the comment:
On 29 April 2015 at 19:42, Sergey B Kirpichev wrote:
>> It's a common computer science technique
>
> Could you provide any language that avoid this optimization?
>
> Here is Perl 5:
> http://perl5.git.perl.org/perl.git/blob/HEAD:/pp_sort
New submission from Paul Moore:
Although the new generator methods introduced in PEP 342 are documented, the
term "coroutine" is not defined anywhere. In particular, the fact that Python
coroutines work in conjunction with an event loop rather than transferring
control directly be
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue23572>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue24127>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Install is noted as being on Windows 10 tech preview. I don't have a Windows 10
installation present, but the similar issues reported in Wine seem to be
related to limited support in Wine for Windows job objects. Have there been any
changes to Job object su
Paul Moore added the comment:
One issue with your code - what would you expect str(test) to produce?
"dir/test.txt" or "dir\test.txt"? That's the point of the "flavour" - is it a
Windows path or a Unix path?
Agreed that an easier method of creating Path s
Paul Moore added the comment:
It looks like something in the QueryInformationJobObject API has changed with
Windows 10. The code says:
ok = QueryInformationJobObject(job, JobObjectExtendedLimitInformation,
&info, sizeof(info), &rc);
if (!o
Paul Moore added the comment:
Cheers. I missed a bit of code, job comes from "job = CreateJobObject(NULL,
NULL)" so it shouldn't be NULL unless that call failed.
Rather than speculate though, I'll leave it with you.
Paul Moore added the comment:
For that type of function, I'd suggest you use a standalone function rather
than subclassing and methods or operator overloading. You don't gain enough to
be worth the complexity of having to subclass path objects. And duck typing
means that your func
Paul Moore added the comment:
Adding Jason Coombs and Vinay Sajip, as if this needs a fix to the launcher
code, then the launchers used by distlib and setuptools (for exe wrappers of
console entry points) will need to be changed as well.
It would be really useful if all 3 projects used a
Paul Moore added the comment:
I have no problem with that - it's a style choice certainly.
As I said, I'd like to see simpler subclassing of pathlib objects. I just think
it'll be quite hard to do (given the complexities of classes for Windows/Unix
as well as pure and concret
Paul Moore added the comment:
> Are you the author of path lib ?
Nope, that's Antoine.
--
___
Python tracker
<http://bugs.python.org/issue24132>
___
_
Paul Moore added the comment:
> What is the good way to propose a patch ?
If you have a patch, attach it here, and it will get reviewed.
--
___
Python tracker
<http://bugs.python.org/issu
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue17620>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue1602>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I agree with Steve, we shouldn't be constrained to preserve all the
undocumented internals of distutils - doing that in the past is what has made
distutils essentially unmaintainable.
I don't think there's a concrete example of real code that wi
Paul Moore added the comment:
You should add docs for the new method, as well.
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue24195>
___
___
Paul Moore added the comment:
Just as a note - to test a pure Pthon patch like this, you can apply the patch
to your installed Python 3.4 installation, and just run the test using that.
There should be no need to build your own Python.
>python C:\Apps\Python34\Lib\t
Paul Moore added the comment:
So just to be clear - this proposal would *only* affect the tagged filename
used for loading ".pyd" files? (And in practice, the untagged form is normally
used for Windows .pyd files anyway...)
--
nosy: +
Paul Moore added the comment:
Multiprocessing works by firing up additional processes. Those processes won't
have access to functions defined in the interactive interpreter.
Can you reproduce this problem in a standalone script? I suspect not, but if
you can please post the script
Paul Moore added the comment:
OK, if it's not reproducible in a standalone script, I'll close this as it's
expected behaviour.
Correcting the typo in your script (__name__ == "__main__"), I ran it and it
worked as expected on my system:
>type multi.py
import mult
Paul Moore added the comment:
I'm not a heavy user of concurrent.futures, so I don't have a strong opinion.
I've never felt a need for this function, though, so I guess I'm -0. A recipe
in the docs would be good, though.
--
__
Paul Moore added the comment:
I presume the copy method is intended as a file copy, not for copying the
object. But calling the method copy() is likely to be confusing, precisely as
happened here :-)
--
nosy: +paul.moore
___
Python tracker
<h
Paul Moore added the comment:
Supporting mingw building of extensions has always been a complicated process,
mainly because there appear to be many variants of mingw (and in particular,
there seem to be multiple 64-bit builds). Add to this the fact that cygwin is
sometimes used as a cross
Paul Moore added the comment:
Not at all. Mingw support is important for the scientific community, as I
understand it, and I'm willing to help there if I can. That won't be at the
cost of other areas I can contribute to, but I consider packaging as much my
area of expertise as Win
Paul Moore added the comment:
Ruben,
Thanks for the detailed explanations. Just to be clear, I am *not* the person
that will take this aspect of the process forward - that will be the community
of people building (or wanting to build) extensions for Python with mingw. I
don't know if
Paul Moore added the comment:
> If there is no interest in having a (community-supported, semi-
> official) GCC-built Python on Windows, I'm sure something else
> can also be worked out, which would include stripping the current
> dinosaur -mno-cygwin code which is what this b
Paul Moore added the comment:
On 19 May 2015 at 17:09, Руслан Ижбулатов wrote:
> 3) Use MSVC for CPython and MinGW-w64 for the rest and somehow ensure that
> FDs are converted when passing the CRT barrier. And stat structs as well. And
> everything else that differs. This is
Paul Moore added the comment:
==
ERROR: test_read_only_directory (test.test_tempfile.TestMkdtemp)
--
Traceback (most recent call last):
File "C:\Work\Pro
Paul Moore added the comment:
Fantastic news, thanks for the feedback.
Closing this as a third party issue.
--
resolution: -> third party
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Paul Moore added the comment:
Works fine with the new patch:
>.\rt.bat -x64 -q test_tempfile
C:\Work\Projects\cpython\PCbuild>"C:\Work\Projects\cpython\PCbuild\amd64\python.exe"
-Wd -E -bb "C:\Work\Projects\cpython\PCbuild\..\lib\test\regrtest.py"
test_tempfile
Paul Moore added the comment:
Ralf, thanks for the comments. The scientific community is definitely the key
group that *need* mingw (as opposed to people who merely want to use it because
they don't want to buy into MS compilers, or for similar personal reasons).
My personal view is th
Paul Moore added the comment:
The patch looks fine to me, although I don't think you need the comment showing
the old code. The new code is perfectly clear on its own.
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
I'm not sure I follow. Isn't the point of this patch to try again in certain
cases of a PermissionError, where currently the code breaks out of the loop
early? How can the result be worse than the current behaviour? Suerly sometimes
(maybe not always
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue2528>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
In the light of Steve Dower's work to "un-deprecate" bytes paths, I agree this
should be added.
--
___
Python tracker
<http://bugs.pyt
Paul Moore added the comment:
You can actually handle this already, with a simple wrapper program (based on
the one in PC\WinMain.c):
/* Minimal main program -- everything is loaded from the library. */
#include "Python.h"
#define WIN32_LEAN_AND_MEAN
#include
int wmain()
{
Paul Moore added the comment:
I'd prefer not to hard code __main__.py, as I'd quite like to be able to have a
number of copies of the executable, each running its own script. (I foresee
putting all my little Python utility scripts in a directory with a Python
installation an
Paul Moore added the comment:
See https://docs.python.org/3/using/windows.html#embedded-distribution - "When
extracted, the embedded distribution is (almost) fully isolated from the user’s
system, including environment variables, system registry settings, and
installed packages."
New submission from Paul Moore:
The zipapp module allows users to bundle their application as a single file
"executable". On Windows, the file is given a ".pyz" extension which is
associated with the Python launcher. However, this approach is not always
equivalent to a na
Paul Moore added the comment:
(1) It starts an extra process (unless you're running the application from
cmd.exe) and (2) in some cases, the system won't recognise a cmd file as an
executable. For a simple example,
t.cmd:
@echo Hello from t
example.py:
from subprocess import r
Paul Moore added the comment:
I'm still unsure whether this would be a good idea. On the plus side, it
provides (in conjunction with the "embedded" distribution) a really good way of
producing a standalone application on Windows. On the minus side there are some
limitations wh
Paul Moore added the comment:
OK, here's a first draft documentation patch. As it's purely a documentation
change, I guess it should go into the 3.5, 3.6 and trunk branches? For now it's
against trunk (it's not like that file has changed recently anyway), and I'll
Paul Moore added the comment:
is_dir is a *method*. To find out if an entry is a directory, you need to call
it.
So you need
from os import DirEntry, scandir
def test_is_dir():
for item in os.scandir(TEST_DIR):
if item.is_dir():
# ^^ note change
Paul Moore added the comment:
I can recreate this (based on the screenshots from #28366).
To reproduce, open IDLE. You get the console banner and prompt. Save that file
using File-Save. The close IDLE. Reopen it, do File-Open to open your saved
console session, then use the "Run" m
Paul Moore added the comment:
1. I don't think searching . should be included - on Unix /usr/bin/env searches
PATH, and I believe we should do the same here.
2. The PATH search does happen (from my reading of the code) but it looks for a
"python3" command, which isn't avai
Paul Moore added the comment:
I agree that the docs are a little confusing on this. Having said that, though,
I'm not entirely sure the behaviour needs fixing. The scenario where there's a
problem is:
1. User has written a script that needs Python 3 and won't run with Python
601 - 677 of 677 matches
Mail list logo
