[issue21172] Unexpected behaviour with logging.LogRecord first arg is dict case
Roundup Robot added the comment: New changeset d08e3586dde3 by Vinay Sajip in branch '2.7': Issue #21172: isinstance check relaxed from dict to collections.Mapping. http://hg.python.org/cpython/rev/d08e3586dde3 New changeset 5e303360db14 by Vinay Sajip in branch '3.4': Issue #21172: isinstance check relaxed from dict to collections.Mapping. http://hg.python.org/cpython/rev/5e303360db14 New changeset 8e6b8cfeb172 by Vinay Sajip in branch 'default': Closes #21172: Merged fix from 3.4. http://hg.python.org/cpython/rev/8e6b8cfeb172 -- nosy: +python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21172 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1100942] Add datetime.time.strptime and datetime.date.strptime
Changes by Maciej Szulik solt...@gmail.com: -- hgrepos: -232 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1100942 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21194] json.dumps with ensure_ascii=False doesn't escape control characters
New submission from Weeble: The JSON spec (http://www.json.org/) does not allow unescaped control characters. (See the railroad diagram for strings and the grammar on the right.) If json.dumps is called with ensure_ascii=False, it fails to escape control codes in the range U+007F to U+009F. Here's an example: import json import unicodedata for i in range(256): ... jsonstring = json.dumps(chr(i), ensure_ascii=False) ... if any(unicodedata.category(ch) == 'Cc' for ch in jsonstring): ... print(Fail:,repr(chr(i))) Fail: '\x7f' Fail: '\x80' Fail: '\x81' Fail: '\x82' Fail: '\x83' Fail: '\x84' Fail: '\x85' Fail: '\x86' Fail: '\x87' Fail: '\x88' Fail: '\x89' Fail: '\x8a' Fail: '\x8b' Fail: '\x8c' Fail: '\x8d' Fail: '\x8e' Fail: '\x8f' Fail: '\x90' Fail: '\x91' Fail: '\x92' Fail: '\x93' Fail: '\x94' Fail: '\x95' Fail: '\x96' Fail: '\x97' Fail: '\x98' Fail: '\x99' Fail: '\x9a' Fail: '\x9b' Fail: '\x9c' Fail: '\x9d' Fail: '\x9e' Fail: '\x9f' -- components: Library (Lib) messages: 215868 nosy: weeble priority: normal severity: normal status: open title: json.dumps with ensure_ascii=False doesn't escape control characters type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21194] json.dumps with ensure_ascii=False doesn't escape control characters
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti, pitrou, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20539] math.factorial may throw OverflowError
Stefan Krah added the comment: OverflowError during initialization dates back to the early days of Python: http://hg.python.org/cpython/rev/0437738279a8 Integer arithmetic actually did raise OverflowError back then: 2 * 22 Traceback (most recent call last): File stdin, line 1, in ? OverflowError: integer multiplication This of course no longer happens, so the whole idea of OverflowError seems slightly outdated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11838] IDLE: make interactive code savable as a runnable script
Terry J. Reedy added the comment: #21140 is about saving Output Window (renamed) as .txt instead of .py. Same method should be used to save shell log as .txt. My idea is that File menu for shell window should, if possible, have both Save as log Save as runnable code -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11838 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
New submission from Eric O. LEBIGOT: The documentation for a None (empty) format for floats indicates that it is equivalent to the g format. This does not appear to be correct (http://stackoverflow.com/questions/16525924/precise-definition-of-float-string-formatting). The Python 3.4 documentation (https://docs.python.org/3.4/library/string.html#format-specification-mini-language) seems to be much closer to what Python 2.7 does. It would be useful to have a more correct documentation for the effect of a None format for floats in Python 2.7 (maybe by copying the Python 3.4 documentation if it applies). -- assignee: docs@python components: Documentation messages: 215871 nosy: docs@python, lebigot priority: normal severity: normal status: open title: None float format: incomplete documentation type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21196] Name mangling example in Python tutorial
New submission from Chandan Kumar: The example used for demonstrating name mangling could be better if two versions of code are shown - one with name mangling and one without. I have modified the original example to incorporate this (see attached). -- assignee: docs@python components: Documentation files: name_mangling_works.py messages: 215872 nosy: chandan, docs@python, rhettinger priority: normal severity: normal status: open title: Name mangling example in Python tutorial type: enhancement Added file: http://bugs.python.org/file34781/name_mangling_works.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21196 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20539] math.factorial may throw OverflowError
Mark Dickinson added the comment: Looks like this harmless-looking issue has opened up a can of worms. the whole idea of OverflowError seems slightly outdated. Well, not entirely. It's still got a place for overflow of mathematical operations, and I think it's clearly the correct exception in that case (indeed, it's about the only case I can think of where OverflowError is clearly the correct exception). from math import exp exp(5000.0) Traceback (most recent call last): File stdin, line 1, in module OverflowError: math range error I'd treat conversion to float as a special case of this; that is, the following is another case where OverflowError is (IMO) the right thing to use: float(10**1000) Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to float A less clear-cut case: sqrt(10**500) Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to float This one still seems okay to me, even though the sqrt result *is* within the floating-point range. You can read this as two operations: a conversion from the integer input to a float, followed by a floating-point square root operation, and it's the intermediate result that overflows. And a case that's clearly wrong: 53 10**100 # Why not simply return 0? Traceback (most recent call last): File stdin, line 1, in module OverflowError: Python int too large to convert to C ssize_t Another historical oddity is that OverflowError inherits from ArithmeticError (along with FloatingPointError and ZeroDivisionError), which supports its use for arithmetic and mathematical operations that overflow their target type. OverflowError.__mro__ (class 'OverflowError', class 'ArithmeticError', class 'Exception', class 'BaseException', class 'object') In the interests of moving this *particular* issue forward, I'll revert to OverflowError for this patch. I still personally think it's the wrong exception, but: (1) It's not more wrong than before: we were already raising OverflowError for large positive values. (2) It achieves the main aim of replacing an obscure error message with a more understandable one (which is what Nick wanted in the first place: msg210454). (3) Given the lack of clarity about which exception types are appropriate where, I think we shouldn't be changing exception types unless/until there's a clear vision of where we want to end up. Getting that clear vision may require a python-dev discussion. We can still make the change from OverflowError to ValueError at some later point once it's clear that that's the right thing to do. But converting from OverflowError to ValueError now, and then deciding later that that was wrong and converting back to OverflowError would be a horrible thing to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21196] Name mangling example in Python tutorial
Chandan Kumar added the comment: Adding the second code sample, since only one attachment allowed at one go. -- Added file: http://bugs.python.org/file34782/without_name_mangling.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21196 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21196] Name mangling example in Python tutorial
Chandan Kumar added the comment: Here is a link to the documentation section in question: https://docs.python.org/2/tutorial/classes.html#private-variables-and-class-local-references -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21196 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21161] list comprehensions don't see local variables in pdb in python3
Jurko Gospodnetić added the comment: Just ran into this problem and it's so uncomfortable researching dynamic structures at run-time using PDB without this. :-( As a workaround, you can use a trick similar to this one to 'import' your locals into the list comprehension body: [l['r'](x) for l in (locals(),) for x in l['some_local']] assuming 'r' 'some_local' are two local variables in your surrounding scope. Ugly, but at least it can be made/forced to work if needed... Best regards, Jurko Gospodnetić -- nosy: +Jurko.Gospodnetić versions: +Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21161 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20539] math.factorial may throw OverflowError
Stefan Krah added the comment: Mark Dickinson rep...@bugs.python.org wrote: the whole idea of OverflowError seems slightly outdated. Well, not entirely. It's still got a place for overflow of mathematical operations, and I think it's clearly the correct exception in that case (indeed, it's about the only case I can think of where OverflowError is clearly the correct exception). Indeed, I was focusing on integer arithmetic and assignments. For float operations and conversions OverflowError is quite natural. (3) Given the lack of clarity about which exception types are appropriate where, I think we shouldn't be changing exception types unless/until there's a clear vision of where we want to end up. Getting that clear vision may require a python-dev discussion. Using OverflowError for now sounds like a good plan. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
Eric V. Smith added the comment: An empty format specifier can (and to my knowledge, does) match str(). So you get: format(1e10, '') '100.0' format(1e10, 'g') '1e+10' str(1e10) '100.0' The SO question is asking about an empty presentation type, which is indeed similar to 'g' for floats. I think this is all the same in 2.7 and 3.4, with the exception of how str() might operate on floats. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20539] math.factorial may throw OverflowError
Roundup Robot added the comment: New changeset 273e17260d25 by Mark Dickinson in branch 'default': Issue #20539: Improve math.factorial error messages and types for large inputs. http://hg.python.org/cpython/rev/273e17260d25 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
Eric O. LEBIGOT added the comment: These examples are good. I am confused, though, about The SO question is asking about an empty presentation type, which is indeed similar to 'g' for floats.: the question is actually about why the '' format gives a result that differs from the 'g' format despite the Python 2.7 documentation saying that a None format type is The same as 'g'.. Both the SO question and your examples show that the Python 2.7 documentation is incorrect, unless the other commenters and I were missing something… Clarifying the documentation would in any case be useful, as the comments to the SO question show… -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20539] math.factorial may throw OverflowError
Mark Dickinson added the comment: Patch applied to the default branch (but with OverflowError instead of ValueError for large positive inputs). I don't see a lot of benefit in applying the fix to the maintenance branches. Closing this issue. -- resolution: - fixed status: open - closed versions: +Python 3.5 -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20539 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided
Changes by Mark Dickinson dicki...@gmail.com: -- assignee: - mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided
Mark Dickinson added the comment:
I was wondering how the TypeError got there in the first place. Diving into
the history is instructive: changeset cdfdd5359411 modified the exception
message:
taniyama:cpython mdickinson$ hg log -r19719
changeset: 19719:cdfdd5359411
branch: legacy-trunk
user:Tim Peters tim.pet...@gmail.com
date:Wed Sep 05 06:24:58 2001 +
summary: Make the error msgs in our pow() implementations consistent.
Before that change, the code looked like this:
if (x != Py_None) {
PyErr_SetString(PyExc_TypeError, integer pow() arg
3 must not be specified when arg 2 is 0);
return NULL;
}
From that point of view the TypeError makes more sense: it's complaining about
the wrong number of arguments rather than the negative value. The current
message changes the perspective, and I agree that ValueError makes more sense.
Tim: any objections to changing the exception type from TypeError to ValueError
for Python 3.5?
I'd prefer not to change it for 2.7 or 3.4: there's an (admittedly probably
quite low) risk of code breakage, and little real gain to offset that breakage.
--
nosy: +tim.peters
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21193
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21197] venv does not create lib64 directory and appropriate symlinks
New submission from Matthias Dahl: Creating a new venv on a multilib system does not install an appropriate link from lib to lib64 or the other way around. Currently, venv creates a single lib dir, but everything installed with pip within the venv, will be installed to lib64/... instead while lib will remain empty. For some third party apps, this is confusing. virtualenv, for example, installs a lib64 symlink to lib automatically. IMHO, more correctly would be a lib to lib64 symlink. -- components: Library (Lib) messages: 215883 nosy: BinaryKhaos priority: normal severity: normal status: open title: venv does not create lib64 directory and appropriate symlinks versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21197 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided
Josh Rosenberg added the comment: Agreed that there is no need to patch 2.7/3.4; this is a pedantic correctness fix, not a serious bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20434] Process crashes if not enough memory to import module
Kristján Valur Jónsson added the comment: Could someone please review this patch? I'd like to see it committed asap. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20434 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11975] Fix referencing of built-in types (list, int, ...)
Brigitta S added the comment: I would like to reference the list methods in a documentation using intersphinx-ing e.g :meth:`list.append` etc. However there are no links generated for these. I may underestimate issues raised in this thread, but it naively seems that removing the :noindex: lines from datastructures.rst would solve the problem. thanks -- nosy: +bsipocz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11975 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
Eric V. Smith added the comment: The rule is: - if the entire format specifier is the empty string (not None, but ''), then return str(value) - else, look at the presentation type. if it is missing, set it to something like 'g' - do the normal float formatting using the presentation type The first of these has an empty string for the format specifier (so uses str(1e10), the rest do not: format(1e10, '') '100.0' format(1e10, ' ') ' 100.0' format(1e10, ' g') ' 1e+10' format(1e10, ' e') ' 1.00e+10' format(1e10, ' f') ' 100.00' Now, how much the something like g part of the above is true is debatable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21192] Idle: Print filename when running a file from editor
Adnan Umer added the comment:
Method: runcode
Class: ModifiedInterpreter
Line: 752
Added
if code.co_filename[0] != '':
self.tkconsole.write('Executing ' + code.co_filename + '\n')
To print file path that is executed
--
nosy: +Adnan.Umer
versions: +Python 3.4
Added file: http://bugs.python.org/file34783/PyShell.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21192
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11975] Fix referencing of built-in types (list, int, ...)
Éric Araujo added the comment: I may underestimate issues raised in this thread I re-read the discussion, these are the two main issues: 1) We’d like list/tuple/etc. documented in two different pages (as functions and as types), which causes issues when Sphinx builds its index of referenceable objects, as investigated by Jonas. 2) We’d like to have link targets for list.count/tuple.count/etc. but the existing doc has one place only to document all sequence types’ count method, so the fix is not simple. For 1), I now think that Ezio’s builtins.list/list hack could be a good idea, as long as “list” (i.e. not “builtins.list”) is always displayed in the text for humans (I don’t care about URIs or rst source), and that people using intersphinx can write “:meth:`list.append`” and don’t have to go with “:meth:`builtins.list.append list.append`”. For 2), I would be fine with adding mostly empty method directives to make links work, without duplicating the info in the existing “common sequence operations” table and footnotes. For example, in https://docs.python.org/3/library/stdtypes.html#tuples after “Tuples implement all of the :ref:`common typesseq-common` sequence operations”, I’d add directives for tuple.index and tuple.count. On a related note, it’s unfortunate that the global index has one entry for “tuple (built-in function)”, seven entries for “tuple object”, but none for “tuple.count” (and search doesn’t find it either) or “tuple class”. -- stage: patch review - needs patch versions: +Python 3.5 -Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11975 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20434] Process crashes if not enough memory to import module
Eric Snow added the comment: I don't see a review link. Looks like your patch wasn't against tip (at attach-time) or you used the --git flag in diff. Having the patch in the review tool would be really would be really helpful. I'll take a look otherwise, but won't be able to immediately regardless. -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20434 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7980] time.strptime not thread safe
Changes by Erik Purins e...@purins.com: -- nosy: +epu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21198] Minor tarfile documentation bug
New submission from Andrew Scheller: I've just noticed that the documentation for TarInfo.type says To determine the type of a TarInfo object more conveniently, use the is_*() methods below. However none of the methods mentioned actually contain an underscore, so I believe the documentation should be updated to ...use the is*() methods below. (for comparison, the documentation for stat.S_IFMT correctly talks about is*() functions) -- assignee: docs@python components: Documentation messages: 215892 nosy: docs@python, lurchman priority: normal severity: normal status: open title: Minor tarfile documentation bug type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20434] Process crashes if not enough memory to import module
Kristján Valur Jónsson added the comment: Ok, retrying without the --git flag (I thought that was recommended, it was once...) -- Added file: http://bugs.python.org/file34784/string_resize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20434 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20434] Process crashes if not enough memory to import module
Changes by Kristján Valur Jónsson krist...@ccpgames.com: Removed file: http://bugs.python.org/file34779/string_resize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20434 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
New submission from Matt Mackall: Python's file_read uses an 'l' type to parse its args which results in a 31-bit size limit on reads on 64-bit Windows. It should instead use an ssize_t. Related Mercurial bug: http://bz.selenic.com/show_bug.cgi?id=4215 -- components: IO messages: 215893 nosy: Matt.Mackall, larry, ncoghlan priority: normal severity: normal status: open title: Python on 64-bit Windows uses signed 32-bit type for read length type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21198] Minor tarfile documentation bug
Changes by Berker Peksag berker.pek...@gmail.com: -- type: enhancement - versions: -Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21198 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
paul j3 added the comment: http://stackoverflow.com/questions/22990977/why-does-this-argparse-code-behave-differently-between-python-2-and-3 is answered by this change in how `required` arguments are tested, and how subparsers fell through the cracks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7980] time.strptime not thread safe
Changes by Mark Dickinson dicki...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21191] os.fdopen() may eat file descriptor and still raise exception
Dima Tisnek added the comment:
I'm not sure if you are referring to Python's C-level fdopen or GNU libc fdopen.
GNU libc fdopen does not consume file descriptor on error:
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include string.h
#include errno.h
#include unistd.h
int main(int argc, char** argv)
{
int fd = -1;
int rv = 0;
FILE* fh = NULL;
if (argc3) return 1;
errno = 0;
fd = open(argv[1], O_RDONLY);
printf(got fd %d errno %d text %s\n, fd, errno, strerror(errno));
errno = 0;
fh = fdopen(fd, argv[2]);
printf(got fh %x errno %d text %s\n, fh, errno, strerror(errno));
errno = 0;
rv = close(fd);
printf(got rv %d errno %d text %s\n, rv, errno, strerror(errno));
}
[dima@bmg ~]$ ./a.out /etc/passwd w
got fd 4 errno 0 text Success
got fh 0 errno 22 text Invalid argument
got rv 0 errno 0 text Success
To be fair, GNU libc fdopen doesn't consider it an error to use a file
descriptor that refers to a directory, which is the crux of this bug.
Anyhow, point is the semantics change your patch brings in sets Python 2.7+ in
contrast with both Python 3.x and GNU libc.
Perhaps if it's too hard to implement properly, it's better to leave this issue
as won't fix / technical limitation?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21191
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21199] Python on 64-bit Windows uses signed 32-bit type for read length
Larry Hastings added the comment: Benjamin: given the brave new world of 2.7 living even longer, Guido said this sort of bug fix was fair game. Will you accept a patch for this in 2.7? -- assignee: - larry nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21199 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19628] maxlevels -1 on compileall for unlimited recursion
Claudiu.Popa added the comment: Ping. :) Can someone review this patch, please? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19628 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21194] json.dumps with ensure_ascii=False doesn't escape control characters
akira added the comment: json.dumps works correctly in this case. Both json/application rfc [1] and ecma json standard [2] say: All characters may be placed within the quotation marks, except for the characters that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters (U+ through U+001F). i.e., only a subset (00-1F) of control characters must be escaped in json string [1]: https://tools.ietf.org/html/rfc7159#section-7 [2]: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf -- nosy: +akira ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21194 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21197] venv does not create lib64 directory and appropriate symlinks
Antoine Pitrou added the comment: Which third party apps are these? AFAIK, venv's directory layout is private - it shouldn't be interpreted by other programs (as opposed to the system-level lib/lib64 layout). -- nosy: +pitrou, vinay.sajip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21197 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20924] openssl init 100% CPU utilization
Antoine Pitrou added the comment: Thanks. It would be nice if you could investigate why the underlying NT socket is in non-blocking mode (AFAIK, this issue hasn't been reported before). Also, it would be nice if you could check with Python 3 as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20924 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided
Antoine Pitrou added the comment: +1 for ValueError as well. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21177] ValueError: byte must be in range(0, 256)
Antoine Pitrou added the comment: There's no real problem. I find must be in the range [0, 255] easier to understand, but I also would not make a big effort to change this. The problem is that [0, 255] looks very much like a Python list, not a range. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21177 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21177] ValueError: byte must be in range(0, 256)
Stefan Krah added the comment: There's no real problem. I find must be in the range [0, 255] easier to understand, but I also would not make a big effort to change this. As for me, we can close this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21177 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21177] ValueError: byte must be in range(0, 256)
Antoine Pitrou added the comment: Uh, from the context, it's clear that the error is that 256 doesn't fit in the average 8-bits byte. Is there an actual problem here? (if you don't know what a byte is, you probably shouldn't use that form of the bytes() constructor) -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21177 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs
Changes by Geoffrey Spear geoffsp...@gmail.com: -- nosy: +geoffreyspear ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21015 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21127] Path objects cannot be constructed from str subclasses
Antoine Pitrou added the comment: I'm curious: what is the use case for str subclasses in Path objects? If this is to be supported, I think I'd rather force-cast to str rather than accept arbitrary subclasses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21127 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs
Antoine Pitrou added the comment: The OpenSSL command advertise itself as 0.9.8y but it doesn't include any ECDH ciphers. Really? Apple's packaging looks almost criminal here. FreeBSD 9 is failing as well: It's not necessarily the same issue as on OS X. Stefan, can you post the output of the following commands: * openssl ciphers -v * openssl ciphers -v ECDH * openssl ciphers -v EECDH -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21015 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21015] support SSL_CTX_set_ecdh_auto on newer OpenSSLs
Stefan Krah added the comment: This is for FreeBSD-9 (which, to be fair, has EOL status): [stefan@freebsd-amd64 ~]$ openssl ciphers -v DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export [stefan@freebsd-amd64 ~]$ openssl ciphers -v ECDH Error in cipher list 34610:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_lib.c:1218: [stefan@freebsd-amd64 ~]$ openssl ciphers -v EECDH Error in cipher list 34611:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_lib.c:1218: -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21015 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21193] pow(a, b, c) should not raise TypeError when b is negative and c is provided
Tim Peters added the comment: Yup, agreed with all: ValueError makes a lot more sense, but the change shouldn't be backported. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21193 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20351] Add doc examples for DictReader and DictWriter
Charles-Axel Dein added the comment: Hey - is there anything else I need to do here? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20351 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21191] os.fdopen() may eat file descriptor and still raise exception
Benjamin Peterson added the comment:
On Thu, Apr 10, 2014, at 10:46, Dima Tisnek wrote:
Dima Tisnek added the comment:
I'm not sure if you are referring to Python's C-level fdopen or GNU libc
fdopen.
GNU libc fdopen does not consume file descriptor on error:
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdio.h
#include string.h
#include errno.h
#include unistd.h
int main(int argc, char** argv)
{
int fd = -1;
int rv = 0;
FILE* fh = NULL;
if (argc3) return 1;
errno = 0;
fd = open(argv[1], O_RDONLY);
printf(got fd %d errno %d text %s\n, fd, errno, strerror(errno));
errno = 0;
fh = fdopen(fd, argv[2]);
printf(got fh %x errno %d text %s\n, fh, errno, strerror(errno));
errno = 0;
rv = close(fd);
printf(got rv %d errno %d text %s\n, rv, errno, strerror(errno));
}
[dima@bmg ~]$ ./a.out /etc/passwd w
got fd 4 errno 0 text Success
got fh 0 errno 22 text Invalid argument
got rv 0 errno 0 text Success
To be fair, GNU libc fdopen doesn't consider it an error to use a file
descriptor that refers to a directory, which is the crux of this bug.
I meant once you manage to get fdopen to succeed, the fd has basically
been consumed.
Anyhow, point is the semantics change your patch brings in sets Python
2.7+ in contrast with both Python 3.x and GNU libc.
I realize.
Perhaps if it's too hard to implement properly, it's better to leave this
issue as won't fix / technical limitation?
I mean if you'd prefer for it to just be inconsistent in 2.x...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21191
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21195] None float format: incomplete documentation
Eric O. LEBIGOT added the comment: The Python 2.7 goes even as far as to say that format(1e10, ' ') should give the same as format(1e10, ' g') (not something similar to g), which is obviously incorrect. If the Python 3.4 documentation for the empty presentation type of floats were used in the Python 2.7 documentation, it would be closer to the real behavior of Python 2.7, so that would be an improvement. Now, the real question is whether the Python 3.4 documentation applies exactly to Python 2.7, here, or whether improving the Python 2.7 documentation would require a different description. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21195 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21177] ValueError: byte must be in range(0, 256)
Konstantin Zemlyak added the comment: To clarify few things: - Yes, I know that 256 doesn't fit into byte. I was checking how bytes/bytearray are handling overflow. - I know that range() is a half-open interval. Yet this error message still gave me a wtf moment because I didn't realize it was talking about python's range() builtin and not about mathematical term. So even though this message is technically 100% correct it still doesn't feel right. May I propose a message byte must be in range [0-255] instead? This won't be confused with either python's range() nor [] list notation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21177 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
