[issue17246] inspect.getargvalues fails if arg name is not bound to a value
Maciej Górski added the comment: In my opinion formatargvalues function is quite useless in current day as ArgInfo provides all the information. I'm however willing to fix this. IMO we should just omit the args/varargs/kwargs that have been deleted, since the values do not exist in the current frame anymore. I can implement the idea propossed in 2013, but I feel this seems less intuative(?) and might be worse for backwards compatibility (if anyone ever actually expects some values from formatargvalues, but I haven't been able to find an example of that). Thank you in advance for any input. -- nosy: +macgors ___ Python tracker <https://bugs.python.org/issue17246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47129] Improve errors messages in f-string syntax errors
Maciej Górski added the comment: Thanks for helping me with my very first python contribution! @eric.smith @lys.nikolaou -- ___ Python tracker <https://bugs.python.org/issue47129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47138] Bump Sphinx or pin Jinja2 to fix docs build
Maciej Olko added the comment: I've update both PRs to contain the pin only. -- ___ Python tracker <https://bugs.python.org/issue47138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47138] Bump Sphinx or pin Jinja2 to fix docs build
Change by Maciej Olko : -- pull_requests: +30232 pull_request: https://github.com/python/cpython/pull/32109 ___ Python tracker <https://bugs.python.org/issue47138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47138] Bump Sphinx or pin Jinja2 to fix docs build
Change by Maciej Olko : -- keywords: +patch nosy: +Maciej Olko nosy_count: 2.0 -> 3.0 pull_requests: +30231 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32111 ___ Python tracker <https://bugs.python.org/issue47138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Maciej Olko added the comment: > This really should be handled in a new issue since the original fixes for all > affected releases are already in the field. Sorry, I got suggested too much with expected fix which is common for both of those issues. Shall I create a new issue? > Moreover, we should be a bit careful about bumping the required Sphinx > version for older releases as this has caused problems for downstream > distributors of Python in the past. Can't we just pin the Jinja2 version for > current releases? Didn't know about the problems for distributors. Definitely just pinning Jinja2 is enough. -- ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47129] Improve errors messages in f-string syntax errors
Maciej Górski added the comment: I agree as well. I will change it to the new version :) Thanks for your input in this. -- ___ Python tracker <https://bugs.python.org/issue47129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47129] Improve errors messages in f-string syntax errors
Maciej Górski added the comment: Understandable. In this case I can maybe propose something along the lines of "f-string: empty expression not allowed (Conversion specifier '!' can only follow non-empty expressions)", and so on for each of the specifiers. This way the original message is still present and we just add some more information. I'm open to any of your ideas. -- ___ Python tracker <https://bugs.python.org/issue47129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47129] Improve errors messages in f-string syntax errors
Change by Maciej Górski : -- keywords: +patch pull_requests: +30206 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32127 ___ Python tracker <https://bugs.python.org/issue47129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47129] Improve errors messages in f-string syntax errors
New submission from Maciej Górski :
When an empty expression is provided in curly brackets inside an f-string we
get Syntax Error: "f-string: empty expression not allowed".
This is correct, however error with the same message is raised in the following
cases: f"{!foo}", f"{!}", f"{:bar}", f"{=}", etc.
For example, should someone make an error and try to negate an expression with
'!' instead of 'not' (i.e. f"{!True}"), they would get a confusing error,
saying that the expression is empty, when it isn't.
I propose we raise an error with the message: "f-string: optional specifier
'%c' must follow a non-empty expression.
--
components: Parser
messages: 416069
nosy: lys.nikolaou, macgors, pablogsal
priority: normal
severity: normal
status: open
title: Improve errors messages in f-string syntax errors
___
Python tracker
<https://bugs.python.org/issue47129>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Change by Maciej Olko : -- pull_requests: +30194 pull_request: https://github.com/python/cpython/pull/32111 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Change by Maciej Olko : -- pull_requests: +30186 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/32109 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Maciej Olko added the comment: After the Jinja version 3.1.0 release today [1], documentation builds fail for all stable branches. Sphinx in versions pinned on those branches fails with ImportError. [2] Backporting 14a4fce457033412278ca9a056787db424310dc3 to 3.10 and 3.9 fixes the problem for them (build is successful with 4.2.0). For 3.8 and 3.7 pinning down Jinja is required (docs don't build smoothly with 4.2.0 for those branches). Could some core developer help with the backports? I am starting to work on PRs with pins for 3.8 and 3.7. [1] https://jinja.palletsprojects.com/en/3.1.x/changes/#version-3-1-0 [2] % sphinx-build --version Traceback (most recent call last): File "…/cpython/Doc/./venv/bin/sphinx-build", line 5, in from sphinx.cmd.build import main File "…/cpython/Doc/venv/lib/python3.9/site-packages/sphinx/cmd/build.py", line 25, in from sphinx.application import Sphinx File "…/cpython/Doc/venv/lib/python3.9/site-packages/sphinx/application.py", line 42, in from sphinx.registry import SphinxComponentRegistry File "…/cpython/Doc/venv/lib/python3.9/site-packages/sphinx/registry.py", line 24, in from sphinx.builders import Builder File "…/cpython/Doc/venv/lib/python3.9/site-packages/sphinx/builders/__init__.py", line 26, in from sphinx.util import import_object, logging, rst, progress_message, status_iterator File "…/cpython/Doc/venv/lib/python3.9/site-packages/sphinx/util/rst.py", line 22, in from jinja2 import environmentfilter ImportError: cannot import name 'environmentfilter' from 'jinja2' (…/cpython/Doc/venv/lib/python3.9/site-packages/jinja2/__init__.py) -- resolution: fixed -> status: closed -> open versions: -Python 3.11, Python 3.6 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Change by Maciej Olko : -- pull_requests: +27520 pull_request: https://github.com/python/cpython/pull/29256 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Maciej Olko added the comment: It occurs that the documentation builds without warnings on most recent Sphinx -- version 4.2.0. Probably we should bump the version in 3.11, 3.10 and 3.9 to 4.2.0. That would enable us to remove the pin on docutils. -- ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Maciej Olko added the comment: I'm sorry for the confusion. I might have make more checking on my side before proposing a fix. -- ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Maciej Olko added the comment: For what it's worth I have just successfully built documentation on 3.7 and 3.6 branches locally. It looks like Sphinx 2.3.1 used there doesn't use this part of docutils API that have changed recently. Sphinx 2.3.1 has requirement of "docutils>=0.12", just like 3.2.1. We can pin docutils version to current (0.18) "just in case" to prevent a breakage in the future or do nothing – maybe it won't break – maybe the docutils API used is narrow enough. -- ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Change by Maciej Olko : -- keywords: +patch pull_requests: +27493 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29230 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Maciej Olko added the comment: The pin can be removed after bumping Sphinx to at least 3.5.4, which introduced upper limit for docutils version. https://github.com/sphinx-doc/sphinx/commit/9263eea38379822e053c67ad1d17036d724c5e41 -- ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Change by Maciej Olko : -- versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
Change by Maciej Olko : -- versions: -Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45618] Documentation builds fail with Sphinx 3.2.1
New submission from Maciej Olko : Since the release of Docutils 0.18 today building Python documentation fails. In CPython repository we have Sphinx pinned to 3.2.1, which has too loose requirement for Docutils version in install_requires – docutils>=0.12. Example of failing build: https://github.com/python/python-docs-pl/runs/4009459257. My suggestion is to pin down docutils in docs requirements. -- assignee: docs@python components: Documentation messages: 405060 nosy: Maciej Olko, docs@python priority: normal severity: normal status: open title: Documentation builds fail with Sphinx 3.2.1 type: crash versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45593] SpooledTemporaryFile.truncate returns None
Change by Maciej Urbański : -- keywords: +patch pull_requests: +27466 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29197 ___ Python tracker <https://bugs.python.org/issue45593> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45593] SpooledTemporaryFile.truncate returns None
New submission from Maciej Urbański : Related: https://bugs.python.org/issue40287 https://bugs.python.org/msg319145 -- components: Library (Lib) messages: 404914 nosy: rooter priority: normal severity: normal status: open title: SpooledTemporaryFile.truncate returns None type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45593> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44541] collections.abc.Sequence index implementation
Maciej Kopeć added the comment: Sorry for the hastily posted issue, when stop is not given this should work properly, and since stop is exclusive in python, this shall be expected behaviour. -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue44541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44541] collections.abc.Sequence index implementation
New submission from Maciej Kopeć : Hello, https://github.com/python/cpython/blob/3.9/Lib/_collections_abc.py#L1012 Shouldn't the loop condition be i <= 0 not i < 0? The implementation now is causing not to search in 1-element sequences, since it raises ValueError. Please let me know if this is the expected behaviour. Kind regards, Maciej Kopeć -- messages: 396783 nosy: LordVilgefortz priority: normal severity: normal status: open title: collections.abc.Sequence index implementation type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44495] wrong FNAME in tarfile if tgz extension is used
New submission from Maciej Misiak :
This code is incomplete:
def _init_write_gz(self):
...
if self.name.endswith(".gz"):
self.name = self.name[:-3]
# RFC1952 says we must use ISO-8859-1 for the FNAME field.
self.__write(self.name.encode("iso-8859-1", "replace") + NUL)
If it is used in following way '.gz' is stripped properly and
FNAME='somefile.tar':
tarfile.open('somefile.tar.gz', 'w:gz')
but with
tarfile.open('somefile.tgz', 'w:gz')
FNAME is incorrectly prepared as somefile.tgz
--
components: Library (Lib)
messages: 396382
nosy: maciej.mm.misiak
priority: normal
severity: normal
status: open
title: wrong FNAME in tarfile if tgz extension is used
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue44495>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42481] Add to pathlib function to check permission similar to os.access
Change by Maciej Olko : -- nosy: +Maciej Olko ___ Python tracker <https://bugs.python.org/issue42481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41510] Mentions of pdb.set_trace() in library/functions and library/sys incorrectly states that set_trace expects no arguments
Change by Maciej Olko : -- title: Mentions of pdb.set_trace() in library/functions and library/sys uncorrectly states that set_trace expects no arguments -> Mentions of pdb.set_trace() in library/functions and library/sys incorrectly states that set_trace expects no arguments ___ Python tracker <https://bugs.python.org/issue41510> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41510] Mentions of pdb.set_trace() in library/functions and library/sys uncorrectly states that set_trace expects no arguments
New submission from Maciej Olko : An argument was added to pdb.set_trace() in Python 3.7 and those fragments of documentation should have been updated: library/functions.rst:120 > By default, sys.breakpointhook() calls pdb.set_trace() expecting no arguments. library/sys.rst > For example, the default binding (e.g. pdb.set_trace()) expects no arguments, > but you might bind it to a function that expects additional arguments > (positional and/or keyword). -- assignee: docs@python components: Documentation messages: 375064 nosy: Maciej Olko, docs@python priority: normal severity: normal status: open title: Mentions of pdb.set_trace() in library/functions and library/sys uncorrectly states that set_trace expects no arguments versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41510> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration
Change by Maciej Olko : -- nosy: +Maciej Olko ___ Python tracker <https://bugs.python.org/issue40204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37292] _xxsubinterpreters: Can't unpickle objects defined in __main__
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue37292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15751] Support subinterpreters in the GIL state API
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue15751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue10915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36877] [meta] Move fields from _PyRuntimeState to PyInterpreterState.
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue36877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36876] Global C variables are a problem.
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue36876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39511] [subinterpreters] Per-interpreter singletons (None, True, False, etc.)
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue39511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38880] Subinterpreters: List interpreters associated with a channel end
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue38880> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36225] Lingering subinterpreters should be implicitly cleared on shutdown
Change by Maciej Szulik : -- nosy: +maciej.szulik ___ Python tracker <https://bugs.python.org/issue36225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39430] tarfile.open(mode="r") race condition when importing lzma
Maciej Gol added the comment: This is a HUGE eye opener! Didn't know of that 'import' vs 'from x import y' difference. Thanks a lot! Is it documented somewhere ? pt., 24 sty 2020, 15:08 użytkownik Serhiy Storchaka napisał: > > Serhiy Storchaka added the comment: > > It is intended to support circular imports. Let foo.py contains "import > bar" and bar.py contains "import foo". When you execute "import foo", the > import machinery first creates an empty module foo, adds it to sys.modules, > reads foo.py and executes it in the namespace of module foo. When the > interpreter encounters "import bar" in foo.py, the import machinery creates > an empty module bar, adds it to sys.modules, reads bar.py and executes it > in the namespace of module bar. When the interpreter encounters "import > foo" in bar.py, the import machinery takes the module foo from sys.modules. > So you break an infinite cycle and can import modules with cyclic > dependencies. > > You can argue that cyclic import does not look as a good practice, but > actually it is pretty common case when you import a submodule in a package. > If foo/__init__.py contains "from .bar import Bar", the foo module must be > imported before you import foo.bar, but is not completely initialized at > that time yet. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue39430> > ___ > -- ___ Python tracker <https://bugs.python.org/issue39430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39430] tarfile.open(mode="r") race condition when importing lzma
Maciej Gol added the comment: By the way, thanks a lot for the fix <3 -- ___ Python tracker <https://bugs.python.org/issue39430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39430] tarfile.open(mode="r") race condition when importing lzma
Maciej Gol added the comment: > PR 18161 fixes race condition by using "from ... import ..." > which waits until the module be completely initialized if the specified > names are not set. Correct me if I'm wrong, but I think the behavior of 'import lzma' in this case (vulnerable to race conditions) is not as intended? Shouldn't we also fix the 'import' statement itself? In general, I understand that due to how dynamic Python is, it might not be possible to load every single name at import time using `import` and using `from x import y` brings more determinism (because we have a safeguard now). But, looking at the stacktrace from ipython the problem lies in a sequence of import statements, not dynamic python coding. Shouldn't the importing mechanism be more deterministic in such case? For sure, it should not return an empty module (this is the case when race condition occurs). I think a race condition caused by simply using `import` statements (not `from x import y`) is a big caveat in the statement itself and how python imports work. Haven't checked if the cause is isolated to how tarfile works, or works in general, though :-( -- ___ Python tracker <https://bugs.python.org/issue39430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39430] tarfile.open(mode="r") race condition when importing lzma
Maciej Gol added the comment: Uploading fixed file (the former had a typo) -- Added file: https://bugs.python.org/file48861/test.py ___ Python tracker <https://bugs.python.org/issue39430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39430] tarfile.open(mode="r") race condition when importing lzma
Change by Maciej Gol : Removed file: https://bugs.python.org/file48860/test.py ___ Python tracker <https://bugs.python.org/issue39430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39430] tarfile.open(mode="r") race condition when importing lzma
New submission from Maciej Gol :
Hey guys,
We have a component that archives and unarchives multiple files in separate
threads that started to
misbehave recently.
We have noticed a bunch of `AttributeError: module 'lzma' has no attribute
'LZMAFile'` errors, which are
unexpected because our python is not compiled with LZMA support.
What is unfortunate, is that given the traceback:
Traceback (most recent call last):
File "test.py", line 18, in
list(pool.map(test_lzma, range(100)))
File "/opt/lang/python37/lib/python3.7/concurrent/futures/_base.py", line
598, in result_iterator
yield fs.pop().result()
File "/opt/lang/python37/lib/python3.7/concurrent/futures/_base.py", line
428, in result
return self.__get_result()
File "/opt/lang/python37/lib/python3.7/concurrent/futures/_base.py", line
384, in __get_result
raise self._exception
File "/opt/lang/python37/lib/python3.7/concurrent/futures/thread.py",
line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "test.py", line 14, in test_lzma
tarfile.open(fileobj=buf, mode="r")
File "/opt/lang/python37/lib/python3.7/tarfile.py", line 1573, in open
return func(name, "r", fileobj, **kwargs)
File "/opt/lang/python37/lib/python3.7/tarfile.py", line 1699, in xzopen
fileobj = lzma.LZMAFile(fileobj or name, mode, preset=preset)
AttributeError: module 'lzma' has no attribute 'LZMAFile'
the last line of the traceback is right AFTER this block (tarfile.py:1694):
try:
import lzma
except ImportError:
raise CompressionError("lzma module is not available")
Importing lzma in ipython fails properly:
In [2]: import lzma
---
ModuleNotFoundError Traceback (most recent call last)
in
> 1 import lzma
/opt/lang/python37/lib/python3.7/lzma.py in
25 import io
26 import os
---> 27 from _lzma import *
28 from _lzma import _encode_filter_properties,
_decode_filter_properties
29 import _compression
ModuleNotFoundError: No module named '_lzma'
When trying to debug the problem, we have noticed it's not deterministic. In
order to reproduce it,
we have created a test python that repeatedly writes an archive to BytesIO and
then reads from it.
Using it with 5 threads and 100 calls, gives very good chances of reproducing
the issue. For us it
was almost every time.
Race condition occurs both on Python 3.7.3 and 3.7.6.
Test script used to reproduce it attached.
I know that the test script writes uncompressed archives and during opening
tries to guess the compression.
But I guess this is a legitimate scenario and should not matter in this case.
--
files: test.py
messages: 360551
nosy: Maciej Gol
priority: normal
severity: normal
status: open
title: tarfile.open(mode="r") race condition when importing lzma
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48860/test.py
___
Python tracker
<https://bugs.python.org/issue39430>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36076] ssl.get_server_certificate should use SNI
New submission from Maciej Grela :
The ssl.get_server_certificate function doesn't send SNI information causing an
wrong certificate to be sent back by the server (or connection close in some
cases). This can be seen when trying to use get_server_certificate against a
site behind cloudflare. An example is provided below:
$ python3 -V
Python 3.7.2
$ python3 -c "import ssl;
print(ssl.get_server_certificate(('www.mx.com',443)))" | openssl x509 -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
89:2a:bc:df:8a:f3:d6:f6:ae:c5:18:5a:78:ec:39:6e
Signature Algorithm: ecdsa-with-SHA256
Issuer: C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited,
CN=COMODO ECC Domain Validation Secure Server CA 2
Validity
Not Before: Dec 19 00:00:00 2018 GMT
Not After : Jun 27 23:59:59 2019 GMT
Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain,
CN=ssl803013.cloudflaressl.com
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:ff:c1:c3:f1:c0:8a:08:84:ad:e4:25:f6:c3:03:
1f:26:0a:b4:85:e0:65:0e:f5:8b:13:1e:21:b2:54:
94:8c:f3:ce:98:eb:cf:ff:ff:1d:3a:03:22:b1:7c:
5f:13:e5:09:1f:77:b0:e8:ac:bf:e6:6c:ea:cb:57:
df:e1:c8:14:da
ASN1 OID: prime256v1
NIST CURVE: P-256
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:40:09:61:67:F0:BC:83:71:4F:DE:12:08:2C:6F:D4:D4:2B:76:3D:96
X509v3 Subject Key Identifier:
4B:F4:77:CD:FB:04:DC:0D:B2:A5:99:B8:6F:17:CC:80:DF:AE:59:DF
X509v3 Key Usage: critical
Digital Signature
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.6449.1.2.2.7
CPS: https://secure.comodo.com/CPS
Policy: 2.23.140.1.2.1
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.comodoca4.com/COMODOECCDomainValidationSecureServerCA2.crl
Authority Information Access:
CA Issuers -
URI:http://crt.comodoca4.com/COMODOECCDomainValidationSecureServerCA2.crt
OCSP - URI:http://ocsp.comodoca4.com
X509v3 Subject Alternative Name:
DNS:ssl803013.cloudflaressl.com, DNS:*.hscoscdn00.net,
DNS:hscoscdn00.net
1.3.6.1.4.1.11129.2.4.2:
..u...q...#...{G8W.
.Rd6...g..P..F0D. ...0J|..2I..}%.Q.P...Zg..
..ej...Y^.Ti^..].w.t~..1.3..!..%OBp...^B
..75y..{.V...g..Pv.H0F.!..1#I..\.#2...$...X
..!...].{o..ud..6OV
Q.x...J_([!.
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:0c:8c:b6:ea:68:e4:d6:d6:18:95:50:8f:77:41:
63:51:81:59:3b:1b:e6:38:47:88:f3:47:d5:b0:0b:03:c5:ba:
02:21:00:d2:19:3f:71:e2:64:36:79:d1:4c:c9:98:fd:74:d7:
32:53:f6:b4:de:09:65:d8:a0:60:85:eb:f1:1f:75:35:75
-BEGIN CERTIFICATE-
MIIFBzCCBK2gAwIBAgIRAIkqvN+K89b2rsUYWnjsOW4wCgYIKoZIzj0EAwIwgZIx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTgwNgYDVQQD
Ey9DT01PRE8gRUNDIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIgQ0Eg
MjAeFw0xODEyMTkwMDAwMDBaFw0xOTA2MjcyMzU5NTlaMGwxITAfBgNVBAsTGERv
bWFpbiBDb250cm9sIFZhbGlkYXRlZDEhMB8GA1UECxMYUG9zaXRpdmVTU0wgTXVs
dGktRG9tYWluMSQwIgYDVQQDExtzc2w4MDMwMTMuY2xvdWRmbGFyZXNzbC5jb20w
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAT/wcPxwIoIhK3kJfbDAx8mCrSF4GUO
9YsTHiGyVJSM886Y68///x06AyKxfF8T5Qkfd7DorL/mbOrLV9/hyBTao4IDBzCC
AwMwHwYDVR0jBBgwFoAUQAlhZ/C8g3FP3hIILG/U1Ct2PZYwHQYDVR0OBBYEFEv0
d837BNwNsqWZuG8XzIDfrlnfMA4GA1UdDwEB/wQEAwIHgDAMBgNVHRMBAf8EAjAA
MB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBPBgNVHSAESDBGMDoGCysG
AQQBsjEBAgIHMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5j
b20vQ1BTMAgGBmeBDAECATBWBgNVHR8ETzBNMEugSaBHhkVodHRwOi8vY3JsLmNv
bW9kb2NhNC5jb20vQ09NT0RPRUNDRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZl
ckNBMi5jcmwwgYgGCCsGAQUFBwEBBHwwejBRBggrBgEFBQcwAoZFaHR0cDovL2Ny
dC5jb21vZG9jYTQuY29tL0NPTU9ET0VDQ0RvbWFpblZhbGlkYXRpb25TZWN1cmVT
ZXJ2ZXJDQTIuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC5jb21vZG9jYTQu
Y29tMEgGA1UdEQRBMD+CG3NzbDgwMzAxMy5jbG91ZGZsYXJlc3NsLmNvbYIQKi5o
c2Nvc2NkbjAwLm5ldIIOaHNjb3NjZG4wMC5uZXQwggEEBgorBgEEAdZ5AgQCBIH1
BIHyAPAAdQC72d+8H4pxtZOUI5eqkntHOFeVCqtS6BqQlmQ2jh7RhQAAAWfEHVAd
AAAEAwBGMEQCIB73izCk6hPeSnyYAjJJD959JRpRHFD2EwNa3Bzo3mcUAiASBZfK
xLxlg5H302r4gOVZXrFUaV6Ylpy57rzdrvb4XQB3AHR+2oMxrTMQkSGcziVPQnDC
v/1eQiAIxjc1eeYQe8xWAAABZ8QdUHYAAAQDAEgwRgIhAMMxI0kXulz+sMgA7iMy
LrjbJLcZ6ViL4e71CpHc99etAiEAzKFdBXtvvJR1ZAj4Nk9WClGbeB
[issue26528] NameError for built in function open when re-raising stored exception from yielded function
Maciej Urbański <roo...@kyberian.net> added the comment: Reproduced in both v3.6.4 and v3.7.0a3 -- nosy: +rooter versions: +Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26528> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29860] smtplib.py doesn't capitalize EHLO.
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29891] urllib.request.Request accepts but doesn't check bytes headers
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29458] random.seed version=1 behavior
New submission from Maciej Obarski: random.seed version=1 wont generate the same randint sequences in python2 and python3 Python 2.7: >>> seed(1); randint(0,100) 13 Python 3.6: >>> seed(1,version=1); randint(0,100) 17 The documentation states that versio=1 is "provided for reproducing random sequences from older versions of Python" and "If a new seeding method is added, then a backward compatible seeder will be offered." -- components: Extension Modules messages: 287089 nosy: Maciej Obarski priority: normal severity: normal status: open title: random.seed version=1 behavior type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29236] 'an ASCII string of one or more PEM-encoded certificates' needs to be unicode
New submission from Maciej Piechorka: In documentation it is specified that cadata parameter in load_verify_locations is 'an ASCII string of one or more PEM-encoded certificates'. However the code is actually determining it based on PyUnicode_Check function so the 'ASCII string' actually needs to be unicode object. In Python 3 it seems to be fixed by checking by PyObject_GetBuffer. -- assignee: docs@python components: Documentation, SSL messages: 285176 nosy: docs@python, uzytkownik priority: normal severity: normal status: open title: 'an ASCII string of one or more PEM-encoded certificates' needs to be unicode versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322
Maciej Szulik added the comment: I've chatted a bit with David about this feature. Here are some thoughts: - check what SMTP standard says about some validation rules - add validate method, probably into email package -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28879] smtplib send_message should add Date header if it is missing, per RFC5322
Maciej Szulik added the comment: I tend to agree with Eric Lafontaine, looking at the quote Henning von Bargen posted the originator address field is also required, but yet we don't explicitly check its presence in the code, but rely on the SMTP server to error out. -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Maciej Szulik added the comment: Thank you David, of course I'll remind you :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28240] Enhance the timeit module: display average +- std dev instead of minimum
Changes by Maciej Fijalkowski <fij...@gmail.com>: -- nosy: -fijall ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15013] smtplib: add low-level APIs to doc?
Maciej Urbański added the comment: I guess documenting `data` method may still be needed after all. For now I followed the suggestions from comments to best of my ability. Please see attached patch. -- keywords: +patch nosy: +rooter Added file: http://bugs.python.org/file45086/issue15013.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15013> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: any json data validation library recommendation? (Reposting on Python-Lists Prohitibited)
On Thursday, October 6, 2016 at 7:20:58 AM UTC+1, Lawrence D’Oliveiro wrote: > What action are users supposed to take on such errors, other than include > them in a bug report? By users I mean API users (developers). Most common action would be to add a missing field, correct typo or change value type. Failing validation is usually user error, and rarely leads to reporting a bug. -- https://mail.python.org/mailman/listinfo/python-list
any json data validation library recommendation?
Hi I'm writing json data validation tool in a language other than python, but knowing that there is plenty of good tools for it, I am looking for inspiration here. I am aware of json schema standard, but on its own its rather verbose and I'd rather have models defined in code (directly or via some DSL). Can anyone recommend library that provides good API for declaring data schemas, so I could see how it could be done? (Doing it is not a problem. Doing it in a way that's convenient for users, readable and generates good error messages is something I care about). Thanks -- Maciej Dziardziel fied...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
[issue28320] Hostname validation is False by default in imaplib
New submission from Maciej Szulik: According to David [1] hostname validation should be True by default for the imaplib, my tests clearly show something different. Additionally he states you Christian were doing so, that's why I'm opening this not to forget about the problem and discuss eventually what should happen. [1] http://bugs.python.org/review/25591/diff/16398/Lib/test/test_imaplib.py#newcode451 -- assignee: christian.heimes components: email messages: 22 nosy: barry, christian.heimes, maciej.szulik, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Hostname validation is False by default in imaplib type: security versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Maciej Szulik added the comment: David I apologize for 2 emails from Reitveld, for some reason it didn't show me all in one view :/ (I need to master Reitveld better). I've just updated patch according to your comments. -- Added file: http://bugs.python.org/file44896/new_imap_tests_v5.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Changes by Maciej Szulik <solt...@gmail.com>: -- hgrepos: -322 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27908] del _limbo[self] KeyError
Maciej Urbański added the comment: To address @Dima.Tisnek concern I have changed exception message in case thread start process is merely in progress. I kept `self._started` check under a lock so we can avoid more extreme race condition of one thread checking `self._started` right before another sets it and exits the limbo. As for testing `self._started` under a lock, but setting it without one. I'm avoiding it only because of performance reasons. The read is super cheap, while notification of `.set()` is more complex, so if aesthetics are only reasons for doing it there then I would advise against holding that lock while executing it. Of course I could also do a `self in _active` check under a lock, but that is slightly more costly, than `self._started` check and not any more useful. I may be prematurely optimizing things, but people tend to like they threads to startup ASAP. -- Added file: http://bugs.python.org/file44677/issue27908_2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27908] del _limbo[self] KeyError
Maciej Urbański added the comment: @Dima.Tisnek, only reason for having both of these conditions together is so I won't have to repeat the same error message in the code at little price of the performance in this edge case (trying to start the same thread multiple times). Unless I'm missing something there should be no way how it would make this lock required for setting `self._started`. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27908] del _limbo[self] KeyError
Maciej Urbański added the comment: Successfully reproduced on 2.7.12 and 3.5.2 . Currently there seems to be no protection against starting the same thread twice at the same time. What was checked was only if start operation already finished once. Attached patch makes it so limbo, our starting threads' waiting room, is checked first. -- keywords: +patch nosy: +rooter versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file44643/issue27908.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27908> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Maciej Szulik added the comment: Thanks, I'll try to update the patch in the following days. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c
Maciej Fijalkowski added the comment: On windows the profiler runs in a separate thread and pauses/restarts other threads (hence the requirements are slightly different). HEAD_LOCK etc. are def not async-signal safe, but it's not an issue on linux -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27483] Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c
New submission from Maciej Fijalkowski: Hi The use case here is for C-based statistical profilers. When running vmprof on linux/os x, you can get the current thread state from PyThreadState_GetUnchecked or a similar solution. However, on windows you need to walk all the interpreter state, for which there is an API. However that API is only ever used with locks (HEAD_LOCK/HEAD_UNLOCK), which are not exposed, which turns API mostly useless. -- messages: 270188 nosy: fijall, haypo priority: normal severity: normal status: open title: Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c type: enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27321] Email parser creates a message object that can't be flattened
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Maciej Szulik added the comment: David I'm uploading the patch with all the review comments addressed. The changes from just the review can be seen here: https://bitbucket.org/soltysh/cpython/commits/91708e0c6e7c5230bd69b1135b82ef47b6dc4d43?at=default (please ignore the changes to test_logincapa_withclient_certfile, these are not part of the final patch). -- Added file: http://bugs.python.org/file43023/new_imap_tests_v4.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27132] New assert method that checks an error message for a list of strings
Maciej Szulik added the comment: You could, but then you end up writing nasty regex-es to do that. The idea here is to create a native function that will verify a number of words in whatever order. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27132] New assert method that checks an error message for a list of strings
New submission from Maciej Szulik: To quote David from http://bugs.python.org/review/25591/diff/16398/Lib/test/test_imaplib.py: "I've been thinking I'd like a new assert method that checks an error message for a list of strings in any order, but I haven't opened an issue for it :)" -- components: Tests messages: 266454 nosy: maciej.szulik, r.david.murray priority: normal severity: normal status: open title: New assert method that checks an error message for a list of strings type: enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5996] abstract class instantiable when subclassing dict
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27010] email library could "recover" from bad mime boundary like (some?) email clients do
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26543] imaplib noop Debug
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17580] ctypes: ARM hardfloat argument corruption calling functions with many float arguments
Maciej Fijalkowski added the comment: The easiest way to check is to run the tests attached -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17580] ctypes: ARM hardfloat argument corruption calling functions with many float arguments
Maciej Fijalkowski added the comment: Then maybe it's fixed, I have no idea -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17580] ctypes: ARM hardfloat argument corruption calling functions with many float arguments
Maciej Fijalkowski added the comment: Apparently you can't have an opinion from ctypes experts. Can you please commit the upstream fix that has been committed 3 years ago or just stop vendoring random, old, broken version of ctypes if you can't maintain it enough to pull fixes from upstream? -- nosy: +fijall ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17580> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26461] PyInterpreterState_Head(), PyThreadState_Next() etc can't be sanely used
New submission from Maciej Fijalkowski: All the internal uses of this API guard everything with HEAD_LOCK/HEAD_UNLOCK that's not exposed. It's not safe to traverse the whole API without holding those locks and those locks are static and module local -- messages: 261030 nosy: fijall priority: normal severity: normal status: open title: PyInterpreterState_Head(), PyThreadState_Next() etc can't be sanely used ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26176] EmailMessage example doesn't work
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26176> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26459] Windows build instructions are very inaccurate
New submission from Maciej Fijalkowski: I've tried following the dev guide (still not successful) to compile a debug version of cpython 2.7 and a couple issues that I run into: * The VS2010 vs VS2008 confustion - the docs say "most versions before 3.3 use VS2008" - what does it mean by "most"? The current cpython trunk seems to work only on 2010 (with a variety of fun errors). * VS2010 is hard to download, as is 2008 - direct links would help * nowhere it's mentioned that you need to run stuff from VS console * the readme and the devguide disagree on a few points - readme seems to be better, but also not ideal * the docs don't say how to get svn.exe (that is install tortoiseHG, but then select extra tools from somewhere) * the build seems to require perl, despite claiming it's not Other things are misguiding too, but fixing all of the above would be a massive step forward -- assignee: docs@python components: Documentation messages: 261009 nosy: docs@python, fijall priority: normal severity: normal status: open title: Windows build instructions are very inaccurate versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26399] CSV Injection Vulnerability
Maciej Szulik added the comment: Closing in favor of http://psf.upfronthosting.co.za/roundup/meta/issue580 -- nosy: +maciej.szulik resolution: -> wont fix status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26375] Python 2.7.10 and 3.4.4 hang on imaplib.IMAP4_SSL()
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26375> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26314] interned strings are stored in a dict, a set would use less memory
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26252] Add an example to importlib docs on setting up an importer
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26110] Speedup method calls 1.2x
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Maciej Szulik added the comment: David I think I've re-implemented, using the new style, all the methods from ThreadedNetworkedTests and ThreadedNetworkedTestsSSL, the new classes are NewIMAPTests and NewIMAPSSLTests accordingly. -- stage: -> patch review Added file: http://bugs.python.org/file41675/new_imap_tests_v3.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Maciej Szulik added the comment: David can you please take a look once more, I've applied all the changes you've asked for. I'm currently working on adding the existing tests rewritten to use the new framework so it's easy to compare. It's still in progress but the general idea should maintain. -- keywords: +patch Added file: http://bugs.python.org/file41610/new_imap_tests_v2.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23942] Explain naming of the patch files in the bug tracker
Maciej Szulik added the comment: Ezio, I've meant we should provide some guidelines with information the system will pick whatever they choose based on submission date. More informational than as a requirement. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11245] Implementation of IMAP IDLE in imaplib?
Changes by Maciej Szulik <solt...@gmail.com>: -- nosy: +maciej.szulik ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21815] imaplib truncates some untagged responses
Maciej Szulik added the comment: I've checked the patch: it looks good, applies cleanly to latest default and passes all the tests. I'm ok with merging this as is. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21815] imaplib truncates some untagged responses
Maciej Szulik added the comment: Lita can you please apply the changes from latest review (from SilentGhost). Especially the one regarding newline, which currently fails to apply this patch on default. If all those will be cleaned I'll recommend this patch for David for inclusion. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21815] imaplib truncates some untagged responses
Maciej Szulik added the comment: Lita if you still have problems or want to ask questions reach out to me on IRC, I'm soltysh on freenode. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22137] Test imaplib API on all methods specified in RFC 3501
Maciej Szulik added the comment: Per the discussion we've had with David on IRC here's what happening. The last patch I've submitted is meant to clean up the tests by: 1. having single _setup method 2. the _setup method should addClenup to clean the environment 3. have stubs with implemented mostly used methods, all others should be implemented ad-hoc in test methods 4. use unittest.main() for running tests The current idea is to create tests along the current one, to show how the new improve the readability. For this work I'm reopening previously submitted issue http://bugs.python.org/issue25591 The current issue will be on dependent on it and no further work should be done unless we have the tests cleared. -- keywords: -patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] refactor imaplib tests
Maciej Szulik added the comment: I'm reopening this issue per discussion with David we've had on IRC. The scope of this issue to refactor current tests to make them more readable and clean. The most important work is: 1. having single _setup method 2. the _setup method should addClenup to clean the environment 3. have stubs with implemented mostly used methods, all others should be implemented ad-hoc in test methods 4. use unittest.main() for running tests We'll do it along current tests to show the improvement. Once we reach satisfactory level we will remove the old tests. This issue is to show this progress. -- assignee: -> maciej.szulik keywords: -patch resolution: duplicate -> status: closed -> open superseder: Test imaplib API on all methods specified in RFC 3501 -> title: improve test coverage for the imaplib -> refactor imaplib tests ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21815] imaplib truncates some untagged responses
Maciej Szulik added the comment: Perfect, thanks! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13940] imaplib: Mailbox names are not quoted
Maciej Szulik added the comment: siemer thx for the comments in the review. I'll try to address them by the end of this week. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] improve test coverage for the imaplib
Maciej Szulik added the comment: I've just found the original issue where I wanted to submit the new tests. I'm closing this in favor of http://bugs.python.org/issue22137. -- resolution: -> duplicate status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22137] Test imaplib API on all methods specified in RFC 3501
Maciej Szulik added the comment: Resubmitting from http://bugs.python.org/issue25591, which I filled in unnecessarily. Here are the rewritten test case I've developed during PyCon sprints along with David. Once we'll have the entire test suite in place it'll be safer to introduce any changes I'd like to cover, including updating the implementation to newest RFC 3501 version. -- hgrepos: +325 Added file: http://bugs.python.org/file41264/new_imap_tests.diff ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25591] improve test coverage for the imaplib
Changes by Maciej Szulik <solt...@gmail.com>: -- superseder: -> Test imaplib API on all methods specified in RFC 3501 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
