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
Barry A. Warsaw added the comment:
On Jun 14, 2013, at 07:53 PM, Brett Cannon wrote:
>I'll put it into importlib.util.MAGIC.
+1
--
___
Python tracker
<http://bugs.python.org
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18217>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Jun 14, 2013, at 09:27 PM, R. David Murray wrote:
>How would you do dynamic switching of translation locale at runtime, then?
flufl.i18n :)
http://pythonhosted.org/flufl.i18n/
--
___
Python tracker
&l
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 01:00 PM, Eli Bendersky wrote:
>What is the theoretical problem here? I though that it's an explicit design
>goal of enums? Which RED - Color.RED, or MeatReadiness.RED? For sockets:
>
>>>> class SocketType(IntEnu
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 06:45 AM, Ethan Furman wrote:
>To sum up: the name is already available in the name, no need to have it be
>the value as well. I am open to changing the start value to zero instead of
>one (which is what I do in my customization o
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 01:48 PM, Nick Coghlan wrote:
>I created issue 18264 after I tried it and found my theoretical concern
>wasn't theoretical at all: swapping a true integer for the current
>incarnation of enum.IntEnum breaks (at least) JSON
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18264>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 01:45 PM, Nick Coghlan wrote:
>Allowing __str__ to be inherited from Enum rather than from the concrete type
>will similarly break any serialisation protocol that relies on str() to
>handle integers. The float case is even tricki
Barry A. Warsaw added the comment:
On Jun 19, 2013, at 02:09 PM, Eric Snow wrote:
>There's at least one stdlib module that does this pretty well (sqlite3, I
>think). This is where a simple serialization (and deserialization of course)
>protocol would come in handy.
Yeah, my
Barry A. Warsaw added the comment:
It applies cleanly, builds without noticeable problems and does what it's
advertised to do. In other words, looks great to me!
I say go for it.
--
___
Python tracker
<http://bugs.python.org/is
Barry A. Warsaw added the comment:
On Jun 20, 2013, at 02:26 PM, STINNER Victor wrote:
>
>"python -I" and "spython" sound like two ways to get the same results. I
>would prefer to only have one way.
Where does spython come from?
Personally, I'd much rather
Barry A. Warsaw added the comment:
On Jun 21, 2013, at 04:18 PM, Éric Araujo wrote:
>Working with an explicit translator object sounds much better to me too. I
>haven’t used it yet, but Babel has been on my radar for long, and does that
>(like flufl.i18n from what I can tell).
f
Barry A. Warsaw added the comment:
On Jun 22, 2013, at 01:08 AM, Nick Coghlan wrote:
>Can I vote for something like "__builtin__" as the protocol, rather than
>something entirely specific to serialisation? As in "return the most
>appropriate builtin type with the same
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18299>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18312>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18335>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
.dedent() is a no-brainer. JFDI. +1
.indent() I guess makes sense for symmetry, although I've rarely used it. -0
As for docstrings, I can imagine other alternatives, so let's let someone
interested in that go through the P
Barry A. Warsaw added the comment:
On Jul 02, 2013, at 02:12 AM, Nick Coghlan wrote:
>So +1 from me for a -I isolated mode, and I'll adjust PEP 432 as necessary to
>cope.
PEP 394 is probably related to any such additional binary.
--
___
Barry A. Warsaw added the comment:
On Jul 02, 2013, at 07:16 AM, Serhiy Storchaka wrote:
>If most user code should catch a ModuleNotFoundError exception, perhaps it
>will be better rename old ImportError to ImportlibError (or ImportingError,
>or ImportMachineryError, or BaseImportError
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18395>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18394>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Jul 08, 2013, at 11:56 AM, Antoine Pitrou wrote:
>I don't think it's a good idea to maintain a list of hard-coded
>paths in Python: it's not manageable, and it will always become
>outdated. If there was a widely-respected stand
Barry A. Warsaw added the comment:
I clarified the wording.
--
nosy: +barry
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Barry A. Warsaw:
urllib.request.urlopen() takes a `timeout` argument with a default value, but
the default value is "hidden" and undocumented. As implemented, the value is
socket._GLOBAL_DEFAULT_TIMEOUT, but even this isn't really correct or useful.
The p
Barry A. Warsaw added the comment:
Targeting only 3.4 because, while this should no break any (reasonable )
backward compatibility, it is technically an API change and thus should not get
backported.
--
___
Python tracker
<http://bugs.python.
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18422>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
On Jul 10, 2013, at 05:53 AM, R. David Murray wrote:
>Please see issue 14425 and then let us know if this is still valid. It's
>been a while since I looked at the code and I no longer remember the details,
>but I seemed confident in my conclusi
New submission from Barry A. Warsaw:
If you have a custom object that implements __hash__() and it returns a value
wider than Py_ssize_t, built-in hash() on the object will truncate information.
This is because hash() takes the value returned by obj.__hash__() and coerces
it through
Changes by Barry A. Warsaw :
--
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue18440>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue18440>
___
___
Python-bugs-list
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue10434>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Barry A. Warsaw :
--
nosy: +barry
___
Python tracker
<http://bugs.python.org/issue18510>
___
___
Python-bugs-list mailing list
Unsubscribe:
Barry A. Warsaw added the comment:
In general, I like where this is going. I agree that a stdout redirector is
probably the most common case, and for that, it almost always (for me)
redirects to an open file. The use case for stderr redirection is usually,
but not always, to redirect stderr to
New submission from Barry A. Warsaw:
A colleague discovered an interesting implementation different between
C-defined functions and Python-defined functions called with **kws arguments.
He tried to do this:
>>> from collections import defaultdict
>>> '{foo}{bar}&#x
Barry A. Warsaw added the comment:
On Jul 23, 2013, at 04:24 AM, Alexander Belopolsky wrote:
>@contextlib.contextmanager
>def redirect_stdout(stream):
>old_stdout = sys.stdout
>sys.stdout = stream
>yield
>sys.stdout = old_stdout
Make that:
@contextlib.
Barry A. Warsaw added the comment:
On Jul 29, 2013, at 01:55 PM, Antoine Pitrou wrote:
>Perhaps the "placeholder" argument should actually include the last
>whitespace, to allow people to omit the whitespace, or use a non-breaking
>space instead?
>
> >>>
Barry A. Warsaw added the comment:
Comments on the diff.
> -Two good reasons to break a particular rule:
> +Some especially good reasons to ignore a particular guideline:
It's probably enough to just s/Two/Some/ - not sure the 'especially' emphasis
is really needed.
>
1801 - 1900 of 2726 matches
Mail list logo
