Paul Moore added the comment:
LGTM. Maybe worth a documentation note - "Changed in 3.6 - added an exit
message"? But I'm OK with it as is if you don't think that's worth it.
--
nosy: +paul.moore
___
Python tracker
<http:
Paul Moore added the comment:
On 23 July 2016 at 23:01, Eryk Sun wrote:
>> I assume you wouldn't expect to support shebang lines
>> like "#!python3.6r"?
>
> That's already supported in py.ini in the [commands] section, per PEP 397.
True, I'd forgot
Paul Moore added the comment:
This sounds like 2 related items (but I'm happy for them both to be under this
issue, I'm not suggesting we need 2 issues):
1. Allowing py -register to add PEP 514 metadata to the registry for the given
path.
2. Allowing py - to use PEP 514 met
Paul Moore added the comment:
Thanks for the explanation. Based on what's been said, I'd have no objections
to this, on a "you don't pay for what you don't use" basis - i.e., users who
don't enable AMSI should not pay any cost for its existence.
I'd be
Paul Moore added the comment:
I presume by "we" you mean "the core"? There's nothing to stop 3rd party code
using COM APIs.
The only downside to using COM in (user) Python code at the moment is the need
for a dependency on pywin32 (robust, mature, but a bi
Paul Moore added the comment:
> This doesn't work when COM objects have to be kept around. In the AMSI case...
OK, so that's a limitation. Is there any *other* use case for keeping COM
objects (that are created by the core) around? If not, then like it or not,
this is a problem
Paul Moore added the comment:
>> I am puzzled as to why "use safe_exec rather than exec" isn't an option
> Because you're going to have a hard time convincing malware authors to use it.
:-) So the malicious payload is the whole python command, not just file.bin.
Paul Moore added the comment:
OK, so a 3rd party module providing a "safe_exec" function would make a good
proof of concept, I assume. You could probably do that using comtypes or
pywin32.
I'm not going to try to say what is or isn't a security threat, that's no
Paul Moore added the comment:
Strong -1 on anything that scans my locally-written scripts by default. There's
no reason or justification for that.
Maybe there's a point in having a way to submit an untrusted Python code
snippet for scanning, but why would that need to be a core s
Paul Moore added the comment:
Hmm, this'll teach me to rely on my memory rather than checking :-)
It seems to me that core code that needs COM can use it by wrapping the code in
CoInitializeEx(sys.coinit_flags)...CoUninitialize(). That will either work fine
(I don't know where y
Paul Moore added the comment:
Things I know that call CoInitialize - pywin32/pythoncom and comtypes. I assume
the proposal is to call CoInitializeEx in a way that won't break those?
I'm not sure I see how this would affect the user (i.e. Python code). Brett
mentions detecting
Paul Moore added the comment:
The problem appears to be related to https (maybe openssl?) I just did the
following test:
>py -2
Python 2.7.12rc1 (v2.7.12rc1:13912cd1e7e8, Jun 12 2016, 05:57:31) [MSC v.1500
64 bit (AMD64)] on win32
Type "help", "copyright", "cr
Paul Moore added the comment:
Tim, I just got the issue with the x64 installer from python.org
(https://www.python.org/ftp/python/2.7.12/python-2.7.12rc1.amd64.msi)
--
___
Python tracker
<http://bugs.python.org/issue27
Paul Moore added the comment:
Confirmed I can reproduce the issue on Windows 7, with Python 2.7.12rc1. I
don't have C debugging capabilities on this PC, so that's as far as I can go
for now.
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Thanks Tim.
To clarify, the only 2 places that pip calls ctypes is to get the user
application directory (and we've confirmed that doesn't error when called
direct from Python), and in the vendored colorama package (which we removed and
still got the
Paul Moore added the comment:
Hmm, OK. So code that currently needs to access QWORD values and decodes the
bytes returned would be broken by this change. Equally it is possible (albeit
not ideal) to get the data out with the current behaviour.
I can't judge how likely it is that anyon
Paul Moore added the comment:
I'm not sure I follow your comment. In Python 3.5,
>>> from winreg import REG_QWORD
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name 'REG_QWORD'
So exposing REG_QWORD from the winreg mod
Paul Moore added the comment:
My instinct is that this should only go into 3.6. It's a remote possibility,
but someone could otherwise write code that uses REG_DWORD64 and say that it
"works on 3.5" because they tested on 3.5.x, only to have it fail on 3.5.1.
But if someone wit
Changes by Paul Moore :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27064>
___
___
Python-bugs-list
Paul Moore added the comment:
OK, no problem. Like you say, not a high priority.
--
___
Python tracker
<http://bugs.python.org/issue27064>
___
___
Python-bug
Paul Moore added the comment:
Terry: Correct.
As 3.4 is in security fix mode, and 2.7 doesn't come with the launcher (which I
hadn't realised - thanks for pointing this out Zach!) the only real backport
candidate is 3.5, so I definitely don't think it's worth backpo
Paul Moore added the comment:
Thanks Ned. Personally, I'm still inclined *not* to add this to 2.7/3.5. People
will get it when the install the 3.6 alphas, sure, but that seems to me to be a
relatively obvious consequence of installing an alpha that includes a component
that's us
Paul Moore added the comment:
Because of the nature of the launcher, there's not much we can do about that
IMO. And there was no real objection to changing the default on the
python-ideas thread (at least for interactive use).
But I'll wait to see if Ned has anyth
Paul Moore added the comment:
Thanks Steve. I wasn't sure over versioning, which is why I decided to be
conservative. Also, it's probably not good to change the default behaviour on
people when they just install a patch rele
New submission from Paul Moore:
By default, the launcher tries to launch (the latest version of) Python 2 on
the user's machine. This can be altered with the configuration file, and if the
user doesn't have Python 2 installed Python 3 will be used. Now that we are at
Python 3.6,
Paul Moore added the comment:
Ah, thanks. I probably did the commit the wrong way round in that case, as I
committed to tip. How should I do the commit into 3.5? (I'm also somewhat
confused by the fact that hg describes the 3.5 branch as &quo
Changes by Paul Moore :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Paul Moore added the comment:
Thanks Victor. I'll sort this out this evening when I get to my PC with access
to the CPython repo.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Paul Moore:
People often look towards collections.namedtuple when all they actually want is
"named attribute" access to a collection of values, without needing a tuple
subclass, or positional access. In these cases, types.SimpleNamespace may be a
better fit.
Changes by Paul Moore :
--
nosy: -paul.moore
___
Python tracker
<http://bugs.python.org/issue24557>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Sigh. I had installed Python 2.7 at some point, and py.exe picked it up by
default :-(
Isn't it about time that py.exe defaulted to the latest version installed, not
the latest version of Python 2?
--
___
P
Paul Moore added the comment:
That's weird. I can confirm it's working for me on 3.5.1. I'll double check I
wan't in 2.7 when I'm back at my work PC, but I didn't *think* I was. But
regardless, there's clearly no bug
New submission from Paul Moore:
See the following test (in Python 3.5):
>>> u'a\nb£'.encode('utf-8').splitlines()
['a', 'b\xc2\xa3']
I encode a string in UTF-8, then use the (bytes) splitlines function on it. The
return value is a list of st
Changes by Paul Moore :
--
keywords: +easy
___
Python tracker
<http://bugs.python.org/issue26336>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Just to clarify, it's intended that you simply "python -m pip install --upgrade
pip setuptools" to get the latest version.
--
nosy: +paul.moore
___
Python tracker
<http://bugs.pyt
Paul Moore added the comment:
Why is it too late to install a new importer to sys.path_hooks when zipimport
is installed? As far as I am aware, running the stdlib from a zipfile works
fine, which seems to be equivalent to your use case.
--
nosy: +paul.moore
Changes by Paul Moore :
--
nosy: -paul.moore
___
Python tracker
<http://bugs.python.org/issue25444>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
It's a very personal choice, but I prefer the current icons. I'm -1 on this
change.
--
___
Python tracker
<http://bugs.python.o
New submission from Paul Moore:
I have had a user install of Python 3.5rc3 for some time on one of my PCs. It
also had plenty of other versions on there - 3.4, 3.3, 2.7 and 2.6. The 3.5rc3
install was a user install.
I have my Python 3.4 install set up on PATH, and I've configured py.i
Paul Moore added the comment:
Also, the Windows build process is documented in PCBuild/readme.txt - see
https://hg.python.org/cpython/file/tip/PCbuild/readme.txt
More generally the devguide documents how to build CPython -
https://docs.python.org/devguide/setup.html#compiling
New submission from Paul Moore:
At the moment, building an application that embeds Python requires the user to
have a full install of Python on the build machine, to get access to the
include and library files.
Now that we provide an embeddable build of Python on Windows, would it be worth
Paul Moore added the comment:
> Maybe we can special-case pip uninstalling it from the site-packages folder?
> *Paul* - any thoughts?
Sorry, I've been following this thread but it's been moving pretty fast, so I'm
probably replying too late to be helpful now :-(
One alte
Paul Moore added the comment:
Now that "Add Python to PATH" is an option on the front screen of the installer
(not hidden behind the scary "customize" option) this can be closed.
I recall Steve suggesting there might be issues with the way a user install
results in the
Paul Moore added the comment:
This is standard Windows behaviour. Executables are always located first in the
directory where your program (in this case the Python executable) is running
from - even before searching PATH.
If you want to use a different Python, you should specify the full path
Paul Moore added the comment:
As noted, this behaviour is as documented, and is deliberately designed to
execute the shebang line as either an executable (which calc is) or one of a
specific set of "virtual" entries (which does not include /bin/env).
--
resolution: -&
Paul Moore added the comment:
On 30 June 2015 at 23:30, M.-A. Lemburg wrote:
> I don't remember the details of why this feature was added,
> but can imagine that it was supposed to enable installation
> of new importers via .pth files.
I don't know for certain if this
Paul Moore added the comment:
Cool. Easier distribution is good. Better compatibility with GPL requirements
(depending only on "system facilities") is probably helpful for the general
community, too.
Embedding in C++ built with a different version of the compiler is always going
t
Paul Moore added the comment:
+1 from me on this. Are there any specific technical implications (in terms of
ease of interoperability, ability to use a different compiler to build Python,
or whatever)? Whether there are or not, I'm still in favour - I think it's a
good thing anyway
Paul Moore added the comment:
Personally, I'm OK with the wording in the 3.5.0b2 docs, as far as basic
terminology and glossary-style information goes.
I think coroutines, async, and event loops are badly under-documented in the
broader context, though - there is very little in the
Paul Moore added the comment:
I'm still somewhat confused as to why we're looking at this in the context of
manually building an extension. It's *certainly* true that anyone attempting to
build a Python extension by hand (as per Matthew Barnett's instructions) should
be
Paul Moore added the comment:
Looks OK to me.
I assume the differences between the math and cmath code and tests is because
cmath uses Argument Clinic and math doesn't, and cmath uses unittest.main
whereas math adds the suites manually? As far as I can see, that's what&#
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:
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
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:
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:
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:
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:
==
ERROR: test_read_only_directory (test.test_tempfile.TestMkdtemp)
--
Traceback (most recent call last):
File "C:\Work\Pro
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:
> 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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue1602>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue17620>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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:
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:
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:
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:
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:
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:
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:
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
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue24127>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Paul Moore :
--
nosy: +paul.moore
___
Python tracker
<http://bugs.python.org/issue23572>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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
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
301 - 400 of 677 matches
Mail list logo
