Paul Moore p.f.mo...@gmail.com added the comment:
Windows 7, 32 bit.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13175
___
___
Python-bugs
Paul Moore p.f.mo...@gmail.com added the comment:
I suppose so, yes. But it feels symptomatic of a general lack of clean
error handling, which I think should be fixed :-(
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13172
Paul Moore p.f.mo...@gmail.com added the comment:
No it didn't - I had not built the _msi module when I built Python for some
reason. I have built _msi now, and everything works. Sorry for the false alarm.
Arguably, the command shouldn't fail, it should simply omit the bdist_msi
command from
New submission from Paul Moore p.f.mo...@gmail.com:
With a simple setup.cfg defining a distribution containing a single Python
module, if you misspell the modules keyword (say, as module) then pysetup
does nothing without reporting the error.
This silent failure is very hard to debug
Paul Moore p.f.mo...@gmail.com added the comment:
Unfortunately, no. I have been unable to get this in a reproducible form - but
I have seen it a few times now. I will keep trying to reproduce.
The worst thing is that packaging fails to recognise the data in RECORD and
won't uninstall
New submission from Paul Moore p.f.mo...@gmail.com:
The title explains. Here is an example:
PS D:\Data\python-sample\python pysetup install
Installing from source directory: 'D:\\Data\\python-sample\\python'
running install_dist
running build
running build_py
running install_lib
byte-compiling
New submission from Paul Moore p.f.mo...@gmail.com:
PS D:\Data\python-sample\python pysetup run bdist_wininst
running bdist_wininst
running build
running build_py
Invalid command install
Traceback (most recent call last):
File D:\Data\cpython\lib\packaging\command\__init__.py, line 57
New submission from Paul Moore p.f.mo...@gmail.com:
In a directory with 2 files, setup.cfg and a single C file containing source
for an extension module. The same happens with a pure-python module. This is on
Windows.
PS D:\Data\python-sample D:\Data\cpython\PCbuild\python.exe -m
New submission from Paul Moore p.f.mo...@gmail.com:
On Windows, packaging seems to create RECORD files with an additional CR at the
end of the line. (So the line end is CR CR LF). This does not seem to be
consistent, but it is likely to be because a file is being opened in text mode
rather
New submission from Paul Moore p.f.mo...@gmail.com:
I am trying to create a pysetup package that contains a precompiled binary
extension, which can be installed without compiling, by using the resource file
feature of setup.cfg. This may be incorrect usage of pysetup, but at a minimum
Paul Moore p.f.mo...@gmail.com added the comment:
On 9 October 2011 04:21, Éric Araujo rep...@bugs.python.org wrote:
Éric Araujo mer...@netwok.org added the comment:
I don’t have a Windows VM set up yet, but I can try to write a patch in the
coming weeks and ask you to test it. Deal
Changes by Paul Moore p.f.mo...@gmail.com:
--
nosy: +pmoore
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12779
___
___
Python-bugs-list mailing
New submission from Paul Moore p.f.mo...@gmail.com:
When uninstalling a package installed using a bdist_wininst installer, the
uninstall reports XXX files and directories could not be removed. The problem
appears to be the __pycache__ directories introduced in Python 3.2, which
Paul Moore p.f.mo...@gmail.com added the comment:
Not really (tbh, not at all). If I get some spare time, I can have a
look at producing a patch, but I have little time available for coding
at the moment (and I'm switching constantly between 3 PCs, so never
have a working development environment
Changes by Paul Moore p.f.mo...@gmail.com:
--
nosy: +pmoore
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12678
___
___
Python-bugs-list mailing
Paul Moore p.f.mo...@gmail.com added the comment:
Patch looks good to me. Can this be applied? As a temporary workaround I have
set my buildbot to run interactively. Once the fix is applied, I will switch
back to running as a service.
--
keywords: +buildbot
Changes by Paul Moore p.f.mo...@gmail.com:
--
nosy: +gpolo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9931
___
___
Python-bugs-list mailing
Paul Moore p.f.mo...@gmail.com added the comment:
Perhaps somewhat orthogonal to the patch, but in terms of the original hang
issue, does your service definition have the interact with desktop option
checked? That ought to permit any normal UI processing to take place as if
you were
Paul Moore p.f.mo...@gmail.com added the comment:
This bug appears to be Unix-only. On Windows:
from subprocess import *
p1 = Popen(['cat'], stdin=PIPE, stdout=PIPE)
p2 = Popen(['grep', 'a'], stdin=p1.stdout, stdout=PIPE)
p1.stdin.write(\n)
p1.stdin.close()
p2.stdout.read
Paul Moore p.f.mo...@gmail.com added the comment:
Certainly the 2.7 branch on my buildbot is now OK (3.x is failing for
other reasons :-()
--
status: pending - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9055
Paul Moore p.f.mo...@gmail.com added the comment:
I'm not sure what needs to be done to move this forward, but as it's a problem
with the test rather than with any actual code, could something be done to
avoid masking real issues? I agree with Thomas that in the absence of any other
solution
Paul Moore p.f.mo...@gmail.com added the comment:
I don't think that they do, any more than for any .py script. (I assume you're
talking about in the .py script). Generated scripts on Unix can be whatever the
code wants, and on Windows I thought the idea of generated scripts had been
dropped
Paul Moore p.f.mo...@gmail.com added the comment:
Thanks for clarifying.
No, I don't agree. Barring fancy if os.platform games in setup.py,
scripts will be platform-independent Python code. From Distributing
Python Modules section 2.5, Scripts are files containing Python
source code
Paul Moore p.f.mo...@gmail.com added the comment:
I don't propose to raise a PEP myself. The issue with ABCs seems to me to be a
fundamental design issue, and I think it's better to leave raising any PEP, and
managing the subsequent discussion, to someone with a deeper understanding
Paul Moore p.f.mo...@gmail.com added the comment:
Martin's analysis (and the description of the commit he refers to) indicates
that the correct fix is Cuiseppe's suggestion to change the relative imports to
absolute:
from _multiprocessing import ...
as the previous code was only working
Paul Moore p.f.mo...@gmail.com added the comment:
Here's a patch implementing the suggested change. test_multiprocessing passes.
I am just running the full test suite now.
--
keywords: +patch
Added file: http://bugs.python.org/file17849/mp.diff
Paul Moore p.f.mo...@gmail.com added the comment:
Full test suite also looks OK.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9144
New submission from Paul Moore p.f.mo...@gmail.com:
test_issue_8959_b fails when run from a service (in this case, from a
buildslave running as a service).
It appears to count the number of open windows, expecting a non-zero value. But
when run as a service, it looks like the return count
Paul Moore p.f.mo...@gmail.com added the comment:
One of the tests in test_socket is checking that an attempt to connect to a
port with no server running gives socket.error. For that, we need a port that's
guaranteed to have no server present.
I think that one of the tests in test_httplib
Paul Moore p.f.mo...@gmail.com added the comment:
Thanks for the suggestions, I'll see if I can implement something based on them.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8576
Paul Moore p.f.mo...@gmail.com added the comment:
Here's a patch for test_logging. It needed a minor tweak to logging.config -
but I can't see anywhere that this affects the documentation, so I didn't do a
doc patch. I hope that's OK.
I'll have a look at test_socket but that looks a bit too
Paul Moore p.f.mo...@gmail.com added the comment:
Might work - but the only ones that were actually failing for me were
test_multiprocessing and test_smtplib. So I'm not quite sure where/when the
error would be raised on the remaining 2 (socket httplib). But I'll keep it
in mind
New submission from Paul Moore p.f.mo...@gmail.com:
test_support.find_unused_port attempts to find an unused port to use. The
approach is fragile (as noted in the docstring) in certain cases. In
particular, it appears that Windows takes a short time to free the socket after
it is closed
Changes by Paul Moore p.f.mo...@gmail.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8576
___
___
Python-bugs-list mailing
Paul Moore p.f.mo...@gmail.com added the comment:
OK. I've attached a patch which removes the use of get_unused_port for
test_smtplib and test_multiprocessing. It doesn't use bind_port as both cases
test classes that create their own port internally, rather I've used port 0
Paul Moore p.f.mo...@gmail.com added the comment:
I can run a test on my buildbot - but I may not have a chance until
tomorrow. I'll do that and report back unless someone else reports
that they have managed to run a test before me.
--
___
Python
Paul Moore p.f.mo...@gmail.com added the comment:
I can confirm it fixes the issue, too.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7341
New submission from Paul Moore p.f.mo...@gmail.com:
It looks like the Control Panel\Desktop\dragfullwindows registry entry
can have value 2 (it does on my buildbot!) The distutils test
test_msvc9compiler assumes that only values 0 and 1 are valid.
The following patch (against trunk) fixes
New submission from Paul Moore p.f.mo...@gmail.com:
Windows 3.x buildbots are failing in test_tarfile.
The problem, as best I can diagnose it, appears to be a failure
somewhere in the tarfile module to close files on exceptions. The error
is WindowsError: [Error 32] The process cannot access
Paul Moore p.f.mo...@gmail.com added the comment:
This sounds reasonable to me. I would like to see this patch applied.
Note - someone involved with the cygwin port should confirm that the
patch does indeed no longer cause issues for cygwin.
--
nosy: +pmoore
New submission from Paul Moore p.f.mo...@gmail.com:
In revision 62197, Mon Apr 7 01:53:39 2008 UTC, Mark Hammond added code
to Lib/distutils/command/bdist_wininst.py which was intended to select
an architecture-specific installer executable.
In doing so, the code appears to have broken
Changes by Paul Moore p.f.mo...@gmail.com:
--
nosy: +pmoore
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2889
___
___
Python-bugs-list mailing
New submission from Paul Moore p.f.mo...@gmail.com:
There is no way to determine the list of classes for which issubclass(C,
x) is true. The MRO of the class is fine for normal inheritance, but for
ABCs it is possible to register classes which don't inherit from the
ABC, so that you have
Paul Moore p.f.mo...@gmail.com added the comment:
I raised issue 5405. Armin Roachner commented over there that it's not
even possible in principle to enumerate the ABCs a class implements
because ABCs can do semantic checks (e.g., checking for the existence of
a special method).
So documenting
Changes by Paul Moore p.f.mo...@gmail.com:
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5135
___
___
Python-bugs-list mailing list
Unsubscribe:
http
Paul Moore p.f.mo...@gmail.com added the comment:
I raised issue 5405. Armin Ronacher commented over there that it's not
even possible in principle to enumerate the ABCs a class implements
because ABCs can do semantic checks (e.g., checking for the existence of
a special method).
So documenting
Paul Moore p.f.mo...@gmail.com added the comment:
Good point! So a documentation patch, to the effect that there is no way
of determining which ABCs a given class is an instance of, would be an
appropriate resolution, I guess.
___
Python tracker rep
Paul Moore p.f.mo...@gmail.com added the comment:
In principle I don't have a problem with the automatic generation of an
EXE (I assume it generates a shell script with no extension on Unix?)
but it should be done in such a way that the EXE is version-independent.
This is necessary to ensure
Paul Moore p.f.mo...@gmail.com added the comment:
Here's an updated patch. I've reverted to the name simplegeneric and
documented the limitation around ABCs (I've tried to give an explanation
why it's there, as well as a hint on now to work around the limitation -
let me know if I'm overdoing
Paul Moore p.f.mo...@gmail.com added the comment:
Agreed (in principle). However, in practice the subtleties of override
order must be documented (and a method of implementation must be
established!!!) Consider:
class A:
... pass
...
class C:
... __metaclass__ = abc.ABCMeta
...
class
Paul Moore p.f.mo...@gmail.com added the comment:
Very good point. Registering for the standard ABCs seems like an
important use case. Unfortunately, it seems to me that ABCs simply don't
provide that capability - is there a way, for a given class, of listing
all the ABCs it's registered under
Paul Moore p.f.mo...@gmail.com added the comment:
Well spotted! I missed that when I checked. I will add tests and
documentation.
I agree that generic is better. I only left it as it was because the
original intent was simply to move the existing code - but that's not a
particularly good reason
Paul Moore p.f.mo...@gmail.com added the comment:
Here's an updated patch.
Added file: http://bugs.python.org/file12936/generic.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5135
Paul Moore p.f.mo...@gmail.com added the comment:
Fair comment. As Ryan said, it's a bit of a bikeshed issue. I prefer
generic, on the basis that I'd prefer to keep the simple name for the
simple use - something as complex as the RuleDispatch version could use
the name dispatch (if they want
Paul Moore p.f.mo...@gmail.com added the comment:
Agreed about the compatibility. It's there from pkgutil, where to be
honest, it's even less necessary, as simplegeneric was for internal use
only, there. I'm certainly not aware of any backward compatibility
requirements for functools.
Assuming
New submission from Paul Moore p.f.mo...@gmail.com:
This patch takes the existing simplegeneric decorator, currently an
internal implementation detail of the pkgutil module, and exposes it as
a feature of the functools module.
Documentation and tests have been added, and the pkgutil code has
New submission from Paul Moore [EMAIL PROTECTED]:
The latest version of Mingw binutils, 2.18.50.20080109, uses a 4-part
version number which distutils does not like (StrictVersion only allows
for 3 parts).
The attached patch fixes this, simply by using LooseVersion (the version
number has
Paul Moore [EMAIL PROTECTED] added the comment:
Thanks,
Paul.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Paul Moore [EMAIL PROTECTED] added the comment:
Nick, thanks I now see the issue. I'll work up a test to check for this
(and then correct it :-)).
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
Paul Moore [EMAIL PROTECTED] added the comment:
But that's not a valid loader.
I'm still struggling here. I see what you're trying to get at, but I
can't see how I can write a valid loader that does this.
To test the problem you're suggesting (that the code calls load_module
when the module
Paul Moore [EMAIL PROTECTED] added the comment:
It has to be a valid loader, as I see no reason to support loaders that
aren't valid. In any case, I did try incrementing a counter and it
doesn't demonstrate the problem. If you try the currently attached
patch, you should see that. (I assume
Paul Moore [EMAIL PROTECTED] added the comment:
Thanks for the update. Something's seriously screwy here. I am getting
no failures, so you can probably see why I was confused. Can you tell me
what platform, etc (anything that might be relevant) and I'll try to see
what's going
Paul Moore [EMAIL PROTECTED] added the comment:
By the way, for comparison, I'm running the test (under Windows) using
rt -q -v test_pkgutil from the PCBuild directory. I can't see how
test_getdata_filesys can fail, as long as you're running it from the
correct place - it reads
Paul Moore [EMAIL PROTECTED] added the comment:
Ah, no. I see your command line. I get the same failure as you in that
case. I can see why test_getdata_filesys fails in that case, I'll fix
that. I'm confused as to why test_alreadyloaded fails there but not via
rt.bat, but nevertheless I can fix
Paul Moore [EMAIL PROTECTED] added the comment:
OK, I found it. There were 2 problems, the double-loading one, and a
problem with adding my importer to sys.meta_path - if the test failed, I
wasn't removing it (so it was there for the next test, and interfering
with it).
Here's a fixed patch
Changes by Paul Moore [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file9799/pkgutil.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
___
Python-bugs-list
New submission from Paul Moore [EMAIL PROTECTED]:
This patch adds a new get_data function to the pkgutil module, allowing
access to data stored in the package directory. It wraps the PEP 302
loader get_data function, so that it works with such loaders (for
example, zipimport).
The patch
Paul Moore [EMAIL PROTECTED] added the comment:
I'm not sure I understand. It uses pkgutil.get_loader, which returns a
wrapper for filesystem modules. You pointed me to it. It seems to work,
that's what test_getdata_filesys is testing in test_pkgutil.py.
Can you supply a testcase that fails
Paul Moore [EMAIL PROTECTED] added the comment:
Is that true? loader.load_module(pkg) should return sys.modules[pkg]
without reloading if it already exists. See PEP 302 Specification part
1: The Importer Protocol:
The load_module() method has a few responsibilities that it must
fulfil *before
Changes by Paul Moore [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file9792/pkgutil.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2439
__
___
Python-bugs-list
Paul Moore added the comment:
I believe that mailbox.py is expected to work with files opened in
binary mode. A long time ago I opened a bug on th email package
(http://bugs.python.org/issue586899) which turned out to be because
mailbox.py required binary mode files. The conclusion
New submission from Paul Moore:
When running the test suite on Windows, test_socket_ssl hangs.
After a bit of investigation, it appears that the test is hanging at
line 184 (if self.s.stdout.readline() != ERROR\n:) in
OpenSSLServer._external.
The problem is that the test assumes it can read
New submission from Paul Moore:
The latest MSI daily snapshot installer for Python 2.6 (19 Nov) does not
include the .pem files for the SSL tests from the Lib\test directory.
--
components: Installation
messages: 57666
nosy: pmoore
severity: normal
status: open
title: MSI installer does
Paul Moore added the comment:
The following looks like it may be OK. I have no way of testing it,
unfortunately, as I don't currently have a working build environment,
and I've no idea how to build the MSI even if I did...
Added file: http://bugs.python.org/file8782/msi.patch
Paul Moore added the comment:
PJE's patch looks OK. I agree with Nick that the chain of s in
PyImport_GetImporter should be expanded into a chain of ifs. As it
stands, the code is needlessly obfuscated.
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org
601 - 675 of 675 matches
Mail list logo
