New submission from Barry A. Warsaw :
This looks like a serious regression in 3.7. @ned.deily - I'm marking this as
a release blocker, but feel free of course to downgrade it.
Run the following as
$ python3.6 badconfig.py
Hey, it works!
$ python3.7 badconfig.py
Traceback (most recent
Barry A. Warsaw added the comment:
I think this introduced a regression in 3.7. See bpo-33802
https://bugs.python.org/issue33802
--
keywords: +3.7regression -patch
nosy: +barry
priority: normal -> deferred blocker
resolution: fixed ->
stage: resolved ->
status: close
Barry A. Warsaw added the comment:
I think the regression is caused by the fix for bpo-23835
https://bugs.python.org/issue23835
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +7137
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Barry A. Warsaw :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Barry A. Warsaw :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Barry A. Warsaw added the comment:
This really isn't enough information to know exactly what's going on in your
case, but there are things that are known to be slow for CLI startups.
Probably the biggest contributor is pkg_resources. Of course, that's a third
party library
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue33901>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
"It's complicated" :) But technically speaking they are all separate projects,
so while there is synergy, CPython itself *imports* some of those to provide
various tasks, but it doesn't lead their development. You'll find a lot of
New submission from Barry A. Warsaw :
The _PyCoreConfig structure in pystate.h has some interesting fields that I
don't think are exposed anywhere else to Python-land. I was particularly
interested recently in hash_seed and use_hash_seed. I'm thinking that it may
be useful to e
Barry A. Warsaw added the comment:
On Jun 20, 2018, at 13:28, Christian Heimes wrote:
>
> Christian Heimes added the comment:
>
> hash_seed and use_hash_seed could be added to sys.hash_info. This would be
> the first place I'd look for the information. After all I impl
Barry A. Warsaw added the comment:
I think the basic implementation problem is that by the time you get to
get_hash_info() in sysmodule.c, you no longer have access to the _PyCoreConfig
object, nor the _PyMain object that it's generally attach
New submission from Barry A. Warsaw :
pth files are evil. They are very difficult to debug because they're processed
too early. They usually contain globs of inscrutable code. Exceptions in pth
files can get swallowed in some cases. They are loaded in indeterminate order.
They are
Barry A. Warsaw added the comment:
Thanks for the hint! I had a feeling there had to be an API to get at it, but
I couldn’t find it. Maybe we should start documenting the Python Secret
Underscore API? :)
On Jun 22, 2018, at 00:04, STINNER Victor wrote:
>
> _PyCoreConfig *core_
Barry A. Warsaw added the comment:
I think there's another thing I'd like to change, and it seems like it's "just"
an implementation detail. In _Py_HashRandomization_Init(), if use_hash_seed is
0, then we directly inject the random bits into the buffer, and then th
Barry A. Warsaw added the comment:
Nosying Nick. I agree there's some overlap with Python startup restructuring,
but it feels kind of orthogonal too. I really am only exposing (some elements)
of that structure to Python.
What might be interesting though would be if we want to expos
Barry A. Warsaw added the comment:
We could make the hash_seed 64 bits.
--
___
Python tracker
<https://bugs.python.org/issue33919>
___
___
Python-bugs-list m
Barry A. Warsaw added the comment:
There are lots of problems with pth files, although arbitrary code execution is
probably the most egregious. They are also notoriously difficult to debug, and
happen before any control is given to user code. They certainly are
unnecessary for namespace
Barry A. Warsaw added the comment:
Although I guess that would require modifications to lcg_urandom(). I don't
feel qualified to change that function.
--
___
Python tracker
<https://bugs.python.org/is
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +7475
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Barry A. Warsaw added the comment:
On Jun 23, 2018, at 18:56, Nick Coghlan wrote:
>
> My request (wearing my "BDFL-delegate for packaging interoperability
> standards" hat) is that proponents of the change resist the temptation to
> view the problem that way :)
&g
Barry A. Warsaw added the comment:
On Jun 23, 2018, at 20:21, Nick Coghlan wrote:
>
> Only exposing a `forced_hash_seed` (and hiding randomly generated ones as
> `forced_hash_seed=None`) seems reasonable though, since those can already be
> read from os.environ anyway.
On
Barry A. Warsaw added the comment:
I think we'll clearly need a PEP for this clean up. I'd like to see a separate
"preload" feature as well, especially one that is deterministic and happens
before site.py. Not sure if that shou
Barry A. Warsaw added the comment:
It's a convenient API. I think originally I may have just don't effectively a
getattr on the imported module, but I don't remember (and don't have original
implementation handy - thanks, rebase!)
I don't have particularly stro
Barry A. Warsaw added the comment:
On Jul 5, 2018, at 14:23, Ivan Pozdeev wrote:
>
> Ivan Pozdeev added the comment:
>
>> They are very difficult to debug because they're processed too early.
>
> .pth's are processed by site.py, so no more difficult than si
Barry A. Warsaw added the comment:
AFAICT, that future only works in the REPL.
--
___
Python tracker
<https://bugs.python.org/issue34084>
___
___
Python-bug
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue34296>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Agreed it should be non-public, but can we please call it sys._is_interned()?
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue34
Barry A. Warsaw added the comment:
https://docs.python.org/3/reference/import.html#regular-packages
Regular packages have __init__.py files and namespace packages do not.
"Implicit non-namespace packages" aren't really A Thing.
This design choice is deliberate; nam
Barry A. Warsaw added the comment:
Not sure if I'll have time before the core sprints to check the implementation
with shiv, but I can give it a try then. Do you mind waiting until then?
--
___
Python tracker
<https://bugs.python.org/is
New submission from Barry A. Warsaw :
https://importlib_metadata.rtfd.org
We're fleshing out the API and implementation in the standalone library, but
once we're confident of the API and semantics, we will want to port this into
Python 3.8.
--
assignee: barry
component
Change by Barry A. Warsaw :
--
keywords: +patch
pull_requests: +8750
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34632>
___
___
Py
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue34726>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: -barry
___
Python tracker
<https://bugs.python.org/issue34694>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
Hi Serhiy. I'm curious whether this is a pure clean up or if there are actual
problems you're trying to fix.
* I'm okay with using _PyObject_GetBuiltin() but it does bother me in general
to use too many non-public (and thus undocumented)
Barry A. Warsaw added the comment:
New changeset 5a5ce064b3baadcb79605c5a42ee3d0aee57cdfc by Barry Warsaw (Zackery
Spytz) in branch 'master':
bpo-5950: Support reading zips with comments in zipimport (#9548)
https://github.com/python/cpython/commit/5a5ce064b3baadcb79605c5a42ee3d
Change by Barry A. Warsaw :
--
components: +Library (Lib) -Interpreter Core
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.o
Change by Barry A. Warsaw :
--
versions: +Python 3.8 -Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue25812>
___
___
Python-bugs-list m
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue25812>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
assignee: -> nnja
___
Python tracker
<https://bugs.python.org/issue25812>
___
___
Python-bugs-list mailing list
Unsubscrib
Barry A. Warsaw added the comment:
This is a nice approach to the problem. I completely agree that we cannot
change `is` semantics. I'm okay with leaving it to checkers to catch `== None`.
--
___
Python tracker
<https://bugs.py
Change by Barry A. Warsaw :
--
title: test_posix -> test_posix fails on macOS 10.14 Mojave
___
Python tracker
<https://bugs.python.org/issue35070>
___
___
Py
New submission from Barry A. Warsaw :
It looks like macOS 10.14 Mojave has changed the return value for getgroups().
On 10.13 it returns the set of GIDs give by `id -G` but afaict on 10.14 it
returns only the primary GID.
$ python3 -c "import os; print(os.getgroups())"
[101]
$
Barry A. Warsaw added the comment:
Seems to fail for me with every version of Python 3 on Mojave. In master, it’s
test_getgroups().
> Ned Deily added the comment:
>
> $ sw_vers
> ProductName: Mac OS X
> ProductVersion: 10.14
> BuildVersion: 18A391
Mine i
Barry A. Warsaw added the comment:
On Oct 25, 2018, at 13:17, Ned Deily wrote:
>
> OK. When you asy "every version of Python 3", are those all versions you've
> built yourself? If so, what ./configure arguments do you use?
Yes, built myself from source (both .tar.g
Barry A. Warsaw added the comment:
We're wondering if it could be a weird interaction with Active Directory. This
is my work laptop, so it's all integrated with LDAP and whatnot. I don't have
Mojave on my personal laptop yet (maybe this weekend). I'm guessing that
Barry A. Warsaw added the comment:
Yes, I've rebooted :) I've modified your C program a little and here's the
code and output.
#include
#include
#include
int main()
{
gid_t grouplist[32];
int n;
int gidsetsize;
for (gidsetsize = 0; gidsetsize <
Barry A. Warsaw added the comment:
% gcc -v gg.c
Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Con
Barry A. Warsaw added the comment:
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv
-O3 -Wall -v -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter
-Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-function-declaration -I. -I
Barry A. Warsaw added the comment:
I really have no idea what's going on. I've looked at posixmodule.c and tried
to reproduce as best I can in a standalone C program.
In both cases getgroups(0, NULL) returns 15. In the standalone version, when I
then call getgroups(15, grouplist
Barry A. Warsaw added the comment:
Yep, stepping through Python with lldb, that's what's happening. I know one of
my coworkers has been able to reproduce it. I'll chime in next once I upgrade
my personal machine and can try it there, since I know
Barry A. Warsaw added the comment:
Wonderful
--
___
Python tracker
<https://bugs.python.org/issue35070>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I've now updated my personal machine to Mojave and cannot reproduce the
failure. I'm going to chalk this one up to some weird corporate active
directory or whatnot weirdness. I'd still love to know why the code in Python
works diffe
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue35181>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Barry A. Warsaw :
As we're beginning to roll out macOS 10.14 High Sierra, we're seeing an
increase in core files inside /cores. This can consume a ton of disk space if
you have coredumps enabled. I don't have a short reproducer yet, but we
believe thi
Change by Barry A. Warsaw :
--
title: macOS 10.14 High Sierra crashes in multiprocessing -> macOS 10.14 Mojave
crashes in multiprocessing
___
Python tracker
<https://bugs.python.org/issu
Barry A. Warsaw added the comment:
That should of course be 10.14 Mojave.
--
___
Python tracker
<https://bugs.python.org/issue35219>
___
___
Python-bugs-list m
Barry A. Warsaw added the comment:
On Nov 12, 2018, at 13:34, Pablo Galindo Salgado wrote:
> Apparently setting the env variable OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES
> should fix some fork-related changes. Have you tried already doing this? Does
> it change the behaviour of t
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue33725>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I'm not sure whether it's a duplicate or not, since in my case it doesn't hang,
but instead core dumps. It's seems like the reasoning given in the Ruby bug is
relevant to Python too, so maybe we should adopt the same workaround. For ou
Barry A. Warsaw added the comment:
On Nov 10, 2018, at 04:50, Ivan Pozdeev wrote:
> In its .pth file, each such package will import the hook's module (which will
> cause the hook to be installed on the first import) and "register" its
> namespaces and/or dependencie
Barry A. Warsaw added the comment:
I've done a fair bit of testing and it seems rather inconsistent as to whether
either of these work when added right before an explicit call to `os.fork()`:
os.environ['OBJC_DISABLE_INITIALIZE_FORK_SAFETY'] = 'YES'
ctyles.cdll.Loa
Barry A. Warsaw added the comment:
Based on my testing, the environment variable has to be set before the parent
process starts. Neither os.environ nor os.putenv seem to do the trick.
--
___
Python tracker
<https://bugs.python.org/issue35
Barry A. Warsaw added the comment:
I'm still testing this solution, but it looks like if you set the environment
variable, and then double fork, the granchild won't crash. Roughly:
os.putenv('OBJC_DISABLE_INITIALIZE_FORK_SAFETY', 'YES')
pid = os.fork()
if
Barry A. Warsaw added the comment:
Nope, actually double fork doesn't work. It's misleading because in my
testing, the first invocation of the process causes the core dump, but
subsequent runs do not.
--
___
Python track
Barry A. Warsaw added the comment:
I am going to dupe this to 33725 after all.
--
resolution: -> duplicate
superseder: -> High Sierra hang when using multi-processing
___
Python tracker
<https://bugs.python.org/i
Change by Barry A. Warsaw :
--
versions: +Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue33725>
___
___
Python-bugs-list m
Barry A. Warsaw added the comment:
issue35219 is where I've run into this problem. I'm still trying to figure out
all the details in my own case, but I can confirm that setting the environment
variable does not always help.
--
___
Pyth
Change by Barry A. Warsaw :
--
title: High Sierra hang when using multi-processing -> macOS crashes after fork
with no exec
___
Python tracker
<https://bugs.python.org/issu
Change by Barry A. Warsaw :
--
title: macOS crashes after fork with no exec -> Pytho crashes on macOS after
fork with no exec
___
Python tracker
<https://bugs.python.org/issu
Change by Barry A. Warsaw :
--
title: Pytho crashes on macOS after fork with no exec -> Python crashes on
macOS after fork with no exec
___
Python tracker
<https://bugs.python.org/issu
Barry A. Warsaw added the comment:
Hoo boy. I'm not sure I have the full picture, but things are starting to come
into focus. After much debugging, I've narrowed down at least one crash to
urllib.request.getproxies(). On macOS (darwin), this ends up calling
_scproxy.get_proxi
Barry A. Warsaw added the comment:
A few other things I don't understand:
* Why does setting OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES only seem to work
when it's set in the shell before the parent process executes? AFAICT, it does
*not* work if you set that in os.environ in
Barry A. Warsaw added the comment:
FWIW, I suspect that setting the environment variable only helps if it's done
before the process starts. You cannot set it before the fork and have it
affect the child.
--
___
Python tracker
&
Barry A. Warsaw added the comment:
On Nov 14, 2018, at 10:11, Davin Potts wrote:
>
>
> Davin Potts added the comment:
>
> Barry's effort as well as comments in other links seem to all suggest that
> OBJC_DISABLE_INITIALIZE_FORK_SAFETY is not comprehensive in its a
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31818>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
versions: +Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue31818>
___
___
Python-bugs-list m
Barry A. Warsaw added the comment:
Closing in favor of issue33725
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Barry A. Warsaw added the comment:
I have a reliable way to call *something* in the pthread_atfork prepare
handler, but I honestly don't know what to call to prevent the crash.
In the Ruby thread, it seemed to say that you could just dlopen
/System/Library/Frameworks/Foundation.fram
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18065>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On May 26, 2013, at 12:37 PM, Mark Lawrence wrote:
>Barry, would you like to follow up on this?
My personal interest in this has waned, since I try to avoid 2to3 like the
plague. ;)
--
___
Python tracker
&l
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18093>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue13647>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue13655>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18128>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
It's probably worth changing. My only concern would be backwards compatibility
issues.
--
___
Python tracker
<http://bugs.python.org/is
Barry A. Warsaw added the comment:
While it's true that it can be confusing to users, it's not a bug.
http://docs.python.org/2/reference/compound_stmts.html#function
and a nice treatise on the subject by the Effbot:
http://effbot.org/zone/default-values.htm
--
no
Barry A. Warsaw added the comment:
The changes to smtpd.py seem reasonable to me. I see no reason not to make
this change, so +1.
--
___
Python tracker
<http://bugs.python.org/issue11
Barry A. Warsaw added the comment:
In a somewhat similar vein, replace_header() retains the original header order.
Not quite what the OP wants, but useful.
The problem I had originally with a position-aware method is getting the API
right. I didn't want to add a position argume
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18163>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18162>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18166>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18165>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
+1 for the decorator!
--
___
Python tracker
<http://bugs.python.org/issue18042>
___
___
Python-bugs-list mailing list
Unsub
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18042>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Jun 11, 2013, at 08:47 PM, Brett Cannon wrote:
>To facilitate deprecating imp, need to move imp.source_from_cache() and
>cache_from_source() to importlib.util or as static methods on
>importlib.machinery.SourceLoader.
+1 for importlib.util. They
Barry A. Warsaw added the comment:
On Jun 11, 2013, at 08:44 PM, Brett Cannon wrote:
>As part of deprecating imp, need to move imp.get_magic() to importlib where
>it now belongs. Will be exposed as an attribute instead of a function,
>though.
so, importlib.magic ?
--
nos
Barry A. Warsaw added the comment:
I'd like to see it be more easily accessible.
--
___
Python tracker
<http://bugs.python.org/issue18192>
___
___
Pytho
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18198>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
The only argument I have about it is that if someone *does* want to use, it
should be fairly easily discoverable. Also, since it's a concrete value, it
seems a little weird that it's stashed in an abc.
I suppose importlib.machinery.MAGIC is b
1501 - 1600 of 2574 matches
Mail list logo
