Paul Moore added the comment:
Checking the exact error could be a bit fragile. I have a feeling I recently
saw an issue somewhere with code that stopped working on Python 3.4 because the
precise error raised for a read-only file changed. I don't recall where the
issue was, unfortun
Paul Moore added the comment:
I've been around here for a while, but yeah, I'll keep an eye out for pip stuff
now, too. Good thought.
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Agreed, that is not necessary. Nor was Martin suggesting it as far as I can
tell, he was simply saying that it would be less disruptive in the broader
scheme of things than messing with the Python registry scheme to work around
the limitation that 32 and 64 bit
Paul Moore added the comment:
OK, fair enough (I agree that the Windows behaviour here is the root cause of
the problem). However, it *would* have been possible for the registry keys to
be HKEY_LOCAL_MACHINE\Software\Python\PythonCore\3.4-32 and
HKEY_LOCAL_MACHINE\Software\Python\PythonCore
Paul Moore added the comment:
Should this be mentioned in the 3.3.5 changelog
(http://docs.python.org/3.3/whatsnew/changelog.html)?
--
___
Python tracker
<http://bugs.python.org/issue20
Paul Moore added the comment:
Re unit tests. Doh. Of *course* there are tests for importing from zipfiles.
And I just ran them (on Windows) and they worked. So there's something more
complex going on here and I don't know how you test for it, sorry (short of by
trying an import fr
Paul Moore added the comment:
I have reports from virtualenv users that this is not happening on Linux, BTW.
Could it be platform-specific somehow? Have the Unix users here been able to
reproduce this?
As regards a unit test, presumably we could ship a preconstructed zipfile in
the test
Paul Moore added the comment:
Will someone make sure this gets logged the way it needs to for Larry's 3.4rc2
cherrypick process? Ta.
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
Can anyone confirm if this is a Windows-only issue? I need to know whether I
should block Python 3.3.4 in virtualenv for everyone, or just for Windows.
I only have Windows I can test on.
--
___
Python tracker
<h
Paul Moore added the comment:
OK, I can confirm that both the patches fix the issue when applied to the
relevant branches.
--
___
Python tracker
<http://bugs.python.org/issue20
Paul Moore added the comment:
OK, confirmed.
Backing out to just before revision 2807a5f011e4 the problem has disappeared.
Re-applying just 2807a5f011e4 causes the issue to appear again.
--
___
Python tracker
<http://bugs.python.org/issue20
Paul Moore added the comment:
Georg - see http://bugs.python.org/issue20621#msg211209 for what I did. That
shows backing out did *not* fix the issue. But I did backout on the default
branch, and my backout may not have worked as I explained.
I just tried to do hg backout on the 3.3 branch and
Paul Moore added the comment:
Thanks for the workaround. I'm going to try to do some serious testing of all
this over the weekend, I'll let you know how it goes.
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
Note - we're going to have to work around this bug in Virtualenv (even if it's
just in code specific to 3.3.4) so a workaround for 3.3.4 and an explanation of
what's going wrong would be useful, a
Paul Moore added the comment:
I tried hg backout 2807a5f011e4. It gave errors in the form of dialog boxes
titled "Microsoft Visual Studio" saying "File '-nosplash' not found". I've no
idea where these came from and whether they matter, but I tried clicking OK
Paul Moore added the comment:
OK, I have a build of 3.4 that shows the bug. How do I revert
http://hg.python.org/cpython/rev/20b77ff040b6 ? hg backout -r 20b77ff040b6 says
"abort: cannot backout a merge changeset".
--
___
Python trac
Paul Moore added the comment:
I'm afraid I don't have things set up to do a Python build right now. I *might*
have time later, and if so I'll give it a try, but I can't promise. Also, I
haven't yet managed to show the issue on 3.4.0rc1, but that may be because my
ch
Paul Moore added the comment:
Apologies, cut & paste error.
3.3.2 32-bit:
PS 20:49 C:\Work\Scratch\virtualenv-pfm
>py -3.3-32 -c "import pip"
PS 20:49 C:\Work\Scratch\virtualenv-pfm
>py -3.3-32 -V
Python 3.3.2
3.4rc0 is not affected either:
PS 20:54 C:\Work\Scratch\virtua
Paul Moore added the comment:
This is still the case in the 3.4rc0 Windows installer. Could we get something
definite for 3.4 final? It may be too late for that to be anything other than
documenting that the command "pip" is not available, but given that most 3rd
party documents us
New submission from Paul Moore:
There appears to be a significant issue with importing from zip files on Python
3.3.4. I have tested this on Windows 7, 64-bit, using the MSI installer from
python.org.
To reproduce, download virtualenv and extract the
C:\Work\Scratch\virtualenv-pfm
Paul Moore added the comment:
I had not noticed that, but yes. It would be unreasonable on Windows to install
pip3 and pip3.4 but not plain pip. So +1 on this change.
(In fact, on Windows, omitting the versioned names would conform more closely
to how Python is installed, but it'
Paul Moore added the comment:
Fix now merged into pip 1.5.X branch
--
___
Python tracker
<http://bugs.python.org/issue20053>
___
___
Python-bugs-list mailin
Paul Moore added the comment:
https://github.com/pypa/pip/pull/1543
--
___
Python tracker
<http://bugs.python.org/issue20053>
___
___
Python-bugs-list mailin
Paul Moore added the comment:
Sounds reasonable. Having thought about it a bit more, I don't think it's a big
deal. I'll put a PR together for special-casing devnull.
--
___
Python tracker
<http://bugs.pyt
Paul Moore added the comment:
Maybe. I don't know what *else* might fail because devnull is special. The
filename gets passed straight to configparser, for a start.
But if you want to do that I'm OK with that - I just won't make that change
myself. Would the special-casing
Paul Moore added the comment:
In ensurepip, _disable_pip_configuration_settings has the line:
os.environ['PIP_CONFIG_FILE'] = os.devnull
On Windows, os.devnull does not behave like a real file in that
os.path.exists(os.devnull) is False even though opening it works fine. So tha
Paul Moore added the comment:
As noted in http://bugs.python.org/issue1311 (referenced from
http://bugs.python.org/issue20541) it's not actually correct to assume that
os.path.exists(os.devnull) returns true, as on Windows the "null device" is not
a proper filesystem object.
Paul Moore added the comment:
Sigh. Yes, I looked at that and wondered if os.devnul would show as existing,
but I similarly misread the test and assumed it was testing what it was meant
to test :-(
os.path.exists(os.devnull) is false on Windows (just checked) so this
assumption *is* what&#
Paul Moore added the comment:
Nothing obvious or Windows-specific from what I can see. It does seem to me
that EnvironmentVarGuard doesn't monkeypatch os.environ even though it looks
like it intends to (__exit__ sets it back, but __enter__ doesn't monkeypatch
it). So maybe th
Paul Moore added the comment:
Maybe it's not applicable to 3.3 somehow, which is what I tried. I applied the
patch to the distutils in the system installed Python, then ran pip install
numpy from a virtualenv.
It's quite possible that a million things could have gone wrong in th
Paul Moore added the comment:
Sigh. Looks like it doesn't fix the issue of building numpy - plus it doesn't
apply cleanly. My apologies for the noise, I'll report the issues with the
patch back on the numpy issue where I was told a
Paul Moore added the comment:
Unfortunately not really - it's the numpy guys that need this, so hopefully the
original poster can comment.
I'll see if I can hand-patch the relevant files and do a pip install numpy to
see if it fixes that specific scenario. I'll report back.
I
Paul Moore added the comment:
Is there any chance this can be included in Python 3.4? It would apparently
allow numpy to be built with stock tools on Windows Python.
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue16
Paul Moore added the comment:
Looks like that works. At least in my case - I just did
def del_rw(action, name, exc):
os.chmod(name, stat.S_IWRITE)
os.remove(name)
shutil.rmtree(path, onerror=del_rw)
Something more robust might check if name is a directory and os.rmdir
Paul Moore added the comment:
It's similar. But the problem is that it only returns a list of errors, it
doesn't let you address the error *while the rmtree is in progress*.
The key thing is that if you can fix the problem in onerror, you can avoid
needing to restart the whole
Paul Moore added the comment:
The most obvious solution would be if the onerror argument allowed for retries.
At the moment, all it can do is report issues, not recover. Suppose that
returning True from onerror meant "retry the operation". Then you could do
def set_rw(operation,
Paul Moore added the comment:
It would not be impossible for the ensurepip call in the Windows installer to
set the --default-pip flag, if that gives a better user experience on Windows.
I'm not wedded to either answer myself, but given that versioned executable
names are uncommon on Wi
Paul Moore added the comment:
Fair enough. Can the justification be recorded somewhere, please? It's
inconsistent with most other Python commands on Windows. (I don't recall what
the justification was, and can't come up with a search that locates the
di
New submission from Paul Moore:
The Python 3.4b2 installer for Windows does not install a "pip.exe" wrapper
when the default options are selected. Only the "pip3.exe" and "pip3.4.exe"
commands are provided.
The documentation for ensurepip makes it clear that
Paul Moore added the comment:
I'm in favour of keeping it simple - "use your common sense" should be a
general guideline here (even though I know people's tastes differ, and that can
be a source of endless debate :-))
--
___
P
Paul Moore added the comment:
+1 on switching the wording in the overriding principle section to say "factory
function to class". Although the fact that I made that mistake reflects my
point that if I'm thinking of class->wrapper as an "internal change" then I'
Paul Moore added the comment:
How about simply adding a further sentence, something like:
"Where a class is being used conceptually as a callable (for example, context
managers), the naming convention for callables (lower_case_with_underscores)
should be followed."
Maybe also add
Paul Moore added the comment:
Cool. Patch attached (this fixes __VENV_NAME__ and implements __VENV_PROMPT__)
--
keywords: +patch
Added file: http://bugs.python.org/file31938/venv_prompt.patch
___
Python tracker
<http://bugs.python.org/issue19
New submission from Paul Moore:
The documentation for venv states that __VENV_NAME__ in scripts is replaced by
the name of the virtualenv. In fact, it is replaced by context.prompt, which is
the prompt, rather than the name.
The various activate scripts are not consistent with this behaviour
New submission from Paul Moore:
Make the Windows Python installer set PATHEXT when "Register Python extensions"
is set. This allows users to run a scripy by typing the name of the .py file at
the command line without the .py extension.
The patch needs review - I have not been abl
Changes by Paul Moore :
Removed file: http://bugs.python.org/file30966/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18491>
___
___
Python-bug
Paul Moore added the comment:
Updated patch, as per discussion.
--
Added file: http://bugs.python.org/file30994/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18
Paul Moore added the comment:
I've no problem with that suggestion. The patch is clean enough that ifdef-ing
it out won't be hard.
Revised patch incoming :-) It's needed for the pyw support in any case.
--
___
Python
Paul Moore added the comment:
Correct about .pyw files - I had forgotten those, I will update the patch.
The idea of "support code" was to (somewhat) alleviate Mark's question about
"what is this for", I was wondering if it was worth adding a module to the
stdlib whic
Changes by Paul Moore :
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue18491>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore:
Adds "exe wrapper" functionality to the Windows launcher. This is a preliminary
patch, for comments - the code is there and works, but I need to add
documentation (and maybe tests - are there any existing tests for the launcher?)
Also to be consider
Changes by Paul Moore :
--
keywords: +patch
Added file: http://bugs.python.org/file30966/launcher_wrapper.patch
___
Python tracker
<http://bugs.python.org/issue18
New submission from Paul Moore:
Some small improvements to the powershell "Activate" script for venvs:
1. Can be run as a command, rather than needing to be dot sourced. This matches
the behaviour of bat files, and of virtualenv's "activate" script, and avoids a
Paul Moore added the comment:
There's also https://pypi.python.org/pypi/sarge
One other thing I *often* want to do when scripting commands is to capture
output, but provide some form of "progress" reporting (something like a dot per
line of output, usually). That's ann
Paul Moore added the comment:
On 23 May 2013 20:11, Roumen Petrov wrote:
> > Is this approach acceptable?
> It is not enough.
>
Support for compilers other than gcc (including cross-compilers) is a
separate issue, and one which is much less likely to
Paul Moore added the comment:
+1 for Oscar's proposed fix. It sounds like a sensible approach.
--
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
There is a patch for this (against the standalone pylauncher project) at
https://bitbucket.org/pmoore/pylauncher.
--
keywords: +patch
___
Python tracker
<http://bugs.python.org/issue17
New submission from Paul Moore:
The Python launcher for windows should recognise a hashbang line of
#!/usr/bin/env python, and use the python executable found on PATH to run the
script. If no python executable is present on PATH the launcher should fall
back to the current behaviour (using
Paul Moore added the comment:
On 2 May 2013 16:35, Dmi Baranov wrote:
> Paul, result as iterable of CodecInfo objects is gives much more
> flexibility than the names of codecs (whats if you will have a few codecs
> with the same name in different SearchObjects?)
Works for me. My us
Paul Moore added the comment:
@doerwalter In that case, I'd take the view that such a codec should simply not
return anything. The discovery mechanism can be limited to returning only
statically discoverable codec names (and it can be documented as such).
The original use case was to su
New submission from Paul Moore:
The codecs module allows the user to register additional codecs, but does not
offer a means of getting a list of registered codecs.
This is important, for example, in a tool to re-encode files. It is reasonable
to expect that such a tool would offer a list of
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue15867>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Paul Moore :
--
nosy: -pmoore
___
Python tracker
<http://bugs.python.org/issue13198>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
It's the open file object argument, not the path. I assume that if you
supplied None, the code opened the file for you.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org
Paul Moore added the comment:
Logged as #15902.
--
___
Python tracker
<http://bugs.python.org/issue15828>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Moore:
imp.load_module appears to have a regression - the file argument is not allowed
to be None when loading a C_EXTENSION. The pywin32 post-install script for
version 217 calls imp.load_module for a C extension with file=None, so
presumably this worked in earlier
Paul Moore added the comment:
On 10 September 2012 11:47, Tim Golden wrote:
>
> Tim Golden added the comment:
>
> Paul, are you using the hg tip of pywin32? pywin32_postintall.py was
> patched a couple of months ago to use imp.load_dynamic (essentially to
> work around this is
Paul Moore added the comment:
The applied fix appears to have a regression - the file argument is not allowed
to be None. The pywin32 post-install script calls imp.load_module for a C
extension with file=None, so presumably this worked in earlier versions.
The regression breaks the
Paul Moore added the comment:
Applies and builds cleanly on Win7 32-bit. The speed difference is visible here
too:
PS D:\Data\cpython\PCbuild> .\python.exe -m timeit -s "from _thread import
allocate_lock; l=allocate_lock()" "l.acquire();l.release()"
100 loops, be
Paul Moore added the comment:
As an alternative, maybe leave the "stuck" worker, but allow the pool
to recognise when a worker has not processed new messages for a long
period and spawn an extra worker to replace it. That would avoid the
starvation issue, and the stuck workers woul
New submission from Paul Moore :
I have an application which fires off a number of database connections via a
multiprocessing pool. Unfortunately, the database software occasionally gets
"stuck" and a connection request hangs indefinitely. This locks up the whole
process doing the
Paul Moore added the comment:
> - Will “@%~dp0\..\python.exe” get the proper path for people who do not
> install Python to C:\?
%~dp0\..\python.exe locates python relative to the batch file (one
directory up) so will work as long as the bat file is in Scripts. The
@ just suppresses e
Paul Moore added the comment:
On 14 February 2012 15:48, Éric Araujo wrote:
>
> Éric Araujo added the comment:
>
>> The initial errors look like complaints about existing packages I have
>> installed by other means
> They’re logging messages, not errors. They appear
Paul Moore added the comment:
> Damn, bitten by the use of universal newlines! I guess I should split on a
> literal '\n' instead of calling splitlines. Could you make that change in
> your clone and tell me if it does the trick?
Not for a few days, but I'll
New submission from Paul Moore :
I created a bdist_wininst installer for distutils2 and installed it into my
Python 2.7.2 installation. This is on Wondows, 32-bit. I then tried to do a
simple install to test it was working.
>python -m distutils2.run install stemming
Checking the installat
Paul Moore added the comment:
Produces RECORD files with CR-CR-LF line endings (see issue13175). This breaks
pysetup remove.
I can't tell if this patch is good otherwise - it's certainly no worse than the
behaviour of the unpatched version, but that's
Paul Moore added the comment:
A better example in terms of "intended to be text" might be ChangeLog files.
These are clearly text files, but of sufficiently standard format that they can
be manipulated programmatically.
Consider a program to get a list of all authors who changed a
Paul Moore added the comment:
>> Do I need to hg clone then do some magic pip incantation to get it installed?
> Why would you want to install it? Clone it, hack on it in place, run tests
> in place. :)
>
> FTR, “bin/pip install -e .” is the command to “install” a project
Paul Moore added the comment:
I'll try to take a look over the next couple of days.
--
___
Python tracker
<http://bugs.python.org/issue13123>
___
___
Pytho
Paul Moore added the comment:
I'm writing a PEP, also as a result of Nick's suggestion on python-ideas. I
don't think it will be too hard to get the basic framework of the PEP in place.
When I'm done, would you like to see it and comment before I post to the wider
pyt
Paul Moore added the comment:
> Maybe you’re using the old PyPI release or Tarek’s outdated Bitbucket
> repository. http://hg.python.org/distutils is current, contains pysetup and
> supports -m distutils2.run.
I just did pip install distutils2 in a virtualenv. If that doesn't
Paul Moore added the comment:
Have you had a chance to look at this yet?
--
___
Python tracker
<http://bugs.python.org/issue13123>
___
___
Python-bugs-list mailin
Paul Moore added the comment:
We're running a bit lower on time now. Any progress? The whole discussion on
python-dev around binary formats petered out with no real conclusions :-(
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
Any progress on this one?
I tried to reproduce using distutils2, but don't know how distutils2 works -
there's no pysetup and python -m distutils2.run doesn't work the same as python
-m packaging.run.
Can we at least get packaging working in tim
Paul Moore added the comment:
A simple rebuild and test run of that test in debug mode didn't fail...
I'll run the full test suite as a check, but that could take some time - that
buildslave isn't the fastest in the world...
--
___
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue2292>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.pyth
Paul Moore added the comment:
One important point - in the "new world" where data files living
alongside code is unsupported, the bdist_msi and bdist_wininst
installers need to be updated to install data files as needed. This
may work already (I'll do some tests to see how well
Changes by Paul Moore :
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I see what you're saying - and looking through sysconfig.cfg, I can see how
things are expected to be laid out (and how I'd configure it if I didn't like
it :-))
But as far as I can see, there's no way in packaging to describe a module that
Paul Moore added the comment:
Yes, working correctly now
--
___
Python tracker
<http://bugs.python.org/issue13181>
___
___
Python-bugs-list mailing list
Unsub
Paul Moore added the comment:
First one - the problem is in packaging.manifest._translate_pattern, which uses
os.path.join on regex parts. That won't work on Windows where os.sep is a
backslash, as the backslash is a RE metacharacter.
Actually, the file list seems to only use '/&
Paul Moore added the comment:
I'm not getting the second error on my home PC. As the failing buildbot is
mine, I'll have a look on there to see if I can reproduce when I get the chance.
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
> Would you be satisfied with a more helpful traceback that would point you
> immediately to missing msi? Do you prefer that bdist_msi
> catch an ImportError for _msi and print a short error message instead of a
> traceback in all its glory?
I'
Paul Moore added the comment:
> That’s odd. Are the pyc files in RECORD?
Yes, but not in __pycache__ where they should be.
PS D:\Data\python-sample\python> type
D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RECORD
D:\Data\cpython\Lib\site-packages\he
Paul Moore added the comment:
On 17 October 2011 14:15, Éric Araujo wrote:
>> The file passed to csv.writer should be opened with newline=''.
> How will we port this to 2.x?
No idea :-( The 2.7 documentation says use the 'b' flag, but that
probably doesn'
Paul Moore added the comment:
New patch including some basic tests.
--
Added file: http://bugs.python.org/file23422/bdist_simple.patch
___
Python tracker
<http://bugs.python.org/issue13
Changes by Paul Moore :
Removed file: http://bugs.python.org/file23417/bdist_simple.patch
___
Python tracker
<http://bugs.python.org/issue13189>
___
___
Python-bugs-list m
New submission from Paul Moore :
The attached patch is a first version of a bdist_simple binary distribution
format for packaging. There is a bdist_simple command to build the
distribution, and pysetup install has been updated to handle bdist_simple
format distributions (only as local files
Paul Moore added the comment:
Here's a patch. It includes a test, but I don't expect the test will catch the
issue except on Windows...
--
keywords: +patch
Added file: http://bugs.python.org/file23416/recordfix.patch
___
Python trac
501 - 600 of 677 matches
Mail list logo
