[issue46865] *() Invalid Syntax: iterable unpacking of empty tuple
Robert Spralja added the comment: I understand that it's invalid synatax, but not why. On Sat, 26 Feb 2022 at 10:07, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > It is an invalid syntax. Write foo(*((stri,) if stri else ())). > > -- > nosy: +serhiy.storchaka > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <https://bugs.python.org/issue46865> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46865] *() Invalid Syntax: iterable unpacking of empty tuple
New submission from Robert Spralja : ` >>> def foo(num=1): ... return num ... >>> foo(*(bool,) is bool else *()) File "", line 1 foo(*(bool,) is bool else *()) ^ SyntaxError: invalid syntax >>> foo(*(bool,) if bool else *()) File "", line 1 foo(*(bool,) if bool else *()) ^ SyntaxError: invalid syntax >>> def foo(num=1): ... return num ... >>> stri = '' >>> foo(*(stri,) if stri else *()) File "", line 1 foo(*(stri,) if stri else *()) ^ SyntaxError: invalid syntax >>> foo(*((stri,) if stri else ())) 1 >>> ` Iterable unpacking of empty tuple seems to not work in one example but does in another. -- messages: 414085 nosy: spralja priority: normal severity: normal status: open title: *() Invalid Syntax: iterable unpacking of empty tuple versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46865> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46745] Typo in new PositionsIterator
New submission from Robert-André Mauchin : In Objects/codeobject.c, poisitions_iterator should read positions_iterator -- components: C API messages: 413209 nosy: eclipseo priority: normal pull_requests: 29479 severity: normal status: open title: Typo in new PositionsIterator versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46548] macOS installers cannot be signed on Monterey
Robert Xiao added the comment: I noticed that the official installer seems to be built using an entirely different process, as it produces a single-file .pkg in xar format with an embedded Distribution file, rather than an .mpkg directory. Is there documentation on how these packages are generated? It seems like the scripts for that aren't in the Python source tree? -- ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46548] macOS installers cannot be signed on Monterey
Change by Robert Xiao : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46548] macOS installers cannot be signed on Monterey
New submission from Robert Xiao : I am building unofficial macOS packages for personal use. My main build machine is running macOS Monterey 12.1 and Xcode 13.2.1. I recently attempted to build Python 3.8.12 as a package using build-installer.py. This worked fine after a bit of dependency wrangling (mostly, downloading the right Tcl/Tk source files manually) and produced an installer package and DMG as expected. However, it is apparently impossible to actually sign the package. I receive the following error: % productsign --sign 'Apple Development: ...' /private/tmp/_py/installer/Python.mpkg /private/tmp/_py/installer/Python-signed.mpkg productsign: preparing "Python.mpkg" for signing ... productsign: error: component package "PythonFramework-3.8.pkg" uses legacy installer features that make it impossible to sign. Unfortunately, searching for "legacy installer features" yields zero useful hits, which is a bit of a surprise. I assume that this error message was added to a recent macOS/Xcode build, but I am unable to downgrade easily. I believe this is probably being triggered because the way the packages are put together differs from the way pkgbuild/productbuild would do it. The longer term solution would probably be to switch to those tools instead of assembling the packages by hand. Issue reproduces with Python 3.11a4 sources as well, so I'm tagging it as applying for 3.8~3.11. -- components: Build messages: 411857 nosy: nneonneo priority: normal severity: normal status: open title: macOS installers cannot be signed on Monterey versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46485] ~ PEG operator in the grammar
Robert Einhorn added the comment: Thanks -- resolution: not a bug -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue46485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46485] ~ PEG operator in the grammar
New submission from Robert Einhorn :
This is probably not an error and I may misinterpret the PEP 617, but I don't
know what the ~ PEG operator means in the next rule if there is no alternative:
assignment_expression:
| NAME ':=' ~ expression
And similarly with this rule if there is no more alternative:
assignment:
| NAME ':' expression ['=' annotated_rhs ]
| ('(' single_target ')'
| single_subscript_attribute_target) ':' expression ['=' annotated_rhs
]
| (star_targets '=' )+ (yield_expr | star_expressions) !'=' [TYPE_COMMENT]
| single_target augassign ~ (yield_expr | star_expressions)
Related links:
https://docs.python.org/3/reference/grammar.html
https://www.python.org/dev/peps/pep-0617/#id9
--
components: Parser
messages: 411360
nosy: RobEin, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: ~ PEG operator in the grammar
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46485>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46231] grammar rule definition is missing: invalid_double_starred_kvpairs
New submission from Robert Einhorn :
Definition of invalid_double_starred_kvpairs PEG grammar rule is not found:
https://docs.python.org/3.10/reference/grammar.html
# PEG grammar rule:
dict:
| '{' [double_starred_kvpairs] '}'
| '{' invalid_double_starred_kvpairs '}'
--
components: Parser
messages: 409525
nosy: RobEin, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: grammar rule definition is missing: invalid_double_starred_kvpairs
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46231>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46230] NEWLINE* is missing in 'file' rule in PEG grammar
New submission from Robert Einhorn : https://docs.python.org/3.10/reference/grammar.html # original grammar rule: file: [statements] ENDMARKER # suggested grammar rule: file: NEWLINE* [statements] ENDMARKER -- components: Parser messages: 409524 nosy: RobEin, lys.nikolaou, pablogsal priority: normal severity: normal status: open title: NEWLINE* is missing in 'file' rule in PEG grammar versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45948] Unexpected instantiation behavior for xml.etree.ElementTree.XMLParser(target=None)
New submission from Robert Steed : Expected instantiation of xml.etree.ElementTree.XMLParser(target=None) to create a parser using default TreeBuilder -- components: XML files: XMLParserFail.py messages: 407458 nosy: rdsteed priority: normal severity: normal status: open title: Unexpected instantiation behavior for xml.etree.ElementTree.XMLParser(target=None) type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file50465/XMLParserFail.py ___ Python tracker <https://bugs.python.org/issue45948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44956] curses getch returns wrong value
New submission from Robert T McQuaid :
This applies to Python 3.8 under Debian-11 Bullseye.
Under curses getch should return the value of curses.KEY_B2
(350 decimal) when pressing the keypad 5. Instead it
returns 574.
The simple program following the signature block
illustrates the problem.
Robert T McQuaid
558 McMartin Road
Mattawa Ontario P0H 1V0
phone: 705-744-6274
email: r...@fixcas.com
# Put the following lines in a file bug.py
# Run from a terminal with: python3 bug.py
import curses as cs
def report(stdscr):
print('press the keypad 5')
global result
result=stdscr.getch()
cs.initscr()
cs.wrapper(report)
print('KEY_B2 (decimal): '+str(cs.KEY_B2))
print('input decimal value: '+str(result))
--
components: Library (Lib)
messages: 399917
nosy: arbor
priority: normal
severity: normal
status: open
title: curses getch returns wrong value
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue44956>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43299] pyclbr.readmodule_ex traversing "import __main__": dies with ValueError: __main__.__spec__ is None / is not set
Robert added the comment:
You see the usecase from the stack trace: PythonWin (the IDE from pywin32
package) uses pyclbr - to inspect arbitrary user code.
(Neither code is from me)
I'm not inspecting __main__ explicitely. The problem seems to arise in newer
Python versions (3.10+?) because the class browser now seems to parse imports
somehow recursively (_readmodule() several times in the stack trace) and when
user code somewhere contains e.g. "import __main__" ...
pyclbr should perhaps handle (not fail in) all legal cases w/o breaking: when
some strange builtin/extension/artificial has .__spec__ as None or not set or
no python code. (We cannot force any user code to monkey patch
__main__.__spec__ or potential other modules.)
>>> mod = types.ModuleType('mymod')
>>> mod.__spec__
# (None)
>>>
importlib.util._find_spec_from_path() has choosen to raise ValueError instead
of an extra custom Error (or a special return value) for those cases and to
return None for the similar case of 'not found') . Though those 3 cases are
similiar in consequence here. pyclbr also "cheaply abuses" ImportError /
ModuleNotFound to translate one of those cases (None return value) for internal
signaling. (There is never a real ImportError just remote linguistic similarity
;-) )
Hence the simple pragmatic fix by kind of reunification of signaling the "end
of the game" here - as the way of signaling here is anyway rather pragmatic and
evolution style.
ValueError is often (ab)used to signal application level errors "cheaply" (to
not define and distribute an extra Exception type) - and its a limited internal
case here where mix-up with errors from something like "math.sqrt(-1)" is not
possible w/o coding bugs (which are to be detected by tests)
But you may establish a more meticulous error / return value signaling system -
which though will require changes / refactoring in several places and
consideration for compatibility ...
(Think its hardly worth it)
--
___
Python tracker
<https://bugs.python.org/issue43299>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43547] support ZIP files with zeroed out fields (e.g. for reproducible builds)
Change by Robert Pollak : -- nosy: +jondo ___ Python tracker <https://bugs.python.org/issue43547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43321] PyArg_ParseTuple() false-returns SUCCESS though SystemError and missing data (when PY_SSIZE_T_CLEAN not #define'd)
New submission from Robert :
When PY_SSIZE_T_CLEAN is not #defined in Py3.10, PyArg_ParseTuple() etc. sets
a SystemError but the return value says 1 (=SUCCESS)!
=> Causes terrific crashes with unfilled variables - instead of a clean Python
exception.
Background: pywin32 suffers in masses from the drop of int support for the
s#/y#/et#... formats in PyArg_ParseTuple() etc. (PY_SSIZE_T_CLEAN is required
in Py3.10). And only part of the source is already PY_SSIZE_T_CLEAN. Now it is
very difficult to even run tests and weed out / check, because of freezes
instead of nice Python exceptions.
=> Instead of preventing such freezes, the PY_SSIZE_T_CLEAN mechanism became
the opposite: a clever trap, a sword of Damocles :)
The cause is in getargs.c:
=== getargs.c / convertsimple()
#define REQUIRE_PY_SSIZE_T_CLEAN \
if (!(flags & FLAG_SIZE_T)) { \
PyErr_SetString(PyExc_SystemError, \
"PY_SSIZE_T_CLEAN macro must be defined for '#'
formats"); \
return NULL; \
}
#define RETURN_ERR_OCCURRED return msgbuf
===
=> The return NULL is further processed as no msg NULL -> no error.
=> Perhaps it should be a `return converterr(...)` or `return
sstc_system_error(...)` !?
--
components: Interpreter Core
messages: 387678
nosy: kxrob
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple() false-returns SUCCESS though SystemError and missing
data (when PY_SSIZE_T_CLEAN not #define'd)
type: crash
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43321>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43299] pyclbr.readmodule_ex traversing "import __main__": dies with ValueError: __main__.__spec__ is None / is not set
Change by Robert : -- keywords: +patch pull_requests: +23407 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24623 ___ Python tracker <https://bugs.python.org/issue43299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43247] How to search for a __main__ module using pyclbr in Python3?
Robert added the comment:
# `__main__` of the source code directory: `/tmp/rebound/rebound`.
# differentiate `__main__` of my target source code to read from the built-in
`__main__`? In other words, how do I read the module `__main__` of the
codebase: rebound?
=> when __main__.py is inside a package, use the full dotted module name - and
an appropriate search path below that directory:
pyclbr.readmodule_ex('rebound.__main__')
pyclbr.readmodule_ex('lib2to3.__main__')
When __main__.py is intended as a top level module / script, I think such a
name collision with an internal module name is a bad idea at all.
(For a special local purposes you could use a symlink or so?)
(I experience a bug with pyclbr (in py3.10 at least) when it traverses an
"import __main__" statement. It causes also "ValueError: __main__.__spec__ is
None" or "ValueError: {}.__spec__ is not set". But this seems to be an actual
bug w/o bug report so far: #43299 )
--
nosy: +kxrob
___
Python tracker
<https://bugs.python.org/issue43247>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43299] pyclbr.readmodule_ex traversing "import __main__": dies with ValueError: __main__.__spec__ is None / is not set
New submission from Robert :
When pyclbr.readmodule_ex() is traversing "import __main__" or another
module without __spec__, it dies completely
with "ValueError: __main__.__spec__ is None / is not set".
=> It should at least continue with the (big) rest
as the comment in _ModuleBrowser.visit_Import() says:
# If we can't find or parse the imported module,
# too bad -- don't die here.
And optionally fall back to using __file__ when present?
Traceback (most recent call last):
File
"C:\Python310\Lib\site-packages\pythonwin\pywin\framework\editor\ModuleBrowser.py",
line 128, in OnActivateView
self.CheckRefreshList()
File
"C:\Python310\Lib\site-packages\pythonwin\pywin\framework\editor\ModuleBrowser.py",
line 181, in CheckRefreshList
self.CheckMadeList()
File
"C:\Python310\Lib\site-packages\pythonwin\pywin\framework\editor\ModuleBrowser.py",
line 173, in CheckMadeList
self.rootitem = root = self._MakeRoot()
File
"C:\Python310\Lib\site-packages\pythonwin\pywin\framework\editor\ModuleBrowser.py",
line 153, in _MakeRoot
data = reader(mod, path and [path])
File "C:\Python310\lib\pyclbr.py", line 120, in readmodule_ex
return _readmodule(module, path or [])
File "C:\Python310\lib\pyclbr.py", line 159, in _readmodule
return _readmodule(submodule, parent['__path__'], package)
File "C:\Python310\lib\pyclbr.py", line 184, in _readmodule
return _create_tree(fullmodule, path, fname, source, tree, inpackage)
File "C:\Python310\lib\pyclbr.py", line 272, in _create_tree
mbrowser.visit(ast.parse(source))
File "C:\Python310\lib\ast.py", line 410, in visit
return visitor(node)
File "C:\Python310\lib\ast.py", line 418, in generic_visit
self.visit(item)
File "C:\Python310\lib\ast.py", line 410, in visit
return visitor(node)
File "C:\Python310\lib\pyclbr.py", line 243, in visit_Import
_readmodule(module.name, [])
File "C:\Python310\lib\pyclbr.py", line 167, in _readmodule
spec = importlib.util._find_spec_from_path(fullmodule, search_path)
File "C:\Python310\lib\importlib\util.py", line 69, in _find_spec_from_path
raise ValueError('{}.__spec__ is None'.format(name))
ValueError: __main__.__spec__ is None
--
components: Library (Lib)
messages: 387520
nosy: kxrob
priority: normal
severity: normal
status: open
title: pyclbr.readmodule_ex traversing "import __main__": dies with ValueError:
__main__.__spec__ is None / is not set
type: crash
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43299>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43209] system cannot find the file specified in subprocess.py
New submission from robert j richardson :
When using >python synth.py in the directory
google-api-java-client-services-master
python returns:
synthtool > Cloning
https://github.com/googleapis/discovery-artifact-manager.git.
synthtool > Cleaning output directory.
Traceback (most recent call last):
File "D:\google-api-java-client-services-master\synth.py", line 47, in
shell.run("rm -rf .cache".split(), cwd=repository)
File
"C:\Users\rober\AppData\Local\Programs\Python\Python39\lib\site-packages\synthtool\shell.py",
line 27, in run
return subprocess.run(
File
"C:\Users\rober\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line
501, in run
with Popen(*popenargs, **kwargs) as process:
File
"C:\Users\rober\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line
947, in __init__
self._execute_child(args, executable, preexec_fn, close_fds,
File
"C:\Users\rober\AppData\Local\Programs\Python\Python39\lib\subprocess.py", line
1416, in _execute_child
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified
--
components: Windows
messages: 386871
nosy: paul.moore, robertjrichardson, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: system cannot find the file specified in subprocess.py
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43209>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43032] Size of pie chart in matplotlib (frame affects it)
New submission from Robert : Hi all. Is it an issue or on purpose that enabling and disabling the frame in plt.pie() results in different sized pie charts? In my opinion the code below should provide identical sized charts. If it is on purpose, can you give me a reference? I am using the conda version of pyhton but colleagues experience the same behavior. import matplotlib.pyplot as plt f = plt.figure(figsize=(10,5),dpi=300) ax1 = f.add_axes([0,0,0.5,1]) ax2 = f.add_axes([0.5,0,0.5,1]) ax1.pie([180,180],center=(0.5,0.5),radius=0.5,frame=False) ax2.pie([180,180],center=(0.5,0.5),radius=0.5,frame=True) plt.show() -- messages: 385713 nosy: twisterior priority: normal severity: normal status: open title: Size of pie chart in matplotlib (frame affects it) versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue43032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42681] mistake in curses documentation
New submission from Robert T McQuaid : The description of color_pair starts with curses.color_pair(color_number) It should be curses.color_pair(pair_number) -- assignee: docs@python components: Documentation messages: 383344 nosy: arbor, docs@python priority: normal severity: normal status: open title: mistake in curses documentation versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42173] Drop Solaris support
Robert D. French added the comment: Hello! I just want to lend my voice in favor of maintaining "Solarish" support as well, and offer what help I may for resolving issues. -- nosy: +robertdfrench ___ Python tracker <https://bugs.python.org/issue42173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42163] _replace() no longer works on platform.uname_result objects
Robert O'Callahan added the comment: I filed issue 42189, which is similar but maybe worse: copy.deepcopy() is broken for platform.uname_result objects. -- nosy: +rocallahan ___ Python tracker <https://bugs.python.org/issue42163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42189] copy.deepcopy() no longer works on platform.uname_result objects
New submission from Robert O'Callahan : Starting from Python 3.9, copy.deepcopy can't copy a platform.uname_result object. ``` Python 3.9.0 (default, Oct 6 2020, 00:00:00) [GCC 10.2.1 20200826 (Red Hat 10.2.1-3)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> import copy >>> u = platform.uname() >>> print(u) uname_result(system='Linux', node='localhost.localdomain', release='5.8.16-300.fc33.x86_64', version='#1 SMP Mon Oct 19 13:18:33 UTC 2020', machine='x86_64') >>> v = copy.deepcopy(u) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.9/copy.py", line 172, in deepcopy y = _reconstruct(x, memo, *rv) File "/usr/lib64/python3.9/copy.py", line 264, in _reconstruct y = func(*args) File "/usr/lib64/python3.9/copyreg.py", line 91, in __newobj__ return cls.__new__(cls, *args) TypeError: () takes 6 positional arguments but 7 were given ``` Looks similar to issue 42163 but I guess it might need to be fixed differently. This has broken building Intel's Xed library, which uses a Python-based build system: https://github.com/intelxed/mbuild -- components: Library (Lib) messages: 379853 nosy: rocallahan priority: normal severity: normal status: open title: copy.deepcopy() no longer works on platform.uname_result objects type: behavior versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42189> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42103] DoS (MemError via CPU and RAM exhaustion) when processing malformed Apple Property List files in binary format
New submission from Robert Wessen :
In versions of Python from 3.4-3.10, the Python core plistlib library supports
Apple's binary plist format. When given malformed input, the implementation can
be forced to create an argument to struct.unpack() which consumes all available
CPU and memory until a MemError is thrown as it builds the 'format' argument to
unpack().
This can be seen with the following malformed example binary plist input:
```
$ xxd binary_plist_dos.bplist
: 6270 6c69 7374 3030 d101 0255 614c 6973 bplist00...UaLis
0010: 74a5 0304 0506 00df 4251 4351 44a3 t.BQCQD.
0020: 0809 0a10 0110 0210 0308 0b11 1719 1b1d
0030: 0101 000b
0040: 0029...)
```
The error is reached in the following lines of plistlib.py:
(https://github.com/python/cpython/blob/e9959c71185d0850c84e3aba0301fbc238f194a9/Lib/plistlib.py#L485)
```
def _read_ints(self, n, size):
data = self._fp.read(size * n)
if size in _BINARY_FORMAT:
return struct.unpack('>' + _BINARY_FORMAT[size] * n, data)
```
When the malicious example above is opened by plistlib, it results in 'n' being
controlled by the input and it can be forced to be very large. Plistlib
attempts to build a string which is as long as 'n', consuming excessive
resources.
Apple's built in utilities for handling plist files detects this same file as
malformed and will not process it.
--
components: Interpreter Core
messages: 379175
nosy: wessen
priority: normal
severity: normal
status: open
title: DoS (MemError via CPU and RAM exhaustion) when processing malformed
Apple Property List files in binary format
type: resource usage
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42103>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26680] Incorporating float.is_integer into Decimal
Robert Smallshire added the comment: Yes Raymond, I can prepare a new PR as soon as the faulty PR has been rolled back. -- ___ Python tracker <https://bugs.python.org/issue26680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26680] Incorporating float.is_integer into the numeric tower and Decimal
Robert Smallshire added the comment: First, I would like to apologise for the confusion I have inadvertently caused. I didn't see Raymond's question and Guido's clear response here about not modifying the numeric tower, as it came _long_ after activity had moved to GitHub, and code had been reviewed over there. Now Raymond has linked back to here and I've caught up with the situation, I offer to make a compensating PR with reverts the changes to the numeric tower. I should be able to do this in the next day or two. Please let me know whether you would like me to proceed, or whether you intend to handle the a partial or complete rollback among yourselves. -- ___ Python tracker <https://bugs.python.org/issue26680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41878] python3 fails to use custom mapping object as symbols in eval()
Robert Haschke added the comment: Thanks, Josh, for this clarification. What is the suggested mitigation? Obviously, I need to pass all symbols from my hierarchical dictionary in a flattend version as a dict to globals. Or do you see another option? -- ___ Python tracker <https://bugs.python.org/issue41878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41878] python3 fails to use custom mapping object as symbols in eval()
Robert Haschke added the comment:
Looks like the list generator is considered as a new nested scope, which
prohibits access to local variables?
This basic expression, passing local symbols only, fails as well:
eval('[abc[i]*abc[i] for i in [0, 1, 2]]', {}, dict(abc=[1, 2, 3]))
while this one, passing dict as global symbols, works:
eval('[abc[i]*abc[i] for i in [0, 1, 2]]', dict(abc=[1, 2, 3]))
However, passing globals must be a real dict. So I cannot simply pass my custom
mapping to globals.
--
title: python3 fails to use custom dict-like object as symbols in eval() ->
python3 fails to use custom mapping object as symbols in eval()
___
Python tracker
<https://bugs.python.org/issue41878>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41878] python3 fails to use custom dict-like object as symbols in eval()
New submission from Robert Haschke :
The attached file implements a custom dict-like class (MyDict) as a minimal
example of code I am using in a larger codebase.
Before you ask, why I reimplemented a dict-like object: The real code base
employs a hierarchical dict, referencing recursively to the parent dict, if a
key cannot be found in the current dict.
The main code of the file defines two entries/variables for this dict:
symbols = MyDict()
symbols['abc'] = '[1, 2, 3]'
symbols['xyz'] = 'abc + abc'
and eval_text('xyz', symbols) should evaluate to the python expression as you
would have evaluated those variables in a python interpreter.
While this works for the first given expression (above), it fails for this one:
symbols['xyz'] = '[abc[i]*abc[i] for i in [0, 1, 2]]'
raising NameError: name 'abc' is not defined.
The same code works perfectly in python 2.7. Hence, I assume this is a bug in
python3.
--
files: buggy.py
messages: 377616
nosy: Robert Haschke
priority: normal
severity: normal
status: open
title: python3 fails to use custom dict-like object as symbols in eval()
versions: Python 3.8
Added file: https://bugs.python.org/file49476/buggy.py
___
Python tracker
<https://bugs.python.org/issue41878>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39727] cgi.parse() fatally attempts str.decode when handling multipart/form-data
Robert added the comment: Would this patch already solve? : https://github.com/python/cpython/pull/19130 There seems to be another bug: The strange 'latin-1' default encoding of cgi.parse(), which only has effect in non-mulitpart: if hasattr(fp,'encoding'): encoding = fp.encoding else: encoding = 'latin-1' ( cgi.FieldStorage and the other functions in cgi and urllib.parse use a 'utf-8' default correctly - and do not try fp.encoding, which is usually not present and not reasonable in form handling WSGI. And 'application/x-www-form-urlencoded' implies utf-8. ) => that default should possibly become utf-8. Optionally cgi.parse() could take an extra parameter encoding=None . -- nosy: +kxroberto2 ___ Python tracker <https://bugs.python.org/issue39727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Robert Reynolds added the comment:
A pure python demonstration of the problem looks like this (`__file__` stores
the path to the executed module):
```python
with open(__file__) as f:
src = f.read()
with open(__file__, 'w') as f:
f.write('\n\n\n\n\n# Whoops! Wrong line!\n')
f.write(src)
raise NotImplementedError('The prepended lines have confused you.')
```
--
nosy: +Robert Reynolds
___
Python tracker
<https://bugs.python.org/issue8087>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8087] Unupdated source file in traceback
Robert Reynolds added the comment: I second [what was said by Aigars Mahinovs](https://bugs.python.org/issue8087#msg300990) about long-running processes giving confusing tracebacks that make debugging very difficult. I have a Natural Language Processing pipeline extracting features from a large corpus of texts, and that process can take days to complete. If the underlying modules have since been edited, then when an Exception occurs – including a KeyboardInterrupt – then the traceback shows the wrong lines. The functions listed at the end of the line are correct, which is the only reason I was able to easily detect the source of my confusion; the line number cited was no longer inside of the listed function! I propose one more simple thing to track that would be helpful in my situation: how many lines were in the file at call time vs now. It would be (potentially) helpful to have a warning point out that the cited module is now 17 lines longer than it was when it was imported. That way I can make more intelligent guesses about what line was actually the culprit. Obviously there could have been additions and deletions, which muddies the water, but this would at least be a starting point. -- ___ Python tracker <https://bugs.python.org/issue8087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40417] PyImport_ReloadModule emits deprecation warning
Robert Rouhani added the comment: No problem! Happy to contribute where I can :) -- ___ Python tracker <https://bugs.python.org/issue40417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40417] PyImport_ReloadModule emits deprecation warning
Change by Robert Rouhani : -- pull_requests: +19250 pull_request: https://github.com/python/cpython/pull/19935 ___ Python tracker <https://bugs.python.org/issue40417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40417] PyImport_ReloadModule emits deprecation warning
Change by Robert Rouhani : -- pull_requests: +19249 pull_request: https://github.com/python/cpython/pull/19934 ___ Python tracker <https://bugs.python.org/issue40417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40417] PyImport_ReloadModule emits deprecation warning
Robert Rouhani added the comment: We have a fairly straightforward workaround of using the "warnings" module to redirect to stdout, so we personally don't have a need. Unreal, however, follows the VFX Reference Platform ( https://vfxplatform.com/) which is migrating from 2.7 to 3.7.x this year. They will likely run into this during their migration, so backporting to 3.7 would be useful. On Fri, May 1, 2020 at 8:22 AM Eric Snow wrote: > > Eric Snow added the comment: > > Did you have a need for this to be fixed in 3.8 or earlier? This seems > reasonably and simple enough to backport. I suppose someone could be > relying on an implicit import of the "imp" module, but that seems highly > unlikely and suspect anyway. :) > > -- > nosy: +brett.cannon, ncoghlan > > ___ > Python tracker > <https://bugs.python.org/issue40417> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40417] PyImport_ReloadModule emits deprecation warning
New submission from Robert Rouhani : It appears as though PyImport_ReloadModule is importing the deprecated "imp" module. I integrated a newer version of Python into Unreal Engine 4, which internally calls this function for some of it's own modules. Normally a stray warning wouldn't be of much concern to me, but the process of "cooking" (converting raw assets to optimized/final assets) will fail if anything is written to stderr. This makes it impossible to package a copy of the game for testing or release without a workaround. I'm going to add a test to _testembed.c to verify my fix. Is this something that I should include in the Github PR? -- components: Interpreter Core messages: 367501 nosy: Robert Rouhani priority: normal severity: normal status: open title: PyImport_ReloadModule emits deprecation warning type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40322] struct.pack adding unexpected byte in 'B' format
Robert Bressan added the comment: After placing a standard size instead of a native one, solved. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40322] struct.pack adding unexpected byte in 'B' format
New submission from Robert Bressan :
struct.pack() is adding an unexpected null byte.
When I've run this code:
___
import struct
d = {'c':b'a', 'b':1, 'B':1, '?':False, 'h':2, 'H':2, 'i':-3, 'I':3, 'l':4,
'L':4, 'q':5, 'Q':5, 'f':100.0, 'd':2.0}
for x in d:
y = struct.pack(x,d[x])
print('len('+x+') = ' + str(len(y)) + ': ' + str(y))
x = struct.pack('fBHL', 100, 1, 2,4)
print('len(fBHL) = ' + str(len(x)) + ': ' + str(x))
¯¯¯
I got this return:
___
len(c) = 1: b'a'
len(b) = 1: b'\x01'
len(B) = 1: b'\x01'
len(?) = 1: b'\x00'
len(h) = 2: b'\x02\x00'
len(H) = 2: b'\x02\x00'
len(i) = 4: b'\xfd\xff\xff\xff'
len(I) = 4: b'\x03\x00\x00\x00'
len(l) = 4: b'\x04\x00\x00\x00'
len(L) = 4: b'\x04\x00\x00\x00'
len(q) = 8: b'\x05\x00\x00\x00\x00\x00\x00\x00'
len(Q) = 8: b'\x05\x00\x00\x00\x00\x00\x00\x00'
len(f) = 4: b'\x00\x00\xc8B'
len(d) = 8: b'\x00\x00\x00\x00\x00\x00\x00@'
len(fBHL) = 12: b'\x00\x00\xc8B\x01\x00\x02\x00\x04\x00\x00\x00'
¯¯¯
I believe the last line pack ("fBHL") consumes 11 bytes (4+1+2+4), and
analysing the bytearray, the B is packing 2 bytes, instead of one. My expected
result was:
___
len(fBHL) = 11: b'\x00\x00\xc8B\x01\x02\x00\x04\x00\x00\x00'
¯¯¯
--
components: Interpreter Core
messages: 366734
nosy: Robert Bressan
priority: normal
severity: normal
status: open
title: struct.pack adding unexpected byte in 'B' format
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue40322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39535] multiprocessing.Process file descriptor resource leak
Robert Pierce added the comment: It appears as if the problem is the sentinel FIFO opened by (for example) multiprocessing.popen_fork.Popen._launch(). It registers a finalization class to close the sentinel on garbage collection. Instead, it should be closed in poll() or wait() when the child process is reaped and known to be dead. The sentinel serves no purpose after the child is reaped, and waiting till garbage collection means that programs forking large numbers of processes cannot control file descriptor utilization. -- ___ Python tracker <https://bugs.python.org/issue39535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39535] multiprocessing.Process file descriptor resource leak
New submission from Robert Pierce : multiprocessing.Process opens a FIFO to the child. This FIFO is not documented the the Process class API and it's purpose is not clear from the documentation. It is a minor documentation bug that the class creates non-transparent resource utilization. The primary behavioral bug is that incorrect handling of this FIFO creates a resource leak, since the file descriptor is not closed on join(), or even when the parent Process object goes out of scope. The effect of this bug is that programs generating large numbers of Process objects will hit system resource limits of open file descriptors. -- assignee: docs@python components: Documentation, Library (Lib) files: proc_test.py messages: 361273 nosy: Robert Pierce, docs@python priority: normal severity: normal status: open title: multiprocessing.Process file descriptor resource leak type: resource usage versions: Python 3.6 Added file: https://bugs.python.org/file48878/proc_test.py ___ Python tracker <https://bugs.python.org/issue39535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws
Robert Xiao added the comment: Could this be solvable if `closefd` were a writable attribute? Then we could do file = None try: file = io.open(fd, ..., closefd=False) file.closefd = True except: if file and not file.closefd: os.close(fd) raise I believe this should be bulletproof - a KeyboardInterrupt can happen anywhere in the `try` and we will not leak or double-close. Either file.closefd is set, in which case `file` owns the fd and will close it eventually, or file.closefd is not set in which case the fd needs to be manually closed, or file doesn't exist (exception thrown in io.open or while assigning file), in which case the fd still needs to be manually closed. Of course, this can leak if a KeyboardInterrupt lands in the `except` - but that's not something we can meaningfully deal with. The important thing is that this shouldn't double-close if I analyzed it correctly. This is a somewhat annoying pattern, though. I wonder if there's a nicer way to implement it so we don't end up with this kind of boilerplate everywhere. -- ___ Python tracker <https://bugs.python.org/issue39318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws
New submission from Robert Xiao : tempfile.NamedTemporaryFile creates its wrapper like so: try: file = _io.open(fd, mode, buffering=buffering, newline=newline, encoding=encoding, errors=errors) return _TemporaryFileWrapper(file, name, delete) except BaseException: _os.unlink(name) _os.close(fd) raise If _TemporaryFileWrapper throws any kind of exception (even KeyboardInterrupt), this closes `fd` but leaks a valid `file` pointing to that fd. The `file` will later attempt to close the `fd` when it is collected, which can lead to subtle bugs. (This particular issue contributed to this bug: https://nedbatchelder.com/blog/202001/bug_915_please_help.html) This should probably be rewritten as: try: file = _io.open(fd, mode, buffering=buffering, newline=newline, encoding=encoding, errors=errors) except: _os.unlink(name) _os.close(fd) raise try: return _TemporaryFileWrapper(file, name, delete) except BaseException: _os.unlink(name) file.close() raise or perhaps use nested try blocks to avoid the _os.unlink duplication. -- components: Library (Lib) messages: 359888 nosy: nneonneo priority: normal severity: normal status: open title: NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39231] Mistaken notion in tutorial
New submission from Robert : https://docs.python.org/3/tutorial/controlflow.html 4.7.8. Function Annotations [...] "The following example has a positional argument, a keyword argument, and the return value annotated:" It is not a "positional argument" but an "optional argument". -- assignee: docs@python components: Documentation messages: 359443 nosy: docs@python, r0b priority: normal severity: normal status: open title: Mistaken notion in tutorial type: enhancement ___ Python tracker <https://bugs.python.org/issue39231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38345] Add end lines to pyclbr objects
Change by Robert Kearns : -- keywords: +patch pull_requests: +16124 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16534 ___ Python tracker <https://bugs.python.org/issue38345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38345] Add end lines to pyclbr objects
Change by Robert Kearns : -- components: Library (Lib) nosy: RobertKearns priority: normal severity: normal status: open title: Add end lines to pyclbr objects type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38345> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26680] Incorporating float.is_integer into the numeric tower and Decimal
Robert Smallshire added the comment: > * no forward movement for a year and half For most of that year and a half my pull-request was sitting in Github <https://github.com/python/cpython/pull/6121> awaiting review by two core devs, of which you Raymond, were one. I don't like to hassle people who contribute their free time to Python and assumed you or the other reviewer would get around to it good time. Mark Dickinson kindly reviewed the my changes shortly before the 3.8 window closed, but I didn't have capacity to follow up before it was too late. The changes Mark wanted were largely to do with in-code documentation rather than the the substance of the change. Assuming it really is too late for 3.8, even if I made the changes Mark wanted immediately, I would like to see this change in 3.9. > * opposition from multiple core devs Guido approved the change in a pronouncement on python-dev. <https://mail.python.org/pipermail/python-dev/2018-March/152437.html> -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue26680> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: optionally autoconvert table_info's DATETIME fields
Robert Pollak added the comment: Sorry for not providing a pull request yet. By the way, the "DB Browser for SQLite" (https://sqlitebrowser.org/) also interprets DATETIME fields correctly. (Could someone please change the "Stage" of this issue to "needs patch"?) -- versions: +Python 3.8 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue35145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Oh, I didn't mean to imply that these are the only options I'd support - just that these are the things I've thought through and that I think will all work well... I'm sure there are more options available ;) -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Change by Robert Collins : -- versions: +Python 3.9 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Ok so design wise - there is state on the TestCase that influences assertions; in potentially two ways. The first way is formatting - the amount of detail shown in long list comparisons etc. The second way I don't think we have at the moment, but potentially it could influence the fidelity of comparisons for NearlyEquals and the like - generally though we tend to pass those in as parameters. So just ripping everything off into standalone functions loses the home for that state. It either becomes global (ugh), or a new object that isn't a test case but is basically the same magic object that has to be known is carried around, or we find some other way of delegating the formatting choice and controls. hamcrest has some prior art in this space, and testtools experimented with that too. wordpress has managed to naff up the formatting on my old blog post about this https://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ and https://testtools.readthedocs.io/en/latest/for-test-authors.html#matchers Its been on my TODO for a very long time to put together a PEP for adding matchers to the stdlib; I find the full system we did in testtools very useful because it can represent everything from a trivial in-memory string error through to a disk image for a broken postgresql database, without running out of memory or generating mojibake but if we wanted to do something smaller that didn't prejuidice extensions like testtools still doing more that would be fine too. The core idea of matchers is that rather than a standalone function f() -> nil/raise, you build a callable object f() -> Option(Mismatch), and a Mismatch can be shown to users, combined with other mismatches to form composites or sequences and so forth. So this would give room for the state around object formatting and the like too. -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Right now that attribute could be set by each test separately, or even varied within a test. TBH I'm not sure that the attribute really should be supported; perhaps thinking about breaking the API is worth doing. But - what are we solving for here. The OP here seems interested in using the assertion like things entirely outside of a test context. What would a nice clean API for that be? (Yes I like matchers, but put that aside - if the APIs aren't close enough, lets make sure we do a good job for each audience rather than a compromise..) -- ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37262] Make unittest assertions staticmethods/classmethods
Robert Collins added the comment: I think this is strictly redundant with that other ticket and I'm going to close it. That said, they need access to self.failureException. https://docs.python.org/3/library/unittest.html#unittest.TestCase.failureException -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19645] decouple unittest assertions from the TestCase class
Robert Collins added the comment: Sorry for the slow reply here; There are API breaks involved in any decoupling that involves the exception raising because of the failureException attribute. Something with signalling that can be adapted by other test suites etc might have merit, but I think we are lacking a clear use case for doing this to the existing exceptions. Setting up a way for new things to be more easily used by users of other test frameworks is quite attractive; perhaps just writing them as separate functions with an adapter to failureException would be sufficient. -- versions: +Python 3.9 -Python 3.5 ___ Python tracker <https://bugs.python.org/issue19645> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33591] ctypes does not support fspath protocol
Robert added the comment: Can anyone do a review? -- ___ Python tracker <https://bugs.python.org/issue33591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36656] Please add race-free os.link and os.symlink wrapper / helper
Robert Collins added the comment: Thank you @Eryk -- ___ Python tracker <https://bugs.python.org/issue36656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36656] Please add race-free os.link and os.symlink wrapper / helper
Robert Collins added the comment: I'd like to add a few notes; please do consider Windows interactions here - Windows does not have the same model for inode replacement that Posix has. Secondly, I note that the thread model discussed here hasn't been particular well articulated. In particular the vagaries of directories with the sticky bit set are quite different to those where attacker and victim share group permissions : TOCTTOU attacks do imply that post-atomic operation attacks will be possible, and I disagree with the analysis by Serhiy suggesting that they are necessarily so. However I also agree with Toshio that the os module is not the right place to provide a more secure API: we have to have the basic primitive exposed to Python code somewhere, otherwise the higher level APIs such as you'd like to use are not creatable. My suggestion is that you put a module up on PyPI that provides the secure behaviour necessary, get some feedback on that, get some cross-platform experience, and then, if desired, propose it for inclusion in shutil or similar in the stdlib. I'm also going to retitle this - because actually, os.link and os.symlink aren't racy *per se* on Posix - its how they are used that is racy: and the very fact that a secure variant can be written (however ugly) is demonstration of that. -- nosy: +rbcollins title: Race conditions due to os.link and os.symlink POSIX specification -> Please add race-free os.link and os.symlink wrapper / helper ___ Python tracker <https://bugs.python.org/issue36656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36994] Missing tests for CALL_FUNCTION_EX opcode profiling method_descriptor
Robert Collins added the comment: New changeset b892d3ea468101d35e2fb081002fa693bd86eca9 by Robert Collins (Jeroen Demeyer) in branch 'master': bpo-36994: add test for profiling method_descriptor with **kwargs (GH-13461) https://github.com/python/cpython/commit/b892d3ea468101d35e2fb081002fa693bd86eca9 -- nosy: +rbcollins ___ Python tracker <https://bugs.python.org/issue36994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34125] Profiling depends on whether **kwargs is given
Robert Collins added the comment: New changeset b892d3ea468101d35e2fb081002fa693bd86eca9 by Robert Collins (Jeroen Demeyer) in branch 'master': bpo-36994: add test for profiling method_descriptor with **kwargs (GH-13461) https://github.com/python/cpython/commit/b892d3ea468101d35e2fb081002fa693bd86eca9 -- nosy: +rbcollins ___ Python tracker <https://bugs.python.org/issue34125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24653] Mock.assert_has_calls([]) is surprising for users
Robert Collins added the comment: I'm reopening this because I don't agree. I opened the bug because we have evidence that users find the current documentation confusing. Saying that its not confusing to us doesn't fix the confusion. Why should we mention the special case of an empty set? Because its the only special case. A simple single sentence: "Note: to assert that no calls were made see `assert_not_called`" would probably both cover the special case and direct users to the right place for that use case. -- resolution: wont fix -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue24653> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Robert Boehne added the comment: I wonder if there's anyone with AIX 7 who can attempt to reproduce this. We have another AIX machine, but it is down for the moment. I would like to eliminate a problem on this machine as the cause. -- ___ Python tracker <https://bugs.python.org/issue36843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Robert Boehne added the comment:
It doesn't look good:
robb@nepal:/raid/checkouts-raid/robb/nepal$ xlc_r -q64 -O0 -g
-qlanglvl=extc1x -o urandom urandom.c
robb@nepal:/raid/checkouts-raid/robb/nepal$ ./urandom
open O_RDONLY failed
open O_RDONLY | O_CLOEXEC failed
robb@nepal:/raid/checkouts-raid/robb/nepal$ uname -a
AIX nepal 1 7 00FA7FB84C00
robb@nepal:/raid/checkouts-raid/robb/nepal$
On Thu, May 9, 2019 at 6:21 PM STINNER Victor
wrote:
>
> STINNER Victor added the comment:
>
> Robert Boehne: pyurandom() uses _Py_open_noraise("/dev/urandom", O_RDONLY)
> which uses O_CLOEXEC if available. If this flag available? Does it work?
>
> Please try to build attached urandom.c.
>
> Example on my Fedora 29:
>
> open O_RDONLY succeeded
> read(16) -> 16
> open O_RDONLY | O_CLOEXEC succeeded
> read(16) -> 16
>
> --
> Added file: https://bugs.python.org/file48322/urandom.c
>
> ___
> Python tracker
> <https://bugs.python.org/issue36843>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue36843>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Robert Boehne added the comment:
Reading a few bytes from /dev/urandom via dd:
robb@nepal:/raid/checkouts-raid/robb/nepal/build-py37$ dd if=/dev/urandom
bs=256 count=1
??S?(#L???~]?B?^??8?f&?_|Vi??@??[joG>St??;?$?1?*??24???RD?"4`??aҼ#???f???
?}
??^zC?@?"?.^?gn??p?t?R*=Ӫ?8*?L??
8??bu?߂???8?Ŵ?`??y??٫K?.?~陵#5?t??h?e!?G@)B?R???(9kLX??BUH5=?||??El???a+n@??V?c?N?^ͯ?y?n??]??$݇?Mp?,#???K?i8?`?v??~`L?1+0
records in.
1+0 records out.
robb@nepal:/raid/checkouts-raid/robb/nepal/build-py37$ dd if=/dev/urandom
bs=256 count=1
_d?(?n???1bRԺ{??I??"Ѱ"|???E
p??^??q#??
~yZ$u??e}?3?qw#?{*T1+0 records
in.nR)?-?B???x??{~hϼ+?7۪شVW??"?d?n??V??t??R(\YC?3=?p?-ӽ?m??P???A?M??68??9Y?](??xn+?a?ܯ?W
1+0 records out.
robb@nepal:/raid/checkouts-raid/robb/nepal/build-py37$
--
___
Python tracker
<https://bugs.python.org/issue36843>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Robert Boehne added the comment:
The call to open("/dev/urandom", flags) is returning -1, and errno is set to
22, EINVAL - Invalid argument. could the flags be set incorrectly?
--
___
Python tracker
<https://bugs.python.org/issue36843>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Robert Boehne added the comment:
Opening /dev/urandom seems to return -1
(dbx) print buffer
0x09001000a5f49380
(dbx) print size
24
(dbx) print raise
0
(dbx) step
stopped in dev_urandom at line 311 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
311 if (raise) {
(dbx) step
stopped in dev_urandom at line 378 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
378 fd = _Py_open_noraise("/dev/urandom", O_RDONLY);
(dbx) next
stopped in dev_urandom at line 379 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
379 if (fd < 0) {
(dbx) print fd
-1
(dbx) step
stopped in dev_urandom at line 380 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
380 return -1;
(dbx) step
stopped in dev_urandom at line 401 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
401 }
(dbx) step
stopped in pyurandom at line 519 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
519 }
(dbx) step
stopped in unnamed block in _Py_HashRandomization_Init at line 611 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
611 if (res < 0) {
(dbx) step
stopped in unnamed block in _Py_HashRandomization_Init at line 612 in file
"/raid/checkouts-raid/robb/nepal/build-py37/../../Python-3.7.3/Python/bootstrap_hash.c"
($t1)
612 return _Py_INIT_USER_ERR("failed to get random numbers "
(dbx) continue
continue
^ unrecognized command
(dbx) cont
Fatal Python error: _Py_HashRandomization_Init: failed to get random numbers to
initialize Python
--
___
Python tracker
<https://bugs.python.org/issue36843>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Robert Boehne added the comment: from pyconfig.h: /* Define to 1 if the getrandom() function is available */ /* #undef HAVE_GETRANDOM */ /* Define to 1 if the Linux getrandom() syscall is available */ /* #undef HAVE_GETRANDOM_SYSCALL */ /* Define to 1 if you have the header file. */ /* #undef HAVE_LINUX_RANDOM_H */ /* Define to 1 if you have the `getentropy' function. */ /* #undef HAVE_GETENTROPY */ -- ___ Python tracker <https://bugs.python.org/issue36843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Change by Robert Boehne : Added file: https://bugs.python.org/file48317/config.log.gz ___ Python tracker <https://bugs.python.org/issue36843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
Robert Boehne added the comment: robb@nepal:/raid/checkouts-raid/robb/nepal/build-py37$ gmake xlc_r -c -DNDEBUG -O -q64 -qlanglvl=extc99 -IObjects -IInclude -IPython -I. -I../../Python-3.7.3/Include -I/raid/checkouts-raid/robb/Python-2.7.15/Modules/zlib -DPy_BUILD_CORE -o Modules/_math.o ../../Python-3.7.3/Modules/_math.c LIBPATH=/raid/checkouts-raid/robb/nepal/build-py37 CC='xlc_r' LDSHARED='Modules/ld_so_aix xlc_r -bI:Modules/python.exp -L/raid/checkouts-raid/robb/zlib-dl/Release/rs6000aix_64/lib -Wl,-blibpath:/opt/IBM/xlmass/8.1.3/lib/aix61:/opt/IBM/xlc/13.1.3/lib:/usr/lib:/lib:/opt/Python-3.7/lib -q64 ' OPT='-DNDEBUG -O' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ../../Python-3.7.3/setup.py build Fatal Python error: _Py_HashRandomization_Init: failed to get random numbers to initialize Python Makefile:626: recipe for target 'sharedmods' failed gmake: *** [sharedmods] Error 1 -- ___ Python tracker <https://bugs.python.org/issue36843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36843] AIX build fails with failure to get random numbers
New submission from Robert Boehne : build fails with: ./python -E ../../Python-3.7.3/setup.py build Fatal Python error: _Py_HashRandomization_Init: failed to get random numbers to initialize Python -- components: Build messages: 341821 nosy: Robert Boehne priority: normal severity: normal status: open title: AIX build fails with failure to get random numbers type: compile error versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
Robert Collins added the comment: This is now showing up in end user tools like black: https://github.com/ambv/black/issues/564 -- nosy: +rbcollins versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue26903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Robert Marshall added the comment: The pull request is now ready for a review. Apologies for the delay - took me a bit longer to circle back on this than I would have liked. -- ___ Python tracker <https://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36240] Definitions of time
New submission from Robert Billing : https://docs.python.org/3.7/library/time.html contains the text "UTC is Coordinated Universal Time (formerly known as Greenwich Mean Time, or GMT)". This is not strictly true. Referring to https://en.wikipedia.org/wiki/Coordinated_Universal_Time the definition of UTC is in terms of frequency standards, GMT in terms of astronomy. Hence with GMT each minute has exactly 60 seconds, but the length of the second may vary slightly to account for changes in the Earth's rotation. With UTC each second is the same length, but "leap seconds" can be inserted or removed giving 59 and 61 second minutes. The leap seconds keep the two systems in sync to less than one second. This of course only matters for the most critical applications, but it would be worth documenting correctly. -- assignee: docs@python components: Documentation messages: 337482 nosy: Robert Billing, docs@python priority: normal severity: normal status: open title: Definitions of time type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Robert Marshall added the comment: I have rebased this to recent master hash 53b9e1a1c1 and submitted a pull request. It built in my CI environment, so seems to be OK as far as compiling. I'll run the test suite against it later this evening when I have time to stand up a quick build enviroment with the full dependency list. -- nosy: +Robert Marshall pull_requests: +12095 Added file: https://bugs.python.org/file48175/0001-Build-or-disable-readline-module-with-Editline.patch ___ Python tracker <https://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35970] no help flag in base64 util
New submission from Robert Kuska : I failed today to print help message for base64 utility without an error: $ python3 -m base64 -help option -h not recognized usage: /usr/local/Cellar/python/3.7.2_1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/base64.py [-d|-e|-u|-t] [file|-] -d, -u: decode -e: encode (default) -t: encode and decode string 'Aladdin:open sesame So I felt like this is a ripple in time space continuum worth adjusting. I already opened a PR to address this (probably not so worthy) issue (link attached). -- messages: 335255 nosy: rkuska priority: normal pull_requests: 11851 severity: normal status: open title: no help flag in base64 util ___ Python tracker <https://bugs.python.org/issue35970> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: optionally autoconvert table_info's DATETIME fields
Robert Pollak added the comment:
So my workaround is of course
```
table = pd.read_sql_query('select * from table', con)
column_type = pd.read_sql_query('PRAGMA table_info("table")', con)['type']
datetimes = table.columns[column_type == 'DATETIME']
table.loc[:, datetimes] = table.loc[:, datetimes].apply(pd.to_datetime)
```
I would be interested in creating a pull request for the
`detect_types=CONVERT_DATETIME` argument that I described. Is there any chance
to get that merged? I currently see 541 open cpython pull requests labeled
"awaiting review" :-/
--
___
Python tracker
<https://bugs.python.org/issue35145>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: optionally autoconvert table_info's DATETIME fields
Change by Robert Pollak : -- title: sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields -> sqlite3: optionally autoconvert table_info's DATETIME fields ___ Python tracker <https://bugs.python.org/issue35145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35123] Add style guide for sentinel usage
Robert Wright added the comment:
Perhaps there's confusion over what I mean by "style guide". I'd happily take
Steven's message *as* the style guide. Or, at the very least, the clarification
that sentinels are to be thought of as constants.
It's one of those things that's obvious once mentioned, but might not be
thought of when you're using them.
Though Eric does raise an interesting point about C sentinels. Something like:
kwargs = {}
if mode is not _MISSING:
kwargs.update(mode=mode)
return open(name, "foo", **kwargs)
would work a bit better with multiple arguments, but it's still not great.
--
___
Python tracker
<https://bugs.python.org/issue35123>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields
Robert Pollak added the comment:
Here is now a reduced version of my real use case: 2017v2-reduced.db. The file
was originally created with "Oracle DBConvert". This file contains a table
without rows.
I was wrong in my last comment: There's also no sniffing needed here, see
either of the following useful outputs:
```
In [5]: pd.read_sql_query('PRAGMA table_info("t2")', con)['type']
Out[5]:
0 DATETIME
1VARCHAR (3)
Name: type, dtype: object
In [6]: pd.read_sql_query('SELECT SQL FROM sqlite_master WHERE name = "t2"',
con).iloc[0,0]
Out[6]: 'CREATE TABLE t2 (localtime DATETIME DEFAULT NULL, freq VARCHAR (3))'
```
This also works with the original file from "Oracle DBConvert".
Wouldn't it make sense for sqlite3 to use this information, e.g. when connect()
is called with something like `detect_types=CONVERT_DATETIME`? One could even
call the option CONVERT_ORACLE_DATETIME to describe that one cannot expect it
to work with files from other sources.
If yes, then I suggest changing this issue's title to '"SELECT *" should
optionally autoconvert DATETIME fields if found in DDL'.
The question is of course how much sqlite generating software creates this
metadata. But Oracle is certainly an important actor. And sqlite3 itself could
also save this DDL instead of extending the field names (which seems more
hacky).
--
Added file: https://bugs.python.org/file47911/2017v2-reduced.db
___
Python tracker
<https://bugs.python.org/issue35145>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields
Robert Pollak added the comment:
Paul, the sniffing would be only active for people who explicitly add a
connect() argument like detect_types=DETECT_DATETIME, which can have the
appropriate warning in the docs. You can also extend the sniffing to all
values, not just the first non-missing one. (I'd gladly pay the computational
price.) How many cases are there where a column is full of `-MM-DD
HH:MM:SS.SSS` data, DETECT_DATETIME is switched on, and the user _doesn't_ want
this column to be interpreted as datetime?
(I'm of course not suggesting to try detecting REAL as Julian day, or INTEGER
as Unix Time.)
Forget about my test file, by the way:
I have now found out that I can extract the DATETIME type information from my
test file SQLiteStudio-3449.sqlite in the following two ways:
```
In [3]: pd.read_sql_query('pragma table_info("t")', con)
Out[3]:
cid name type notnull dflt_value pk
00x TEXT0 None 0
11y DATETIME0 None 0
In [4]: pd.read_sql_query('SELECT SQL FROM sqlite_master WHERE name = "t"', con)
Out[4]:
sql
0 CREATE TABLE t (x TEXT, y DATETIME)
```
For my real use case however, those two statements yield empty results :-(
--
___
Python tracker
<https://bugs.python.org/issue35145>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields
Robert Pollak added the comment: I have created the attached sqlite database file (with SQLiteStudio) for testing. I contains a table `t` with a TEXT column `x` and a DATETIME (according to SQLiteStudio) column `y`. The table contains a single row with the value `2018-11-05 12:20:30` for both columns. For some reason SQLiteStudio manages to know these types (although the columns contain the same value, and even after renaming the file and reconnecting to it), so sqlite3 should also be able to detect them. -- Added file: https://bugs.python.org/file47905/SQLiteStudio-3449.sqlite ___ Python tracker <https://bugs.python.org/issue35145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields
Robert Pollak added the comment: Stéphane, your example does not match my use case with unknown table structure. Does everyone agree that such a sniffing is out of scope for sqlite3? That's not what I'd call "batteries included" :-( -- title: sqlite3: "select *" should optionally autoconvert TEXT datetime fields -> sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields ___ Python tracker <https://bugs.python.org/issue35145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should optionally autoconvert TEXT datetime fields
Change by Robert Pollak : -- title: sqlite3: "select *" should autoconvert datetime fields -> sqlite3: "select *" should optionally autoconvert TEXT datetime fields ___ Python tracker <https://bugs.python.org/issue35145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should autoconvert datetime fields
Robert Pollak added the comment: Thank you, Paul, for your hints on sniffing. I have now asked at SqliteStudio for confirmation that they also do content sniffing to detect datetime text fields: https://github.com/pawelsalawa/sqlitestudio/issues/3449 . So in this issue I am suggesting to embed this datetime text sniffing into sqlite3, for optional activation. Perhaps a new flag value of detect_types=DETECT_DATETIME to the sqlite3.connect() function would be suitable? -- ___ Python tracker <https://bugs.python.org/issue35145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35150] Misc/README.valgrind out-of-date
New submission from Robert Henry : File Misc/README.valgrind is out of date with respect to python3.8. There are important sections of this file that are 15 years old! Example: the README.valgrind refers to "Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c" but there's no such symbol in obmalloc.c (There is in Python/dtoa.c) I have no idea if the valgrind suppression file Misc/valgrind-python.supp is up to date, but it bears examination by an expert. -- assignee: docs@python components: Documentation messages: 329151 nosy: docs@python, rrh priority: normal severity: normal status: open title: Misc/README.valgrind out-of-date versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue35150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should autoconvert datetime fields
Robert Pollak added the comment: (In fact, I am currently taking the first non-missing entry of each text column and trying to dateutil.parser.parse it. If that works, I use pandas.to_datetime on the column.) -- ___ Python tracker <https://bugs.python.org/issue35145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35145] sqlite3: "select *" should autoconvert datetime fields
New submission from Robert Pollak :
Currently, fields are converted to datetime as described in
https://docs.python.org/3/library/sqlite3.html#sqlite3.PARSE_COLNAMES :
'select x as "x [datetime]" from table'
In my use case I don't know the names and locations of the datetime fields in
advance. So I would need to do pandas.read_sql_query('select * from table',
con) and get correct datetime columns.
(My current workaround is try calling pandas.to_datetime on each text column
afterwards.)
The type info has to be available in the sqlite database, because I see that
SQLiteStudio correctly detects the datetime columns.
--
components: Library (Lib)
messages: 329128
nosy: jondo
priority: normal
severity: normal
status: open
title: sqlite3: "select *" should autoconvert datetime fields
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35145>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35123] Add style guide for sentinel usage
Robert Wright added the comment: Just the classic problems caused by inconsistency in code - confusion when reading, and disagreements when writing. For reading: Where should I look in a file for the sentinels? Is this value a sentinel, or is it some other type of variable? For writing, there will always be disagreements in PRs, so we should nip it in the bud. You raise a good point about exposing sentinel values. I was previously on the fence about whether sentinels should (in general) be private, or public. -- ___ Python tracker <https://bugs.python.org/issue35123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35124] Add style guide for unit tests
New submission from Robert Wright : There should be a style guide for tests, to prevent arguments about their use in future code. -- messages: 328986 nosy: madman bob priority: normal severity: normal status: open title: Add style guide for unit tests ___ Python tracker <https://bugs.python.org/issue35124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35123] Add style guide for sentinel usage
New submission from Robert Wright : Sentinel values are used inconsistently in the Python code base. It would be helpful to have a style guide (about eg. casing, placement, and sentinel reuse) to prevent arguments about their use in future code. -- messages: 328984 nosy: madman bob priority: normal severity: normal status: open title: Add style guide for sentinel usage ___ Python tracker <https://bugs.python.org/issue35123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33074] dbm corrupts index on macOS (_dbm module)
Robert Xiao added the comment: I just started a new project, thoughtlessly decided to use `shelve` to store data, and lost it all again thanks to this bug. To reiterate: Although `gdbm` might fix this issue, it's not installed by default. But the issue is with `dbm`: Python is allowing me to insert elements into the database which exceed internal limits, causing the database to become silently corrupt upon retrieval. This is an unacceptable situation - a very normal, non-complex use of the standard library is causing data loss without any indication that the loss is occurring. At the very least there should be a warning or error that the data inserted exceeds dbm's limits, and in an ideal world dbm would not fall over from inserting a few KB of data in a single row (but I understand that's a third party problem at that point). Can't we just ship a dbm that is backed with a more robust engine, like a SQLite key-value table? -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue33074> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35005] argparse should accept json and yaml argument types
Robert Benson added the comment:
What I'm talking about is reading a single arg (of a dictionary or collection
type) that can be split across multiple lines, rather than a single line
containing multiple args
My motivation was that reading args from a file should behave in a manner
similar to other command-line utilities, such as the `-d` option for `curl` and
the `-e` option for `ansible`. These take the entire file you give it and store
it as one dictionary or object, not by merging it with the rest of the
namespace but by taking the dictionary as the value of just that arg. So:
argument_parser.add_argument("-d", "--data", type=argparse.JsonType) # just
for example
if I call the program with `--data @foo.json`
I want argument_parser.parse_args().data to be the dict that is in foo.json,
whether foo.json is pretty-printed or not.
I haven't done an exhaustive search of StackOverflow, but seeing a couple top
answers indicated that this was not readily available without the user at least
having to call `json.loads` on a string argument themselves, when it seems
logical that it would be built into the library to parse the json into a
dictionary
--
___
Python tracker
<https://bugs.python.org/issue35005>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35005] argparse should accept json and yaml argument types
New submission from Robert Benson : Using `argparse`, I wanted to create an argument that was a JSON dictionary. I found that using this in combination with the `fromfile_prefix_args` keyword argument, that the parser assumes that each argument provided in the file must be on a single line. I want the module to be able to support json files that may be pretty-printed. If it is to accept JSON in this manner, it would be not much more effort to implement YAML parsing as well -- ___ Python tracker <https://bugs.python.org/issue35005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35005] argparse should accept json and yaml argument types
Change by Robert Benson : -- versions: -Python 2.7 ___ Python tracker <https://bugs.python.org/issue35005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35005] argparse should accept json and yaml argument types
Change by Robert Benson : -- components: Library (Lib) nosy: derelbenkoenig priority: normal severity: normal status: open title: argparse should accept json and yaml argument types type: enhancement ___ Python tracker <https://bugs.python.org/issue35005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35005] argparse should accept json and yaml argument types
Change by Robert Benson : -- versions: +Python 2.7 ___ Python tracker <https://bugs.python.org/issue35005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34932] Add macOS TCP_KEEPALIVE to available socket options
Robert Wall added the comment: I saw that article too but reading man tcp(4) [1], it says that this value is in seconds for macOS and testing appears to confirm this. Where the unit of time is different, however, is with the old and new Windows keepalive options discussed in #32394. The SIO_KEEPALIVE_VALS set via the WinSock ioctl is in milliseconds [2] whereas the newer TCP_KEEP* flags are set in seconds [3] but this doesn't seem too bad as they are different interfaces. I'll add the tcp_keepalive flag to the same win_runtime_flags structure as the other options with minimum version 1709 and update the failing test accordingly to take account of the new option. [1] https://github.com/apple/darwin-xnu/blob/xnu-4570.1.46/bsd/man/man4/tcp.4#L172 [2] https://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx [3] https://docs.microsoft.com/en-us/windows/desktop/winsock/ipproto-tcp-socket-options -- ___ Python tracker <https://bugs.python.org/issue34932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34932] Add macOS TCP_KEEPALIVE to available socket options
Robert added the comment: Acknowledging the test failure and message pointing to #32394: == FAIL: test_new_tcp_flags (test.test_socket.TestMSWindowsTCPFlags) -- Traceback (most recent call last): File "C:\projects\cpython\lib\test\test_socket.py", line 5992, in test_new_tcp_flags self.assertEqual([], unknown, AssertionError: Lists differ: [] != ['TCP_KEEPALIVE'] Second list contains 1 additional elements. First extra element 0: 'TCP_KEEPALIVE' - [] + ['TCP_KEEPALIVE'] : New TCP flags were discovered. See bpo-32394 for more information -- It appears that TCP_KEEPALIVE is defined in Windows (in ws2ipdef.h) despite not being documented on https://docs.microsoft.com/en-us/windows/desktop/winsock/ipproto-tcp-socket-options Given that TCP_KEEPIDLE is #define as the value of TCP_KEEPALIVE, I'd guess that it was added at the same time in which case it probably ought to be added to win_runtime_flags for exclusion based on the same Windows version 1709 too. steve.dower: I've added you to the nosy list based on your active participation in #32394. Any thoughts on this one? -- components: +Extension Modules -Library (Lib) nosy: +steve.dower versions: +Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue34932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34932] Add macOS TCP_KEEPALIVE to available socket options
New submission from Robert : macOS uses TCP_KEEPALIVE in place of TCP_KEEPIDLE. It would be good to have this available in the socket library to use directly. Pull request coming up. -- components: Library (Lib) messages: 327351 nosy: llawall priority: normal severity: normal status: open title: Add macOS TCP_KEEPALIVE to available socket options type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24412] setUpClass equivalent for addCleanup
Robert Collins added the comment: Serhiy, thats not a design flaw, its a feature. in a class hierarchy, setup and teardown ordering is undefined: implementors can choose whatever order they want to execute in. e.g. class A(TestCase): def setUp(self): super().setUp() acquire1() class B(A): def setUp(self): acquire2() super().setUp() class C(B): def setUp(self): super().setUp() acquire3() will acquire 2, then 1, then 3. tearDown() is similarly ill defined. Secondly, consider class Example(TestCase): def setUp(self): self._1 = acquire() self.addCleanUp(acquire()) self._3 = acquire() def tearDown(self): self._3.cleanUp() self._1.cleanUp() super().tearDown() As such, there is no ordering of cleanup + teardown that is 'right' in all cases. The question then becomes, which ordering *most facilitates* migration from tearDown to cleanup. The allowable orders are: - with a more complex implementation, per-class (no) - before tearDown starts - after tearDown finishes The common case tearDown tends to look like this: def tearDown(self): super().tearDown() so, by placing doCleanup after tearDown, we make it possible for base classes in a test hierarchy to migrate to cleanups without breaking compatibility with child classes. The cost, as you note is that we make it harder for child classes to migrate until the base class has migrated. But it is strictly better to permit the base class to migrate, because in projects you cannot be sure of all your subclasses out there in the wild, but you can be sure of all your base classes. -- ___ Python tracker <https://bugs.python.org/issue24412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
