On 09/03/2020 17:50, Remy NOEL wrote:
I ran into a problem which, according to a google search is not that
uncommon:
concurrent.futures ThreadPoolExecutor, installs an exit handler
preventing program exit if any of the jobs it is running is blocked. (Which
might be a surprising behaviour to
On Wed, 4 Mar 2020 at 12:33, Chris Angelico wrote:
> Being able to easily distinguish "that isn't callable" from "the
> parameters don't line up" from "the function, during execution, raised
> TypeError" would be useful.
I **completely** agree. And I add that the change can also be
non-breaking,
On Sat, Mar 7, 2020, at 19:31, Cameron Simpson wrote:
> >I *think* I understand the issues. And I can see that some software would
> >need to work with filenames as arbitrary bytes. But that doesn't mean that
> >you can do much with them that way.
>
> Given that the entire UNIX filename API is byt
On Mon, Mar 9, 2020 at 11:18 PM Kyle Stanley wrote:
> We're currently looking into adjusting the current Executor implementation
> (for both TPE and PPE) to not use daemon threads at all for subinterpreter
> compatibility, see https://bugs.python.org/issue39812. Instead of using
> an atexit handl
On Tue, Mar 10, 2020 at 1:04 PM Rhodri James wrote:
> Well, yes. The non-ugly thing would be to make sure your threads are
> well behaved ;-)
>
That is kinda hard to do for the general case, i prefer to have a failsafe.
___
Python-ideas mailing list -
> Most real-world UNIX systems only support ASCII-compatible encodings.
> There's no reason not to solve the problem on such systems by using
> os.fsdecode().
>
Huh?!
Is my Ubuntu derivative not "real world"?
666-tmp % uname -a
Linux popkdm 5.3.0-7629-generic #31~1581628825~19.10~f90b7d5-Ubuntu
On 10/03/2020 14:58, David Mertz wrote:
Most real-world UNIX systems only support ASCII-compatible encodings.
There's no reason not to solve the problem on such systems by using
os.fsdecode().
Huh?!
Is my Ubuntu derivative not "real world"?
666-tmp % uname -a
Linux popkdm 5.3.0-7629-generic
On Mar 10, 2020, at 08:01, David Mertz wrote:
>> Most real-world UNIX systems only support ASCII-compatible encodings.
>> There's no reason not to solve the problem on such systems by using
>> os.fsdecode().
>
> Huh?!
>
> Is my Ubuntu derivative not "real world"?
>
> 666-tmp % uname -a
> Linu
On Tue, 10 Mar 2020 15:16:06 +0100
Remy NOEL wrote:
> On Mon, Mar 9, 2020 at 11:18 PM Kyle Stanley wrote:
>
> > We're currently looking into adjusting the current Executor implementation
> > (for both TPE and PPE) to not use daemon threads at all for subinterpreter
> > compatibility, see https:/
Getting a bit OT, but I *think* this is the story:
I've heard it argued, by folks that want to write Python software that uses
bytes for filenames, that:
A file path on a *nix system can be any string of bytes, except two special
values:
b'\x00' : null
b'\x2f': slash
(consistent with this
On Wed, Mar 11, 2020 at 7:19 AM Christopher Barker wrote:
>
> Getting a bit OT, but I *think* this is the story:
>
> I've heard it argued, by folks that want to write Python software that uses
> bytes for filenames, that:
>
> A file path on a *nix system can be any string of bytes, except two spe
On Mar 10, 2020, at 13:18, Christopher Barker wrote:
>
> Getting a bit OT, but I *think* this is the story:
>
> I've heard it argued, by folks that want to write Python software that uses
> bytes for filenames, that:
>
> A file path on a *nix system can be any string of bytes, except two speci
Remy NOEL wrote:
> This means that if a ThreadExecutor is called from both daemon and
non-daemon threads (which is a very bad idea though), the kind of spawned
threads might be unpredictable.
IIUC, I don't think there's a way that we could reasonably support
stability for provide any guarantees fo
13 matches
Mail list logo
