New submission from Mike Frysinger :
$ python3
Python 3.8.5 (default, Aug 2 2020, 15:09:07)
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.dom import minidom
# Lets parse a simple XM
Change by Mike Frysinger :
--
title: xml.dom.minidom.Element.ownerDocument is hiden ->
xml.dom.minidom.Element.ownerDocument is hidden
___
Python tracker
<https://bugs.python.org/issu
Change by Mike Frysinger :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
title: xml.dom.minidom.rst missed informations -> xml.dom.minidom.rst missing
standalone documentation
___
Python tracker
Mike Frysinger added the comment:
personally i still like having the extra_env setting explicitly broken out, but
i agree that those operators help ease the majority of the pain. i hadn't come
across them before as they aren't in Python 2.
i wouldn't be upset if people declined the FR
New submission from Mike Frysinger :
a common idiom i run into is wanting to add/set one or two env vars when
running a command via subprocess. the only thing the API allows currently is
inherting the current environment, or specifying the complete environment.
this means a lot of copying
Mike Frysinger added the comment:
this would have been nice to have more than once in my personal projects, and
in build/infra tooling for Chromium OS. our alternatives so far have been the
obvious ones: use subprocess.run to capture & return the output, then manually
Mike Frysinger added the comment:
if threading.active_count() returns 1, then you know there's one thread, and
you're it, so it's not racey, and a lock ins't needed.
thinking a bit more, what if the code just use a recursive lock ? that would
restore the single threaded status quo without
Mike Frysinger added the comment:
to be clear, there is no Python or OS restriction that you're aware of for your
earlier statement ? you just want to make it into a new Popen restriction that
didn't previously exist ?
we came across this bug as we upgraded our existing Python 2.7 codebase
Mike Frysinger added the comment:
> fundamentally: this shouldn't work anyways.
>
> You are calling wait() from a signal handler.
> That is a blocking operation.
> You cannot do that from a signal handler.
what definition/spec are you referring to here ? is this a Python l
Mike Frysinger added the comment:
that's highlighting the SemLock._make_name func which doesn't have retry logic
in it. did you mean to highlight SemLock.__init__ which has a retry loop that
looks similar to the C code ?
https://github.com/python/cpython/blob
Mike Frysinger added the comment:
it does seem like the patch was never applied to any python 3 branch :/
--
___
Python tracker
<https://bugs.python.org/issue24
Mike Frysinger <vap...@users.sourceforge.net> added the comment:
specifically, the docs for these classes:
https://docs.python.org/2/library/urlparse.html#results-of-urlparse-and-urlsplit
https://docs.python.org/3/library/urllib.parse.html#urlparse-result-object
> The result obj
Mike Frysinger added the comment:
i don't feel strongly about either version
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Mike Frysinger:
the ac_cv_have_long_long_format test has a nice compile-time fallback for gcc
based compilers:
CFLAGS="$CFLAGS -Werror -Wformat"
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
#include
#include
]], [[
char *buffer;
Mike Frysinger added the comment:
time to close then ?
--
nosy: +vapier
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19372>
___
__
Mike Frysinger added the comment:
if the current builds fail, please make sure to include the config.log file as
that includes a cross-compile test for this setting
--
nosy: +vapier
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Changes by Mike Frysinger vap...@users.sourceforge.net:
--
nosy: +vapier
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24935
___
___
Python-bugs
Mike Frysinger added the comment:
looks like the patch was reversed, but otherwise should be clear what we're
going for
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24935
Mike Frysinger added the comment:
also, it looks like this bug is in python-3.3. not sure what the status of
that branch is, but maybe the backport from 3.4 would be easy ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Mike Frysinger added the comment:
the original report on our side w/bunches of tracebacks: http://crbug.com/481223
with that traceback in hand, it's pretty trivial to write a reproduction :).
attached!
i couldn't figure out how to make it work w/out completely execing a new python
instance
Mike Frysinger added the comment:
we hit this problem daily in Chromium OS's build farm because we use pid
namespaces heavily
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24303
Changes by Mike Frysinger vap...@users.sourceforge.net:
--
nosy: +vapier
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24303
___
___
Python-bugs
Mike Frysinger added the comment:
this has been fixed between py3.2 and py3.3:
http://hg.python.org/cpython/diff/831ae71d0bdc/Lib/multiprocessing/managers.py
so just asking for that to be backported to the py2.x branch :)
--
nosy: +vapier
___
Python
New submission from Mike Frysinger:
the current configure script open codes the pkg-config look up:
AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
rather than using the standard macro from pkg-config's own pkg.m4:
PKG_PROG_PKG_CONFIG
this causes the build env to not operate exactly like other pkg
Mike Frysinger vap...@users.sourceforge.net added the comment:
a uint64_t would fix it for x86_64, but break it most 32bit systems as
sizeof(unsigned long) == 32bit for them
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
New submission from Mike Frysinger vap...@users.sourceforge.net:
the direct call to the getdents syscall is broken on x32. there, the first two
args are not unsigned long, but unsigned long long. patch attached to fix the
issue.
--
components: Extension Modules
files: python-3.2.3
Mike Frysinger vap...@users.sourceforge.net added the comment:
$ echo | gcc -m32 -E -P -dD - | grep LP
nothing
$ echo | gcc -m64 -E -P -dD - | grep LP
#define _LP64 1
#define __LP64__ 1
$ echo | gcc -mx32 -E -P -dD - | grep LP
#define _ILP32 1
#define __ILP32__ 1
Changes by Mike Frysinger vap...@users.sourceforge.net:
--
nosy: +vapier
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3754
___
___
Python-bugs
Mike Frysinger vap...@users.sourceforge.net added the comment:
i really dont understand your point. python uses autoconf and therefore any
questions about python's usage of autoconf to accomplish cross-compiles is
completely valid here.
no one was asking for general autoconf help
Mike Frysinger vap...@users.sourceforge.net added the comment:
AC_TRY_RUN is already documented:
http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fTRY_005fRUN-1992
there are a bunch of distros out there (like OE and Gentoo) that have
been maintaining cross
Mike Frysinger vap...@users.sourceforge.net added the comment:
Gregory: there's no need to be a dick. i'm pointing out the obvious --
bugs have been open literally for *years* with zero assistance/feedback
from anyone who can actually get things merged. people have posted
patches, but no one
Mike Frysinger vap...@users.sourceforge.net added the comment:
the chflags is specifically documented as needing a runtime test:
# On Tru64, chflags seems to be present, but calling it will
# exit Python
which is why i left the default of AC_TRY_RUN but cross-compile falls
back to a simple link
Mike Frysinger vap...@users.sourceforge.net added the comment:
Garrett: your configure method is overly complicated. all you need to
do is set --build=binos_c3.4.3-p1.mips64-octeon-linux. autoconf will
figure out all the other toolchain settings.
___
Python
33 matches
Mail list logo
