[issue46560] ParamSpec: Typo in doc string
New submission from Evan : Apologies if this is pedantic; in the typing.py file the ParamSpec's doc string says: "They are only valid when used in ``Concatenate``, or s the first argument to ``Callable``" I believe it should be: "They are only valid when used in ``Concatenate``, or as the first argument to ``Callable``" s -> as -- messages: 411970 nosy: ESchalton priority: normal severity: normal status: open title: ParamSpec: Typo in doc string type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45807] Strange SyntaxError message / suggestions for "@x = 123"
Change by Evan : -- nosy: +schmave ___ Python tracker <https://bugs.python.org/issue45807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45761] recursive ProcessPoolExecutor invoke unable to return result
New submission from Evan Greenup : Read the hello.py in attachment. This simple shallow recursion will never return result. -- components: Library (Lib) files: hello.py messages: 406003 nosy: evan0greenup priority: normal severity: normal status: open title: recursive ProcessPoolExecutor invoke unable to return result type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file50431/hello.py ___ Python tracker <https://bugs.python.org/issue45761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45761] recursive ProcessPoolExecutor invoke unable to return result
Change by Evan Greenup : Added file: https://bugs.python.org/file50432/hello.py ___ Python tracker <https://bugs.python.org/issue45761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40864] spec_set/autospec/spec seems to not be reading attributes defined in class body
Change by Evan Fagerberg : -- keywords: +patch pull_requests: +21567 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22572 ___ Python tracker <https://bugs.python.org/issue40864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40864] spec_set/autospec/spec seems to not be reading attributes defined in class body
Evan Fagerberg added the comment: Reflecting on it more, there should be a sensible way to retrieve the set attributes of the init method of any class without explicitly instantiating it, via the inspect module. -- ___ Python tracker <https://bugs.python.org/issue40864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40864] spec_set/autospec/spec seems to not be reading attributes defined in class body
Evan Fagerberg added the comment: Rereading the documentation, I see that a class attribute set to null will return a MagicMock for that attribute. That might be a reasonable workaround. Perhaps the more concrete solution would be that dir lists uninitialized class attributes and if a type hint is present the class attributes uses a spec of that type hint. -- ___ Python tracker <https://bugs.python.org/issue40864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40864] spec_set/autospec/spec seems to not be reading attributes defined in class body
Evan Fagerberg added the comment: Sorry one small note, the error in the example happens on ```python logger.propagate = False ``` and not ```python assert logger.propagate is False ``` -- ___ Python tracker <https://bugs.python.org/issue40864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40864] spec_set/autospec/spec seems to not be reading attributes defined in class body
New submission from Evan Fagerberg : Hello, I really like that this library allows for really strict mocking however one thing I have noticed is that it seems like using spec on a mock does not properly read the class body for attributes like some of the documentation claims. For example this is a snippet of the Logger class in python 3.6's `logging` module ```python class Logger(Filterer): name: str level: int parent: Union[Logger, PlaceHolder] propagate: bool handlers: List[Handler] disabled: int ``` Now I want to mock that class ensuring that propagate gets set to False for example ```python from unittest import mock from logging import Logger logger = mock.Mock(spec_set=Logger) logger.propagate = False assert logger.propagate is False *** AttributeError: Mock object has no attribute 'propagate' ``` I have noticed this does work when the value is initialized in the class body so for example ```python class Logger(Filterer): name: str level: int parent: Union[Logger, PlaceHolder] propagate: bool = False handlers: List[Handler] disabled: int ``` This would not fail with the test in question. Wondering if this is intended behavior or not or if I am misunderstanding something. I have tested this with Python 3.6.10, 3.8.2, all with the same result. -- components: Tests messages: 370712 nosy: efagerberg priority: normal severity: normal status: open title: spec_set/autospec/spec seems to not be reading attributes defined in class body type: behavior versions: Python 3.6, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40864> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39833] Bug in html parsing module triggered by malformed input
<pre>
New submission from Evan <ep58...@student.american.edu>:
Relevant base python library--
C:\Users\User\AppData\Local\Programs\Python\Python38\lib\_markupbase.py
The issue- After parsing over 900 SEC filings using beautifulsoup4, I get this
user warning.
UserWarning: unknown status keyword 'ERF' in marked section
warnings.warn(msg)
Followed by a traceback
File
"C:\Users\\AppData\Local\Programs\Python\Python38\lib\site-packages\bs4\__init__.py",
line 325, in __init__
self._feed()
File "C:\Users\\AppData\Local\Programs\Python\Python38\lib\_markupbase.py",
line 160, in parse_marked_section
if not match:
UnboundLocalError: local variable 'match' referenced before assignment
It's probably to due to malformed input from on of the docs.
144 lines into _markupbase lib we have:
# Internal -- parse a marked section
# Override this to handle MS-word extension syntax <![if
word]>content<![endif]>
def parse_marked_section(self, i, report=1):
rawdata= self.rawdata
assert rawdata[i:i+3] == '<![', "unexpected call to
parse_marked_section()"
sectName, j = self._scan_name( i+3, i )
if j < 0:
return j
if sectName in {"temp", "cdata", "ignore", "include", "rcdata"}:
# look for standard ]]> ending
match= _markedsectionclose.search(rawdata, i+3)
elif sectName in {"if", "else", "endif"}:
# look for MS Office ]> ending
match= _msmarkedsectionclose.search(rawdata, i+3)
else:
self.error('unknown status keyword %r in marked section' %
rawdata[i+3:j])
if not match:
return -1
if report:
j = match.start(0)
self.unknown_decl(rawdata[i+3: j])
return match.end(0)
`match` should be set to None in the fall-through else statement right before
`if not match`.
--
components: Library (Lib)
messages: 363234
nosy: SanJacintoJoe
priority: normal
severity: normal
status: open
title: Bug in html parsing module triggered by malformed input
type: compile error
versions: Python 3.8
___
Python tracker <rep...@bugs.python.org>
<<a rel="nofollow" href="https://bugs.python.org/issue39833">https://bugs.python.org/issue39833</a>>
___
___
Python-bugs-list mailing list
Unsubscribe:
<a rel="nofollow" href="https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com">https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com</a>
</pre>
[issue39092] Csv sniffer doesn't attempt to determine and set escape character.
New submission from Evan : I observed a false positive for the csv sniffer has_header method. (It thought there was a header when there was not.) This is due to the fact that in has_header, it determines the csv dialect by sniffing it, and failed to determine that the file I was using had an escape character of '\'. Since it doesn't set the escape character, it then incorrectly broke the first line of the file into columns, since it encountered an escaped quote within a quoted column, and treated that as the end of that column. (It correctly determined that the dialect wasn't doublequote, but apparently still needs to have the escape character set to handle an escaped quotechar.) I think one (or both) of these things should be done here to avoid this false positive: 1.) Allow a dialect to be passed to has_header, so that someone could specify the escape character of the dialect if it were known. 2.) Allow the sniff method of the Sniffer class to detect and set the escapechar. -- components: Library (Lib) messages: 358645 nosy: evan.whitfield priority: normal severity: normal status: open title: Csv sniffer doesn't attempt to determine and set escape character. type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37095] [Feature Request]: Add zstd support in tarfile
New submission from Evan Greenup : Zstandard is getting more and more popular. It could be awesome if tarfile support this compression format for .tar.zst file. -- components: Library (Lib) messages: 343945 nosy: evan0greenup priority: normal severity: normal status: open title: [Feature Request]: Add zstd support in tarfile type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue37095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35355] Some Errors involving formatted strings aren't reported in the right place.
Change by Evan Newman : -- title: Some Errors involving formatted strings aren't reported in the right place. -> Some Errors involving formatted strings aren't reported in the right place. ___ Python tracker <https://bugs.python.org/issue35355> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35355] Some Errors involving formatted strings aren't reported in the right place.
New submission from Evan Newman :
Formatted strings seem to have some quirks.
if you try putting in this, for example;
print(f'{0 0}')
; you get a syntax error, which is probably intended, but where the error is
reported is not always accurate. for example;
#just a comment, it doesn't matter what it says
print(f'{0 0}')
;will raise the syntax error, and highlight the j,u,and s in the comment! that
doesn't help, and makes it look like the comment is the error. this is a real
pain to debug if you hadn't known about this. it took me about 2 hours to
track down the problem. seriously, this should be fixed. I haven't tested the
problem in any editor but idle, so the cause could be anywhere. I was first
using 3.7.0, I've just updated to 3.7.1 to make sure it still happens, and it
does.
--
assignee: terry.reedy
components: IDLE
files: recreation.py
messages: 330719
nosy: Enewman, terry.reedy
priority: normal
severity: normal
status: open
title: Some Errors involving formatted strings aren't reported in the right
place.
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47959/recreation.py
___
Python tracker
<https://bugs.python.org/issue35355>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34706] Signature.from_callable sometimes drops subclassing
Change by Buck Evan : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue34706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34706] Signature.from_callable sometimes drops subclassing
New submission from Buck Evan : Specifically in the case of a class that does not override its constructor signature inherited from object. Github PR incoming shortly. -- components: Library (Lib) messages: 325501 nosy: bukzor priority: normal severity: normal status: open title: Signature.from_callable sometimes drops subclassing versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34379] Move note about repeated calls to json.dump using the same fp to the json.dump section
Change by Evan Allrich : -- keywords: +patch pull_requests: +8215 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34379] Move note about repeated calls to json.dump using the same fp to the json.dump section
New submission from Evan Allrich : At present the note [0] appears under the documentation for `json.dumps` (which does not use the `fp` argument). It seems the note would be better placed with the documentation for the affected function. [0] > Note > > Unlike pickle and marshal, JSON is not a framed protocol, so trying to > > serialize multiple objects with repeated calls to dump() using the same > fp > will result in an invalid JSON file. -- assignee: docs@python components: Documentation messages: 323396 nosy: docs@python, eallrich priority: normal severity: normal status: open title: Move note about repeated calls to json.dump using the same fp to the json.dump section type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Evan Driscoll <eva...@gmail.com> added the comment: One last comment for the time being. I actually think *both* changes are valuable. Fixing the bug, well, fixes the bug if you can set the appropriate flag. The improved error message still helps for existing code and new code that *doesn't* set the flag. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Evan Driscoll <eva...@gmail.com> added the comment:
> I also think that nargs=## could maybe be special-cased to just ignore
> the A/O designation completely and only check there are enough, but I
> haven't tried this out. Does this seem like a viable approach? Would a
> patch that does that, subject to some flag, be of interest?
I can't leave well enough alone, so, with the following additional patch:
-def _match_argument(self, action, arg_strings_pattern):
+def _match_argument(self, action, arg_strings_pattern, arg_strings,
start_index):
+import numbers
+nargs = action.nargs if action.nargs is not None else 1
+if isinstance(nargs, numbers.Number) and len(arg_strings_pattern) >=
nargs:
+return nargs
+
# match the pattern for this action to the arg strings
nargs_pattern = self._get_nargs_pattern(action)
match = _re.match(nargs_pattern, arg_strings_pattern)
...
Then I get this:
>>> import argparse
>>> parser = argparse.ArgumentParser(prog='a2x')
>>> parser.add_argument('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '--safe'])
Namespace(asciidoc_opts='--safe')
Comments on this approach?
(Again, I haven't run tests, it'd need to be controlled by a flag per your
desire to not change existing behavior, etc.)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Evan Driscoll <eva...@gmail.com> added the comment:
I ran into this issue today. (Or rather a couple weeks ago, and I just
diagnosed it today.)
Reading through the thread and from the bug's age it looks like a fix is
probably not to promising, but Cherniavsky Beni's 2016-04-11 22:03 comment
> Can I additional suggest a change to the error message, e.g.:
>
> $ prog --foo -bar
> prog: error: argument --foo: expected one argument
> (tip: use --foo=-bar to force interpretation as argument of --foo)
>
> This can be safely added in the current mode with no opt-in required,
> and will relieve the immediate "but what can I do?" confusions of
> users. The workaround is hard to discover otherwise, as `--foo=x` is
> typically equivalent to `--foo x`.
and found it intriguing.
Messing around with the code, I was able to produce the attached patch, which,
when run on the test case in the original comment, produces this output:
>>> import argparse
>>> parser = argparse.ArgumentParser(prog='a2x')
>>> parser.add_argument('--asciidoc-opts',
... action='store', dest='asciidoc_opts', default='',
... metavar='ASCIIDOC_OPTS', help='asciidoc options')
>>> parser.parse_args(['--asciidoc-opts', '--safe'])
usage: a2x [-h] [--asciidoc-opts ASCIIDOC_OPTS]
a2x: error: argument --asciidoc-opts: expected one argument (if you intended
--safe to be the argument of --asciidoc-opts, pass --asciidoc-opts=--safe
instead)
Would a cleaned-up version of this patch be of interest? (There are a couple
obvious problems, like the out-of-bounds access to the list, PEP8, etc.) Is
there some other way you could suggest to achieve this aim if you don't like
that approach?
(I also think that nargs=## could maybe be special-cased to just ignore the A/O
designation completely and only check there are enough, but I haven't tried
this out. Does this seem like a viable approach? Would a patch that does that,
subject to some flag, be of interest?)
The patch is relative to, I believe, the distribution version of 2.7.8. (Sorry,
it's what I had handy as a custom build. :-) Updating it to .14 and to
3.whatever would be part of the cleanup.)
--
Added file: https://bugs.python.org/file47302/python-argparse-error.patch
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)
Change by Evan Driscoll <eva...@gmail.com>: -- nosy: +evaned ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue9334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31446] _winapi.CreateProcess (used by subprocess) is not thread-safe
New submission from Evan Andrews:
The method used for spawning subprocesses on Windows is not thread-safe under
certain circumstances. The following example demonstrates how this manifests:
>>> import threading
>>> import subprocess
>>> for i in range(100):
... threading.Thread(
... target=subprocess.Popen,
... args=('ping localhost',),
... kwargs={'stdout': subprocess.DEVNULL},
... ).start()
...
Exception in thread Thread-1202:
Traceback (most recent call last):
File "C:\Program Files\Python36\lib\threading.py", line 916, in
_bootstrap_inner
self.run()
File "C:\Program Files\Python36\lib\threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "C:\Program Files\Python36\lib\subprocess.py", line 707, in __init__
restore_signals, start_new_session)
File "C:\Program Files\Python36\lib\subprocess.py", line 990, in
_execute_child
startupinfo)
ValueError: embedded null character
Exception in thread Thread-1206:
Traceback (most recent call last):
File "C:\Program Files\Python36\lib\threading.py", line 916, in
_bootstrap_inner
self.run()
File "C:\Program Files\Python36\lib\threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "C:\Program Files\Python36\lib\subprocess.py", line 707, in __init__
restore_signals, start_new_session)
File "C:\Program Files\Python36\lib\subprocess.py", line 990, in
_execute_child
startupinfo)
ValueError: embedded null character
>>>
subprocess.Popen calls down to _winapi.CreateProcess, which calls
CreateProcessW. When args is passed as a fixed string, the result of the
argument conversion is attached to the object and shared by future calls into C
code. However, the documentation for CreateProcess states:
"The Unicode version of this function, CreateProcessW, can modify the contents
of this string. Therefore, this parameter cannot be a pointer to read-only
memory (such as a const variable or a literal string). If this parameter is a
constant string, the function may cause an access violation." (Source:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx)
It appears CreateProcessW is briefly inserting null characters into the buffer,
causing errors if that buffer is used elsewhere before it is changed back.
The call to CreateProcessW using the shared buffer can be seen here:
https://github.com/python/cpython/blob/b8f4163da30e16c7cd58fe04f4b17e38d53cd57e/Modules/_winapi.c#L879
Note that this error does not occur when passing args as a list, as
subprocess.list2cmdline creates a new (though identical) string for each
invocation.
One potential solution is to allocate a copy of command_line (the shared
buffer) instead of using the original.
--
components: Library (Lib)
messages: 302045
nosy: evan_
priority: normal
severity: normal
status: open
title: _winapi.CreateProcess (used by subprocess) is not thread-safe
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31446>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Evan Andrews added the comment:
Thanks, Vinay. I understand you're busy, and I'm in no particular rush to have
this looked at, so feel free to come back to it when you have more time. I've
submitted the changes as a PR.
I also have an additional concern - even with this change, there is no way to
tell whether a token should be considered special or text:
>>> import shlex
>>> def split(line):
... s = shlex.shlex(line, posix=True, punctuation_chars=True)
... s.whitespace_split = True
... return list(s)
...
>>> split('a&')
['a', '&&', 'b']
>>> split('a "&&" b')
['a', '&&', 'b']
I feel this can be addressed after this as a separate issue but wanted to
mention it now so you're aware.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28595>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Changes by Evan Andrews <evanundersc...@gmail.com>: -- pull_requests: +2134 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Evan Andrews added the comment: Do I need to create a pull request for this? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Evan Andrews added the comment:
Unfortunately shlex.shlex's defaults are probably going to remain that way for
a long time in order to avoid breaking backwards compatibility. Presumably
shlex.split was added so you didn't have to remember to set posix and
whitespace_split yourself.
The particular problem I'm addressing in this issue is that the new
punctuation_chars argument doesn't currently work with whitespace_split.
>>> def split(text, ws=False, pc=False):
... s = shlex.shlex(text, posix=True, punctuation_chars=pc)
... s.whitespace_split = ws
... return list(s)
...
>>> split('foo,bar>baz')
['foo', ',', 'bar', '>', 'baz']
>>> split('foo,bar>baz', ws=True)
['foo,bar>baz']
>>> split('foo,bar>baz', pc=True)
['foo', ',', 'bar', '>', 'baz']
>>> split('foo,bar>baz', ws=True, pc=True)
['foo,bar>baz']
With my patch, the last example outputs ['foo,bar', '>', 'baz'].
Before the release of 3.6 I was arguing that punctuation_chars should not
attempt to augment wordchars at all, since the idea of wordchars is inherently
incorrect as you point out. Now I think it's too late to change, hence my patch
treats this as a new feature in 3.7.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28595>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Evan Andrews added the comment: Attaching an updated patch now that the two linked issues are resolved. -- Added file: http://bugs.python.org/file46335/shlex2.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29262] Provide a way to check for *real* typing.Union instances
Evan added the comment: I'm also interested in this. I've been using 'thing.__origin__ is typing.Union', but this doesn't work in some of the older versions of typing. -- nosy: +evan_ ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22343] Install bash activate script on Windows when using venv
Evan added the comment: Works for me on the master branch. Thanks, Vinay. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22343] Install bash activate script on Windows when using venv
Evan added the comment: Works for me in Git Bash. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29213] python -m venv activate.bat has weird mix of line endings
Evan added the comment: The scripts are being read in with mode 'rb', decoded, modified, then written back out with mode 'w'. This means the EOL conversion doesn't happen on the way in, but does happen on the way out, and so '\r\n' becomes '\r\r\n'. One fix would be to always use binary mode and encode the contents back to bytes instead. However since there are no longer any binary files in venv/Scripts/*, perhaps a better fix is to remove the binary handling entirely and always use text mode? -- nosy: +evan_, vinay.sajip versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29132] shlex.shlex with punctuation_chars and posix doesn't handle punctuation next to quotes
Evan added the comment: I've just submitted the form. I'm attaching a second patch which also addresses another similar bug demonstrated in the test case. The fix is to check for the 'c' state before checking for quotes or escape characters. -- Added file: http://bugs.python.org/file46174/shlex-posix-quote2.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29163] shlex error in posix mode and empty quotes
Evan added the comment: My mistake, it was addressed directly in issue21999. This is already fixed in 2.7.13 and will be fixed in 3.5.3. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29163] shlex error in posix mode and empty quotes
Evan added the comment:
This is also broken in 3.5.2, but not in 3.6.0:
>>> list(shlex.shlex('echo b="",echo bar', posix=True))
['echo', 'b', '=', '', ',', 'echo', 'bar']
I'm guessing it was fixed incidentally by the changes in issue1521950.
--
versions: +Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29163>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29163] shlex error in posix mode and empty quotes
Changes by Evan <evanundersc...@gmail.com>: -- nosy: +evan_ ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
Evan added the comment: Second patch looks good, thanks. Do you also want to doctest that? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
Evan added the comment: Sorry for not being more clear in the original report - the error is in the code, not in the output. The old behavior is punct=False, the new is punct=True. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29132] shlex.shlex with punctuation_chars and posix doesn't handle punctuation next to quotes
Evan added the comment: I've attached a simplistic patch which fixes the problem. I suspect a better fix might be to shuffle the elif branches around so the extra condition isn't necessary. Vinay, what are your thoughts? -- keywords: +patch Added file: http://bugs.python.org/file46112/shlex-posix-quote.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Evan added the comment: I've attached a more complete patch. This takes the conservative approach of retaining all functionality of 3.6 and treating this as a new feature for 3.7. I don't think this is suitable for 3.6.1 given this new behavior contradicts what is currently written in the documentation (though this can be discussed further). I've also run into a couple of other bugs that I've made separate issues for: * The example in the documentation mixes up 'Old' and 'New' (issue29133) * The updated example contains a bug (the '>abc' token should actually be two tokens) (issue29132) These should both be fixed in 3.6.1 regardless of where this goes. -- versions: +Python 3.7 Added file: http://bugs.python.org/file46111/shlex.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29133] Minor inaccuracy in shlex.shlex punctuation_chars example
New submission from Evan: https://docs.python.org/3/library/shlex.html#improved-compatibility-with-shells The code sample here does not match the output - the first line is labelled 'New' and the second line 'Old'. -- assignee: docs@python components: Documentation messages: 284481 nosy: docs@python, evan_ priority: normal severity: normal status: open title: Minor inaccuracy in shlex.shlex punctuation_chars example versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29132] shlex.shlex with punctuation_chars and posix doesn't handle punctuation next to quotes
New submission from Evan:
When both punctuation_chars and posix are used, any punctuation directly next
to quoted characters is interpreted as a single token.
>>> from shlex import shlex
>>> list(shlex('>"a"', posix=True))
['>', 'a']
>>> list(shlex('>"a"', punctuation_chars=True))
['>', '"a"']
>>> list(shlex('>"a"', posix=True, punctuation_chars=True))
['>a'] # should be ['>', 'a']
--
components: Library (Lib)
messages: 284480
nosy: evan_, r.david.murray, vinay.sajip
priority: normal
severity: normal
status: open
title: shlex.shlex with punctuation_chars and posix doesn't handle punctuation
next to quotes
versions: Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29132>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29128] No way to instsall win32com on python 3.6
Evan added the comment: This package doesn't yet have a wheel for Python 3.6, so it falls back on the source distribution, and the setup.py file doesn't run under Python 3. You can either wait for the maintainer to upload the new wheel to PyPI, or take one of the recently built installers from https://sourceforge.net/projects/pywin32/files/pywin32/Build%20220/ -- nosy: +evan_ ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29093] Windows launcher breaks history in Git Bash
Evan added the comment: No problem, thanks for your time. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29093] Windows launcher breaks history in Git Bash
Evan added the comment: This appears to be a bug with Git Bash, not Python or the launcher. Closing. -- resolution: -> third party status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29093] Windows launcher breaks history in Git Bash
Evan added the comment: I tried compiling the version of the launcher from https://github.com/python/cpython/tree/3.3, and the bug is still present there. Previously when I was testing older versions with the launcher I had to uninstall pyreadline from several of them to confirm the bug was present. In retrospect it's obvious that this means the bug would have been hidden from me until now; I just happened to notice it after installing 3.6 because I hadn't installed pyreadline. I now believe this affects *all* versions of the launcher, and that this has nothing to do with 3.6.0 in particular. Associated issue: https://github.com/git-for-windows/git/issues/1013 -- versions: +Python 3.3 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29093] Windows launcher breaks history in Git Bash
Evan added the comment: No, it doesn't provide a version of readline that works with Windows binaries. Trying to import readline fails no matter how I start Python. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29093] Windows launcher breaks history in Git Bash
Evan added the comment: Yes, the history within the current Python session. It's worth noting that the history usually behaves like in cmd.exe, not bash. (I don't have a py.exe without the bug at the moment to confirm that is the same.) Testing now, it seems all the history shortcuts (F1-F9) function correctly when running Python directly, but when run with the launcher all behave as though the history buffer were empty. Somehow the combination of the shell and the launcher are stopping it from keeping history. I'll open an issue on their bug tracker and report back. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29093] Windows launcher breaks history in Git Bash
New submission from Evan: When I launch *any* version of Python using py.exe from Git Bash, the up and down arrows clear the line buffer instead of navigating history. The following things all work as intended: * py.exe in cmd.exe * py.exe in Git Bash using winpty * Python 2.7, 3.5, 3.6 when run directly The only thing that appears to trigger this bug is using the launcher in Git Bash without winpty. Tested with the following versions of Git Bash: * GNU bash, version 4.3.42(2)-release (x86_64-pc-msys) * GNU bash, version 4.3.46(2)-release (x86_64-pc-msys) Unfortunately I can't point to exactly which version of the launcher introduced this bug. Initially I was certain this only happened when I upgraded from 3.5.2 to 3.6.0, but now I've checked another machine with 3.5.2 and 3.4.4, and the bug appears there too. -- components: Windows messages: 284171 nosy: evan_, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows launcher breaks history in Git Bash versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22343] Install bash activate script on Windows when using venv
Evan added the comment: +1, I'm also using Windows with Git Bash and venv is unusable for me without Brandon's workaround. -- nosy: +evan_ ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
Evan added the comment: This issue is relevant to Python 2 on Windows since you need to disable the EOL conversion if you're trying to receive binary data on stdin. See: http://stackoverflow.com/questions/2850893/reading-binary-data-from-stdin -- nosy: +evan_ ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28960] Small typo in Thread.join docs
Evan added the comment: I think the patch should remove the comma, not the double dash. This is a parenthetical remark and should end the same way it starts. See https://www.grammarly.com/handbook/punctuation/dash/2/dash-parenthetical-information/ -- nosy: +evan_ ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Evan added the comment: I've created issue28784 to capture the documentation fixes. When I have more spare time, I'll work on a more complete patch. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28784] shlex.shlex punctuation_chars documentation should use posix=True
New submission from Evan: (This discussion started on issue28595.) The new punctuation_chars keyword argument is intended to provide "compatibility with the parsing performed by common Unix shells like bash, dash, and sh", however the documentation and examples do not mention that the user should also set posix=True (which defaults to False for shlex.shlex but True for shlex.split). Longer term (over several releases), perhaps the default for posix could be changed from False to True. Alternatively, the punctuation_chars argument could also be added to shlex.split, which would avoid having to interact with shlex.shlex directly. -- assignee: docs@python components: Documentation messages: 281612 nosy: docs@python, evan_, r.david.murray, vinay.sajip priority: normal severity: normal status: open title: shlex.shlex punctuation_chars documentation should use posix=True type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Evan added the comment: I have some additional concerns with the changes introduced in http://bugs.python.org/issue1521950: 1. The fact that posix defaults to False in shlex.shlex (but not in shlex.split) is a huge beginner trap. If users are expecting to use this for "compatibility with the parsing performed by common Unix shells like bash, dash, and sh", they must also remember to set posix=True. The documentation for punctuation_chars makes no mention of this. The examples use non-POSIX mode parsing rules. 2. Even with posix=True, there is no mechanism to escape characters that are special inside double quotes, like $. This is a separate unaddressed incompatibility. For 1, this could be fixed by making posix default to True if punctuation_chars is specified. Longer term, perhaps the default could be changed to True in all cases. I'm not sure what to do about 2. (Please let me know if I should split these out into separate issues.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.shlex should not augment wordchars
Changes by Evan <evanundersc...@gmail.com>: -- title: shlex.split should not augment wordchars -> shlex.shlex should not augment wordchars ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28595] shlex.split should not augment wordchars
New submission from Evan:
The changes to shlex due to land in 3.6 use a predefined set of characters to
"augment" wordchars, however this set is incomplete. For example, 'foo,bar'
should be parsed as a single token, but it is split on the comma:
$ echo foo,bar
foo,bar
>>> import shlex
>>> list(shlex.shlex('foo,bar', punctuation_chars=True))
['foo', ',', 'bar']
(For context on where this was encountered, see
https://github.com/kislyuk/argcomplete/issues/161)
Instead of trying to enumerate all possible wordchars, I think a more robust
solution is to use whitespace_split to include *all* characters not otherwise
considered special.
Ideally this would be fixed before 3.6 is released to avoid needing to maintain
backwards compatibility with the current behaviour, although I understand the
timeline may make this difficult.
I've attached a patch with proposed changes, including updates to the tests to
demonstrate the effective difference. I can make the corresponding
documentation changes if we want this merged.
(I've added everyone to the nosy list from http://bugs.python.org/issue1521950
where these changes originated.)
--
components: Library (Lib)
files: without_augmenting_chars.diff
keywords: patch
messages: 279980
nosy: Andrey.Kislyuk, cvrebert, eric.araujo, eric.smith, evan_, ezio.melotti,
python-dev, r.david.murray, robodan, vinay.sajip
priority: normal
severity: normal
status: open
title: shlex.split should not augment wordchars
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file45333/without_augmenting_chars.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28595>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13829] exception error in _scproxy.so when called after fork
Evan Jones added the comment: This is effectively the same as issue 27126. The discussion there convinced me that this may not be working around, since it isn't the only place this can happen! This same crash, caused by libdispatch not being fork compatible, also happens with sqlite and tk. We can probably add a workaround specifically for _scproxy.so, but those others would still cause the crash. -- nosy: +evanj ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27227] argparse fails to parse [] when using choices and nargs='*'
New submission from Evan:
When using nargs='*' with choices, it is impossible to specify 0 args:
from argparse import ArgumentParser
parser = ArgumentParser()
parser.add_argument('foo', choices=['foo'], nargs='*')
args = parser.parse_args([]) # <-- fails, error message below
assert args.foo == []
# usage: args.py [-h] [{foo} [{foo} ...]]
# args.py: error: argument foo: invalid choice: [] (choose from 'foo')
The problem appears to be this block of code trying to validate `value`
immediately after it sets it to `[]`:
# when nargs='*' on a positional, if there were no command-line
# args, use the default if it is anything other than None
elif (not arg_strings and action.nargs == ZERO_OR_MORE and
not action.option_strings):
if action.default is not None:
value = action.default
else:
value = arg_strings
self._check_value(action, value)
The fix seems to be as simple as moving the check under `if action.default is
not None`.
(NOTE: This would be also adequately solved by patches already attached to
http://bugs.python.org/issue9625, however the minimal solution to this problem
is simpler.)
--
components: Library (Lib)
messages: 267404
nosy: evan_
priority: normal
severity: normal
status: open
title: argparse fails to parse [] when using choices and nargs='*'
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27227>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes
Evan Jones added the comment: I have a crazy idea, but I'm not 100% sure how to implement it: If Python was able to detect and report this error in a friendly way, it would allow people to easily understand what is happening and to work around it. How can we do it? First idea: In the implementation of os.fork(), detect if libdispatch has been used. If it has, throw an exception. I think this is probably possible using the libdispatch public APIs, but I'll need to figure out the details. In general, this could apply on Linux as well: throw an exception if the process has more than one thread running? Second idea: On Mac OS X only, libdispatch is intentionally crashing the process. We could install a signal handler that attempts to detect *this specific crash* in order to throw a friendlier exception, or at worst crash with a useful message. Third idea: Add documentation to the multiprocessing module and os.fork that they are very unsafe on Mac OS X? Maybe there is a better way of making this crash "friendlier"? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27126] Apple-supplied libsqlite3 on OS X is not fork safe; can cause crashes
Evan Jones added the comment: To be clear: My reproduction scripts crash both Python 2.7.10 and Python 3.5.1 when you: 1. Download the source bundle from python.org. 2. Run ./configure; make 3. Use the built binary (because ./configure picks up the system version of libsqlite.dylib) I did some more digging: The underlying root cause is Mac OS X's libdispatch.dylib. A ton of system APIs (like this proxy one, or GUI libraries, etc), use it. It seems the proxy settings API use it to manage inter-process communication. libdispatch has code that explicitly "poisons" the process if it forks. I think this is because it internally spawns threads, so the forked child state is unreliable, and they figure it is better for it to crash than to fail randomly. This is the classic "don't mix threads and fork" issue, its just that the threads are hidden inside a bunch of system APIs. One fix for this particular bug would be for _scproxy to fork and use IPC to read the settings, which I think was mentioned in Issue13829. I think it would not also be crazy to ship the amalgamated sqlite3 with Python, to avoid an accidental dependency on sqlite3. Finally: it might make sense to have 'forkserver' be the default mode for multiprocessing on Mac OS X, since there are other things that cause this same problem (Tkinter is reported on the internet). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24573] Using multiprocessing with tkinter frames in Python 3.4.3 crashes in OS X
Evan Jones added the comment: This is another instance of the following bug: http://bugs.python.org/issue27126 libdispatch (grand central dispatch) is not fork safe. The forkserver approach is a good workaround, thanks! -- nosy: +evan.jo...@bluecore.com ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27126] Mac system sqlite3 not fork safe: Bundle a version?
Changes by Evan Jones <evan.jo...@bluecore.com>: Added file: http://bugs.python.org/file43004/osx_python3_crash.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27126] Mac system sqlite3 not fork safe: Bundle a version?
New submission from Evan Jones: The system version of libsqlite3 that is included in Mac OS X is not fork safe. This means that if a process forks, and the child calls into it, it will crash with the stack trace below. I've reproduced this with both Python 2.7.10 and Python 3.5.1 on Mac OS X 10.11.5. There are a number of reports about this issue on the Internet. The only way I can think to solve this problem is to bundle SQLite with the Python source code, and build an included version. This will avoid the problem, since only Apple's fork of SQLite uses the problematic libdispatch library. Details: * Apple ships a version of sqlite3 that uses their "Grand Central Dispatch" libdispatch library. * Grand Central Dispatch is explicitly *not* thread safe. From their docs: https://developer.apple.com/library/mac/documentation/Performance/Reference/GCD_libdispatch_Ref/index.html "Be careful when mixing GCD with the fork system call. If a process makes GCD calls prior to calling fork, it is not safe to make additional GCD calls in the resulting child process until after a successful call to exec or related functions." * Some System APIs also seem to call into this library. In my case: urllib/urllib2 access the system's proxy settings. Related bugs: * I believe this is the root cause of https://bugs.python.org/issue20353 * Celery also has a detailed bug report: https://github.com/celery/celery/issues/869 * Pure native code can cause this crash: http://ludovicrousseau.blogspot.com/2015/01/os-x-yosemite-bug-pcsc-functions-crash.html Crash details from Mac OS X's system Python: Application Specific Information: crashed on child side of fork pre-exec Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libdispatch.dylib 0x7fff92e8b162 _dispatch_barrier_async_f_slow + 356 1 libsqlite3.dylib0x7fff8a607656 sqlite3_initialize + 2950 2 libsqlite3.dylib0x7fff8a605b21 openDatabase + 65 3 _sqlite3.so 0x000105bb9a55 pysqlite_connection_init + 509 4 org.python.python 0x00010567bc24 0x10562f000 + 314404 5 org.python.python 0x000105639202 PyObject_Call + 99 6 _sqlite3.so 0x000105bbdbf0 0x105bb8000 + 23536 7 org.python.python 0x0001056b5a0b PyEval_EvalFrameEx + 13400 8 org.python.python 0x0001056b8541 0x10562f000 + 562497 9 org.python.python 0x0001056b530c PyEval_EvalFrameEx + 11609 10 org.python.python 0x0001056b23c1 PyEval_EvalCodeEx + 1583 11 org.python.python 0x0001056b1d8c PyEval_EvalCode + 54 12 org.python.python 0x0001056d1a42 0x10562f000 + 666178 13 org.python.python 0x0001056d1ae5 PyRun_FileExFlags + 133 14 org.python.python 0x0001056d1634 PyRun_SimpleFileExFlags + 698 15 org.python.python 0x0001056e3011 Py_Main + 3137 16 libdyld.dylib 0x7fff8eb225ad start + 1 -- components: Macintosh files: osx_python_crash.py messages: 266396 nosy: evan.jo...@bluecore.com, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Mac system sqlite3 not fork safe: Bundle a version? versions: Python 2.7, Python 3.5 Added file: http://bugs.python.org/file43003/osx_python_crash.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27126> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only)
Evan Jones added the comment:
I believe the root cause of this bug is the following issue:
http://bugs.python.org/issue27126 ; a workaround is to run the following code
before forking any subprocesses: sqlite3.connect(':memory:').close()
--
nosy: +evan.jo...@bluecore.com
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20353>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25429] Can segfault Python with itertools.chain.from_iterable
New submission from Evan Hubinger: The code import itertools it = itertools.chain.from_iterable((f() for f in [lambda: it])) list(it) definitely segfaults on Python 2.6, 2.7, 3.3, and 3.4, and probably segfaults on other versions as well. The code is clearly incorrect in that the lambda references the variable being defined, but it seems like it should raise an error instead of segfaulting. -- messages: 253112 nosy: Evan Hubinger priority: normal severity: normal status: open title: Can segfault Python with itertools.chain.from_iterable type: crash versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25429> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22680] Blacklist FunctionTestCase from test discovery
Evan Hubinger added the comment: I wrote a patch to blacklist FunctionTestCase in TestLoader, and a test to make sure FunctionTestCase doesn't show up in the TestSuite after loading a module that includes it. The test runs successfully. This is my first patch, so feedback would be appreciated if I did anything wrong. -- keywords: +patch nosy: +Evan Hubinger Added file: http://bugs.python.org/file40040/issue22680.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22680 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24085] large memory overhead when pyc is recompiled
Buck Evan added the comment: @serhiy.storchaka This is a very stable piece of a legacy code base, so we're not keen to refactor it so dramatically, although we could. We've worked around this issue by compiling pyc files ahead of time and taking extra care that they're preserved through deployment. This isn't blocking our 2.7 transition anymore. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24085] large memory overhead when pyc is recompiled
Buck Evan added the comment: New data: The memory consumption seems to be in the compiler rather than the marshaller: ``` $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 16032 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 16032 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 16032 $ python -c 'import repro' 16032 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 8984 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 8984 $ PYTHONDONTWRITEBYTECODE=1 python -c 'import repro' 8984 ``` We were trying to use PYTHONDONTWRITEBYTECODE as a workaround to this issue, but it didn't help us because of this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24085] large memory overhead when pyc is recompiled
New submission from Buck Evan: In the attached example I show that there's a significant memory overhead present whenever a pre-compiled pyc is not present. This only occurs with more than 5225 objects (dictionaries in this case) allocated. At 13756 objects, the mysterious pyc overhead is 50% of memory usage. I've reproduced this issue in python 2.6, 2.7, 3.4. I imagine it's present in all cpythons. $ python -c 'import repro' 16736 $ python -c 'import repro' 8964 $ python -c 'import repro' 8964 $ rm *.pyc; python -c 'import repro' 16740 $ rm *.pyc; python -c 'import repro' 16736 $ rm *.pyc; python -c 'import repro' 16740 -- files: repro.py messages: 242281 nosy: bukzor priority: normal severity: normal status: open title: large memory overhead when pyc is recompiled versions: Python 3.4 Added file: http://bugs.python.org/file39238/repro.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24085] large memory overhead when pyc is recompiled
Buck Evan added the comment: Also, we've reproduced this in both linux and osx. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24085 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1043134] Add preferred extensions for MIME types
Changes by Evan Jones e...@evanjones.ca: -- nosy: +evanj ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1043134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4696] email module does not unfold headers
Changes by Evan Jones e...@evanjones.ca: -- nosy: +evanj ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11513] chained exception/incorrect exception from tarfile.open on a non-existent file
Evan Dandrea e...@ubuntu.com added the comment: David, Thanks for the pointers. I've updated the patch hopefully adequately addressing your concerns. -- components: +Interpreter Core -Library (Lib) type: behavior - Added file: http://bugs.python.org/file21277/tarfile-fix-multiple-exception-on-enoent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11513] chained exception/incorrect exception from tarfile.open on a non-existent file
Changes by Evan Dandrea e...@ubuntu.com: Removed file: http://bugs.python.org/file21223/tarfile-fix-multiple-exception-on-enoent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
Evan Dandrea e...@ubuntu.com added the comment: Updated the patch to address Michael's concerns. -- Added file: http://bugs.python.org/file21221/test_posixpath_with_same_device.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
Evan Dandrea e...@ubuntu.com added the comment: I've looked at the sameopenfile code, and can see no reason why it would not work on Windows. I've asked Brian to verify this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
Evan Dandrea e...@ubuntu.com added the comment: I haven't used addCleanup here, but have noted it for the future. In this case, using it would require adding another function to handle the reassignment, which I think is a bit more messy than the extra bit of indentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11513] Infinite recursion around raising an exception in tarfile
Evan Dandrea e...@ubuntu.com added the comment: *facepalm* Indeed, thanks for pointing that out and nice catch on the race condition. Attached is a patch to fix the issue as you've suggested, and adds a test case for it. -- keywords: +patch Added file: http://bugs.python.org/file21222/tarfile-fix-multiple-exception-on-enoent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11513] Infinite recursion around raising an exception in tarfile
Changes by Evan Dandrea e...@ubuntu.com: Added file: http://bugs.python.org/file21223/tarfile-fix-multiple-exception-on-enoent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11513] Infinite recursion around raising an exception in tarfile
Changes by Evan Dandrea e...@ubuntu.com: Removed file: http://bugs.python.org/file21222/tarfile-fix-multiple-exception-on-enoent.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11548] Passing format= to unpack_archive fails
Changes by Evan Dandrea e...@ubuntu.com: Added file: http://bugs.python.org/file21228/fix_unpack_with_format.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11548] Passing format= to unpack_archive fails
Changes by Evan Dandrea e...@ubuntu.com: Removed file: http://bugs.python.org/file21196/fix_unpack_with_format.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11560] Expand test coverage in shutil
New submission from Evan Dandrea e...@ubuntu.com: The attached patch increases the coverage in shutil. It makes the following changes: - Tests the code paths for file and directory copies across filesystems by mocking out rename. - Adds a test for shutil.copy. - Adds a test for shutil.copy2. - Tests shutil.unpack_archive with the format specified. - Tests the code path for creating the target directory in _make_tarball. I have tested this on Ubuntu natty and OSX 10.6.6. Note that this will fail until http://bugs.python.org/issue11548 is applied. -- components: Tests files: increase_test_shutil_coverage.patch keywords: patch messages: 131041 nosy: ev, tarek priority: normal severity: normal status: open title: Expand test coverage in shutil Added file: http://bugs.python.org/file21229/increase_test_shutil_coverage.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
New submission from Evan Dandrea e...@ubuntu.com: I've expanded the coverage of the posixpath test. The following scenarios have been added: - lexists with a non-existent file. - ismount with binary data. - ismount with a directory that is not a mountpoint. - ismount with a non-existent file. - ismount with a symlink. - expanduser with $HOME unset. - realpath with a relative path. - sameopenfile with a basic test. I have tested it on Ubuntu natty (20110311) and Mac OSX 10.6.6. -- components: Tests files: test_posixpath.patch keywords: patch messages: 130856 nosy: ev priority: normal severity: normal status: open title: Expand test coverage in posixpath type: behavior Added file: http://bugs.python.org/file21122/test_posixpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
Changes by Evan Dandrea e...@ubuntu.com: -- nosy: +michael.foord ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
Evan Dandrea e...@ubuntu.com added the comment: Fixed a typo in the previous patch. -- Added file: http://bugs.python.org/file21124/test_posixpath.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
Evan Dandrea e...@ubuntu.com added the comment: Added an updated patch that includes testing whether ismount would succeed by faking path being on a different device from its parent. -- Added file: http://bugs.python.org/file21125/test_posixpath_with_same_device.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11503] Expand test coverage in posixpath
Evan Dandrea e...@ubuntu.com added the comment: It's probably best to give the fake stats inode numbers, so if the code does fail to check the st_dev fields, it will fail the test. I've updated the patch with this. -- Added file: http://bugs.python.org/file21128/test_posixpath_with_same_device.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11503 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11513] Infinite recursion around raising an exception in tarfile
New submission from Evan Dandrea e...@ubuntu.com:
Using Python tip from Sunday, I noticed that tarfile does not elegantly handle
ENOENT by raising a single exception:
tarfile.TarFile.gzopen('fdsfd', 'r')
Traceback (most recent call last):
File /home/evan/hg/cpython/Lib/tarfile.py, line 1808, in gzopen
fileobj = gzip.GzipFile(name, mode + b, compresslevel, fileobj)
File /home/evan/hg/cpython/Lib/gzip.py, line 157, in __init__
fileobj = self.myfileobj = builtins.open(filename, mode or 'rb')
IOError: [Errno 2] No such file or directory: 'fdsfd'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File stdin, line 1, in module
File /home/evan/hg/cpython/Lib/tarfile.py, line 1812, in gzopen
fileobj.close()
AttributeError: 'NoneType' object has no attribute 'close'
I tried to fix this in a cross-platform way, by attempting to open the file
before processing it, and letting the with statement handle calling close:
diff -r 955547e57cff Lib/tarfile.py
--- a/Lib/tarfile.pySun Mar 13 19:32:21 2011 +0100
+++ b/Lib/tarfile.pyMon Mar 14 19:33:21 2011 -0400
@@ -1793,6 +1793,10 @@
if len(mode) 1 or mode not in rw:
raise ValueError(mode must be 'r' or 'w')
+if mode == r:
+# force an exception if the file does not exist.
+with open(name):
+pass
try:
import gzip
gzip.GzipFile
However, this produces infinite recursion:
...
File /home/evan/hg/cpython/Lib/tarfile.py, line 1738, in open
return func(name, r, fileobj, **kwargs)
File /home/evan/hg/cpython/Lib/tarfile.py, line 1798, in gzopen
with open(name):
File /home/evan/hg/cpython/Lib/tarfile.py, line 1738, in open
return func(name, r, fileobj, **kwargs)
RuntimeError: maximum recursion depth exceeded
Curiously, if I force the ValueError in that same function to be triggered (by
passing a three character string for the mode), that exception is raised fine.
I am therefore wondering if this is a bug in the exit processing.
Unfortunately, my attempts at producing a general test case have been
unsuccessful thusfar.
--
components: Interpreter Core
messages: 130932
nosy: ev
priority: normal
severity: normal
status: open
title: Infinite recursion around raising an exception in tarfile
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11513
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11548] Passing format= to unpack_archive fails
New submission from Evan Dandrea e...@ubuntu.com: Passing the format keyword parameter to shutil.unpack_archive triggers an exception: Traceback (most recent call last): File Lib/test/test_shutil.py, line 650, in test_unpack_archive unpack_archive(filename, tmpdir2, format=format) File /home/evan/hg/cpython/Lib/shutil.py, line 741, in unpack_archive func(filename, extract_dir, **dict(format_info[1])) TypeError: 'function' object is not iterable This is due to that function incorrectly using the _UNPACK_FORMATS dictionary, which is fixed with the attached patch and test case. -- components: Library (Lib) files: fix_unpack_with_format.patch keywords: patch messages: 130948 nosy: ev, tarek priority: normal severity: normal status: open title: Passing format= to unpack_archive fails type: crash Added file: http://bugs.python.org/file21196/fix_unpack_with_format.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11548 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6825] Minor documentation bug with os.path.split
Evan Driscoll eva...@gmail.com added the comment: Hah, I totally forgot about this thing. I'd suggest a change to the proposed patch. The patched version says: In nearly all cases, ``join(head, tail)`` returns a location equivalent to *path* (the only exception being when there were multiple slashes separating *head* from *tail*). Except now the parenthetical remark at the end of that sentence is a bit weird, because a//a != a/a is no longer an exception. I'd suggest a wording such as one of the following, depending on where you want the emphasis (on the meaning of the return value of a path or on the actual contents of the return value as a string): In all cases, ``join(head, tail)`` returns a location equivalent to *path*. In most cases, ``join(head, tail)`` equals *path*; the exceptions to this are when there were multiple slashes separating *head* from *tail* or when *os.altsep* separators are replaced by *os.sep*. The first suggestion could be followed by a remark (but the strings may be unequal) if you'd like. I'd also replace a location equivalent to with a path to the same location as or something like that; location doesn't appear anywhere else on that page, and it seems slightly out of place to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7735] python creates IPv6 DNS requests even when built with --disable-ipv6
New submission from Evan Teran evan.te...@gmail.com:
I have encountered an issue where python will do a request even when built
without IPv6. This becomes an issue because on some configurations this seems
to cause a 5 second delay on DNS lookups (that is a separate issue of course).
Basically here is what I am seeing:
#!/usr/bin/python
import urllib2
print urllib2.urlopen('http://python.org/').read(100)
results in the following:
0.00 10.102.0.79 - 8.8.8.8 DNS Standard query A python.org
0.23 10.102.0.79 - 8.8.8.8 DNS Standard query python.org
0.005369 8.8.8.8 - 10.102.0.79 DNS Standard query response A
82.94.164.162
5.004494 10.102.0.79 - 8.8.8.8 DNS Standard query A python.org
5.010540 8.8.8.8 - 10.102.0.79 DNS Standard query response A
82.94.164.162
5.010599 10.102.0.79 - 8.8.8.8 DNS Standard query python.org
5.015832 8.8.8.8 - 10.102.0.79 DNS Standard query response
2001:888:2000:d::a2
looking at socket.py in create_connection() (line 500 on my python 2.6.4
stdlib) the code is like this:
for res in getaddrinfo(host, port, 0, SOCK_STREAM):
af, socktype, proto, canonname, sa = res
sock = None
try:
sock = socket(af, socktype, proto)
if timeout is not _GLOBAL_DEFAULT_TIMEOUT:
sock.settimeout(timeout)
sock.connect(sa)
return sock
except error, msg:
if sock is not None:
sock.close()
The 3rd argument is the socket type, which is set to 0 which apparently means
unspecified. It seems to me that if python is built without IPv6 support it
should instead pass AF_INET since even if it does get an IPv6 response it can't
possibly use it.
--
components: None
messages: 98036
nosy: Evan.Teran
severity: normal
status: open
title: python creates IPv6 DNS requests even when built with --disable-ipv6
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7735
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3445] Ignore missing attributes in functools.update_wrapper
Evan Klitzke e...@eklitzke.org added the comment: New patch included, with a test case. I had wanted to check the classmethod __module__ thing directly, but that proved to be elusive, since the classmethod gets the __module__ attribute if the module is '__main__', and you can't delete that attribute. My test just tries to assign another attribute which doesn't exist. I just tried to copy the style of the rest of the module, lmk if there are any problems. -- Added file: http://bugs.python.org/file15903/fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3445] Ignore missing attributes in functools.update_wrapper
Evan Klitzke e...@eklitzke.org added the comment: I'm also interested in seeing this fixed. In the current behavior, the following code doesn't work: start code from functools import wraps def magic(func): @wraps(func) def even_more_magic(*args): return func(*args) return even_more_magic class Frob(object): @magic @classmethod def hello(cls): print '%r says hello' % (cls,) end code It fails because classmethods don't have a __module__ attribute, as commented upon elsewhere in this issue. To fix this, you'd either have to either pass in an `assigned` parameter to the `wraps` function, or swap the order of decorator application (i.e. `classmethod(magic(hello))`). This seems arbitrary and unnecessarily complex; skipping over a missing __module__ should be just fine. Mixing `functools.wraps` and `classmethod` is a relatively common use case that should be as simple as possible. I've attached a trivial patch which just ignores missing assigned attributes. -- keywords: +patch nosy: +eklitzke Added file: http://bugs.python.org/file15865/fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6825] Minor documentation bug with os.path.split
New submission from Evan Driscoll eva...@gmail.com: The documentation for os.path.split says, in part: In nearly all cases, join(head, tail) equals path (the only exception being when there were multiple slashes separating head from tail). But this is not quite true: that's not the *only* exception, at least without a somewhat liberal definition of equals. This can also happen if os.altsep is used in the path being split, in which case it will be replaced by os.sep: import ntpath path = a/b (head, tail) = ntpath.split(path) joined = ntpath.join(head, tail) joined == path False joined 'a\\b' [I only selected the versions that I actually verified, but I would guess it's present in more.] -- assignee: georg.brandl components: Documentation messages: 92180 nosy: evaned, georg.brandl severity: normal status: open title: Minor documentation bug with os.path.split versions: Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6785] IncompleteRead / BadStatus when parsing http://peakoil.mobi
New submission from Evan evanphe...@gmail.com: (I'm brand new to Python.org, apologies in advance if this has been recorded elsewhere or is not a bug) I've a simple script which fetching a url using httplib/urllib2 and then simply searches the HTML for a string. Works on every URL I've tried apart from the url http://peakoil.mobi where, for some reason, I get the following: Traceback (most recent call last): File C:\Python26\lib\threading.py, line 524, in __bootstrap_inner self.run() File test.py, line 59, in run html = response.read() File C:\Python26\lib\socket.py, line 327, in read data = self._sock.recv(rbufsize) File C:\Python26\lib\httplib.py, line 518, in read return self._read_chunked(amt) File C:\Python26\lib\httplib.py, line 564, in _read_chunked raise IncompleteRead(value) IncompleteRead: htmlhead title/title/head !-- Redirection Services ASH01WRED02 H1 -- frameset rows='100%, *' frameborder=no framespacing=0 border=0 frame src=http://peakoil.com/modules.php?name=AvantGo; name=mainwindow framebo rder=no framespacing=0 marginheight=0 marginwidth=0/frame /frameset noframes h2Your browser does not support frames. We recommend upgrading your browser. /h2brbr centerClick a href=http://peakoil.com/modules.php?name=AvantGo;here/a to enter the site./center /noframes/html Exception in thread 1: Traceback (most recent call last): File C:\Python26\lib\threading.py, line 524, in __bootstrap_inner self.run() File test.py, line 51, in run response = urllib2.urlopen(req) File C:\Python26\lib\urllib2.py, line 124, in urlopen return _opener.open(url, data, timeout) File C:\Python26\lib\urllib2.py, line 383, in open response = self._open(req, data) File C:\Python26\lib\urllib2.py, line 401, in _open '_open', req) File C:\Python26\lib\urllib2.py, line 361, in _call_chain result = func(*args) File C:\Python26\lib\urllib2.py, line 1130, in http_open return self.do_open(httplib.HTTPConnection, req) File C:\Python26\lib\urllib2.py, line 1103, in do_open r = h.getresponse() File C:\Python26\lib\httplib.py, line 951, in getresponse response.begin() File C:\Python26\lib\httplib.py, line 391, in begin version, status, reason = self._read_status() File C:\Python26\lib\httplib.py, line 355, in _read_status raise BadStatusLine(line) BadStatusLine -- messages: 91972 nosy: kmoon severity: normal status: open title: IncompleteRead / BadStatus when parsing http://peakoil.mobi type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6234] cgi.FieldStorage is broken when given POST data
New submission from Evan Fosmark m...@evanfosmark.com:
Right now, it seems impossible to use cgi.FieldStorage in 3.0 if you're
giving it environ['wsgi.input'] like so:
post_data = cgi.FieldStorage(
fp=environ[wsgi.input],
environ=environ,
keep_blank_values=True
)
It gives the following error:
File /usr/local/lib/python3.0/cgi.py, line 489, in __init__
self.read_urlencoded()
File /usr/local/lib/python3.0/cgi.py, line 589, in read_urlencoded
self.strict_parsing):
File /usr/local/lib/python3.0/urllib/parse.py, line 377, in
parse_qsl
pairs = [s2 for s1 in qs.split('') for s2 in s1.split(';')]
TypeError: Type str doesn't support the buffer API
--
components: Library (Lib)
messages: 89060
nosy: efosmark
severity: normal
status: open
title: cgi.FieldStorage is broken when given POST data
type: behavior
versions: Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6234
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar beh...@gmail.com added the comment:
Nevermind, my bad. With Brett's patch, the build does not work with
--enable-framework
It appears that configure.in makes no assignment to FRAMEWORKLINK or
AC_SUBST call with it, and so it is deposited in the final Makefile
verbatim as @FRAMEWORKLINK@
If --enable-framework is defined, then this compiler command in
Makefile.pre:461 gets executed:
$(CC) -o $(LDLIBRARY) -dynamiclib \
-isysroot ${UNIVERSALSDK} \
-all_load $(LIBRARY) -Wl,-single_module \
-install_name
$(DESTDIR)$(PYTHONFRAMEWORKINSTALLDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)
\
-compatibility_version $(VERSION) \
-current_version $(VERSION) \
$(FRAMEWORKLINK);
Which expands $(FRAMEWORKLINK) to @FRAMEWORKLINK@ because of this.
This makes no use of LIBS or any other environment variable that might
contain -lintl or -framework CoreFoundation, and the build will fail
with linker errors citing undefined intl and CFString symbols.
Attached is a patch that fixes this issue; it combines brett's lintl
patch with the fix for --enable-framework.
--
Added file: http://bugs.python.org/file14174/darwin_lintl_framework.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6154
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7 with macports libintl
Evan Behar beh...@gmail.com added the comment: Curiously, if I define --with-pydebug I get ld: Undefined symbols: ___eprintf If I don't define --with-pydebug but I do use --enable-universalsdk I get a whole different problem: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -c ./Modules/_localemodule.c -o Modules/_localemodule.o ./Modules/_localemodule.c:28:21: error: libintl.h: No such file or directory This leads to whole bunch of other crap. libintl.h is used in other forms of the build, so I'm not sure why this is cropping up. I also have no idea what ___eprintf is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
