[issue46281] Python 3.10.1 build errors on Ubuntu 18.04
Bob Rivoir added the comment: According to synaptic, I have openssl 1.1.1-1ubuntu2.1~18.04-14 installed. On the openssl.org site they mention that this version doesn't eol till 2023. Shouldn't this still work? Or does python require the 3.0 version? -- ___ Python tracker <https://bugs.python.org/issue46281> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46281] Python 3.10.1 build errors on Ubuntu 18.04
New submission from Bob Rivoir : _hashlib and _ssl modules failed to compile on my Ubuntu 18.04 system. Attached is a file with the error outputs. -- files: python-3.10.1-build-errors.txt messages: 409853 nosy: rhr242 priority: normal severity: normal status: open title: Python 3.10.1 build errors on Ubuntu 18.04 type: compile error versions: Python 3.10 Added file: https://bugs.python.org/file50545/python-3.10.1-build-errors.txt ___ Python tracker <https://bugs.python.org/issue46281> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42297] [argparse] Bad error message formatting when using custom usage text
Change by Bob Blanchett : -- nosy: +bobblanchett ___ Python tracker <https://bugs.python.org/issue42297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: And now it's working for me as well. Thanks, @Mariatta. -- resolution: third party -> fixed status: open -> closed ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: I can, if you prefer, close this ticket and create a new one on GitHub (even though this is the same issue, not a different "further" issue). -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: To reproduce, enter "bkline" in the GitHub username field and press Check. -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: Sorry, it's still failing with the same error message. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: Super, thanks! -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: Apparently, it doesn't fail when you enter a name for which it can't find a b.p.o. account. So it knows how to say "beelzebub does not have bpo account" but fails when I put in "bkline" in the GitHub username field. It's tempting to suspect that the 500 error means "yes, I found a b.p.o account for that GitHub user but I just can't say so" but there's no guarantee that this would be a reliable assumption. -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
Bob Kline added the comment: I have reported the failure of the CLA check tool. https://bugs.python.org/issue43790 -- ___ Python tracker <https://bugs.python.org/issue43777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
New submission from Bob Kline : The tool to check whether the CLA has been received fails with a 500 error. Steps to reproduce: 1. Add your GitHub name to your b.p.o. record. 2. Navigate to https://check-python-cla.herokuapp.com/ 3. Enter your GitHub name and press the "Check" button 4. "500 Internal server error / Server got itself in trouble" -- components: Demos and Tools messages: 390612 nosy: bkline priority: normal severity: normal status: open title: CLA check fails with a 500 error ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
Bob Kline added the comment:
Thanks for the clarification. I submitted a PR, but I'm unable to remove the
"CLA not signed" tag from it (even though I have signed the CLA) and form at
https://check-python-cla.herokuapp.com/ ("You can check yourself to see if the
CLA has been received.") blows up with a 500 ("Server got itself in trouble").
Submitting patches for the Python documentation never used to be this hard. :-)
--
___
Python tracker
<https://bugs.python.org/issue43777>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
Bob Kline added the comment: PR submitted: https://github.com/python/cpython/pull/25287 -- ___ Python tracker <https://bugs.python.org/issue43777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
New submission from Bob Kline : The official tutorial instructs users to find third-party packages by using the "pip search" command, which no longer works (and will be deprecated -- and presumably subsequently removed -- according to the error message). See https://docs.python.org/3.10/tutorial/venv.html#managing-packages-with-pip That passage should be removed from the tutorial. -- assignee: docs@python components: Documentation messages: 390550 nosy: bkline, docs@python priority: normal severity: normal status: open title: Remove description of "pip search" command from tutorial versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : -- assignee: -> christian.heimes components: +SSL nosy: +christian.heimes versions: +Python 3.10, Python 3.7, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : Added file: https://bugs.python.org/file49799/server.py ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
New submission from Bob : I wrote a simple proxy with Python3.8 and Asyncio, but I found it couldn't handle passive close correctly, a lot of CLOSE_WAIT sockets couldn't be released. I had trouble shot it for a long time with no progress. netstat -anop tcp | grep CLOSE_WAIT tcp6 0 0 64.XXX.XXX.XXX:80113.58.229.12:46996 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80222.137.35.237:54914CLOSE_WAIT 10485/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80119.39.47.229:53882 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80123.14.254.238:49262CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80121.57.230.51:35036 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80124.235.138.253:44882 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:8036.5.157.219:38006 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) tcp6 0 0 64.XXX.XXX.XXX:80150.255.5.121:39288 CLOSE_WAIT 10486/python3.8 off (0.00/0/0) -- ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43183] Asyncio can't close sockets properly on Linux cause CLOSE_WAIT
Change by Bob : -- components: asyncio nosy: Bob_2021, asvetlov, yselivanov priority: normal severity: normal status: open title: Asyncio can't close sockets properly on Linux cause CLOSE_WAIT type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43183> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41633] pydoc skips methods of nested classes
Bob Kline added the comment: Here is the generated documentation. Note that no mention is made of the inner class's method. -- Added file: https://bugs.python.org/file49429/Screen Shot 2020-08-25 at 11.26.39 AM.png ___ Python tracker <https://bugs.python.org/issue41633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41633] pydoc skips methods of nested classes
New submission from Bob Kline : Although the documentation for the pydoc says that it produces documentation of the classes recursively, this isn't actually true. -- components: Library (Lib) files: repro.py messages: 375891 nosy: bkline priority: normal severity: normal status: open title: pydoc skips methods of nested classes type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49428/repro.py ___ Python tracker <https://bugs.python.org/issue41633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41577] Cannot use ProcessPoolExecutor if in a decorator?
Change by Bob Fang : -- versions: +Python 3.6, Python 3.7, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41577] Cannot use ProcessPoolExecutor if in a decorator?
New submission from Bob Fang : I have this minimal example: ``` from functools import wraps from concurrent import futures import random def decorator(func): num_process = 4 def impl(*args, **kwargs): with futures.ProcessPoolExecutor() as executor: fs = [] for i in range(num_process): fut = executor.submit(func, *args, **kwargs) fs.append(fut) result = [] for f in futures.as_completed(fs): result.append(f.result()) return result return impl @decorator def get_random_int(): return random.randint(0, 100) if __name__ == "__main__": result = get_random_int() print(result) ``` If we try to run this function I think we will have the following error: ``` _pickle.PicklingError: Can't pickle : it's not the same object as __main__.get_random_int ``` I think the main issue here is that the "wraps" decorator itself alters the `func` object and thus make it impossible to pickle. I found this rather strange. I am just wondering if there is any way to get around this behavior? I would want to use `wraps` if possible. Thanks! -- components: Library (Lib) messages: 375614 nosy: bob.fang.london priority: normal severity: normal status: open title: Cannot use ProcessPoolExecutor if in a decorator? type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41410] Opening a file in binary mode makes a difference on all platforms in Python 3
New submission from Bob Kline : The documentation for tempfile.mkstemp() says "If text is specified, it indicates whether to open the file in binary mode (the default) or text mode. On some platforms, this makes no difference." That might have been true for Python 2.x, but in Python 3, there are no platforms for which the choice whether to open a file in binary mode makes no difference. -- assignee: docs@python components: Documentation messages: 374385 nosy: bkline, docs@python priority: normal severity: normal status: open title: Opening a file in binary mode makes a difference on all platforms in Python 3 versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34858] MappingProxy objects should JSON serialize just like a dictionary
Bob Ippolito added the comment: I would certainly reconsider it at this point, I think a bona fide ABC *specific to JSON encoding* would be a good way to do it. simplejson has two ways to do this, the `for_json` parameter which will use a `for_json()` method on any object as the JSON representation if present, and the `namedtuple_as_object` parameter which will do the same for objects with an `_asdict()` method. As part of the standard library it might make more sense to rename `for_json()` to `__json__()` or similar. It is a bit unfortunate that you can't guarantee round-trip on deserialization, but that has always been the case. To get round-tripping (without tagging everything that has been encoded in some way like pickle does), you really should be working with a schema of some kind. -- ___ Python tracker <https://bugs.python.org/issue34858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38438] argparse "usage" overly-complex with nargs="*"
New submission from Bob Alexander :
This program:
import argparse
ap = argparse.ArgumentParser()
ap.add_argument("arg", nargs="*")
ap.parse_args()
Gives usage message:
usage: help_complexity.py [-h] [arg [arg ...]]
It's correct, but unnecessarily complex and challenging to the user.
If I were manually writing the usage, arg... would do, or maybe [arg ...] to be
consistent with other messages??
--
components: Library (Lib)
messages: 354402
nosy: bobjalex
priority: normal
severity: normal
status: open
title: argparse "usage" overly-complex with nargs="*"
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue38438>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38409] Typo in doc string for str.strip
New submission from Bob Dowling : The doc string for str.strip() has a typo: the "d" at the end of "removed" is missing. help(str.strip) Currently: Return a copy of the string with leading and trailing whitespace remove. Should be: Return a copy of the string with leading and trailing whitespace removed. I have attached an offered patch. -- components: Library (Lib) files: str_strip.patch keywords: patch messages: 354209 nosy: Bob Dowling priority: normal severity: normal status: open title: Typo in doc string for str.strip type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48648/str_strip.patch ___ Python tracker <https://bugs.python.org/issue38409> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Change 2to3 to replace 'basestring' with '(str,bytes)'
Bob Kline added the comment: OK, I give up. In parting I will point out that the official Python 2 documentation says "basestring() This abstract type is the superclass for str and unicode. It cannot be called or instantiated, but it can be used to test whether an object is an instance of str or unicode. isinstance(obj, basestring) is equivalent to isinstance(obj, (str, unicode))." That's exactly what the code we are converting (much of which was written years before Python 3 even existed) was doing. As for the idea that we weren't really "planning to use it as logical text" (ignoring the fact that _everyone_ used Python 2 str objects to represent logical text back in 2003, and ignoring the fact that the repro case given at the top of this report converts the 8-bit string value to Unicode -- why else would it do that except to use the value as "logical text"?) ... well, I don't know where to start. I'm done here. :->} -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
Bob Kline added the comment: > Unless you have a specific proposal, ... I _do_ have a specific proposal: replace `basestring` with `(str, bytes)`, which preserves the behavior of the original code. So, if isinstance(value, basestring) becomes if isinstance(value, (str, bytes)) -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
Bob Kline added the comment: > Use str instead. Sure. I understand the advantages of the new approach to strings. Which, by the way, weren't available when this project began. I don't disagree with anything you say in the context of writing new code. I was, however, surprised and dismayed to learn of the cavalier approach the upgrade tool has taken to silently breaking existing code which it is claiming to "fix." Here's my favorite so far. --- cdr.py (original) +++ cdr.py (refactored) @@ -36,15 +36,15 @@ # == from six import itervalues try: -basestring +str is_python3 = False base64encode = base64.encodestring base64decode = base64.decodestring except: base64encode = base64.encodebytes base64decode = base64.decodebytes -basestring = (str, bytes) -unicode = str +str = (str, bytes) +str = str is_python3 = True We wrote this following the example of comparable techniques in http://python-future.org/compatible_idioms.html and similar guides to an upgrade path. Seems we're being punished for taking the trouble to make our code work with Python 2 and 3 during the transition period. :-( It's hard to see how this conversion resulted in something better than what we already had. -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
New submission from Bob Kline : We are attempting to convert a large Python 2 code base. Following the guidance of the official documentation (https://docs.python.org/2/library/functions.html#basestring) we created tests in many, many places that look like this: if isinstance(value, basestring): if not isinstance(value, unicode): value = value.decode(encoding) else: some other code It seems that the 2to3 tool is unaware that replacing basestring with str in such cases will break the software. Here's an example. $ 2to3 repro.py ... --- repro.py(original) +++ repro.py(refactored) @@ -1,8 +1,8 @@ from frobnitz import transform def foo(value, encoding=None): -if isinstance(value, basestring): -if not isinstance(value, unicode): +if isinstance(value, str): +if not isinstance(value, str): value = value.decode(encoding or "utf-8") return value else: Help me understand how this "fix" results in the correct behavior. -- components: 2to3 (2.x to 3.x conversion tool) messages: 350964 nosy: bkline priority: normal severity: normal status: open title: Incorrect "fixing" of isinstance tests for basestring type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: In fact, I suppose it's possible that the warning as I worded it is still not restrictive enough, and that there are subtle dependencies between the fixers which would make the action of one of them render the code no longer safely fixable as Python 2 code by the other fixers, and the real warning should really say something like, "You can only run this tool once in write-in-place mode on a given code set. You can run as many times without the -w option as many times, with as many combinations of fixers as you want, determining which of the fixers you will enable for the final write-in-place run." Are there such dependencies between fixers? -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: Thanks, I understand. However, this highlights something which had slipped under my radar. You get one shot at running a code set through the tool. You can't do what I was doing, which was to run the tool in "don't write" mode, then fix by hand some of the things it says will need to be done, then run it again in the same mode, fix, etc., until I got to the point where I felt like I could trust it (except for things like adding unnecessary `list()` wrappers, for which I learned how to use the option for suppressing certain default fixers), and then run the tool in write mode to fix what was left. I now totally get why the tool did what it did, and why the approach I was using was inappropriate, but was there a warning to this effect that I missed in the documentation? Something like "you can only run this tool once per fixer (or set of fixers) in write mode, and you cannot run a fixer on code for which you have performed any of the needed conversions for that fixer yourself"? Of cour se, it's always possible I'm the only developer clueless enough not to have figured this out without such a warning. :-) Partly in my (lame) defense, I had lured myself into the frame of mind where what I was doing seemed to make sense by having just come out of a similar exercise with pylint, where iterative "fixing" works just fine. I guess I should take this as a good sign, that my brain has moved so far into the Python 3 world that "..." was no longer recognizable as a bytestring. Again, thanks for the gentle explanation. :-) -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment:
Ah, this is worse than I first thought. It's not just converting code by adding
extra backslashes to regular expression strings, where at least the regular
expression engine will do what the original code was asking the Python parser
to do (unless user code checks for and enforces limits on regular expression
string lengths, so even that case is broken), but 2to3 is also mangling strings
in places where the behavior is changed (that is, broken). 2to3 wants to change
if c not in ".-_:\u00B7\u0e87":
to
if c not in ".-_:\\u00B7\\u0e87":
Not the same thing at all, as illustrated here:
$ python
Python 3.7.3 (default, Jun 19 2019, 07:38:49)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> len("\u00B7")
1
>>> len("\\u00B7")
6
>>>
That breaks the original code. This is a serious bug.
--
___
Python tracker
<https://bugs.python.org/issue37996>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: The original string had u"""...""" and the u had already been removed by hand in preparation for moving to Python 3. -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
New submission from Bob Kline :
-UNWANTED = re.compile("""['".,?!:;()[\]{}<>\u201C\u201D\u00A1\u00BF]+""")
+UNWANTED =
re.compile("""['".,?!:;()[\]{}<>\\u201C\\u201D\\u00A1\\u00BF]+""")
The non-ASCII characters in the original string are perfectly legitimate str
characters, using valid standard escapes recognized and handled by the Python
parser. It is unnecessary to lengthen the string argument passed to
re.compile() and defer the conversion of the doubled escapes for the regular
expression engine to handle.
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 350922
nosy: bkline
priority: normal
severity: normal
status: open
title: 2to3 introduces unwanted extra backslashes for unicode characters in
regular expressions
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37996>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37430] range is not a built-in function
bob gailer added the comment: Thanks for explaining. Indeed range appears in __builtins__. It is a surprise to type range and get in response. sum otoh gives . The distinction between function, type and class seems muddy. When I enter "range" in the index box in the windows documentation display I am offered: (1)built-in function, which takes me to the paragraph that started this issue. It does NOT take me to the built-in functions topic, whereas sum does. (2) object, and range (built-in class)which take me to the built-in types topic. This seems to add to the confusion. -- ___ Python tracker <https://bugs.python.org/issue37430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37430] range is not a built-in function
New submission from bob gailer : In section 8.3 The for statement there is a reference to range as a built-in function. That was true in python 2. Now range is a built-in type. -- assignee: docs@python components: Documentation messages: 346745 nosy: bgailer, docs@python priority: normal severity: normal status: open title: range is not a built-in function type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue37430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37061] The strangest glitch I have ever seen - incorrect indenterror, even on commented out code.
Bob Vegene added the comment: I decided to check the file in notepad++ and I saw that there actually is an indentationerror... However, the save button wasn't working I guess. I can't tell you how many times i hit ctrl+s and clicked save. Wow, so it still is a bug. -- ___ Python tracker <https://bugs.python.org/issue37061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37061] The strangest glitch I have ever seen - incorrect indenterror, even on commented out code.
Bob Vegene added the comment: uhm, the current file is attached now is there some sort of error and you guys see it differently??? i can't be the only one getting this. I swear i have everything right, and i'll attach an image if i need too. -- Added file: https://bugs.python.org/file48364/sys32pack.py ___ Python tracker <https://bugs.python.org/issue37061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37061] The strangest glitch I have ever seen - incorrect indenterror, even on commented out code.
Bob Vegene added the comment: The error it gives is unexpected indent (sys32pack.py, line 41) (im also using IDLE) FYI. -- ___ Python tracker <https://bugs.python.org/issue37061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37061] The strangest glitch I have ever seen - incorrect indenterror, even on commented out code.
Bob Vegene added the comment: No, I removed that before. I actually did have one, but I removed that and it still shows. -- ___ Python tracker <https://bugs.python.org/issue37061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37061] The strangest glitch I have ever seen - incorrect indenterror, even on commented out code.
New submission from Bob Vegene : So, I'm making a simple program that will allow me to quickly copy programs to System32 for use on the command line. When I tried testing this in a file called test.py in the same directory as sys32move.py, I got a very strange error. IndentError. I am very experienced with python and I know how to fix this and why it is caused. I fixed what I thought I could, but the I realized something was off. I commented out everything in sys32move.py and it still outputs this error. Now, commenting this out is unnecessary, as this is a false error anyway. This is test.py: try: import sys32pack install_folder(testfolder) except Exception as e: print(e) input() (you get same behavior without the catching of the error.) SYS32PACK.py: -- components: Build, Cross-Build files: sys32pack.py messages: 343591 nosy: Alex.Willmer, bob.vegena priority: normal severity: normal status: open title: The strangest glitch I have ever seen - incorrect indenterror, even on commented out code. type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file48363/sys32pack.py ___ Python tracker <https://bugs.python.org/issue37061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support
Bob Kline added the comment: I had to add $HOME/usr/lib64 to LD_LIBRARY_PATH to get make to work. -- nosy: +bkline ___ Python tracker <https://bugs.python.org/issue34028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: Here is a debugged version of mylife, which cloned life2.py to use a class for turtle-ing. Note the difficulties at the end of the code -- ontimer(fun, delay) calls for a zero arg function, so draw() cannot be inside the class. Greatly annoying. But now we know. mylife3.py is a suitable example, I think. If cleaned up to standards. I noticed there is a curses life.py example, which is very interesting and fun, but mylife3.py is more fun...and it has 2 different board topologies! And it would make a very good test program. Note that it sets the random seed which establishes the Cell patterns, so a test ought to be repeatable, at least on a given machine. I plan to use mylife3.py instead of a space heater this winter :) -- Added file: https://bugs.python.org/file47927/mylife3.py ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: Apparently the draw() function must call itself via ontimer. That is not in the docs. But 56 variations later...I just copied Grant Jenks. Apparently he knows what's what. And done() must be the last line. If first omitted, only one draw loop executed, but it quits itself. With done(), it loops via ontimer(). def draw(): myDrawCells() update() myComputeOneStep() ontimer(draw, LOOP_TIMER) setup(BOARD_SIDE, BOARD_SIDE, None, None) hideturtle() tracer(False) clear() myInitialize() draw() done() So now alt-Q works in life2DEBUG.py. attached. -- Added file: https://bugs.python.org/file47926/life2DEBUG.py ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: Thanks. I appreciate the time and effort. But I disagree with the characterization of this problem as 'Resolved'. Turtle is supposed to be simple enough for children yet no one can fix simple turtle code and stop an endless loop? What is the rush to close issues? -- ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: OK, thanks. The generated launcher shell command generated includes '-d -i' flags... so I tried running without those and voila, life.py terminates normally. Yay. :-) 2nd, I reviewed the order of commands and I saw that life2.py and mylife.py (the +1 version) did not have a 'done()' or 'mainloop()' as the last line of the program. I added those, to no effect. Does nothing I can see. The other turtle commands appear to me to be "ok", given that the algorithm is different. For example, clear() used to be done every loop -- to erase the turtle tracks -- but that is now done just at the start because only changed cells are updated, and new life/new dead are just updated. So, 50% solved. It is an interesting problem because *my* code seems to be working and *python* does not appear to be working right. Thanks for the help. I might try pygame for a gui instead...this is getting weird. -- ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: hi - i do not use ‘i’...just drag to launcher... and sequence of commands is a good tip but smells like some kind of bug to me if the commands follow written rules. thanks for looking - > > -- ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: I rewrote the life2.py using a class in order to eliminate global variable declarations, and some other things, such as bringing freegames.util#square() instream to be independent of freegames, carefully accounting for every pixel output, etc. Works a little better but alt-Q has no effect whatsoever and it is necessary to Force Quit (mac terminology) or to switch to the shell window and quit that first. Once this bug is fixed, wherever that might be, you might look into using mylife.py as an turtle example -- with whatever changes you like -- because it is interesting to use and it exercises the turtle and tkinter very strenuously. (just leave my name off it...) Thanks for your hard work. -- Added file: https://bugs.python.org/file47925/mylife.py ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: looking at the screen snapshot 'life.py alt-q once.jpg' -- the turtle code keeps running even though System.exit has been completed, and notice the traceback display in the shell caused by the alt-Q. a second press of alt-Q terminates the shell and the turtle code. -- Added file: https://bugs.python.org/file47924/lify.py alt-q once.jpg ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
Change by bob moth : Added file: https://bugs.python.org/file47923/life2.py ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
Change by bob moth : Added file: https://bugs.python.org/file47922/life.py ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: Here is the source, just simply Turtles... https://github.com/grantjenks/free-python-games <https://github.com/grantjenks/free-python-games> Attached life.py and life2.py I don't know what cause the problem. I suspect there is more of a problem than just alt-Q > On Nov 10, 2018, at 15:08, Bob Moth wrote: > > send to you? > > . > > >> On Nov 10, 2018, at 14:41, Eric V. Smith wrote: >> >> >> Eric V. Smith added the comment: >> >> Please create a small program that reproduces the problem. You should strip >> out everything that isn't needed. There's no way we can guess the problem >> without seeing the code. >> >> -- >> nosy: +eric.smith >> >> ___ >> Python tracker >> <https://bugs.python.org/issue35211> >> ___ -- ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
bob moth added the comment: send to you? . > On Nov 10, 2018, at 14:41, Eric V. Smith wrote: > > > Eric V. Smith added the comment: > > Please create a small program that reproduces the problem. You should strip > out everything that isn't needed. There's no way we can guess the problem > without seeing the code. > > -- > nosy: +eric.smith > > ___ > Python tracker > <https://bugs.python.org/issue35211> > ___ -- ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35211] Turtle Shutdown Problem(s)
New submission from bob moth : Running life.py from the Free Python Games requires alt-Q twice, and the GUI keeps running after System.exit. Running life2.py, (which is my clone, and I will happily share it if you want a great stress tester that gobbles 100% of a CPU core for as long as you want,) doesn't respond to alt-Q and requires a force quit. -- components: Tkinter, macOS files: turtle shutdown problem.txt messages: 329640 nosy: bmoth, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Turtle Shutdown Problem(s) type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file47920/turtle shutdown problem.txt ___ Python tracker <https://bugs.python.org/issue35211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35180] Ctypes segfault or TypeError tested for python2.7 and 3
Bob added the comment: Hi Josh thanks for answering me and so quick. So if I understood correctly, by inserting an unexpected and unchecked on value, it could lead to a potential vulnerability in the program? Or just a plain failure (which could be a denial of service also)? Thanks again. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, November 6, 2018 5:07 PM, Josh Rosenberg wrote: > Josh Rosenberg shadowranger+pyt...@gmail.com added the comment: > > The TypeError on Py3 would be because functions taking c_char_p need > bytes-like objects, not str, on Python 3. '%s' % directory is pointless when > directory is a str; instead you need to encode it to a bytes-like object, > e.g. opendir(os.fsencode(directory)) (os.fsencode is Python 3 specific; plain > str works fine on Py 2). > > Your segfault isn't occurring when you load dirfd, it occurs when you call it > on the result of opendir, when opendir returned NULL on failure (due to the > non-existent directory you call it with). You didn't check the return value, > and end up doing flagrantly illegal things with it. > > In neither case is this a bug in Python; ctypes lets you do evil things that > break the rules, and if you break the rules the wrong way, segfaults are to > be expected. Fix your argument types (for Py3), check your return values (for > Py2). > > --- > > nosy: +josh.r > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > Python tracker rep...@bugs.python.org > https://bugs.python.org/issue35180 -- ___ Python tracker <https://bugs.python.org/issue35180> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35180] Ctypes segfault or TypeError tested for python2.7 and 3
New submission from Bob :
~Description of the problem:
I was using ctypes to get a directory file descriptor, and to do so I found
this mailing list (https://lists.gt.net/python/dev/696028) from 2008 where a
user wrote a piece that could do what the asking user and me were looking for.
What concerns me is how much this code has been used when I looked though
Github and Google and came across the same exact pieces.
The code provided looks like this:
from ctypes import CDLL, c_char_p, c_int, Structure, POINTER
from ctypes.util import find_library
class c_dir(Structure):
"""Opaque type for directory entries, corresponds to struct DIR"""
c_dir_p = POINTER(c_dir)
c_lib = CDLL(find_library("c"))
opendir = c_lib.opendir
opendir.argtypes = [c_char_p]
opendir.restype = c_dir_p
dirfd = c_lib.dirfd < -- IT FAILS HERE // STACK TRACE PROVIDED
dirfd.argtypes = [c_dir_p]
dirfd.restype = c_int
closedir = c_lib.closedir
closedir.argtypes = [c_dir_p]
closedir.restype = c_int
dir_p = opendir(".")
print "dir_p = %r" % dir_p
dir_fd = dirfd(dir_p)
print "dir_fd = %r" % dir_fd
print "closed (rc %r)" % closedir(dir_p)
When I implemented it in my machine, I changed it a bit so "opendir()" got its
arguments from an imputed value, and the final program looks like this:
from ctypes import *
import sys
import ctypes
from ctypes.util import find_library
class c_dir(Structure):
"""Opaque type for directory entries, corresponds to struct DIR"""
def get_directory_file_descriptor(directory):
c_dir_p = POINTER(c_dir)
c_lib = CDLL(find_library("c"))
opendir = c_lib.opendir
opendir.argtypes = [c_char_p]
opendir.restype = c_dir_p
dirfd = c_lib.dirfd < -- SAME. FAILS HERE.
dirfd.argtypes = [c_dir_p]
dirfd.restype = c_int
closedir = c_lib.closedir
closedir.argtypes = [c_dir_p]
closedir.restype = c_int
dir_p = opendir("%s" % directory)
print ("dir_p = %s:%r" % (directory, dir_p))
dir_fd = dirfd(dir_p)
print("dir_fd = %r" % dir_fd)
print ("closed (rc %r)" % closedir(dir_p))
get_directory_file_descriptor(sys.argv[1])
When I run it *with python 2.7*, the program runs normally if I enter the
expected value, like "/home/". But if I don't, the program exits with a
segmentation fault.
In python 3, it fails no matter what with a TypeError.
INPUT when NOT giving the error (in python 2.7): /home/
INPUT when giving the error: aaa
~Stack trace from python 2.7:
Program received signal SIGSEGV, Segmentation fault.
dirfd (dirp=0x0) at ../sysdeps/posix/dirfd.c:27
27 ../sysdeps/posix/dirfd.c: No such file or directory.
(gdb) bt
#0 dirfd (dirp=0x0) at ../sysdeps/posix/dirfd.c:27
#1 0x76698e40 in ffi_call_unix64 () from
/usr/lib/x86_64-linux-gnu/libffi.so.6
#2 0x766988ab in ffi_call () from /usr/lib/x86_64-linux-gnu/libffi.so.6
#3 0x768a83df in _call_function_pointer (argcount=1,
resmem=0x7fffd630,
restype=, atypes=, avalues=0x7fffd610,
pProc=0x778b8960 , flags=4353)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/callproc.c:837
#4 _ctypes_callproc (pProc=0x778b8960 , argtuple=,
flags=4353,
argtypes=(,),
restype=<_ctypes.PyCSimpleType at remote 0xa38ce0>, checker=0x0)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/callproc.c:1180
#5 0x768acd82 in PyCFuncPtr_call.lto_priv.107
(self=self@entry=0x77e322c0,
inargs=inargs@entry=(,),
kwds=kwds@entry=0x0)
at /build/python2.7-dPs3Rr/python2.7-2.7.12/Modules/_ctypes/_ctypes.c:3954
#6 0x004c15bf in PyObject_Call (kw=0x0, arg=(,),
func=<_FuncPtr(__name__='dirfd') at remote 0x77e322c0>) at
../Objects/abstract.c:2546
#7 do_call (nk=, na=, pp_stack=0x7fffd890,
func=<_FuncPtr(__name__='dirfd') at remote 0x77e322c0>) at
../Python/ceval.c:4567
#8 call_function (oparg=, pp_stack=0x7fffd890) at
../Python/ceval.c:4372
#9 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#10 0x004c136f in fast_function (nk=, na=, n=1,
pp_stack=0x7fffd9b0, func=) at
../Python/ceval.c:4435
#11 call_function (oparg=, pp_stack=0x7fffd9b0) at
../Python/ceval.c:4370
#12 PyEval_EvalFrameEx () at ../Python/ceval.c:2987
#13 0x004b9ab6 in PyEval_EvalCodeEx () at ../Python/ceval.c:3582
#14 0x004eb30f in PyEval_EvalCode (
locals={'c_void_p': <_ctypes.PyCSimpleType at remote 0xa3df50>, 'c_int64':
<_ctypes.PyCSimpleType at remote 0xa1d7b0>, 'c_ssize_t': <_ctypes.PyCSimpleType
at remote 0xa1d7b0>, 'c_longdouble': <_ctypes.PyCSimpleType at remote
0xa3c360>, 'Union': <_ctypes.UnionType at remote 0x76abc400>, 'cdll':
) at remote 0x77e2c450>,
'c_wchar': <_ctypes.PyCSimpleType at remote 0xa3f0b0>, 'me
[issue35111] Make Custom Object Classes JSON Serializable
Bob Ippolito added the comment:
That's what the for_json method is in simplejson, it does not have widespread
usage.
You can implement that when encoding:
```
def json_default(obj):
try:
return obj.__json__()
except AttributeError:
raise TypeError("{} can not be JSON encoded".format(type(obj)))
json.dumps(foo(), default=json_default)
```
This way, you can choose precisely how the output needs to work when encoding.
It's not ideal for every use case, but nothing is. The point is that it doesn't
get in your way, whatever you need to do can be done without any awful tricks,
so long as you have control over the dumps call site.
--
___
Python tracker
<https://bugs.python.org/issue35111>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35111] Make Custom Object Classes JSON Serializable
Bob Ippolito added the comment: The trouble with having such a hook is that it would take precedence over any customization you might want or need to do to satisfy the protocol you're implementing. Other than the limited set of types that are part of the JSON specification, there's essentially no standard for encoding of anything else. This is why customization is left to the call sites for encoding and decoding, and I would recommend using the `default` and `object_pairs_hook` keyword arguments to `dumps` and `loads` respectively for that, rather than any of the options that you've enumerated. For what it's worth, simplejson has had a `for_json` method hook for several years to encourage some consolidation, but it's opt-in and there hasn't been a lot of demand to make it the default. The inverse `from_json` type operation is not supported. If you think about it, how *could* you even implement such a thing in the general case, in a way that wouldn't have lots of surprises and performance issues? -- ___ Python tracker <https://bugs.python.org/issue35111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35005] argparse should accept json and yaml argument types
Bob Ippolito added the comment: I don't think that this has anything in particular to do with the json module, at least it certainly shouldn't need any additional functionality from there. YAML parsing isn't available in the stdlib last I checked, so that is probably not really up for consideration for direct integration. In any case, I think the best approach would be to first do some research (StackOverflow, GitHub, etc.) to see how other folks are doing this in the wild, to see if there's a common pattern that should be made available in the stdlib. -- ___ Python tracker <https://bugs.python.org/issue35005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34529] add the option for json.dumps to return newline delimited json
Bob Ippolito added the comment: I suggested that each module would likely implement its own functions tailored to that project's IO and error handling requirements. The implementation may differ slightly depending on the protocol. This is consistent with how JSON is typically dealt with from a web framework, for example. -- ___ Python tracker <https://bugs.python.org/issue34529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34529] add the option for json.dumps to return newline delimited json
Bob Ippolito added the comment:
I think the best start would be to add a bit of documentation with an example
of how you could work with newline delimited json using the existing module
as-is. On the encoding side you need to ensure that it's a compact
representation without embedded newlines, e.g.:
for obj in objs:
yield json.dumps(obj, separators=(',', ':')) + '\n'
I don't think it would make sense to support this directly from dumps, as it's
really multiple documents rather than the single document that every other form
of dumps will output.
On the read side it would be something like:
for doc in lines:
yield json.loads(doc)
I'm not sure if this is common enough (and separable enough from I/O and error
handling constraints) to be worth adding the functionality directly into json
module. I think it would be more appropriate in the short to medium term that
the each service (e.g. BigQuery) would have its own module with helper
functions or framework that encapsulates the protocol that the particular
service speaks.
--
___
Python tracker
<https://bugs.python.org/issue34529>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34364] problem with traceback for syntax error in f-string
New submission from bob gailer :
Inconsistent tracebacks. Note that the traceback for bug.py does not
reference the
module file and line number.
# bug.py
def f():
f'''
{d e}'''
a=b
import bug
Traceback (most recent call last):
File "", line 1
(d e)
^
SyntaxError: invalid syntax
# bug2.py
def f():
f'''
{de}'''
a=b
import bug2
bug2.f()
Traceback (most recent call last):
File "C:\python\bug2.py", line 5, in
a=b
NameError: name 'b' is not defined
--
messages: 323301
nosy: bgailer
priority: normal
severity: normal
status: open
title: problem with traceback for syntax error in f-string
___
Python tracker
<https://bugs.python.org/issue34364>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31652] make install fails: no module _ctypes
Bob Kline added the comment: Confirming that this is still failing with 3.7.0 released. -- nosy: +bkline ___ Python tracker <https://bugs.python.org/issue31652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
Change by Bob Vincent <pillarsdot...@gmail.com>: -- nosy: +pillarsdotnet ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1294959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25257] In subject line email library inserts unwanted space after a thousands comma in a number
Bob Hossley <bhoss...@ieee.org> added the comment: Mike, Thank you. I moved to Python 3 some time ago. I confirm that Python 3 does not have the problem. But I can't conveniently verify your workaround for Python 2. Regards, Bob bhoss...@ieee.org On 2018-03-27 11:30 AM, Mike Edmunds wrote: > > Mike Edmunds <medmu...@gmail.com> added the comment: > > Here's a workaround for Python 2.7: > > ``` > class HeaderBugWorkaround(email.header.Header): > def encode(self, splitchars=' ', **kwargs): # only split on spaces, > rather than splitchars=';, ' > return email.header.Header.encode(self, splitchars, **kwargs) > > # and then... > > msg['Subject'] = HeaderBugWorkaround(subject, 'utf-8', header_name='Subject') > > ``` > > (If you have the option, you're almost certainly better off moving to Python > 3 for anything email related. But if you're maintaining code that has to be > Python 2.7 compatible, this might help.) > > -- > nosy: +medmunds > > ___ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue25257> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33060] Installation hangs at "Publishing product information"
New submission from Bob Klahn <bobsto...@comcast.net>: I am unable to install Python 2.7.14 on my Windows 7 PC. Using python-2.7.14.amd64.msi . The installation hangs at the "Publishing product information" step. Subsequent installation attempts result in the message "Python 2.7.14 (64-bit) setup was interrupted. Your system has not been modified. To install this program at a later time, please run the installation again. Click the Finish button to exit the Installer." I need to be able to make this work! With this version of Windows and this version of Python. Help! -- components: Installation messages: 313702 nosy: bobstones priority: normal severity: normal status: open title: Installation hangs at "Publishing product information" versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline <bkl...@rksystems.com> added the comment: > ... jemalloc can reduce memory usage ... Thanks for the tip. I downloaded the source and successfully built the DLL, then went looking for a way to get it loaded. Unfortunately, DLL injection, which is needed to use this allocator in Python, seems to be much better supported on Linux than on Windows. Basically, Microsoft's documentation [1] for AppInit_DLL, the shim for DLL injection on Windows, says (in effect) "here's how to use this technique, but we don't recommend using it, so here's a link [2] for what we recommend you do instead. That link takes you to "Try searching for what you need. This page doesn’t exist." [1] https://support.microsoft.com/en-us/help/197571/working-with-the-appinit-dlls-registry-value [2] https://support.microsoft.com/en-us/help/134655 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue11849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline <bkl...@rksystems.com> added the comment: Thanks for your responses to my comments. I'm working as hard as I can to get my customer's systems migrated into the Python 3 world, and I appreciate the efforts of the community to provide incentives (such as the resolution for this failure) for developers to upgrade. However, it's a delicate balancing act sometimes, given that we have critical places in our system for which the same code runs more than twice as slowly on Python 3.6 as on Python 2.7. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue11849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline <bkl...@rksystems.com> added the comment:
Sorry, I should have used the language of the patch author ("the resolution").
Without the resolution, Python 2.7 eventually runs out of memory and crashes
for some correctly written user code.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11849>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline <bkl...@rksystems.com> added the comment: Would it be inappropriate for this fix to be applied to 2.7? -- nosy: +bkline ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue11849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29992] Expose parse_string in JSONDecoder
Bob Ippolito <b...@redivi.com> added the comment: Generally speaking, parsing some things as decimal or datetime are schema dependent. It's unlikely that you would want to parse every string that looks enough like a decimal as a decimal, or that you would want to pay the cost of checking every string in the whole document to see if it's a decimal. This use case is probably better served using something like object_pairs_hook where you have some context available. Ultimate flexibility is not the goal of this interface. It's grown a bit too much of that over time. At this point I'm a lot more interested in proposals that remove options rather than add them. In order to provide maximal flexibility it would be much nicer to have a streaming interface available (like SAX for XML parsing), but that is not what this is. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31856] Unexpected behavior of re module when VERBOSE flag is set
Bob Kline <bkl...@rksystems.com> added the comment: The light finally comes on. I actually *was* putting a backslash into the string value, with the raw flag (which is, of course, what you were trying to tell me). Thanks for your patience. :-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31856> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31856] Unexpected behavior of re module when VERBOSE flag is set
Bob Kline <bkl...@rksystems.com> added the comment: I had been under the impression that "escaped" in this context meant that an escape character (the backslash) was part of the string value for the regular expression (there's a little bit of overloading going on with that word). Thanks for setting me straight. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31856> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31856] Unexpected behavior of re module when VERBOSE flag is set
New submission from Bob Kline <bkl...@rksystems.com>:
According to the documentation of the re module, "When this flag [re.VERBOSE]
has been specified, whitespace within the RE string is ignored, except when the
whitespace is in a character class or preceded by an unescaped backslash; this
lets you organize and indent the RE more clearly. This flag also lets you put
comments within a RE that will be ignored by the engine; comments are marked by
a '#' that’s neither in a character class [n]or preceded by an unescaped
backslash." (I'm quoting from the 3.6.3 documentation, but I've tested with
several versions of Python, as indicated in the issue's `Versions` field, all
with the same results.)
Given this description, I would have expected the output for each of the pairs
of calls to findall() in the attached repro code to be the same, but that is
not what's happening. In the case of the first pair of calls, for example, the
non-verbose version finds two more matches than the verbose version, even
though the regular expression is identical for the two calls, ignoring
whitespace and comments in the expression string. Similar problems appear with
the other two pairs of calls.
Here's the output from the attached code:
['&', '(', '/Term/SemanticType/@cdr:ref', '==']
['/Term/SemanticType/@cdr:ref', '==']
[' XXX ']
[]
[' XXX ']
[]
It would seem that at least one of the following is true:
1. the module is not behaving as it should
2. the documentation is wrong
3. I have not understood the documentation correctly
I'm happy for it to be #3, as long as someone can explain what I have not
understood.
--
components: Library (Lib), Regular Expressions
files: regex-repro.py
messages: 304849
nosy: bkline, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Unexpected behavior of re module when VERBOSE flag is set
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47232/regex-repro.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31856>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31519] Negative number raised to even power is negative (-1 ** even = negative)
Bob Hunkins added the comment: Thanks. Stupid of me. Appreciate the correction. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31519] Negative number raised to even power is negative (-1 ** even = negative)
New submission from Bob Hunkins: Hello, I'm only a novice with Python, so please take it easy on me if I have transgressed. I am using Python 3.6.2 on a win10 64 bit machine, and entered this: >>> a= [-1 ** x for x in range(1,10)] >>> print(a) [-1, -1, -1, -1, -1, -1, -1, -1, -1] which is not correct. however, entering this: >>> b = [pow(-1, x) for x in range(1,10)] >>> print(b) [-1, 1, -1, 1, -1, 1, -1, 1, -1] which is correct. Any negative number entered and raised to an even power seems to not return a positive value, but the pow(x,y) function works. I never have reported a bug on any programming language ever, and surprisingly I can't find a report of this (I did search, so if it's out there, I must not understand how to use the search. Forgive me. As I said, I'm very new to Python and I'm not a professional programmer.) -- messages: 302529 nosy: rdhunkins priority: normal severity: normal status: open title: Negative number raised to even power is negative (-1 ** even = negative) type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29992] Expose parse_string in JSONDecoder
Bob Ippolito added the comment: That's not a very convincing argument. Python 2 only returns byte strings if the input is a byte string and the contents of the string are all ASCII. Facilitating that sort of behavior in 3 would probably cause more issues than it solves. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30114] json module: it is not possible to override 'true', 'false' values during encoding bool
Bob Ippolito added the comment: Agreed, this does seem unnecessary. The library has been in active use for over a decade, and this is the first time I've seen this request. I would recommend preprocessing the data that you're going to encode if you have a need for this. -- stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29992] Expose parse_string in JSONDecoder
Bob Ippolito added the comment: I agree with that sentiment. If we were to want to support this use case I would rather put together a coherent way to augment the parsing/encoding of anything than bolt it on to what we have. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29992> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29863] Add a COMPACT constant to the json module
Bob Ippolito added the comment: I suppose I'm +0. I don't think this is particularly useful, but this is closer to the ideal of just having a boolean option. We should probably also plan to remove the documentation for what the type of separators is to give the impression that COMPACT and the default are the only valid options. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29636] Specifying indent in the json.tool command
Bob Ippolito added the comment:
Probably the best thing we could do here is to mirror the options available in
similar tools, such as jq: https://stedolan.github.io/jq/manual/#Invokingjq
The relevant options here would be:
--indent
--tab
--compact-output
--sort-keys
The default indent in jq is 2, which I tend to prefer these days, but maybe 4
is still appropriate given PEP 8:
$ echo '[{}, {"a": "b"}, 2, 3, 4]' | jq
[
{},
{
"a": "b"
},
2,
3,
4
]
This is how jq interprets --compact-output:
$ echo '[{}, {"a": "b"}, 2, 3, 4]' | jq --compact-output
[{},{"a":"b"},2,3,4]
I do not think that it's worth having the command-line tool cater to people
that want to indent in other ways (e.g. using a string that isn't all spaces or
a single tab).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29636>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29667] socket module sometimes loses response packets
New submission from Bob Kline:
The socket module does not always return response packets which are
successfully delivered to the client host. We ran into this problem with an
HTTP request for which socket.recv() raised an exception instead of returning
the 301 redirection response which the web server sent back:
socket.error: [Errno 10054] An existing connection was forcibly closed by the
remote host
We did some packet tracing, and saw that there were six packets exchanged for
the connection:
client: [SYN]
server: [SYN,ACK]
client: [ACK]
client: GET /cam HTTP/1.1 ...\r\n\r\n
server: HTTP/1.0 301 Moved Permanently ...\r\n\r\n
server: [RST,ACK]
The failure appears to be timing dependent. If the 301 response is processed
quickly enough (the usual case), the socket.recv() call returns it successfully
to the caller. If sufficient delay is introduced, however, the 301 response is
discarded, and the exception is raised. This can happen, for example, if the
socket library has to take the time to handle setting up a requested timeout.
On a slow enough machine, the following code will reproduce the problem:
import socket
s = socket.create_connection(("www.cancer.gov", 80), timeout=5)
s.sendall("GET /cam HTTP/1.1\r\nHost: www.cancer.gov\r\n\r\n")
print s.recv(8192)
You might have to stick a time.sleep(.5) call right in front of the s.recv()
call if you can't find a slow enough machine to test on.
This appears to be a Windows-specific problem, as I can't reproduce it on a
Linux or OS X client, no matter how much of a delay is introduced.
Platform: Windows (any version) with Python 2.7 or Python 3.6.
--
components: Library (Lib)
messages: 288648
nosy: bkline
priority: normal
severity: normal
status: open
title: socket module sometimes loses response packets
type: behavior
versions: Python 2.7, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29667>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29540] Add compact=True flag to json.dump/dumps
Bob Ippolito added the comment: I would recommend a moratorium on new options until we have a plan to make the usage of the JSON APIs simpler overall. It's accumulated too many options over time. The real trouble is figuring out how to do this in a backwards compatible way that does not impact performance too much. Off-hand, I can't think of any obvious way aside from using new function names with a cleaner options list. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29540] Add compact=True flag to json.dump/dumps
Bob Ippolito added the comment: I agree, in isolation it's a fine proposal, but the interface here is already a bit too complex and the benefit is pretty minimal. When the size really does matter, you can take care to set it correctly once and be done with it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
Bob Alexander added the comment: Oops, clarification... I just reread my kind of long previous post, and realized it wasn't very explicit that anything concerning file extensions or prepending the current directory to the PATH apply to Windows only; not Unix (of course). The "returning absolute, normalized paths" suggestions are multi-platform I only tested the modified code on Windows. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
Bob Alexander added the comment: Since there seems to be ongoing work on the "which" function, here are a few more thoughts on this function's future: - The existing version does not prepend the current directory to the path if it is already in the path. If the current directory is in the path but is not the first element, it will not be the first directory searched. It seems that the desired behavior is to search the current directory first, so the current directory should *always* be prepended. The existing "which" function already has an optimization to only search each directory once, so it's not a problem if the current directory is unconditionally prepended and may end up in there twice. This change would actually be a "correction", since the doc says the current directory is prepended - The function should always return an absolute path, which is the behavior of the Unix(1) "which" command and, I think, is the typical expected behavior of a "which"-type request. The existing implementation returns a relative path in certain cases, such as if the file is found via a relative directory reference in the path. This change is not inconsistent with the doc, since the doc does not address it. - It would be nice if the extension added when the given command has no extension were lower case, instead of the upper case extension retrieved from the PATHEXT environment variable. Several other "which" implementations work that way (e.g. see Go's os/exec.LookPath function), producing a more aesthetically pleasing name, as well as being more consistent with naming practices of the last 20+ years. The shocking-looking upper case sxtensions remind me of VERY OLD DOS programs :-) This presents no conflict with the doc, and does not affect "correctness" since Windows file names are case-independent. A previous commenter objected to adding lower case extensions, but consider: - The current version never returns the extension case of the actual file. It returns the extension of the command string passed to the function, if any, otherwise it adds the extension from the PATHEXT environment variable, either of which might not match the actual file. - Returning the actual extension of the found file might be nice, but would require additional I/O; added expense for little return. This is not done in the current version. - The PATHEXT variable that ships with Windows contains the allowable extensions in upper case, an old DOS artifact. Few executable files these days have uppercase extensions. Using a lower case extension when the function has to invent one is a "modernization". - It would be nice if the returned file path were normalized. Currently, sometimes an unnormalized path is returned with a leading ".\". I did write an update to "which" with the above changes, and also updated the unit tests with: - 2 new tests to catch the bug that is the subject of this issue. - some tests were updated for the small changes such as normalization and lower case added extensions. A zip file is attached with my updates. I'm not an official "contributor", but feel free incorporate the contents in any way you deem appropriate. The files are: shutil.py updated shutil module shutil.py_3_5_1 existing 3.5.1 shutil module -- basis for updates test_shutil_for_current_w_added_tests.py unit tests for existing 3.5.1 version of shutil with new tests to catch this bug test_shutil_for_new_version.py unit tests for attached updated version of shutil test_shutil_3_5_1.py existing 3.5.1 unit tests -- basis for updates Bob -- Added file: http://bugs.python.org/file42365/new_which_bug_files.zip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25257] In subject line email library inserts unwanted space after a thousands comma in a number
New submission from Bob Hossley:
In my function makeMsg(), there is:
msg = email.mime.nonmultipart.MIMENonMultipart('text',
'plain', charset='utf-8')
msg['Subject'] = email.header.Header(subject, 'utf-8')
subject has no space after the thousands comma:
u'1,010 words - "The Blackmail Caucus, a.k.a. the Republican Party" By Paul
Krugman'
But
msg['Subject'].__str__()
'1, 010 words - "The Blackmail Caucus,\n a.k.a. the Republican Party" By Paul
Krugman'
has a space after the thousands comma and the email message later generated has
a space after the thousands comma.
This is objectionable.
Note that the email library also inserts a newline after the comma that is
followed by a space. Since I see no effect of this newline on the email
generated, I have no objection to the newline.
--
components: email
messages: 251782
nosy: SegundoBob, barry, r.david.murray
priority: normal
severity: normal
status: open
title: In subject line email library inserts unwanted space after a thousands
comma in a number
type: behavior
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25257>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25257] In subject line email library inserts unwanted space after a thousands comma in a number
Bob Hossley added the comment: Thank you R. David Murray. I look forward to being able to move my application to Python 3. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25257> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24949] Identifier lookup in a multi-level package is flakey
Bob Hossley added the comment: msg<249269> Thank you David Murray. I should have asked myself, what is reasonable behavior? In the case of email.mime.nonmultipart an explicit import is clearly needed. I was misled by my experience with the os library. As a "package" it is very different from the email library. Importing os also makes available all of what appear at the script syntax level to be all its "sub-packages." 2015-08-28 09:57:26 /home/bob06 $ python Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> print(os.path.split) In the future I will try to remember that the effects of importing a "package" depend on how the "package" is packaged. So far as I'm concerned this issue is closed. I doubt that symptom "flakey Python behavior" is serious enough to interest Canonical. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24949> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24949] Identifier lookup in a multi-level package is flakey
Bob Hossley added the comment: msg249272 Thank you Martin Panter for the documentation URL's. The import machinery is so complicated that I have given up trying to understand what is "correct" behavior.Depending on the code in the relevant __init__.py and/or explicitly referenced Python modules each Python library can have vastly different import behavior. I believe the simplest way to figure out what an import does and hence, what import statements I need is to run a Python interpreter in a terminal, execute an import statement, and then use the dir() function several times to see what the import statement did. The import documentation is only slightly useful due to its great length and complexity. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24949> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24949] Identifier lookup in a multi-level package is flakey
New submission from Bob Hossley:
This seems like a bug to me, but it may be a recognized limitation even though
I couldn't find any documentation suggesting that my tests should not work
reliably. I see no reason why my tests should not work reliably.
I have reliably reproduced the flakeyness under Windows XP with Python 2.6.4
and under Xubuntu 14.04 64-bit with Python 2.7.6 and Python 3.4.0.
Ubuntu 14.04 (trusty) - XFCE desktop (Xubuntu) 64-bit
Gnome: 3.8.4
Kernel: 3.13.0-62-generic
GCC Version: 4.8 (x86_64-linux-gnu)
Xorg Version: 1.15.1 (12 February 2015 02:49:29PM)
Rebooting doesn't help.
I first encountered the flakeyness in a complicated script which I will
describe in outline first. The very, very simple interactive Python sessions
that follow are probably of more interest and use to you.
---
Outline of my complicated script:
import email
# The next line works around a flakeyness in Python
from email.mime.nonmultipart import MIMENonMultipart
msg = email.mime.nonmultipart.MIMENonMultipart('text', 'plain',
charset='utf-8')
Without the above work around I always get Error:
AttributeError: 'module' object has no attribute 'nonmultipart'
Note import email is global. from email.mime.nonmultipart import
MIMENonMultipart is local to the function containing the msg = line which
is the line that fails whenever the workaround is absent.
---
XP Interpreter Session:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Adminpython
Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type help, copyright, credits or license for more information.
import email
print email.mime.nonmultipart.__file__
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'nonmultipart'
print email.mime.nonmultipart.__file__
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'nonmultipart'
print email.mime.nonmultipart.__file__
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'nonmultipart'
print email.mime.nonmultipart.__file__
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'nonmultipart'
print email.mime.nonmultipart.__file__
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'nonmultipart'
from email.mime import nonmultipart
print email.mime.nonmultipart.__file__
C:\bin\Python26\lib\email\mime\nonmultipart.pyc
Xubuntu Python 2.7.6 Session
2015-08-25 14:02:46 /home/bob06
$ python
Python 2.7.6 (default, Jun 22 2015, 17:58:13)
[GCC 4.8.2] on linux2
Type help, copyright, credits or license for more information.
import email
print(email.mime.nonmultipart.__file__)
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'nonmultipart'
print(email.mime.nonmultipart.__file__)
/usr/lib/python2.7/email/mime/nonmultipart.pyc
Xubuntu Python 3.4.0 Session
2015-08-27 15:27:39 /home/bob06
$ python3
Python 3.4.0 (default, Jun 19 2015, 14:20:21)
[GCC 4.8.2] on linux
Type help, copyright, credits or license for more information.
import email
print(email.mime.nonmultipart.__file__)
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'module' object has no attribute 'mime'
print(email.mime.nonmultipart.__file__)
/usr/lib/python3.4/email/mime/nonmultipart.py
--
components: Interpreter Core
messages: 249269
nosy: SegundoBob
priority: normal
severity: normal
status: open
title: Identifier lookup in a multi-level package is flakey
type: compile error
versions: Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24949
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24641] Log type of unserializable value when raising JSON TypeError
Bob Ippolito added the comment: This seems like a very reasonable proposal. It would be great if we could also include a path in the error message (e.g. `obj[foo][1][bar]`) as well to provide enough context to track down the error quickly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24641 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24518] json.dumps should accept key function for ``sort_keys``
Bob Ippolito added the comment: Seems like a good idea to me, I'll make sure this gets in simplejson as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24518 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24518] json.dumps should accept key function for ``sort_keys``
Bob Ippolito added the comment: On further investigation, simplejson has implemented this functionality under a different name since 2.5.0 (2012-03-29). If item_sort_key is a callable (not the default), then the output of dictionaries will be sorted with it. The callable will be used like this: sorted(dct.items(), key=item_sort_key). This option takes precedence over sort_keys. Changed in version 2.5.0: item_sort_key is new in 2.5.0. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24518 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
Bob Alexander added the comment: Hi R. David -- My report is just to notify y'all of a bug that I noticed. The bug is causing me no problem, and it's your option as to whether to fix it or not. I offered a fix, but I haven't the time to perform diffs, etc. You could make that diff yourself, since I sent my modified which function. Just replace the existing which function in the version of shutil you would like to fix, and perform the diff. Bob On Wed, Jun 24, 2015 at 8:26 PM, R. David Murray rep...@bugs.python.org wrote: R. David Murray added the comment: Could you please submit your proposal as a patch? (A diff -u against the existing version). -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24505 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24505 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24505] shutil.which wrong result on Windows
New submission from Bob Alexander:
Python session with 3.5b2
Showing existing error:
from shutil import which
Works OK
which(python)
'C:\\Python27\\python.EXE'
Also works OK
which('C:\\Python27\\python.EXE')
'C:\\Python27\\python.EXE'
Fails
which('C:\\Python27\\python')
Showing better results with my fix (attached):
from which2 import which
which(python)
'C:\\Python27\\python.exe'
which('C:\\Python27\\python.exe')
'C:\\Python27\\python.exe'
which('C:\\Python27\\python')
'C:\\Python27\\python.exe'
Problem is with the short-circuiting code near the beginning of the function.
It fails to check the extensions for Windows when short-circuited.
My fix has a few other improvements -- efficiency and nicer output without
those ugly upper-case extensions.
--
components: Library (Lib)
files: which2.py
messages: 245780
nosy: bobjalex
priority: normal
severity: normal
status: open
title: shutil.which wrong result on Windows
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file39805/which2.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24505
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24223] argparse parsing (mingling --option and optional positional argument)
Bob Alexander added the comment:
Thanks for the note, Martin. I agree that it's a duplicate. (I had done a
brief search for possible dups, but didn't find that one!)
Bob
On Sun, May 17, 2015 at 8:29 PM, Martin Panter rep...@bugs.python.org
wrote:
Martin Panter added the comment:
I suggest this is a duplicate of Issue 15112. The same problem also
happens with nargs=*, and that issue apparently has a patch to handle
both cases.
For the record, this is the resulting error, and a demo that it works if
the option comes before the positional arguments:
print(test 2:, ap.parse_args([abc, --option, mmm]))
usage: [-h] [--option] arg_1 [arg_2]
: error: unrecognized arguments: mmm
Traceback (most recent call last):
File stdin, line 1, in module
File /home/proj/python/cpython/Lib/argparse.py, line 1729, in
parse_args
self.error(msg % ' '.join(argv))
File /home/proj/python/cpython/Lib/argparse.py, line 2385, in error
self.exit(2, _('%(prog)s: error: %(message)s\n') % args)
File /home/proj/python/cpython/Lib/argparse.py, line 2372, in exit
_sys.exit(status)
File /home/pythonstartup.py, line 345, in exit
raise SystemExit(code)
__main__.SystemExit: 2
ap.parse_args([--option, abc, mmm])
Namespace(arg_1='abc', arg_2='mmm', option=True)
--
nosy: +vadmium
resolution: - duplicate
stage: - resolved
status: open - closed
superseder: - argparse: nargs='*' positional argument doesn't accept any
items if preceded by an option and another positional
title: argparse parsing bug - argparse parsing (mingling --option and
optional positional argument)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24223
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24223
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24223] argparse parsing bug
New submission from Bob Alexander: Here is simple example of failure to parse arguments that should parse OK. In the following little program, the second from last line contains an aargument sequence that parses OK, but the last line should but doesn't. import argparse ap = argparse.ArgumentParser() ap.add_argument(--option, action=store_true) ap.add_argument(arg_1) ap.add_argument(arg_2, nargs=?) print(test 1:, ap.parse_args([abc, mmm, --option])) print(test 2:, ap.parse_args([abc, --option, mmm])) -- components: Library (Lib) messages: 243447 nosy: bobjalex priority: normal severity: normal status: open title: argparse parsing bug type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24223 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
