[Python-ideas] Re: Adding PyInstaller to the standard library

On Mon, 23 Nov 2020 at 03:37, Christopher Barker wrote: > > On Sun, Nov 22, 2020 at 6:34 AM Paul Moore wrote: >> 4. Support for C extensions. > > That last one if VERY limiting :-( Correct. But it's ultimately an OS limitation - you can't run a shared library direct from a zipfile. There are wor

[Python-ideas] Re: PyInstaller funding

Greetings, I suggest: -- To setup PyInstaller funding via the PSF like the pallets does can be a first step to something more concrete -- To let the PSF take over the lib (requires the PSF and your approval) Kind Regards, Abdur-Rahmaan Janhangeer about | bl

[Python-ideas] Re: Adding PyInstaller to the standard library

On Sun, Nov 22, 2020 at 07:37:35PM -0800, Christopher Barker wrote: > I'm curious about zipapp -- I've heard of it, but never tried to use it -- > does it get much use in the wild? I am quite confident that one of the most used, if controversial, Python applications in the wild is a zipapp on Li

[Python-ideas] Re: Adding PyInstaller to the standard library

Also, virtualenv is distributed as a zipapp these days. Paul On Mon, 23 Nov 2020 at 08:44, Steven D'Aprano wrote: > > On Sun, Nov 22, 2020 at 07:37:35PM -0800, Christopher Barker wrote: > > > I'm curious about zipapp -- I've heard of it, but never tried to use it -- > > does it get much use in th

[Python-ideas] Re: Adding PyInstaller to the standard library

> > Oh, and Chrome itself needs to be updated -- only on > > what, millions of machines? V8 is bundled with Chrome -- you know, kind of > > like a > > PyInstaller app bundles Python ;-) > > Uhhh... no, that's kind of like how Python bundles Python. That's not > bundling an app. You update Chrome o

[Python-ideas] Re: Adding PyInstaller to the standard library

On Mon, 23 Nov 2020 at 10:39, Mathew Elman wrote: > > I would argue this sounds like a case for a "python_runner", i.e. a > lightweight python vm that can run python apps, e.g. zipapps. Something like > the blender_runner for blender. Making it explicitly an app that runs via > some other engin

[Python-ideas] Re: Adding PyInstaller to the standard library

On 23/11/20 11:38 pm, Mathew Elman wrote: I would argue this sounds like a case for a "python_runner", i.e. a lightweight python vm that can run python apps, e.g. zipapps. Something like the blender_runner for blender. Making it explicitly an app that runs via some other engine. How would tha

[Python-ideas] Re: Adding PyInstaller to the standard library

I suppose functionally there may be little difference, but having an explicit "runner" would allow two things: 1. the runner and stdlib for it could be in a compress format itself since it doesn't need to provide any utility for editing or navigating human readable modules. and so lighter 2. it

[Python-ideas] Re: Adding PyInstaller to the standard library

Greetings list, On Mon, Nov 23, 2020 at 12:44 PM Steven D'Aprano wrote: > On Sun, Nov 22, 2020 at 07:37:35PM -0800, Christopher Barker wrote: > > > I'm curious about zipapp -- I've heard of it, but never tried to use it > -- > > does it get much use in the wild? > > I am quite confident that one

[Python-ideas] Re: Adding PyInstaller to the standard library

> That's essentially like Java's JRE. For what it's worth, on my PC the > JRE is 196M in size. Whereas a full Python distribution is only 94M, > and the embedded distribution is 15M. So I think Python already has > that, more or less. I hadn't realised that, so thanks :) > But my experience with

[Python-ideas] Re: Adding PyInstaller to the standard library

On Mon, 23 Nov 2020 at 11:32, Mathew Elman wrote: > I imagine there would be a way to have an install install the runner if there > is not one on the machine, and use the existing one if there is, and creating > a venv in either case. Meaning that using the equivalent of an embedded JRE > would

[Python-ideas] Re: PyInstaller funding

I cannot speak for the Board, since I'm not currently on it. I think it's *probable* they'd be willing to be a fiscal sponsor for PyInstaller, as they have for some other things, but only if the developers really want that. All that really gets is an ability for donators to flag funds as pass-thro

[Python-ideas] Re: 'Infinity' constant in Python

IEEE 754 is incredibly consistent with mathematics. The easiest way to determine if a float operation would return inf, -inf, or NaN is to quite literally make an expression and take the limit of it as a certain variable approaches infinity. 0/0, inf/inf, 0*inf, inf-inf are standard Indeterm

[Python-ideas] Re: 'Infinity' constant in Python

Is there a different IEEE spec or CAS that distinguishes between 1/x and 2/x where x=0? assert 1/0 != 2/0 != math.inf/0 On Mon, Nov 23, 2020, 2:44 PM wrote: > IEEE 754 is incredibly consistent with mathematics. > > The easiest way to determine if a float operation would return inf, -inf, > or N

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, Nov 24, 2020 at 8:26 AM Wes Turner wrote: > > Is there a different IEEE spec or CAS that distinguishes between 1/x and 2/x > where x=0? > > assert 1/0 != 2/0 != math.inf/0 > No, why should there be? There is absolutely no difference between them mathematically. The limit of 1/x as x ten

[Python-ideas] Re: 'Infinity' constant in Python

On Mon, Nov 23, 2020 at 04:26:20PM -0500, Wes Turner wrote: > Is there a different IEEE spec or CAS that distinguishes between 1/x and > 2/x where x=0? No. x/0.0 would either signal an error (in Python terms: raise an exception) or return a NAN. The specific NAN it might return is not set by th

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, Nov 24, 2020 at 9:05 AM Steven D'Aprano wrote: > > On Mon, Nov 23, 2020 at 04:26:20PM -0500, Wes Turner wrote: > > > Is there a different IEEE spec or CAS that distinguishes between 1/x and > > 2/x where x=0? > > No. x/0.0 would either signal an error (in Python terms: raise an > exception

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, Nov 24, 2020 at 09:01:27AM +1100, Steven D'Aprano wrote: > On Mon, Nov 23, 2020 at 04:26:20PM -0500, Wes Turner wrote: > > > Is there a different IEEE spec or CAS that distinguishes between 1/x and > > 2/x where x=0? > > No. x/0.0 would either signal an error (in Python terms: raise an >

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, Nov 24, 2020 at 08:32:21AM +1100, Chris Angelico wrote: > On Tue, Nov 24, 2020 at 8:26 AM Wes Turner wrote: > > > > Is there a different IEEE spec or CAS that distinguishes between 1/x and > > 2/x where x=0? > > > > assert 1/0 != 2/0 != math.inf/0 > > > > No, why should there be? There i

[Python-ideas] Re: 'Infinity' constant in Python

On Tue, Nov 24, 2020 at 9:32 AM Steven D'Aprano wrote: > > On Tue, Nov 24, 2020 at 08:32:21AM +1100, Chris Angelico wrote: > > On Tue, Nov 24, 2020 at 8:26 AM Wes Turner wrote: > > > > > > Is there a different IEEE spec or CAS that distinguishes between 1/x and > > > 2/x where x=0? > > > > > > a

[Python-ideas] Re: Matching TypedDicts and other values in JSON

On 11/22/20 10:15 AM, Guido van Rossum wrote: > - We intentionally don't support things like `isinstance(x, List[str])` > because that would require checking all the items with `isinstance(item, > str)`, and that seems a speed trap. Reverting this decision would be > hard work. Aye. I imagine man

[Python-ideas] Re: Matching TypedDicts and other values in JSON

I recommend taking this to typing-sig... On Mon, Nov 23, 2020 at 19:18 David Foster wrote: > On 11/22/20 10:15 AM, Guido van Rossum wrote: > > - We intentionally don't support things like `isinstance(x, List[str])` > > because that would require checking all the items with `isinstance(item, >

[Python-ideas] Re: Adding PyInstaller to the standard library

On Mon, Nov 23, 2020 at 12:09 AM Paul Moore wrote: > On Mon, 23 Nov 2020 at 03:37, Christopher Barker > wrote: > > My feeling is that it hits middle ground that isn't very useful. If you > can count on your users having a proper Python installation ,then they can > use pip to install your packag