Change by Barry A. Warsaw :
--
title: open().write() fails on 2 GB+ data (OS X) -> open().write() and .read()
fails on 2 GB+ data (OS X)
___
Python tracker
<https://bugs.python.org/issu
Barry A. Warsaw added the comment:
Nosying myself since I just landed here based on an internal $work bug report.
We're seeing it with reads. I'll try to set aside some work time to review the
PRs.
--
nosy: +barry
___
Python tracker
<ht
Barry A. Warsaw added the comment:
All I know is that for 3.7 and 3.8 (3.6 is different), I have this little
helper script to build against Homebrew libraries.
#!/bin/sh
export CPPFLAGS="-I$(brew --prefix sqlite3)/include -I$(brew --prefix
zlib)/include"
export LDFLAGS="-L
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue35905>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
New changeset 69091cb497b2f0fe7e2789b30b43cf78caf9de9b by Barry Warsaw (Nina
Zakharenko) in branch 'master':
bpo-35321: Set the spec origin to frozen in frozen modules (#11732)
https://github.com/python/cpython/commit
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue35839>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
versions: +Python 3.6
___
Python tracker
<https://bugs.python.org/issue35321>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue35835>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Jan 22, 2019, at 07:16, Samuel Colvin wrote:
>
> Ok, if I create a PR, should it just remove MailmanProxy completely or mark
> it as deprecated in the docs to be removed in 3.9?
>
> Personally, I think it should be ok to remove it c
Barry A. Warsaw added the comment:
Yes, it should be deprecated and removed. TBH, IMHO smtpd.py should be
entirely deprecated. aiosmtpd (3rd party) is a much more modern approach.
--
___
Python tracker
<https://bugs.python.org/issue35
Barry A. Warsaw added the comment:
I am mentoring Nina so I'll review this.
--
___
Python tracker
<https://bugs.python.org/issue35321>
___
___
Python-bugs-list m
Barry A. Warsaw added the comment:
Frozen module's origin isn't really documented AFAICT. Here's the link to the
library reference:
https://docs.python.org/3/library/importlib.html?highlight=origin#importlib.machinery.ModuleSpec.origin
The language reference doesn't really have anything
Change by Barry A. Warsaw :
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue35321>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
I believe this bug does not affect Python 3.8:
(Using a Python 3.8 virtualenv):
% python demo.pyz
Reading: resource.txt
Length: 19
% python `pwd`/demo.pyz
Reading: resource.txt
Length: 19
I think it's too risky (and too much work, given it would have
Barry A. Warsaw added the comment:
On Jan 14, 2019, at 17:30, STINNER Victor wrote:
>
> I don't think that you will like it, but I feel that a PEP will be needed
> here to list use cases and explain what replace .pth files for each use
> case. Maybe no replacement for some use c
Barry A. Warsaw added the comment:
On Jan 14, 2019, at 07:17, Nick Coghlan wrote:
>
> I'll also reiterate that I am *completely* opposed to deprecating the "append
> entries to sys.path" usage model, as there is absolutely nothing wrong with
> that (if distros are en
Barry A. Warsaw added the comment:
On Jan 14, 2019, at 04:14, Antoine Pitrou wrote:
>
> As I said: editable installs (`pip install -e`) are an important use case of
> .pth files.
Is that true outside of virtual environments? I care less about .pth files
inside venvs, si
Barry A. Warsaw added the comment:
On Jan 14, 2019, at 04:02, STINNER Victor wrote:
>
> I really hate .pth files because the slow down Python startup time for *all*
> applications whereas .pth files are usually specific to a very few
> applications using one or two spec
Barry A. Warsaw added the comment:
> To make a potentially viable concrete proposal here, I think a reasonable
> first step would be to change the ".pth" file processing code in site.py to
> emit PendingDeprecationWarning for the 'if line.startswith(("import &qu
Barry A. Warsaw added the comment:
On Jan 7, 2019, at 03:16, Ronald Oussoren wrote:
>
> Do you know why the namespace package loader lies about the source and code?
> Both .get_source() and .get_code() return a value that isn't None.
> And likewise: Why is the namespace pa
Change by Barry A. Warsaw :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue35673>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On the first point, I'd categorize this as a documentation bug, and in fact,
it's inconsistent with the language reference, which doesn't have the same
language:
https://docs.python.org/3/reference/import.html#__loader__
On the second point, it probably
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue35673>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue35651>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
New changeset 55cc34500e5abbfedb89adc95e3f94d53c544933 by Barry Warsaw (Chris
Rands) in branch 'master':
bpo-35526: make __future__.barry_as_FLUFL mandatory for Python 4.0 (#11218)
https://github.com/python/cpython/commit
Barry A. Warsaw added the comment:
Let's extend the "joke" and make it mandatory in Python 4! :)
--
___
Python tracker
<https://bugs.python.o
Barry A. Warsaw added the comment:
On Dec 12, 2018, at 17:59, Ned Deily wrote:
>
> Ned Deily added the comment:
>
>> Would it be safe to run the multiprocessing tests on recent macOS with the
>> OBJC_DISABLE_INITIALIZE_FORK_SAFETY environment variable set?
>
&g
Barry A. Warsaw added the comment:
I think it make sense to disable this test; the only possible modification
would be to only disable it for macOS <= 10.13. AFAIK, that's the first
version where core dumps were possible. (Aside: I also saw these core dumps
for a long time on 10
Barry A. Warsaw added the comment:
I'm actually fine either way. Consider me a solid ±0
--
___
Python tracker
<https://bugs.python.org/issue34850>
___
___
Pytho
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.framework
Barry A. Warsaw added the comment:
Closing in favor of issue33725
--
stage: -> resolved
status: open -> closed
___
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/issue31818>
___
___
Python-bugs-list m
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue31818>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 abilit
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
<ht
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 the parent
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_proxies() which
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
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: High Sierra hang when using multi-processing -> macOS crashes after fork
with no exec
___
Python tracker
<https://bugs.python.org/issu
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.
--
___
Python tracker
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:
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
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 tracker
<ht
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 pid == 0:
subpid = os.fork
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'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.LoadLibrary('/System/Library
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'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 our
internal projects
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:
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
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
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
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 this is related
Change by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<https://bugs.python.org/issue35181>
___
___
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 differently
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:
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 it isn't on AD
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), I again
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:
% 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:
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 < 22; ++gidsets
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
whatever corporate
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.gz and
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
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]
$
Change by Barry A. Warsaw :
--
title: test_posix -> test_posix fails on macOS 10.14 Mojave
___
Python tracker
<https://bugs.python.org/issue35070>
___
___
Py
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.python.
Change by Barry A. Warsaw :
--
assignee: -> nnja
___
Python tracker
<https://bugs.python.org/issue25812>
___
___
Python-bugs-list mailing list
Unsubscrib
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 :
--
versions: +Python 3.8 -Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue25812>
___
___
Python-bugs-list m
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/5a5ce064b3baadcb79605c5a42ee3d0aee57cdfc
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
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) APIs. It makes
Change by Barry A. Warsaw :
--
nosy: -barry
___
Python tracker
<https://bugs.python.org/issue34694>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :
--
keywords: +patch
pull_requests: +8750
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34632>
___
___
Py
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
components: Library
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/issue25
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; namespac
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
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:
AFAICT, that future only works in the REPL.
--
___
Python tracker
<https://bugs.python.org/issue34084>
___
___
Python-bug
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 site/sitecus
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 strong feelings on the matter
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 should be one
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:
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
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:
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/issue33
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:
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:
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 expose
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 there's no
hash_
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_
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 also
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 attached
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 al
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 expose
201 - 300 of 2236 matches
Mail list logo
