[issue44452] Allow paths to be joined without worrying about a leading slash
Zbyszek Jędrzejewski-Szmek added the comment:
> I can see the need for generalized 'drive' support that sets an arbitrary
> path prefix as the 'drive'. For example, if "/var/tmp/instroot" is a 'drive',
> then joining it to "/some/path" returns "/var/tmp/instroot/some/path".
> However, subsequently joining that result to "/suffix" would return
> "/var/tmp/instroot/suffix".
I think that the "drive concept" only makes sense on Windows. With POSIX paths,
the expectation is that you can concatenate paths recursively, and consistency
is much more useful than the drive concept.
One special case where you might concat multiple levels of paths is when the
paths are generated through some configuration mechanism, and an occasional
absolute path might sneak in, but we still want to use the same "relative"
concatenation.
For example:
def path_to_some_binary_in_container(container, usr_merge_was_done=True):
"""Construct a path with support for systems with /usr/bin and legacy systems
with /bin (https://fedoraproject.org/wiki/Features/UsrMove).
"""
path_to_containers = '/var/lib/machines'
prefix = 'usr/' if usr_merge_was_done else '/'
suffix = 'bin/some-binary'
return path_to_containers / container / prefix / suffix
path_to_some_binary('cont1') returns
PosixPath('/var/lib/machines/cont1/usr/bin/some-binary'), but
path_to_some_binary('cont1', False) returns PosixPath('/bin/some-binary'). The
"bug" is that '/' was used instead of ''. This is exactly the
pitfall that I want to avoid:
return path_to_containers // container // prefix // suffix
will do the expected thing.
--
___
Python tracker
<https://bugs.python.org/issue44452>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44452] Allow paths to be joined without worrying about a leading slash
Zbyszek Jędrzejewski-Szmek added the comment:
> It doesn't make sense to "concatenate" one absolute path to another.
Please see the original description of the issue, or Serhiy's example. I was
thinking about about a case where paths are resolved relative to a container
root in a filesystem. Serhiy brings up the case of a web server which
concatenates paths from one namespace (URLs) to paths from another (fs paths).
> / has a simple explanation: if you start at /foo, and then do cd bar, you'll
> end up in /foo/bar. But if you start at /foo, and then do cd /bar, you'll end
> up in /bar.
You are thinking about a user doing operations in a shell. The two cases
described are precisely NOT like this. In both examples, no matter what the
path is, it is not allowed to go above the "root of the namespace". I.e. if you
start at "/foo", and concatenate "/bar", you end up in "/foo/bar". If you are
looking up "https://example.com/some/path;, you want "/srv/www/some/path", etc.
> what to do with C:\foo\bar, C:foo\bar, \\?\c\foo\bar, etc?
I think that with those paths there is no solution. They already don't work in
any reasonable way:
>>> pathlib.Path('/asdf') / ("C:/some/path")
>>>
PosixPath('/asdf/C:/some/path')
>>> pathlib.Path('C:\\asdf') / ("C:/some/path")
>>>
PosixPath('C:\\asdf/C:/some/path')
Windows paths make no sense in the context of combination of namespaces and
path concatenation, so I think it's fine to keep current behaviour (whatever it
exactly is) for them. While the UNIX paths were designed to allow arbitrary
nesting, the Windows paths were designed to always allow per-volume operations.
The two concepts cannot be combined.
> In any case you need to have some validation to disallow "..".
Yes, that is a good point. In my code I do some validation that disallows ".."
early on. But I think that the hypothetical //-operator should reject paths
with "..".
> But lstrip('/') works well here.
It kind of does, but
- it's rather verbose
- it breaks the order, because it's on the right of the argument.
I'll write to python-ideas.
--
___
Python tracker
<https://bugs.python.org/issue44452>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44452] Allow paths to be joined without worrying about a leading slash
New submission from Zbyszek Jędrzejewski-Szmek :
pathlib.Path.__truediv__(), i.e. pathlib.Path.joinpath() is surprising when the
second argument starts with a slash.
>>> pathlib.Path('/foo') / '/bar'
>>> PosixPath('/bar')
I know that this follows the precedent set by os.path.join(), and
probably makes sense in some scenarios. But for the general operation
of "concatenating paths", it doesn't fit very well. In particular,
when concatenating multiple components this becomes even stranger:
>>> pathlib.Path('/var/tmp/instroot') / '/some/path' / '/suffix'
>>> PosixPath('/suffix')
In my particular use case, I'm concatenating some user specified paths
relative to some root. The paths may or may not be absolute.
To avoid this pitfall, something like this is necessary:
>>> pathlib.Path('/var/tmp/instroot') / p.lstrip('/') / q.lstrip('/')
Please provide a way to do this natively. I think it'd be nice to
use // or + for this:
>>> pathlib.Path('/var/tmp/instroot') // '/some/path' // '/suffix'
>>> PosixPath('/var/tmp/instroot/some/path/suffix')
--
components: Library (Lib)
messages: 396058
nosy: zbysz
priority: normal
severity: normal
status: open
title: Allow paths to be joined without worrying about a leading slash
type: behavior
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue44452>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41531] Python 3.9 regression: Literal dict with > 65535 items are one item shorter
Zbyszek Jędrzejewski-Szmek added the comment: Bisect says 8a4cd700a7426341c2074a2b580306d2d60ec839 is the first bad commit. Considering that 0x appears a few times in that patch, that seems plausible ;) -- ___ Python tracker <https://bugs.python.org/issue41531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41531] Python 3.9 regression: Literal dict with > 65535 items are one item shorter
Zbyszek Jędrzejewski-Szmek added the comment: Also reproduces with today's git. -- nosy: +zbysz ___ Python tracker <https://bugs.python.org/issue41531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41193] traceback when exiting on read-only file system
Zbyszek Jędrzejewski-Szmek added the comment: Wow, that was quick. Thanks! -- ___ Python tracker <https://bugs.python.org/issue41193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41193] traceback when exiting on read-only file system
Change by Zbyszek Jędrzejewski-Szmek : -- nosy: +asottile ___ Python tracker <https://bugs.python.org/issue41193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41193] traceback when exiting on read-only file system
New submission from Zbyszek Jędrzejewski-Szmek : [Originally reported as https://bugzilla.redhat.com/show_bug.cgi?id=1852941.] $ touch ~/foo touch: cannot touch '/home/fedora/foo': Read-only file system $ python Python 3.9.0b3 (default, Jun 10 2020, 00:00:00) [GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ^D Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/lib64/python3.9/site.py", line 462, in write_history readline.write_history_file(history) OSError: [Errno 30] Read-only file system Looking at /usr/lib64/python3.9/site.py, it already silently skips PermissionError. If a user is running with the file system in ro mode, they almost certainly are aware of the fact, since this is done either on purpose or as a result of disk corruption, and the traceback from python is not useful. Suppression of PermissionError was added in b2499669ef2e6dc9a2cdb49b4dc498e078167e26. Version-Release number of selected component (if applicable): python3-3.9.0~b3-1.fc33.x86_64 -- messages: 372832 nosy: zbysz priority: normal severity: normal status: open title: traceback when exiting on read-only file system versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34033] distutils is not reproducible
Change by Zbyszek Jędrzejewski-Szmek : -- nosy: +zbysz ___ Python tracker <https://bugs.python.org/issue34033> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Zbyszek Jędrzejewski-Szmek added the comment: If you can import the module that defines the parser, and get at the generated parser, this should be trivial to integrate with the build system. Something like: PYTHONPATH=. python3 -c 'import mymodule; p=mymodule.make_parser(); p.print_manpage(file="mymodule.1")' This operation could either be done automatically during build always, or it could just be done by the developers and the man page put under version control. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Changes by Zbyszek Jędrzejewski-Szmek <zbys...@in.waw.pl>: -- nosy: +zbysz ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: Updated version (based on issue-23725.patch from rbcollins): - move tempdir description at the end of the main section, before Examples - do not add my name second time in ACKS -- Added file: http://bugs.python.org/file40122/issue-23725.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: I don't think tempdir should be removed. I just think it should not be used. So what about moving the description of tempdir to the end, as it was in the last patch, but calling the section Other functions and variables. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
Zbyszek Jędrzejewski-Szmek added the comment:
Oh, for the record, the build failure:
building 'time' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-Werror=declaration-after-statement -I../Include -I. -IInclude
-I/usr/local/include -I/home/zbyszek/python/cpython/Include
-I/home/zbyszek/python/cpython/build -c
/home/zbyszek/python/cpython/Modules/timemodule.c -o
build/temp.linux-x86_64-3.6/home/zbyszek/python/cpython/Modules/timemodule.o
/home/zbyszek/python/cpython/Modules/timemodule.c: In function ‘time_strftime’:
/home/zbyszek/python/cpython/Modules/timemodule.c:656:9: error: unknown type
name ‘_Py_BEGIN_SUPPRESS_IPH’
_Py_BEGIN_SUPPRESS_IPH
^
/home/zbyszek/python/cpython/Modules/timemodule.c:656:9: error: ISO C90 forbids
mixed declarations and code [-Werror=declaration-after-statement]
/home/zbyszek/python/cpython/Modules/timemodule.c:658:9: error:
‘_Py_END_SUPPRESS_IPH’ undeclared (first use in this function)
_Py_END_SUPPRESS_IPH
^
/home/zbyszek/python/cpython/Modules/timemodule.c:658:9: note: each undeclared
identifier is reported only once for each function it appears in
/home/zbyszek/python/cpython/Modules/timemodule.c:662:9: error: expected ‘;’
before ‘if’
if (buflen 0 || i = 256 * fmtlen) {
^
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24664
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
New submission from Zbyszek Jędrzejewski-Szmek: I'm not sure if I'm doing something wrong, because other people should be seeing this too... Anyway, attached patch fixes the issue for me. -- components: Interpreter Core, Library (Lib) files: 0001-Always-define-_Py_-_SUPPRESS_IPH-macros.patch keywords: patch messages: 246910 nosy: zbysz priority: normal severity: normal status: open title: build failure with _Py_BEGIN_SUPPRESS_IPH undefined versions: Python 3.6 Added file: http://bugs.python.org/file39947/0001-Always-define-_Py_-_SUPPRESS_IPH-macros.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
Zbyszek Jędrzejewski-Szmek added the comment: Indeed, make distclean fixes the problem. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Changes by Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file39104/tempfile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: Replying to review here... I get 500 server error in the patch review reply dialogue :( On 2015/04/15 02:40:14, r.david.murray wrote: http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst File Doc/library/tempfile.rst (left): http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#oldcode55 Doc/library/tempfile.rst:55: :keyword:`with` statement, just like a normal file. Why did you remove this statement? It is redundant. The fact that this can be used as CM is already mentioned in the introduction and in the description of TemporaryFile. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst File Doc/library/tempfile.rst (right): http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode25 Doc/library/tempfile.rst:25: The need to use the insecure :func:`mktemp` function is eliminated. How about we get even more radical. Let's eliminate the mention of mktemp from the documentation, except for a Deprecated Functions section at the end, where we explain that it is deprecated because it is insecure and anything you could do with it you can do with the un-deprecated functions. Agreed. I'll submit a new version which removes all the historical notes and adds a Deprecated section at the end for tempdir and mktemp. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode27 Doc/library/tempfile.rst:27: instead a string of six random characters is used. Let's likewise eliminate the mention of the process id, and just leave the explanation that six random characters are used. OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode31 Doc/library/tempfile.rst:31: directories. It is no longer necessary to use the global *tempdir* variable. The global tempdir variable can likewise be moved to the deprecated section and removed from mention here. OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode42 Doc/library/tempfile.rst:42: collected). Under Unix, the directory entry for the file is either not created at all or removed or is removed OK. http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode247 Doc/library/tempfile.rst:247: There should be another blank line here. v5: - relegate `tempdir` and `mktemp` descriptions to 'Deprecated functions and variables' section at the end. This requires moving some descriptions around. - add missing is pointed out in review - add missing 's' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: v6: - add newline -- Added file: http://bugs.python.org/file39112/tempfile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: Ping? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: v2: - remove reflows - update TemporaryDirectory description too - do not call things which are not functions functions - with O_TMPFILE the file is not unlinked, also update TemporaryFile description for that - link to Examples -- Added file: http://bugs.python.org/file38634/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: Please start sentences with capital letters, specifically “mkstemp() and mkdtemp() are lower-level functions . . .”. This would make the sentence more convoluted... I think that with markup it is pretty clear that this is a function name and the lowercase letter it not misleading. The new sentence at the top about context managers seems out-of-place. Perhaps something like “They can also be used as context managers, which triggers the cleanup on exit.” The two sentences are merged now. The new paragraph about cleanup of TemporaryFile is good, but I think it now makes the last sentence of that entry redundant: “. . . can be used in a ‘with’ statement . . .” Yes, removed. v3: - remove sentence “. . . can be used in a ‘with’ statement . . .” - merge two senteces in first paragraph -- Added file: http://bugs.python.org/file38640/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] update tempfile docs to say that TemporaryFile is secure
Zbyszek Jędrzejewski-Szmek added the comment: Actually they are not classes, so the proposed wording cannot be used. But indeed it sounds better with the and. v4: - one more and -- Added file: http://bugs.python.org/file38643/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23725] [PATCH] update tempfile docs to say that TemporaryFile is secure
New submission from Zbyszek Jędrzejewski-Szmek: tempfile docs can use some refreshing. -- components: Library (Lib) files: 0001-docs-update-description-of-TemporaryFile-and-tempfil.patch keywords: patch messages: 238713 nosy: zbysz priority: normal severity: normal status: open title: [PATCH] update tempfile docs to say that TemporaryFile is secure versions: Python 3.5 Added file: http://bugs.python.org/file38608/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23725 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22345] https://docs.python.org/release/1.4/ returns 403
New submission from Zbyszek Jędrzejewski-Szmek: This is the last link on https://www.python.org/doc/versions/. -- assignee: docs@python components: Documentation messages: 226457 nosy: docs@python, zbysz priority: normal severity: normal status: open title: https://docs.python.org/release/1.4/ returns 403 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22345 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21071] struct.Struct.format is bytes, but should be str
New submission from Zbyszek Jędrzejewski-Szmek:
In Python 2, Struct.format used to be a str. In Python 3 it is bytes, which is
unexpected.
Why do I expect .format to be a string:
- This format is pretty much the same as a {}-format - plain text
- according to documentation it is composed of things like characters from a
closed set '.=@hi...', a subset of ASCII,
- it is always called format string in the documentation
Why is this a problem:
- If I use a str format in constructor, I expect to get a str format,
- Comparisons are broken:
struct.Struct('x').format == 'x'
False
struct.Struct('x').format[0] == 'x'
False
- doctests are broken
struct.Struct('x').format
'x' # in Python 2
b'x' # in Python 3
--
components: Library (Lib)
messages: 214903
nosy: zbysz
priority: normal
severity: normal
status: open
title: struct.Struct.format is bytes, but should be str
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21071
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21071] struct.Struct.format is bytes, but should be str
Zbyszek Jędrzejewski-Szmek added the comment: Maybe a flag param for the constructor? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21071 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17429] platform.platform() can throw Unicode error
Zbyszek Jędrzejewski-Szmek added the comment: At least for /etc/os-release, which is slated to replace /etc/fedora-release and other distribution specific files, the encoding in mandated to be UTF-8: http://www.freedesktop.org/software/systemd/man/os-release.html All strings should be in UTF-8 format, and non-printable characters should not be used. -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17429 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17380] initproc return value is unclear
Zbyszek Jędrzejewski-Szmek added the comment: On Fri, Mar 08, 2013 at 02:30:18PM +, Amaury Forgeot d'Arc wrote: Amaury Forgeot d'Arc added the comment: The return value for error conditions should be -1. - typeobject.c checks with 0 - in _iomodule.c, there is == -1 - and pygobject/gobject/gobjectmodule.c just does:: if (...tp_init(...)) PyErr_Print(); That's not very nice. Would it make sense to unify those checks, e.g. for initproc() 0? Than the documentation could be updated. Zbyszek -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17380 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17380] initproc return value is unclear
New submission from Zbyszek Jędrzejewski-Szmek:
initproc is declared to return an int, but what returned values mean is not
documented. Noddy_init in
http://docs.python.org/3/extending/newtypes.html?highlight=initproc#adding-data-and-methods-to-the-basic-example
can be seen to return 0 on success and -1 on error, but that's about it.
Also, when I wrote a function which return 1 on error, on every second
invocation the exception would be ignored:
static int Reader_init(Reader *self, PyObject *args, PyObject *keywds)
{
...
if (flags path) {
PyErr_SetString(PyExc_ValueError, cannot use both flags and path);
return 1;
}
...
}
obj(123, '/tmp')
obj(123, '/tmp')
...
ValueError
obj(123, '/tmp')
obj(123, '/tmp')
...
ValueError
I'm not sure how to interpret this since I couldn't find the documentation for
the expected value.
--
assignee: docs@python
components: Documentation, Extension Modules
messages: 183689
nosy: docs@python, zbysz
priority: normal
severity: normal
status: open
title: initproc return value is unclear
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17380
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15847] parse_args stopped accepting tuples
New submission from Zbyszek Jędrzejewski-Szmek: After recent change (78307 '#13922: argparse no longer incorrectly strips '--' after the first one.'), parse_args stopped working with a tuple argument. It is easy to pass tuple to argparse by using positional function arguments: def f(*args): parser.parse_args(args) This will fail, because args is a tuple. It is necessary to have at least one positional argument to trigger the bug. -- components: Library (Lib) files: argparse_parse_args_tuple.diff keywords: patch messages: 169695 nosy: bethard, r.david.murray, zbysz priority: normal severity: normal status: open title: parse_args stopped accepting tuples type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file27095/argparse_parse_args_tuple.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15847] parse_args stopped accepting tuples
Zbyszek Jędrzejewski-Szmek added the comment: On Sun, Sep 02, 2012 at 02:42:34PM +, R. David Murray wrote: R. David Murray added the comment: I wonder if this is problematic enough that it should be treated as a regression and fixed in the next RC? I believe yes, because I've already hit it in two different projects. It is also causes susceptible programs to fail completely. Zbyszek -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15847] parse_args stopped accepting tuples
Changes by Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file27103/argparse_parse_args_tuple.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15847] parse_args stopped accepting tuples
Changes by Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file27095/argparse_parse_args_tuple.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15847] parse_args stopped accepting tuples
Zbyszek Jędrzejewski-Szmek added the comment:
Thanks for noticing. Replaced patch with the ('x') - ('x',) bugfix.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15847
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14854] faulthandler: fatal error with SystemError: null argument to internal routine
Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl added the comment: A new version of the tests: one for 'python -X faulthandler', one for 'PYTHONFAULTHANDLER=1 python'. This one sets the environment properly for the second test, but is slightly more invasive. Both tests fail without Antoine's patch, and both succeed when it is applied. -- Added file: http://bugs.python.org/file25653/issue14854_faulthandler_tests.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14854] faulthandler: segfault with SystemError: null argument to internal routine
New submission from Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl: Simply running './python -X faulthandler' in the source directory gives me this: % ./python -X faulthandler Fatal Python error: Py_Initialize: can't initialize faulthandler SystemError: null argument to internal routine [1]25118 abort (core dumped) ./python -X faulthandler % gdb ./python core Core was generated by `./python -X faulthandler'. Program terminated with signal 6, Aborted. #0 0x7f52d7ff9475 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x7f52d7ff9475 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7f52d7ffc6f0 in *__GI_abort () at abort.c:92 #2 0x004bc984 in Py_FatalError (msg=0x5b3750 Py_Initialize: can't initialize faulthandler) at Python/pythonrun.c:2283 #3 0x004b85ed in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:361 #4 0x004b86ea in Py_Initialize () at Python/pythonrun.c:398 #5 0x004d55a6 in Py_Main (argc=3, argv=0x1b8f010) at Modules/main.c:624 #6 0x0041b120 in main (argc=3, argv=0x7fffc1ebb558) at ./Modules/python.c:65 (gdb) #0 0x7f52d7ff9475 in *__GI_raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x7f52d7ffc6f0 in *__GI_abort () at abort.c:92 #2 0x004bc984 in Py_FatalError (msg=0x5b3750 Py_Initialize: can't initialize faulthandler) at Python/pythonrun.c:2283 #3 0x004b85ed in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:361 #4 0x004b86ea in Py_Initialize () at Python/pythonrun.c:398 #5 0x004d55a6 in Py_Main (argc=3, argv=0x1b8f010) at Modules/main.c:624 #6 0x0041b120 in main (argc=3, argv=0x7fffc1ebb558) at ./Modules/python.c:65 -- messages: 161097 nosy: haypo, zbysz priority: normal severity: normal status: open title: faulthandler: segfault with SystemError: null argument to internal routine ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14854] faulthandler: fatal error with SystemError: null argument to internal routine
Changes by Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl: -- title: faulthandler: segfault with SystemError: null argument to internal routine - faulthandler: fatal error with SystemError: null argument to internal routine ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14854] faulthandler: fatal error with SystemError: null argument to internal routine
Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl added the comment: I can confirm that it works with the patch. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14854] faulthandler: fatal error with SystemError: null argument to internal routine
Zbyszek Jędrzejewski-Szmek zbys...@in.waw.pl added the comment: % PYTHONFAULTHANDLER=1 ./python -E -c 'import faulthandler; faulthandler._sigsegv()' [3]14516 segmentation fault (core dumped) Unless I'm missing something, the env. var. is not working as documented. Patch with two tests is attached: the first does 'python -X faulthandler ...' and passes after Antoine's patch, the second does 'PYTHONFAULTHANDLER=YesPlease python ...' and does not pass. -- keywords: +patch Added file: http://bugs.python.org/file25640/issue14854_faulthandler_tests.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14854 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
