[issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies
Rebecka added the comment: Akira is correct: using time.mktime to produce the expiration date for the cookie is wrong (thank you very much for the pointers!). Using e.g. http.cookiejar.http2time with a HTTP formatted date string gives a correct time stamp (with which cookie.is_expired succeeds), so this was not a bug (just user error...). -- resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22166] test_codecs leaks references
Nick Coghlan added the comment: Yeah, the unique name was a hack to deal with the fact I couldn't unregister anything. As a simpler short term fix for the reference leak, perhaps it would be worth trying a call to traceback.clear_frames(caught) as a new final line in ExceptionChainingTest.assertWrapped? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22166 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19826] Document that bug reporting by email is possible
Mark Lawrence added the comment: I agree with David, I've noticed several messages recently that are mostly untrimmed replies to email so essentially have no actual content. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19826 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22296] cookielib uses time.time(), making incorrect checks of expiration times in cookies
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos
STINNER Victor added the comment: Ping Igor. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22323] Rewrite PyUnicode_AsWideChar() and PyUnicode_AsWideCharString()
STINNER Victor added the comment: There is no patch. You're right. Here it is. -- keywords: +patch Added file: http://bugs.python.org/file36527/unicode_aswidechar.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22323 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6331] Add unicode script info to the unicode database
Elizabeth Myers added the comment: I think this needs to be fixed, then - we need to study why there are so many new records (e.g. what script contributes most new records), and then look for alternatives. The Common script appears to be very fragmented and may be the cause of the issues. One alternative could be to create a separate Trie for scripts. Not having seen the one in C yet, I have one written in Python, custom-made for storing the script database, based on the general idea of a range tree. It stores ranges individually straight out of Scripts.txt. The general idea is you take the average of the lower and upper bounds of a given range (they can be equal). When searching, you compare the codepoint value to the average in the present node, and use that to find which direction to search the tree in. Without coalescing neighbouring ranges that are the same script, I have 1,606 nodes in the tree (for Unicode 7.0, which added a lot of scripts). After coalescing, there appear to be 806 nodes. If anyone cares, I'll be more than happy to post code for inspection. I don't know what this will be used for, but one application is certainly regular expressions. So we need an efficient test whether the character is in the expected script or not. It would be bad if such a test would have to do a .lower() on each lookup. This is actually required for restriction-level detection as described in Unicode TR39, for all levels of restriction above ASCII-only (http://www.unicode.org/reports/tr39/#Restriction_Level_Detection). -- nosy: +Elizacat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6331 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos
Igor Pashev added the comment: Yes, Victor. Your patch works. All os tests are passed :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos
Roundup Robot added the comment: New changeset 27cef7476f2b by Victor Stinner in branch '3.4': Closes #22258: Fix the the internal function set_inheritable() on Illumos. http://hg.python.org/cpython/rev/27cef7476f2b New changeset 4a51c45f405b by Victor Stinner in branch 'default': (Merge 3.4) Closes #22258: Fix the the internal function set_inheritable() on http://hg.python.org/cpython/rev/4a51c45f405b -- nosy: +python-dev resolution: - fixed stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22258] set_inheritable(): ioctl(FIOCLEX) is available but fails with ENOTTY on Illumos
STINNER Victor added the comment: Yes, Victor. Your patch works. All os tests are passed :-) Thanks for the tests. I pushed my fix to Python 3.4 3.5. -- stage: resolved - versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22258 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22325] wrong subtraction result
New submission from Constantino Antunes: I was using python as my calculator when I got a result which had to be rounded to be the value I expected. So I made some tests with a simple case. Given that 0.38 - 0.20 = 0.18, then 1000.38 - 1000.20 should be also 0.18. Here is this calculation done on three different systems: Python 2.7.5 (default, Mar 9 2014, 22:15:05) [GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.0.68)] on darwin Type help, copyright, credits or license for more information. 0.38 - 0.20 0.18 test = lambda x: (x+0.38) - (x+0.20) test(0) 0.18 test(1000) 0.179994998 test(100) 0.185122274 test(10) 0.179475479126 test(1) 0.1800537109375 test(1000) 0.125 --- Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2] on linux2 Type help, copyright, credits or license for more information. 0.38 - 0.20 0.18 test = lambda x: (x+0.38) - (x+0.20) test(0) 0.18 test(1000) 0.179994998 test(1000) 0.125 --- Python 2.4.3 (#1, Oct 23 2012, 22:02:41) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux2 Type help, copyright, credits or license for more information. 0.38 - 0.20 0.17999 test = lambda x: (x+0.38) - (x+0.20) test(0) 0.17999 test(1000) 0.179994998 test(1000) 0.125 -- messages: 226270 nosy: Constantino.Antunes priority: normal severity: normal status: open title: wrong subtraction result versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22325 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems
New submission from Frank Thommen:
Hi,
tempfile.TemporaryFile fails on NFS v4 filesystems.
Assume the following mounts:
$ mount
[...]
psi:/volumes/vol1 on /mnt/nfsv4 type nfs4 (rw,addr=xx.xx.xx.xx)
psi:/volumes/vol1 on /mnt/nfsv3 type nfs (rw,addr=xx.xx.xx.xx)
[...]
$
and the following script testtmpfile.py:
---
#! env python
import tempfile
def _is_writable_dir_unnamed(p):
try:
t = tempfile.TemporaryFile(dir=p)
t.write('1')
t.close()
except OSError: return False
else: return True
def _is_writable_dir_named(p):
try:
t = tempfile.NamedTemporaryFile(dir=p)
t.write('1')
t.close()
except OSError: return False
else: return True
if not _is_writable_dir_unnamed(.):
print (unnamed) . is not writable
else:
print (unnamed) OK
if not _is_writable_dir_named(.):
print (named) . is not writable
else:
print (named) OK
---
Then you'll find the following behaviour:
$ pwd
/mnt/nfsv4
$ /g/software/bin/python-2.7 /tmp/testtmpfile.py
(unnamed) . is not writable
(named) OK
$
$ pwd
/mnt/nfsv3
$ /g/software/bin/python-2.7 /tmp/testtmpfile.py
(unnamed) OK
(named) OK
$
Additionally in the failing case, a - writable - temporary file named tmp* is
left in the directory.
Observed on CentOS 5.10 with kernel 2.6.18-371.11.1.el5 and on CentOS 6.5 with
kernel 2.6.32-431.23.3.el6.x86_64.
The problem appears with Python 2.4, 2.6 and 2.7.
Cheers
frank
--
messages: 226271
nosy: drosera
priority: normal
severity: normal
status: open
title: tempfile.TemporaryFile fails on NFS v4 filesystems
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22326
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22325] wrong subtraction result
R. David Murray added the comment: https://docs.python.org/2/tutorial/floatingpoint.html -- nosy: +r.david.murray resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22325 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems
R. David Murray added the comment: What is the actual OSError raised? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22326 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10312] intcatcher() can deadlock
Changes by Claudiu Popa pcmantic...@gmail.com: -- nosy: -Claudiu.Popa ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10312 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18766] IDLE: Autocomplete in editor doesn't work for un-imported modules
Changes by Saimadhav Heblikar saimadhavhebli...@gmail.com: -- nosy: +sahutd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18766 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19826] Document that bug reporting by email is possible
Brett Cannon added the comment: And I agree with David and Mark. Thanks for the attempt at a patch, Mike, but in hindsight we are going to have to turn down your contribution. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19826 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems
Frank Thommen added the comment: errno:5 strerror: Input/output error -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22326 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19826] Document that bug reporting by email is possible
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: needs patch - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19826 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems
STINNER Victor added the comment: I tried on my Fedora 20 (Linux, kernel 3.14.8-200.fc20.x86_64) and I'm unable to reproduce the issue. $ sudo mkdir /test $ sudo chown haypo: /test $ echo /test *(rw) /etc/exports $ sudo exportfs -af $ sudo mount -t nfs localhost:/test nfs $ cat x.py copy/paste the code from the first message of this issue $ python x.py (unnamed) OK (named) OK $ mount|grep nfs localhost:/test on /home/haypo/nfs type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1) $ python -V Python 2.7.5 -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22326 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22326] tempfile.TemporaryFile fails on NFS v4 filesystems
Frank Thommen added the comment: Agreed. If I export from CentOS and mount on CentOS (local or remote) it seems to work. So this is probably due to our specific fileserver setup or a problem of the underlying filesystem (zfs). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22326 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21527] concurrent.futures.ThreadPoolExecutor does not use a default value
Roundup Robot added the comment: New changeset 2805b0dca798 by Guido van Rossum in branch 'default': Closes #21527: Add default number of workers to ThreadPoolExecutor. (Claudiu Popa.) http://hg.python.org/cpython/rev/2805b0dca798 -- nosy: +python-dev resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21527 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22253] ConfigParser does not handle files without sections
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22253 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under optional arguments
Oliver Smith added the comment: The term optional arguments is a poorly formed adjectival suffix of option. What it's trying to say is these are kwargs rather than these arguments are not compulsory. I ran into this issue with 3.4 and was looking to file a simple change request: In early DOS/Linux days we called these switches. I suggest we simply change the default wording from optional arguments to switches. -- nosy: +Oliver.Smith Added file: http://bugs.python.org/file36528/parrot.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22327] test_gdb failures on Ubuntu 14.10
New submission from Barry A. Warsaw: Lots of them, just like this: == FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests) Ensure that a PyObject* with NULL ob_type is handled gracefully -- Traceback (most recent call last): File /home/barry/projects/python/cpython/Lib/test/test_gdb.py, line 449, in test_NULL_ob_type 'set v-ob_type=0') File /home/barry/projects/python/cpython/Lib/test/test_gdb.py, line 420, in assertSane cmds_after_breakpoint=cmds_after_breakpoint) File /home/barry/projects/python/cpython/Lib/test/test_gdb.py, line 206, in get_gdb_repr import_site=import_site) File /home/barry/projects/python/cpython/Lib/test/test_gdb.py, line 184, in get_stack_trace self.assertEqual(unexpected_errlines, []) AssertionError: Lists differ: [Got object file from memory but can't read symbols: File truncated.] != [] First list contains 1 additional elements. First extra element 0: Got object file from memory but can't read symbols: File truncated. - [Got object file from memory but can't read symbols: File truncated.] + [] -- components: Tests messages: 226280 nosy: barry priority: normal severity: normal status: open title: test_gdb failures on Ubuntu 14.10 versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22327 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22327] test_gdb failures on Ubuntu 14.10
Changes by Barry A. Warsaw ba...@python.org: -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22327 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22328] ur'foo\d' raises SyntaxError
New submission from Markus Unterwaditzer: The string literal `ur'foo\d'` causes a SyntaxError while the equivalent `r'foo\d'` causes the correct string to be produced. -- components: Interpreter Core messages: 226281 nosy: untitaker priority: normal severity: normal status: open title: ur'foo\d' raises SyntaxError type: behavior versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22328 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22328] ur'foo\d' raises SyntaxError
R. David Murray added the comment: This is a conscious design decision. See issue 15096. -- nosy: +r.david.murray resolution: - not a bug stage: - resolved status: open - closed superseder: - Drop support for the ur string prefix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22328 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22043] Use a monotonic clock to compute timeouts
Roundup Robot added the comment: New changeset 330bd57685fc by Victor Stinner in branch 'default': Issue #22043: Fix _PyTime_gettimeofday() if HAVE_GETTIMEOFDAY http://hg.python.org/cpython/rev/330bd57685fc -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22043] Use a monotonic clock to compute timeouts
Roundup Robot added the comment: New changeset b12857782041 by Victor Stinner in branch 'default': Issue #22043: time.monotonic() is now always available http://hg.python.org/cpython/rev/b12857782041 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22043 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Changes by Danek Duvall duv...@comfychair.org: -- nosy: +dhduvall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Danek Duvall added the comment: As a distribution maintainer of several Python modules, I've run into this bug twice in the past week. In each case, the python file in question had a SyntaxError and failed to compile, but the error just scrolled past in a large log and was missed because no failure occurred until we attempted to package the result, and the .pyc files were missing. While we managed to track the problem down fairly easily in both cases, if we only had folks working on the problem that didn't have lots of experience in tracking down build issues, this could have wasted a lot of otherwise valuable engineering time. I understand the desire to be able to package files that fail to compile, but having that be the default seems to me like it fails basic expectations, even given how long this bug has been around. I can't imagine that the number of deliberately-broken python files is particularly large compared to the number of python files that might get broken accidentally (or files that are broken for one version of python but not another) and so being required to maintain an exception list doesn't seem unreasonable. (Neither does some amount of transition period -- one or two minor releases of Python? -- between the introduction of the mechanism and the change of the default.) Would people be interested in a patch to that effect? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under optional arguments
Terry J. Reedy added the comment: To me, the mistake is contrasting 'positional' versus 'optional'. The proper contrasts are 'positional' versus 'named' or 'keyword' -- I believe these are mutually exclusive for command lines -- and 'required' versus 'optional. The two axes (contrasts) are orthogonal. Where are optional positional parameters listed? If, as I presume, they are listed as 'positional' and given that all keyword arguments are already listed in the so-called 'optional' section, I think we should regard 'optional' as a misspelling of 'keyword'. That is a word already familiar to python programmers. The change should only be made in default for the same reason we do not correct minor errors in exception messages in bugfix releases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Éric Araujo added the comment: Again, I think this behaviour was a deliberate decision, not a patch. Developers should use tests to detect syntax errors in their code, not rely on distutils byte compilation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Éric Araujo added the comment: a deliberate decision, not a bug* -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7918] distutils always ignores byte compilation errors
Danek Duvall added the comment: Absolutely true that developers should have tests that would detect such bugs. However, the sooner you detect a bug, the more time you save. And by the time it reaches someone like me, who is just packaging up the module for distribution with an OS, it's just going to waste my time, too, with less benefit (because I'm still not going to have much of an incentive to write tests). Imagine if your C compiler only warned about code that wouldn't compile, and failed to produce the corresponding .o file without erroring out, and the linker failed to error out when that .o file was missing, and that you only noticed the problem when you ran your tests (or, if you're just shipping someone else's code, when your customer calls you to complain). Wouldn't you think that was stunningly broken? Again, I get that there are use cases for having broken code pass through unscathed, but it seems very odd to me (as someone with a long unix background) that this would have been a conscious default. Now that it is the default, I understand the need for caution, but caution needn't (and shouldn't) prevent bugs from getting fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7918 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse required arguments displayed under optional arguments
R. David Murray added the comment: In unix parlance, they are arguments and options (or, sometimes, flags). And then required or not required. So, argparse follows unix precedent here, except that it calls them optional arguments, because everything is added via add_argument. Which is why I suggested changing the label to just 'options'. But I could see using 'switches' instead, that's less ambiguous, and is the term used on Windows (albeit with a different standard syntax). However, every unix man page uses the term 'options'. I definitely think 'keywords' is not a good idea. That's crossing the streams (python parlance versus shell parlance). argparse is building a bridge to the shell world, and should use its terminology for the bits of shell stuff it is implementing...most especially in the default help display. Note that, reading the issue history, the argparse maintainer is urging a doc change only (how to fix the help if you run into this issue), not a behavior change. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9694 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22329] Windows installer can't recover partially installed state
New submission from Llelan D.: Python v3.4.1 x64 on Windows 7 x64. If the python installation directory is deleted, the installer can not remove, change, or repair the installation. When I run the python-3.4.1.amd64.msi installer and choose Remove, it gives me a dialog saying a required file is missing about halfway through. It gives me no clue as to what this file is. If I choose Repair, it gives me a dialog saying The specified account already exists about halfway through. Totally cryptic. If I choose Change and either select that all features or no features will be installed, it gives me a dialog saying The specified account already exists about halfway through. It turns out that the installer is relying on both files in the installation directory and a Windows Intaller key. If the required files are missing, the installer refuses to either remove or repair. If the Windows Installer key still exists, the installer refuses to re-install. When this key is removed, an install can then be done. To be safe, a remove should then be done to clear up any problems and then another clean install. Both of these requirement violate good MSI practice. You are *NEVER* to use a Windows Installer key as an indication of the installed state because that list can be, and often is, easily corrupted. The installer should always be able to perform a complete repair and especially remove without requiring *ANY* installed files or registry keys. This installer desperately needs a complete re-write. It should use its own key to indicate whether the application is installed but should not depend on it in case of a partially installed/removed state, should not require any installed file or registry key to fully repair or remove the application, should be able to re-install no matter the state of a previous installation, and should query the user if any information required is missing from the installation or registry. In other words, the normal MSI installer guidelines. -- components: Installation messages: 226291 nosy: LlelanD, steve.dower priority: normal severity: normal status: open title: Windows installer can't recover partially installed state type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22327] test_gdb failures on Ubuntu 14.10
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22327 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22329] Windows installer can't recover partially installed state
Terry J. Reedy added the comment: I and at least one other person reporting on python-list have had similar problems trying to update an installation. -- nosy: +terry.reedy stage: - needs patch versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22329 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22329] Windows installer can't recover partially installed state
Steve Dower added the comment:
I've been working on the rewrite for 3.5 already (progress at
http://hg.python.org/sandbox/steve.dower) - redoing the installer completely
was one of the conditions for when I signed on to own it.
Martin is still responsible for 3.4, and I'm building 2.7 as required but not
working on the installer at all.
If this bug needs to be fixed in 3.4, it should be assigned to Martin.
Otherwise, if it only needs to be fixed in 3.5, it can be assigned to me and
I'll (try and) remember to make this scenario work. (Basically, uninstall may
need to reinstall some files - this is probably the uninstall step for pip, but
I'm not 100% sure.)
To find out exactly what isn't working, you should be able to run the following
command:
msiexec /l*vx log.txt /x {D54842CB-F761-30BA-881F-1FF821DC44DF}
log.txt can be a full path to any location - the UUID is the product code for
3.4.1 x64. You can attach it here and I'll take a look, or you can check it
yourself for the error. Either way, I don't intend to fix it for 3.4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22329
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
