Mouse added the comment:
The fix applied for this problem actually broke multiprocessing on MacOS. The
change to the new default 'spawn' from 'fork' causes program to crash in
spawn.py with `FileNotFoundError: [Errno 2] No such file or directory`.
I've tested this
Mouse added the comment:
Tried 'spawn', 'fork', 'forkserver'.
- 'spawn' causes consistent `FileNotFoundError: [Errno 2] No such file or
directory`;
- 'fork' consistently works (tested on machines with 4 and 20 cores);
- 'forkser
Mouse added the comment:
@mark.dickinson, the issue you referred to did not show a working sample. Could
you demonstrate on my example how it should be applied? Thanks!
--
___
Python tracker
<https://bugs.python.org/issue33
Mouse added the comment:
Also, adding `p.join()` immediately after `p.start()` in my sample code showed
this timing:
```
$ time python3.8 multi1.py
worker 0 done, got 100 numbers
worker 1 done, got 0 numbers
worker 2 done, got 0 numbers
worker 3 done, got 0 numbers
real0m2.342s
user
New submission from Mouse :
MacOS Catalina 10.15.3 and 10.15.4. Python-3.8.2 (also tested with 3.7.7, which
confirmed the problem being in the fix described in
https://bugs.python.org/issue33725.
Trying to use "multiprocessor" with Python-3.8 and with the new default of
`set_st
Mouse added the comment:
On MacOS Catalina 10.15.4, I still see this problem occasionally even with
p.join() added. See https://bugs.python.org/msg365251 and subsequent messages.
Also, see https://bugs.python.org/issue40106.
--
nosy: +mouse07410
Mouse added the comment:
@mark.dickinson, thank you. Following your suggestion, I've added a comment in
#28965, and created a new issue https://bugs.python.org/issue40106.
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/is
New submission from Mouse:
binascii b2a_base64() documentation says:
The length of data should be at most 57 to adhere to the base64 standard.
This is incorrect, because there is no base64 standard that restricts the
length of input data, especially to such a small value.
What RFC4648 (that
Mouse added the comment:
Yes I know where this came from. :-)
Here is my proposed change.
Replace the statement
The length of data should be at most 57 to adhere to the base64 standard.
with:
To be MIME-compliant, the Base64 output (as defined in RFC4648) should be
broken into lines of at
Mouse added the comment:
Thank you for the quick turn-around, and for taking care of this issue!
--
___
Python tracker
<http://bugs.python.org/issue25495>
___
___
Mouse added the comment:
As far as I remember, the data was not "originally processed in 57-byte
chunks". I've been around the first PEM and MIME standards and discussions (and
code, though not in Python, which wasn't around then) to be in position to
know. :)
Whether
Mouse added the comment:
1. I concede knowing nothing about the early Python library implementation,
functionality, or even purpose.
2. I don't think it makes sense now to either refer to PEM. We'd be two decades
too late for that (well, 27 years, to be precise :).
Mouse added the comment:
Let's not insinuate anything about the input. This is about what constraints on
the OUTPUT MAY be there, not a tutorial from the 80-ties on how one might
accomplish it.
--
___
Python tracker
<http://bugs.py
Mouse added the comment:
And even those constraints depend on the use. E.g. X.509 does not have those.
--
___
Python tracker
<http://bugs.python.org/issue25
Mouse added the comment:
1. I am OK with the following text, modeling referred Perldoc:
b2a_base64( $bytes, $eol );
Encode data by calling the encode_base64() function. The first argument is the
byte string to encode.
The second argument is optional, and provides the line-ending sequence to
Mouse added the comment:
The harm in mentioning the 57-byte chunking is that so far it successfully
confused people.
b2a_base64() function is not coupled to MIME. It has no constraints on either
its input, or its output. *IF* it is used by (in) a MIME application, then the
caller may want
Mouse added the comment:
Unfortunately, NO. The problem (and this bug report) is for Python-3
documentation, so trying to address it in Python-2 rather than in Python-3 does
not make sense.
We seem to both understand and agree that there is no length limitation on
b2a_base64() input, either
Mouse added the comment:
To add: I do not understand your attachment to that 57 "...(exactly 57 bytes of
input data per line)", and request that this parenthesized sentence is removed
from your Python-2.7 doc patch.
Please give the reader the benefit of the doubt, and allow th
Mouse added the comment:
> my patch should be valid for 3.5 also.
> The relevant wording is identical to 2.7.
OK.
> I have resisted removing the magic number 57 for a couple
> of reasons. Reading existing code that uses this number may
> be harder.
You expect to see "exi
Mouse added the comment:
Status...?
--
___
Python tracker
<http://bugs.python.org/issue25495>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
20 matches
Mail list logo
