[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/t

[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

[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 s

[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 <ht

[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> ___ ___

[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 m

[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 Unsub

[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

[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:

[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

[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> ___

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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