[issue21657] pip.get_installed_distributions() Does not return packages in the current working directory
David Fraser added the comment: Filed with pypa at https://github.com/pypa/pip/issues/3091 -- nosy: +davidfraser ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11629] Reference implementation for PEP 397
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8863] Display Python backtrace on SIGSEGV, SIGFPE and fatal error
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7980] time.strptime not thread safe
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7980 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7989] Add pure Python implementation of datetime module to CPython
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7989 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8032] Add gdb7 hooks to make it easier to debug Python
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8032 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6132] Implement the GIL with critical sections in Windows
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6132 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6689] subprocess doesn't pass arguments correctly on Linux when shell=True
David Fraser dav...@sjsoft.com added the comment: Ah, upon closer inspection - the special parameters $0 $1 $2 etc mentioned in the sh docs refer to parameters within the command string, so that: sh -c 'echo $2 $0 $1' run for the people produces: the people run for So the correct patch would be to leave out the extra parameters and just have the quoted string... The question then becomes, is simple .join(args) sufficient or should there be some quoting of them... attaching a patch in the meantime although that needs to be resolved. -- Added file: http://bugs.python.org/file14718/subprocess-shell-args-2.6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6689] subprocess doesn't pass arguments correctly on Linux when shell=True
Changes by David Fraser dav...@sjsoft.com: Removed file: http://bugs.python.org/file14697/current-2.6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6689] subprocess doesn't pass arguments correctly on Linux when shell=True
Changes by David Fraser dav...@sjsoft.com: Removed file: http://bugs.python.org/file14698/current-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2304] subprocess under windows fails to quote properly when shell=True
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2304 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6689] subprocess doesn't pass arguments correctly on Linux when shell=True
New submission from David Fraser dav...@sjsoft.com: (from http://stackoverflow.com/questions/1253122/why-does-subprocess-popen-with-shelltrue-work-differently-on-linux-vs-windows/1254322) When using subprocess.Popen(args, shell=True) to run gcc --version (just as an example), on Windows we get this: from subprocess import Popen Popen(['gcc', '--version'], shell=True) gcc (GCC) 3.4.5 (mingw-vista special r3) ... So it's nicely printing out the version as I expect. But on Linux we get this: from subprocess import Popen Popen(['gcc', '--version'], shell=True) gcc: no input files Because gcc hasn't received the --version option. The docs don't specify exactly what should happen to the args under Windows, but it does say, on Unix, If args is a sequence, the first item specifies the command string, and any additional items will be treated as additional shell arguments. IMHO the Windows way is better, because it allows you to treat Popen(arglist) calls the same as Popen(arglist, shell=True) ones. The strange implementation is actually the UNIX one, which does the following (where each space separates a different argument): /bin/sh -c gcc --version It looks like the correct implementation (at least on Linux) would be: /bin/sh -c gcc --version gcc --version Since this would set the command string from the quoted parameters, and pass the other parameters successfully. From the sh man page section for -c: Read commands from the command_string operand instead of from the standard input. Special parameter 0 will be set from the command_name operand and the positional parameters ($1, $2, etc.) set from the remaining argument operands. This patch seems to fairly simply do the trick, as well as testing it. -- components: Library (Lib) files: current-2.6.patch keywords: patch messages: 91492 nosy: davidfraser severity: normal status: open title: subprocess doesn't pass arguments correctly on Linux when shell=True type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file14697/current-2.6.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6689] subprocess doesn't pass arguments correctly on Linux when shell=True
Changes by David Fraser dav...@sjsoft.com: Added file: http://bugs.python.org/file14698/current-3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6689 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5482] RFC: improve distutils bdist_rpm so it builds pure python modules as single packages that works across architectures
Changes by David Fraser dav...@sjsoft.com: -- nosy: +davidfraser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs and epoch method
David Fraser [EMAIL PROTECTED] added the comment: - Alexander Belopolsky [EMAIL PROTECTED] wrote: Alexander Belopolsky [EMAIL PROTECTED] added the comment: I would like to voice my opposition the totimestamp method. Representing time as a float is a really bad idea (originated at Microsoft as I have heard). In addition to the usual numeric problems when dealing with the floating point, the resolution of the floating point timestamp varies from year to year making it impossible to represent high resolution historical data. In my opinion both time.time() returning float and datetime.fromtimestamp() taking a float are both design mistakes and adding totimestamp that produces a float will further promote a bad practice. The point for me is that having to interact with Microsoft systems that require times means that the conversions have to be done. Is it better to have everybody re-implement this, with their own bugs, or to have a standard implementation? I think it's clearly better to have it as a method on the object. Of course, we should put docs in describing the pitfalls of this approach... ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs and epoch method
David Fraser [EMAIL PROTECTED] added the comment: - STINNER Victor [EMAIL PROTECTED] wrote: STINNER Victor [EMAIL PROTECTED] added the comment: Timedelta formats: (a) Win64: 64 bits unsigned integer, number of 1/10 microsecond - file format: Microsoft Word document (.doc), ASF video (.asf) (b) 64 bits float, number of seconds - file format: AMF metadata used in Flash video (.flv) There are also the PyWinTime objects returned by PythonWin COM calls which are basically FILETIMEs I don't have time to get the details now but I recently submitted a patch to make them work with milliseconds - see http://sourceforge.net/tracker/index.php?func=detailaid=2209864group_id=78018atid=551954 (yes I know this is a bit off-topic here) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2517] Error when printing an exception containing a Unicode string
Changes by David Fraser [EMAIL PROTECTED]: -- nosy: +davidfraser ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2517] Error when printing an exception containing a Unicode string
David Fraser [EMAIL PROTECTED] added the comment: Aha - the __unicode__ method was previously there in Python 2.5, and was ripped out because of the unicode(Exception) problem. See http://bugs.python.org/issue1551432. The reversion is in http://svn.python.org/view/python/trunk/Objects/exceptions.c?rev=51837r1=51770r2=51837 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1551432] __unicode__ breaks for exception class objects
David Fraser [EMAIL PROTECTED] added the comment: Note that this causes problems with converting Exceptions to unicode - see http://bugs.python.org/issue2517 -- nosy: +davidfraser ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1551432 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2517] Error when printing an exception containing a Unicode string
David Fraser [EMAIL PROTECTED] added the comment: So I've got a follow-up patch that adds tp_unicode. Caveat that I've never done anything like this before and it's almost certain to be wrong. It does however generate the desired result in this case :-) Added file: http://bugs.python.org/file10562/tp_unicode_exception.patch ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2517 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2809] string docstring doesn't mention that ' '.split() != ' '.split(' ')
David Fraser [EMAIL PROTECTED] added the comment: Yes that's fantastic, thanks :-) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2809 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2809] string docstring doesn't mention that ' '.split() != ' '.split(' ')
David Fraser [EMAIL PROTECTED] added the comment:
I don't think this really addresses the issue properly...
The original docstring read:
+Note that not specifying sep (or using None) will cause\n\
+empty strings to be removed from the output. thus ' '.strip()\n\
+returns []. while ' '.strip(' ') returns ['', ''].
(Obviously strip is wrong here, it should be split)
The committed docstring reads:
+If sep is not specified or is None, any whitespace string is a
separator and leading and trailing whitespace is stripped before splitting.
But the point is not just that leading and trailing whitespace is
stripped; ''.strip() returns [] while ''.strip(' ') returns ['']. This
is probably the most unexpected corner case; it seems to be better to
say that empty strings are removed from the output.
--
nosy: +davidfraser
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2809
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777412] Python's strftime dislikes years before 1900
David Fraser [EMAIL PROTECTED] added the comment: I have a patch for this, but I don't know which platforms have the problem. On Linux, strftime seems to work fine. Attaching the patch as a work in progress... -- keywords: +patch nosy: +davidfraser Added file: http://bugs.python.org/file10253/strftime-pre-1900.patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777412 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777412] Python's strftime dislikes years before 1900
David Fraser [EMAIL PROTECTED] added the comment: Which version of Python are you using? I could have sworn we just fixed this problem in CVS a couple weeks ago. This was on the latest Python 2.6 svn... but looking at the py3k branch with viewsvn the code is definitely still there too... The relevant commit seems to be r30224 in 2002: I give up: unless I write my own strftime by hand, datetime just can't be trusted with years before 1900, so now we raise ValueError if a date or datetime or datetimetz .strftime() method is called with a year before 1900. Of course I'm not dealing with any of this in the attached patch, but then I don't have the information on which platforms have the problem... but according to the above writing strftime by hand would be the only solution... _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1777412 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs and epoch method
Changes by David Fraser [EMAIL PROTECTED]: -- nosy: +davidfraser __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2736 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
