[issue12055] doctest not working on nested functions
Dave Abrahams added the comment: It's certainly much appreciated, but my tests have to run with a stock python, so I worked around the problem personally. I just reported this because I found (surprisingly, to me) that some of my tests had been silently not-running, which seems like a bad feature of any testing system ;=). On Mon, May 23, 2011 at 12:15 PM, Baptiste Carvello wrote: > > Baptiste Carvello added the comment: > > here is the patch for 2.7. > > Dave: I don't know if or when the patch will be accepted, as this is a new > feature. In the meantime, you can easily patch your system. As the code > changes > are all in Python, you don't need to recompile. Going to your standard library > directory and running a command like the following should do the trick: > > filterdiff -i '*/doctest.py' issue12055-27.diff | patch > > -- > Added file: http://bugs.python.org/file22085/issue12055-27.diff > > ___ > Python tracker > <http://bugs.python.org/issue12055> > ___ -- ___ Python tracker <http://bugs.python.org/issue12055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version incompatibilities in dependencies
Dave Abrahams added the comment: I'm sorry, but it is simply not true that this is not a solved problem. This is a well-understood problem that's solved --- at least as well as anyone could want it to be --- by aptitude (not apt-get) and by http://en.opensuse.org/openSUSE:Libzypp_satsolver -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version incompatibilities in dependencies
Dave Abrahams added the comment: That's quite true. However, I don't think a local index is needed if there's a remote index; you're already looking in a remote index, albeit a less-completeone. And it could be maintained automatically from individual package metadata. Maybe that's out of scope for this project, though. -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11376] Solaris/GCC/shared lib problem
Dave Abrahams added the comment: I run: sudo pip install --upgrade twisted -- ___ Python tracker <http://bugs.python.org/issue11376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11376] Solaris/GCC/shared lib problem
Dave Abrahams added the comment: Note: even after I install Sun CC, -KPIC is unrecognized. At least it's only a warning in this case: $ sudo pip install --upgrade twisted Downloading/unpacking twisted Running setup.py egg_info for package twisted Downloading/unpacking zope.interface (from twisted) Running setup.py egg_info for package zope.interface Downloading/unpacking setuptools (from zope.interface->twisted) Running setup.py egg_info for package setuptools Installing collected packages: setuptools, twisted, zope.interface Found existing installation: setuptools 0.6c12dev-r88846 Uninstalling setuptools: Successfully uninstalled setuptools Running setup.py install for setuptools Installing easy_install script to /usr/bin Installing easy_install-2.6 script to /usr/bin Found existing installation: Twisted 10.0.0 Uninstalling Twisted: Successfully uninstalled Twisted Running setup.py install for twisted /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c conftest.c -o conftest.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c conftest.c -o conftest.o cc: unrecognized option `-KPIC' conftest.c:1:23: sys/epoll.h: No such file or directory building 'twisted.runner.portmap' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/runner/portmap.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/runner/portmap.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/runner/portmap.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/runner/portmap.so building 'twisted.test.raiser' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/test/raiser.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/test/raiser.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/test/raiser.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/test/raiser.so building 'twisted.python._initgroups' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/python/_initgroups.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.o cc: unrecognized option `-KPIC' /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/python/_initgroups.so building 'twisted.internet._sigchld' extension /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c twisted/internet/_sigchld.c -o build/temp.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.o cc: unrecognized option `-KPIC' In file included from /usr/include/python2.6/Python.h:8, from twisted/internet/_sigchld.c:9: /usr/include/python2.6/pyconfig.h:1004:1: warning: "_FILE_OFFSET_BITS" redefined In file included from /usr/include/signal.h:36, from twisted/internet/_sigchld.c:6: /usr/include/sys/feature_tests.h:209:1: warning: this is the location of the previous definition /usr/lib/python2.6/pycc -G build/temp.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.o -L/usr/lib -lpython2.6 -o build/lib.solaris-2.11-i86pc-2.6/twisted/internet/_sigchld.so changing mode of build/scripts-2.6/manhole from 644 to 755 changing mode of build/scripts-2.6/mktap from 644 to 755 changing mode of build/scripts-2.6/pyhtmlizer from 644 to 755 changing mode of build/scripts-2.6/twistd from 644 to 755 changing mode of build/scripts-2.6/trial from 644 to 755 changing mode of build/scripts-2.6/tap2rpm from 644 to 755 changing mode of build/scripts-2.6/tap2deb from 644 to 755 changing mode of build/scripts-2.6/tapconvert from 644 to 755 changing mode of build/scripts-2.6/mailmail from 644 to 755 changing mode of build/scripts-2.6/conch from 644 to 755 changing mode of build/scripts-2.6/cftp from 644 to 755 changing mode of build/scripts-2.6/tkconch from 644 to 755 changing mode of build/scripts-2.6/ckeygen from 644 to 755 changing mode of build/scripts-2.6/lore from 644 to 755 changing mode of /usr/bin/tap2deb to 755 changing mode of /usr/bin/ckeygen to 755 changing mode of /usr/bin/tap2rpm to 755 changing mode of /usr/bin/mktap to 755 changing mode of /usr/bin/pyhtmlizer to 755 changing mode of /usr/bin/twistd to 755 changing mode of /usr/bin/lore to 755 changing mode of /usr/bin/mailmail to 755 changing mode of /usr/bin/cftp to 755 changing mode of /usr/bin/tkconch to 755 changing mode of /usr/bin/conch to 755 changing mode of /usr/bin/trial to 755 changing mode of /usr/bin/tapconvert to 755 changing mode of /usr/bin/manhole to
[issue515074] Extended storage in new-style classes
Dave Abrahams added the comment: I can't imagine what kind of "positive response" you'd want from me. I responded to the last question asked. I certainly don't know whether this is still an issue, though. -- nosy: +dabrahams status: pending -> open ___ Python tracker <http://bugs.python.org/issue515074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version conflicts in dependencies
Dave Abrahams added the comment: I'm not sure the change of title you made is appropriate. The case I described isn't a conflict, in the sense that there is a version of D that satisfies everybody's requirements. Maybe the real title should be something like "exhaustively or comprehensively test dependency resolution." -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Handle version conflicts in dependencies
Dave Abrahams added the comment: Oh, and http://distutils2.notmyidea.org/depgraph.html is a 404 for me. -- ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11376] Solaris/GCC/shared lib problem
New submission from Dave Abrahams : http://twistedmatrix.com/trac/ticket/4916#comment:2 suggests that maybe there's a bug in distutils. Something in the build process for twisted is deciding that I have Sun CC installed instead of letting pycc, which can handle the job of picking the correct PIC flag, do it properly: /usr/lib/python2.6/pycc -DNDEBUG -KPIC -I/usr/include/python2.6 -c conftest.c -o conftest.o gcc: unrecognized option `-KPIC' -- assignee: tarek components: Distutils messages: 129903 nosy: dabrahams, eric.araujo, tarek priority: normal severity: normal status: open title: Solaris/GCC/shared lib problem type: compile error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12055] doctest not working on nested functions
New submission from Dave Abrahams : The attached file demonstrates -- components: Library (Lib) files: bug.py messages: 135770 nosy: dabrahams priority: normal severity: normal status: open title: doctest not working on nested functions versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file21964/bug.py ___ Python tracker <http://bugs.python.org/issue12055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess portability issue
New submission from Dave Abrahams :
On POSIX systems, the PATH environment variable is always used to
look up directory-less executable names passed as the first argument to
Popen(...), but on Windows, PATH is only considered when shell=True is also
passed.
Actually I think it may be slightly weirder than that when
shell=False, because the following holds for me:
C:\>rem # Prepare minimal PATH #
C:\>set
"PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem"
C:\>rem # Prepare a minimal, clean environment #
C:\>virtualenv --no-site-packages e:\zzz
New python executable in e:\zzz\Scripts\python.exe
Installing setuptoolsdone.
C:\>rem # Show that shell=True makes the difference in determining whether
PATH is respected #
C:\>python
Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'])
>>> C:\Python26\python.exe
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'],
>>> env={'PATH':r'e:\zzz\Scripts'})
>>> C:\Python26\python.exe
>>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'],
>>> env={'PATH':r'e:\zzz\Scripts'}, shell=True)
>>> e:\zzz\Scripts\python.exe
That is, it looks like the environment at the time Python is invoked is what
counts unless I pass shell=True. I don't even seem to be able to override this
behavior by changing os.environ: you can clear() it and pass env={} and
subprocess.Popen(['python']) still succeeds.
This is a very important problem for portable code and one that took me hours
to suss out. I think:
a) the current behavior needs to be documented
b) it needs to be fixed if possible
c) otherwise, shell=True should be the default
--
assignee: d...@python
components: Documentation
messages: 104422
nosy: dabrahams, d...@python
priority: normal
severity: normal
status: open
title: subprocess portability issue
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8557>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess portability issue
Dave Abrahams added the comment:
It's worse than I thought; there isn't even one setting for shell that works
everywhere. This is what happens on POSIX (tested on Mac and Ubuntu):
$ mkdir /tmp/xxx
$ cd /tmp/xxx
xxx $ virtualenv /tmp/zzz
xxx $ python
Python 2.6.5 (r265:79063, Mar 23 2010, 08:10:08)
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import *
>>> p = Popen(['python', '-c', 'import sys;print sys.executable'],
... stdin=PIPE,stdout=PIPE,stderr=PIPE,
... env={'PATH':'/tmp/zzz/bin'})
>>> stdout,stderr = p.communicate(None)
>>> print stdout
/tmp/zzz/bin/python
>>> print stderr
>>> p = Popen(['python', '-c', 'import sys;print sys.executable'], shell=True,
... stdin=PIPE,stdout=PIPE,stderr=PIPE,
... env={'PATH':'/tmp/zzz/bin'})
>>> stdout,stderr = p.communicate(None)
>>> print stdout
>>> print stderr
--
___
Python tracker
<http://bugs.python.org/issue8557>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics
Dave Abrahams added the comment: I wrote a Python script (enclosed) to methodically test how these things work, that doesn't rely on peculiarities of sys.executable. The tests did reveal some notable differences on *nix and 'doze: * When shell=False on windows you must launch the process using a full filename (e.g. "foo.exe", not just "foo", pass --invoke-filename to the script to enable that). This may seem obvious to you, but for me it was surprising that one executable lookup function (looking in PATH) is in effect but not the other (extending unqualified executable names). This should be spelled out in the docs. * On *nix, with shell=False and the executable is neither in the PATH in the environment at the time of Python's launch nor in os.environ at the time of Popen, passing Popen an explicit env whose PATH includes the executable is enough to cause it to be found. Not so on 'doze. * On 'doze, when the executable is in the PATH of os.environ but not in that of Popen's explicit env argument, even with shell=False, no Exception is raised (but returncode is nonzero) -- Added file: http://bugs.python.org/file17142/probe.py ___ Python tracker <http://bugs.python.org/issue8557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics and portability
Dave Abrahams added the comment: @r.david.murray: did you try running my test? I think it shows that we are pretty darned close to fully portable. I believe we could fix Popen to make it fully portable pretty easily. In fact, there may be a pure-python fix. Documenting the differences would also not be hard. I would discourage you from relying *solely* on a description such as "uses execvpe on POSIX" to describe the semantics. Aside from being a nonportable description, it doesn't help anyone who isn't familiar with the POSIX system calls. -- ___ Python tracker <http://bugs.python.org/issue8557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics and portability
Dave Abrahams added the comment: I've uploaded a new probe.py that contains a win32 Popen wrapper that I think acts just like *nix's Popen w.r.t. PATH and environment (pass --fix to demonstrate). I suggest using this or an equivalent wrapper for Win32, and documenting the fact that with shell=False, filename extensions need to be supplied explicitly on windows. -- Added file: http://bugs.python.org/file17180/probe.py ___ Python tracker <http://bugs.python.org/issue8557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics and portability
Changes by Dave Abrahams : Removed file: http://bugs.python.org/file17142/probe.py ___ Python tracker <http://bugs.python.org/issue8557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics and portability
Dave Abrahams added the comment: Not to appear impatient, but It's a fairly tidy answer, I think :-) -- ___ Python tracker <http://bugs.python.org/issue8557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics and portability
Dave Abrahams added the comment: I'm probably as ignorant as you are of Windows issues. I just know what my experiments tell me: if you force the contents of any explicit 'env' argument into os.environ before calling Popen, you get the same behavior as on *nix. -- ___ Python tracker <http://bugs.python.org/issue8557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics and portability
Dave Abrahams added the comment: R. David Murray wrote: > There are two questions here: (1) is this behavior consistent across all > microsoft platforms we support? I'll be honest: I don't know. > (2) is this *change* in behavior of Popen acceptable? I don't know that either. > I'll be more inclined to > test things if the tests are in the form of unit tests, which should > be much easier to understand than your test program. I guess no good deed goes unpunished ;-) I also guess that whether you think unit tests will be easier to understand depends on what kind of information you expect to glean from the code. My script was designed to probe for all inconsistencies between ‘doze and POSIX behaviors, and it is more revealing in that respect than a unit test would be. The unit test that would prompt the particular code change I'm suggesting would look more like: put directory X in the env argument's PATH (but not in os.environ) attempt to launch X/some_executable as simply “some_executable” assert that X/some_executable actually ran I don't know what Popen's unit tests look like, and to be honest, right now I just don't have any more time to pour into this particular issue. Even if it doesn't get fixed in Python I'm going to be using my wrapper for uniformity. I hope everything I've done so far is useful to the community but if not, I still have what I need. -- ___ Python tracker <http://bugs.python.org/issue8557> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8617] Non-existent variables documented
New submission from Dave Abrahams : http://docs.python.org/library/site.html#module-site mentions two variables that don't appear in my Python 2.6.5 installation's site module: PYTHONNOUSERSITE New in version 2.6. PYTHONUSERBASE New in version 2.6. -- assignee: d...@python components: Documentation messages: 104985 nosy: dabrahams, d...@python priority: normal severity: normal status: open title: Non-existent variables documented versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8626] TypeError: rsplit() takes no keyword arguments
New submission from Dave Abrahams : Based on the rsplit documentation, I'd expect 'foo bar'.rsplit(maxsplit=1) to work. This is probably a much bigger problem than just rsplit, i.e. I doubt there is a policy about whether documented parameter names need to be usable as keywords, and if not, how one finds out which keywords are supported. -- messages: 105040 nosy: dabrahams priority: normal severity: normal status: open title: TypeError: rsplit() takes no keyword arguments ___ Python tracker <http://bugs.python.org/issue8626> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8653] urlparse.urlparse/urlsplit doc missing
New submission from Dave Abrahams : The docstrings for these functions don't explain the 'scheme' parameter. Even renaming it to default_scheme would help. -- assignee: d...@python components: Documentation messages: 105221 nosy: dabrahams, d...@python priority: normal severity: normal status: open title: urlparse.urlparse/urlsplit doc missing ___ Python tracker <http://bugs.python.org/issue8653> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8656] urllib2 mangles file://-scheme URLs
New submission from Dave Abrahams :
$ touch /tmp/x.html
$ python -c 'import urllib2;resp=urllib2.urlopen("file:///tmp/x.html");print
resp.geturl()'
file:/tmp/x.html
note the missing // after the colon
--
messages: 105250
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urllib2 mangles file://-scheme URLs
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8656>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8657] urlparse.urlunsplit should be smarter about +
New submission from Dave Abrahams :
from urlparse import *
urlunsplit(urlsplit('git+file:///foo/bar/baz'))
=> git+file:/foo/bar/baz
--
messages: 105253
nosy: dabrahams
priority: normal
severity: normal
status: open
title: urlparse.urlunsplit should be smarter about +
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8657>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8653] urlparse.urlparse/urlsplit doc missing
Dave Abrahams added the comment: At Sat, 08 May 2010 22:18:13 +, Éric Araujo wrote: > > > Éric Araujo added the comment: > > I think you mean > http://docs.python.org/library/urlparse.html#urlparse.urlparse > > Dave, perhaps you were looking at an older version? Doc fixes for > maintainance branches are welcome. No, I was looking at (and reporting on) the docstrings. -- ___ Python tracker <http://bugs.python.org/issue8653> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] NamedTemporaryFile usability request
New submission from Dave Abrahams : NamedTemporaryFile is too hard to use portably when you need to open the file by name after writing it. To do that, you need to close the file first (on Windows), which means you have to pass delete=False, which in turn means that you get no help in cleaning up the actual file resource, which as you can see from the code in tempfile.py is devilishly hard to do correctly. The fact that it's different on posix (you can open the file for reading by name without closing it first) makes this problem worse. What we really need for this use-case is a way to say, "delete on __del__ but not on close()." -- components: Library (Lib) messages: 155278 nosy: dabrahams priority: normal severity: normal status: open title: NamedTemporaryFile usability request versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] NamedTemporaryFile unusable under Windows
Dave Abrahams added the comment: I disagree that it's unacceptable for close() and __del__() to behave differently. The acceptable difference would be that __del__() closes (if necessary) /and/ deletes the file on disk, while close() merely closes the file. If you can in fact "change the way the file is opened on Windows so that it can be opened again without closing it first," that would be fine with me. It isn't clear to me that Windows supports that option, but I'm not an expert. Another possibility, of course, is something like what's implemented in: https://github.com/dabrahams/zeroinstall/commit/d76de038ef51bd1dae36280f8743e06c7154b44a#L3R44 (an optional argument to close() that prevents deletion). -- ___ Python tracker <http://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] NamedTemporaryFile unusable under Windows
Dave Abrahams added the comment: If file.close() "offers deterministic resource management," then you have to consider the file's open/closed state to be a resource separate from its existence. A NamedTemporaryFile whose close() deterministically managed the open/closed state but not the existence of the file would be consistent with file. That said, I understand the move toward deprecating (in the informal sense) cleanups that rely on GC. I'm not suggesting breaking backward compatibility, either. I'm suggesting that it might make sense to allow an explicit close-without-delete as an /extension/ of the current interface. Given the move away from GC-cleanups, you'd probably want an explicit unlink() method as well in that case. -- ___ Python tracker <http://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14252] subprocess.Popen.terminate() inconsistent behavior on Windows
New submission from Dave Abrahams : Try the following script on posix and Windows. On Posix: launched . . . exiting killed on Windows: launched . . . exiting Traceback (most recent call last): File "sp.py", line 16, in p.terminate() File "c:\Python26\lib\subprocess.py", line 949, in terminate _subprocess.TerminateProcess(self._handle, 1) WindowsError: [Error 5] Access is denied This inconsistency seems unnecessary and is an obstacle to writing portable code. from subprocess import * import sys, time p = Popen([sys.executable, '-c', ''' import time, sys for i in range(3): time.sleep(.3) print '.', sys.stdout.flush() print 'exiting' '''], stdout = sys.stdout, stderr = sys.stderr) print 'launched' time.sleep(2) p.terminate() print 'killed' -- components: Library (Lib) messages: 155391 nosy: dabrahams priority: normal severity: normal status: open title: subprocess.Popen.terminate() inconsistent behavior on Windows versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue14252> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14252] subprocess.Popen.terminate() inconsistent behavior on Windows
Dave Abrahams added the comment: By the way, the suggested fix would be for terminate() to return a value indicating if the process were already terminated, and not throw an exception in that case. For a user to handle the issue correctly on Windows is rather a nasty project involving a race between process death and the call to terminate() -- ___ Python tracker <http://bugs.python.org/issue14252> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] NamedTemporaryFile unusable under Windows
Dave Abrahams added the comment: Nick, not to belabor this, but I guess you don't understand the use-case in question very well, or you'd see that delete=False doesn't cover it. The use case is this: I have to write a test for a function that takes a filename as a parameter and opens and reads from the file with that name. The test should conjure up an appropriate file, call the function, check the results, and clean up the file afterwards. It doesn't matter when the file gets cleaned up, as long as it is cleaned up "eventually." Having to explicitly delete the file is exactly the kind of boilerplate one wants to avoid in situations like this. Even if Windows allows a file to be opened for reading (in some circumstances) when it is already open for writing, it isn't hard to imagine that Python might someday have to support an OS that didn't allow it under any circumstances. It is also a bit perverse to have to keep the file open for writing after you're definitively done writing it, just to prevent it from being deleted prematurely. I can understand most of the arguments you make against close-without-delete, except those (like the above) that seem to come from a "you shouldn't want that; it's just wrong" stance. -- ___ Python tracker <http://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9458] xml.etree.ElementTree.ElementTree.write(): encoding handling problems
Dave Abrahams added the comment: These bugs are annoying. How does one convert a set of examples into a patch? Do you mean you want these to become test cases? -- nosy: +dabrahams ___ Python tracker <http://bugs.python.org/issue9458> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1572710] cElementTree.SubElement doesn't recognize keyword "attrib"
Dave Abrahams added the comment:
@effbot, I think you may have misread the OP's example. The first two
arguments /are/ being passed positionally. In any case, there's a real bug
here. cElementTree seems to choke on uses of attrib. Change cElementTree to
ElementTree below and this one works, too.
>>> from xml.etree.cElementTree import Element, tostring
>>> print tostring(Element('foo', attrib={}))
Traceback (most recent call last):
File "bug.py", line 2, in
print tostring(Element('foo', attrib={}))
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
line 1127, in tostring
ElementTree(element).write(file, encoding, method=method)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
line 821, in write
serialize(write, self._root, encoding, qnames, namespaces)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
line 933, in _serialize_xml
v = _escape_attrib(v, encoding)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
line 1093, in _escape_attrib
_raise_serialization_error(text)
File
"/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/xml/etree/ElementTree.py",
line 1053, in _raise_serialization_error
"cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize {} (type dict)
--
nosy: +dabrahams
___
Python tracker
<http://bugs.python.org/issue1572710>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1572710] cElementTree.SubElement doesn't recognize keyword "attrib"
Dave Abrahams added the comment:
On second thought, I see what effbot is trying to say... but it's still a bug.
Given the way the interface is declared and the behavior of regular python
functions:
Element(tag, attrib={}, **extra)
indicates that I can pass attrib (or tag, for that matter) as a keyword
argument. Nothing in the documentation gives the C implementation permission
to behave differently.
--
___
Python tracker
<http://bugs.python.org/issue1572710>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9458] xml.etree.ElementTree.ElementTree.write(): encoding handling problems
Dave Abrahams added the comment: I won't get to this, FYI. -- ___ Python tracker <http://bugs.python.org/issue9458> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15531] os.path symlink docs missing
New submission from Dave Abrahams: the docs for os.path don't mention the following facts which I think are important (in fact I assumed the facts would be the reverse): os.path.realpath(l) works when l is a broken symbolic link, returning the path to the (missing) target os.path.readlink(l) causes an error when l is a broken symbolic link. -- assignee: docs@python components: Documentation messages: 167163 nosy: dabrahams, docs@python priority: normal severity: normal status: open title: os.path symlink docs missing type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue15531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15536] re.split doesn't respect MULTILINE
New submission from Dave Abrahams:
This session demonstrates. See especially the very last expression evaluated
>>> s='''this is the end
s='''this is the end
... your only friend
your only friend
... the end'''
the end'''
>>> re.split('^', s, re.MULTILINE)
re.split('^', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('t', s, re.MULTILINE)
re.split('t', s, re.MULTILINE)
['', 'his is ', 'he end\nyour only friend\n', 'he end']
>>> re.split('\n', s, re.MULTILINE)
re.split('\n', s, re.MULTILINE)
['this is the end', 'your only friend', 'the end']
>>> re.split('(?<=\n)', s, re.MULTILINE)
re.split('(?<=\n)', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('^y', s, re.MULTILINE)
re.split('^y', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('$', s, re.MULTILINE)
re.split('$', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('$\n', s, re.MULTILINE)
re.split('$\n', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('\n', s, re.MULTILINE)
re.split('\n', s, re.MULTILINE)
['this is the end', 'your only friend', 'the end']
>>> re.split('^t', s, re.MULTILINE)
re.split('^t', s, re.MULTILINE)
['', 'his is the end\nyour only friend\nthe end']
>>> re.split('^t', s)
re.split('^t', s)
['', 'his is the end\nyour only friend\nthe end']
>>>
--
components: Regular Expressions
messages: 167224
nosy: dabrahams, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.split doesn't respect MULTILINE
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue15536>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15537] MULTILINE confuses re.split
New submission from Dave Abrahams:
compare the output of
$ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print
len(re.split('\n(?=x)', open('/tmp/tst').read()))"
100
with
$ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print
len(re.split('\n(?=x)', open('/tmp/tst').read(), re.MULTILINE))"
9
--
components: Regular Expressions
messages: 167228
nosy: dabrahams, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: MULTILINE confuses re.split
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue15537>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15537] MULTILINE confuses re.split
Dave Abrahams added the comment: Dang! Thanks, and sorry for wasting everyone's time on this. -- ___ Python tracker <http://bugs.python.org/issue15537> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15531] os.path symlink docs missing
Dave Abrahams added the comment: MacOS 10.7 -- ___ Python tracker <http://bugs.python.org/issue15531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15531] os.path symlink docs missing
Dave Abrahams added the comment:
on Sat Aug 04 2012, Larry Hastings wrote:
> Larry Hastings added the comment:
>
> What does the following script print out?
>
> import os
>
> os.chdir('/tmp')
> os.symlink('--success--', 'foo')
> print("this should print --success-- :")
> print(os.readlink('foo'))
> os.unlink('foo')
--8<---cut here---start->8---
this should print --success-- :
--success--
--8<---cut here---end--->8---
So, I guess I don't know what was causing the symptom I observed.
--
___
Python tracker
<http://bugs.python.org/issue15531>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8557] subprocess PATH semantics and portability
Dave Abrahams added the comment:
New data point: in some contexts on Windows (not sure of the exact cause but I
was dealing with multiple drives), even this workaround isn't enough. I ended
up having to do something like this (i.e. manually search the path) on win32:
def full_executable_path(invoked, environ):
if os.path.splitext(invoked)[1]:
return invoked
explicit_dir = os.path.dirname(invoked)
if explicit_dir:
path = [ explicit_dir ]
else:
path = environ.get('PATH').split(os.path.pathsep)
extensions = environ.get(
'PATHEXT',
# Use *something* in case the environment variable is
# empty. These come from my machine's defaults
'.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1'
).split(os.path.pathsep)
for dir in path:
for ext in extensions:
full_path = os.path.join(dir, invoked+ext)
if os.path.exists( full_path ):
return full_path
return invoked # Not found; invoking it will likely fail
class Popen(subprocess.Popen):
def __init__(
self, args, bufsize=0, executable=None,
stdin=None, stdout=None, stderr=None,
preexec_fn=None, close_fds=False, shell=False,
cwd=None, env=None,
*args_, **kw):
if executable is None and not shell:
executable = full_executable_path(args[0], env or os.environ)
super(Popen,self).__init__(
args, bufsize, executable, stdin, stdout, stderr,
preexec_fn, close_fds, shell, cwd, env, *args_, **kw)
--
___
Python tracker
<http://bugs.python.org/issue8557>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8732] Should urrllib2.urlopen send an Accept-Encoding header?
New submission from Dave Abrahams : According to the RFC, the server is allowed to send back any encoding it likes when no Accept-Encoding header is supplied, but all the examples I can find of urllib2.urlopen usage assume they're getting plain text back. I think it would be better to inject an Accept-Encoding header when none is explicitly supplied so that nobody else trips over this issue. See http://support.github.com/discussions/site/1510 -- components: Library (Lib) messages: 105870 nosy: dabrahams priority: normal severity: normal status: open title: Should urrllib2.urlopen send an Accept-Encoding header? versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8732] Should urrllib2.urlopen send an Accept-Encoding header?
Dave Abrahams added the comment: How many tests did you run? My two tests were minutes apart. I have the feeling that this has something to do with cacheing behavior on the server. -- ___ Python tracker <http://bugs.python.org/issue8732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8927] Cannot handle complex requirement resolution
New submission from Dave Abrahams : [This looks like a bug report against PIP because Tarek told me distutils2 would be responsible for this kind of thing and that there was an open ticket for it. However, I can't find any such ticket so I'm posting it here] Not only does pip not check for conflicts as noted in http://bitbucket.org/ianb/pip/src/tip/pip/req.py#cl-928, it doesn't consider any requirements on a package other than the first. So if I have A requires B and C B requires D<=1.1 C requires D<=0.9 installing A will give us D==1.1 rather than D==0.9 Once responsibility for this functionality is sorted out, we may be able to close this ticket or http://bitbucket.org/ianb/pip/issue/119 -- assignee: tarek components: Distutils2 messages: 107214 nosy: dabrahams, tarek priority: normal severity: normal status: open title: Cannot handle complex requirement resolution type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue8927> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9057] Needs a home page
New submission from Dave Abrahams : This project needs a home page. I want to link to it from Ryppl docs, but anyone following a link to, e.g. the bitbucket wiki would think this project was weak at best. -- assignee: tarek components: Distutils2 messages: 108390 nosy: dabrahams, tarek priority: normal severity: normal status: open title: Needs a home page ___ Python tracker <http://bugs.python.org/issue9057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9057] Needs a home page
Dave Abrahams added the comment: Distutils2, sorry. -- ___ Python tracker <http://bugs.python.org/issue9057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9057] Distutils2 needs a home page
Dave Abrahams added the comment: Yes, I understand it's not ready for users. However, even a project in process can benefit from having a home page, to boost awareness and link connectivity. ATM there's no reasonably stable URL I can link to from http://ryppl.org/technology.html I would be happy to create such a page if this is too much trouble. It doesn't have to be very ambitious; just a notice saying D2 is under heavy development and links to relevant resources (e.g. bitbucket) would be fine. -- ___ Python tracker <http://bugs.python.org/issue9057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue515074] Extended storage in new-style classes
Dave Abrahams added the comment: I have no idea. I don't work with low-level python much anymore. Sorry Sent from my moss-covered three-handled family gradunza On May 17, 2013, at 8:54 PM, Ethan Furman wrote: > > Ethan Furman added the comment: > > David, is this still a need? Or, put another way, has Python change enough > in the last 11 years that you can now do what you wanted? > > -- > nosy: +ethan.furman > > ___ > Python tracker > <http://bugs.python.org/issue515074> > ___ -- ___ Python tracker <http://bugs.python.org/issue515074> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
