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

[David Foster]

I am excited about the potential of the new PEP 634-636 "match" statement to
match JSON data received by Python web applications. Often this JSON data is
in the form of structured dictionaries (TypedDicts) containing Lists and
other primitives (str, float, bool, None).

PEP 634-636 already contain the ability to match all of those underlying 
data
types except for TypedDicts, so I'd like to explore what it might look 
like to

match a TypedDict...

Consider an example web application that wants to provide a service to draw
shapes, perhaps on a connected physical billboard.

The service has a '/draw_shape' endpoint which takes a JSON object
(a Shape TypedDict) describing a shape to draw:

from bottle import HTTPResponse, request, route
from typing import Literal, TypedDict, Union

class Point2D(TypedDict):
x: float
y: float

class Circle(TypedDict):
type: Literal['circle']
center: Point2D  # has a nested TypedDict!
radius: float

class Rect(TypedDict):
type: Literal['rect']
x: float
y: float
width: float
height: float

Shape = Union[Circle, Rect]  # a Tagged Union / Discriminated Union

@route('/draw_shape')
def draw_shape() -> None:
match request.json:  # a Shape?
...
case _:
return HTTPResponse(status=400)  # Bad Request

Now, what syntax could we have at the ... inside the "match" statement to
effectively pull apart a Shape?

The current version of PEP 634-636 would require duplicating all the keys
and value types that are defined in Shape's underlying Circle and Rect 
types:


match request.json:  # a Shape?
case {'type': 'circle', 'center': {'x': float(), 'y': 
float()}, \

radius: float()} as circle:
draw_circle(circle)  # type is inferred as Circle
case {'type': 'rect', 'x': float(), 'y': float(), \
'width': float(), 'height': float()} as rect:
draw_rect(rect)  # type is inferred as Rect
case _:
return HTTPResponse(status=400)  # Bad Request

Wouldn't it be nicer if we could use class patterns instead?

match request.json:  # a Shape?
case Circle() as circle:
draw_circle(circle)
case Rect() as rect:
draw_rect(rect)
case _:
return HTTPResponse(status=400)  # Bad Request

Now that syntax almost works except that Circle and Rect, being TypedDicts,
do not support isinstance() checks. PEP 589 ("TypedDict") did not define how
such isinstance() checks should work initially because it's somewhat complex
to specify. From the PEP:

> In particular, TypedDict type objects cannot be used in isinstance() 
tests

> such as isinstance(d, Movie). The reason is that there is no existing
> support for checking types of dictionary item values, since isinstance()
> does not work with many PEP 484 types, including common ones like 
List[str].

> [...]
> This is consistent with how isinstance() is not supported for List[str].

Well, what if we (or I) took the time to specify how isinstance() worked 
with

TypedDict? Then the match syntax above with TypedDict as a class pattern
would work!

Refining the example above even further, it would be nice if we didn't 
have to

enumerate all the different types of Shapes directly in the match-statement.
What if we could match on a Shape directly?

match request.json:  # a Shape?
case Shape() as shape:
draw_shape(shape)
case _:
return HTTPResponse(status=400)  # Bad Request

Now for that syntax to work it must be possible for an isinstance() check to
work on a Shape, which is defined to be a Union[Circle, Rect], and 
isinstance()

checks also aren't currently defined for Union types. So it would be useful
to define isinstance() for Union types as well.

Of course that match-statement is now simple enough to just be rewriten 
as an

if-statement:

if isinstance(shape := request.json, Shape):
draw_shape(shape)
else:
return HTTPResponse(status=400)  # Bad Request

Now *that* is a wonderfully short bit of parsing code that results in
well-typed objects as output. 

So to summarize, I believe it's possible to support really powerful matching
on JSON objects if we just define how isinstance() should work with a 
handful

of new types.

In particular the above example would work if isinstance() was defined for:
* Union[T1, T2], Optional[T]
* T extends TypedDict
* Literal['foo']

For arbitrary JSON beyond the example, we'd also want to support
isinstance() for:
* List[T]

We already support isinstance() for the other JSON primitive types:
* str
* float
* bool
* type(None)

So what do folks think? If I were to start writing a PEP to extend 
isinstance()

to cover at least the 

[Python-ideas] Re: PEP 634-636: Mapping patterns and extra keys

[Guido van Rossum]

Thanks very much for the survey (which actually surprised me somewhat).

Regarding the suggested update for the PEP, I'll make a PR to change that
-- I agree it's worth saying it.

On Sat, Nov 21, 2020 at 5:00 PM David Foster  wrote:

> On 11/19/20 10:08 PM, David Foster wrote:
> > I've completed my survey of how other languages use pattern matching to
> > match Mapping-like and dict-like types, especially focusing on whether
> > they ignore (픸) or disallow (픹) extra keys by default. [...]
>
> To close the loop on this thread:
>
> * Based on (1) the explanation from PEP 622 and Guido RE that  "mappings
> [...] have natural structural sub-typing behavior, i.e., passing a
> dictionary with extra keys somewhere will likely just work" and (2) the
> survey results, I'm now personally fine (+0) with keys being ignored by
> default when matching against mappings.
>
>
> * I do think it might be illustrative to copy the following explanatory
> sentences from the "Mapping Patterns" section of the older PEP 622 to
> the same section of PEP 635 (Structural Pattern Matching: Motivation and
> Rationale):
>
>  > Extra keys in the subject are ignored even if **rest is not present.
> This is different from sequence pattern, where extra items will cause a
> match to fail. But mappings are actually different from sequences: they
> have natural structural sub-typing behavior, i.e., passing a dictionary
> with extra keys somewhere will likely just work.
>
> Specifically the above might replace the following sentence in PEP 635,
> which doesn't really give a rationale:
>
>  > Moreover, the mapping pattern does not check for the presence of
> additional keys.
>
>
> * I still have an interest in strictly matching dictionaries that are
> destined to become TypedDicts, but I can take that conversation to a
> different thread.
>
> --
> David Foster | Seattle, WA, USA
> Contributor to TypedDict support for mypy
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/K5BUKMOCIBUQIITBUQNX6KEHOB4WB5BC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4VCATZRVSNIZM4YUJJHCIDE6ARKO6LE6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Cameron Simpson]

On 22Nov2020 13:22, Steven D'Aprano  wrote:
>On Sun, Nov 22, 2020 at 12:56:01PM +1100, Cameron Simpson wrote:
>> On 21Nov2020 17:54, Chris Angelico  wrote:
>> >The range of people who (a) cannot install from PyPI and can only use
>> >the stdlib, and (b) cannot deploy with a .pyz and must deploy an .exe,
>> >is extremely narrow. In what situation do you have to make a native
>> >executable but cannot get a tool from PyPI to make one?
>>
>> Well, for my personal example, an in house tool for an in house task,
>> the users _can_ copy a Mac .app into their Applications folder. I _do
>> not_ and would not expect them to (likely choice):
>> - install macports or homebrew
>> - install python
>> - install source code and libraries (needed PyQt)
>>
>> They're end users; some are (variously) technical and some aren't, but
>> none should need to be technical.  I want them to copy an app to a new
>> machine and be happy - drag'n'drop a single thing.
>
>Sure, but why does PyInstaller have to be in the std lib for you to
>support this use-case?

It doesn't. I'm not arguing for that; I'm at least slightly against it 
in fact.

I'm _still_ arguing against Chris' apparent position that wanting to 
make a standalone bundle is pretty much a null situation. I think I've 
let his "attractive nuisance" description get under my skin.

Still, as you say:

>That was Chris' question:
>Under what circumstances does somebody have to make a native 
>application
>but **cannot use one of the tools on PyPI to do it**?
>(Or the freeze tool.)

It is true that I, at least, am not in that position: needing to make a 
standalone app and unable to access PyPI to get tools to build it.

I may have misconstrued Chris to mean my users rather than myself. (His 
full question is still quoted at the top of this message for reference.) 
And on that basis I withdraw my example.

But it definitely applies to my users: thier install process should be a 
trivial copy-this-app experience. That does require a complete bundle.

Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OXEDVWJTUFHGZKHDGTILD5K4LWCB3XCR/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stephen J. Turnbull]

Steven D'Aprano writes:
 > On Sun, Nov 22, 2020 at 12:56:01PM +1100, Cameron Simpson wrote:

 > > They're end users[...].  I want them to copy an app to a new 
 > > machine and be happy - drag'n'drop a single thing.

I don't think there is disagreement that this is a reasonable goal.

 > Sure, but why does PyInstaller have to be in the std lib for you to 
 > support this use-case? That was Chris' question:

+1

I think there's another aspect to Chris's questions: is PyInstaller
(or any of the other offerings) enough to deal with (some reasonable
approximation to) "all" of the use cases?

Note that this situation is different from the usual one of "stdlib
does 50%, if not enough, go to PyPI" -- it's likely that the
developer's machine and environment is not all that much like the
target machines, so the developer needs to have deep knowledge of the
foibles of the particular bundling software.  If they don't, it's
unlikely that their users will get the "copy and be happy" experience.
If the developer must make that much effort, it probably makes sense
to choose an bundler that's tuned to their application and platform.
(This may be a distinction without a difference, but I feel like it's
interesting enough to raise even if I'm wrong.)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GRWPXLSCB4KI76NWOQGG2HKGGNWY4JJD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

On Sat, Nov 21, 2020 at 4:04 PM Greg Ewing 
wrote:

> > conda is similar -- there is even the "conda
> > constructor" that will build an installer for a conda environment that
> > meets your specs. But the fact is that you get a LOT of extra stuff
> > along with what you need.
>
> My thinking is that you would only add things to the venv that your
> app needs, as and when you discover that they're needed. E.g. you
> wouldn't add the whole of PyObjC at once, just the submodules you
> use.
>

but unfortunately, that's not how most python packages are set up -- you
install the whole thing at once. As an example, it's really tricky to use
even one function from scipy without installing the whole thing.

And that's in fact where the complications come in for the bundlers -- if
you use PIL, you get all of tkInter. If you use matplotlib, you may get all
of QT and who knows what other back ends.

And there is the other complication that if you have a virtualenv or conda
environment, you still need a single file that looks like an application to
start the whole thing up -- with an icon and all that.

I recently revisited this for an application that used a Browser interface
with a Python server that we wanted to bundle as a desktop app (using
Electron to provide the app wrapper and browser). conda constructor really
didn't help -- it was easier to use PyInstaller for the Python part, and we
got amore compact system.

-CHB








> While this would be more work for the developer, it would allow
> the packaging tool to be far simpler and easier to maintain.
>
> Another benefit of working this way is that it's easier to be sure
> that the package you create will work on machines other than the
> one you developed it on. If it runs in your development environment,
> it should run elsewhere too.
>
> --
> Greg
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/T27AYTW7J2O6E4KWEZ2R6DTFON7UVZAD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZJZBIPDFVSSPB46POOOFVK3NDNKELX6H/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Sun, Nov 22, 2020 at 12:56:01PM +1100, Cameron Simpson wrote:
> On 21Nov2020 17:54, Chris Angelico  wrote:
> >The range of people who (a) cannot install from PyPI and can only use
> >the stdlib, and (b) cannot deploy with a .pyz and must deploy an .exe,
> >is extremely narrow. In what situation do you have to make a native
> >executable but cannot get a tool from PyPI to make one?
> 
> Well, for my personal example, an in house tool for an in house task, 
> the users _can_ copy a Mac .app into their Applications folder. I _do 
> not_ and would not expect them to (likely choice):
> - install macports or homebrew
> - install python
> - install source code and libraries (needed PyQt)
> 
> They're end users; some are (variously) technical and some aren't, but 
> none should need to be technical.  I want them to copy an app to a new 
> machine and be happy - drag'n'drop a single thing.

Sure, but why does PyInstaller have to be in the std lib for you to 
support this use-case? That was Chris' question:

Under what circumstances does somebody have to make a native application 
but **cannot use one of the tools on PyPI to do it**?

(Or the freeze tool.)



-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SOJJ4WDUIP47VOY7FW2RMBBJDPSPKQOM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Cameron Simpson]

On 21Nov2020 17:54, Chris Angelico  wrote:
>The range of people who (a) cannot install from PyPI and can only use
>the stdlib, and (b) cannot deploy with a .pyz and must deploy an .exe,
>is extremely narrow. In what situation do you have to make a native
>executable but cannot get a tool from PyPI to make one?

Well, for my personal example, an in house tool for an in house task, 
the users _can_ copy a Mac .app into their Applications folder. I _do 
not_ and would not expect them to (likely choice):
- install macports or homebrew
- install python
- install source code and libraries (needed PyQt)

They're end users; some are (variously) technical and some aren't, but 
none should need to be technical.  I want them to copy an app to a new 
machine and be happy - drag'n'drop a single thing.

Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WUPSBNSQGALOPCJOISXD62NJH4XPGER5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 634-636: Mapping patterns and extra keys

[David Foster]

On 11/19/20 10:08 PM, David Foster wrote:
I've completed my survey of how other languages use pattern matching to 
match Mapping-like and dict-like types, especially focusing on whether 
they ignore (픸) or disallow (픹) extra keys by default. [...]


To close the loop on this thread:

* Based on (1) the explanation from PEP 622 and Guido RE that  "mappings 
[...] have natural structural sub-typing behavior, i.e., passing a 
dictionary with extra keys somewhere will likely just work" and (2) the 
survey results, I'm now personally fine (+0) with keys being ignored by 
default when matching against mappings.



* I do think it might be illustrative to copy the following explanatory 
sentences from the "Mapping Patterns" section of the older PEP 622 to 
the same section of PEP 635 (Structural Pattern Matching: Motivation and 
Rationale):


> Extra keys in the subject are ignored even if **rest is not present. 
This is different from sequence pattern, where extra items will cause a 
match to fail. But mappings are actually different from sequences: they 
have natural structural sub-typing behavior, i.e., passing a dictionary 
with extra keys somewhere will likely just work.


Specifically the above might replace the following sentence in PEP 635, 
which doesn't really give a rationale:


> Moreover, the mapping pattern does not check for the presence of 
additional keys.



* I still have an interest in strictly matching dictionaries that are 
destined to become TypedDicts, but I can take that conversation to a 
different thread.


--
David Foster | Seattle, WA, USA
Contributor to TypedDict support for mypy
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K5BUKMOCIBUQIITBUQNX6KEHOB4WB5BC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 21/11/20 3:59 pm, Christopher Barker wrote:
On Fri, Nov 20, 2020 at 4:18 PM Greg Ewing With venvs, it seems like it should be possible to have a very

simple tool that just packages up everything in your venv.

>
conda is similar -- there is even the "conda 
constructor" that will build an installer for a conda environment that 
meets your specs. But the fact is that you get a LOT of extra stuff 
along with what you need.


My thinking is that you would only add things to the venv that your
app needs, as and when you discover that they're needed. E.g. you
wouldn't add the whole of PyObjC at once, just the submodules you
use.

While this would be more work for the developer, it would allow
the packaging tool to be far simpler and easier to maintain.

Another benefit of working this way is that it's easier to be sure
that the package you create will work on machines other than the
one you developed it on. If it runs in your development environment,
it should run elsewhere too.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/T27AYTW7J2O6E4KWEZ2R6DTFON7UVZAD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A pypi-based app store solution for platform specific installation

[Wes Turner]

setup.py:setup(project_urls=) can include URLs to the app store entries for
the package; though other than displaying all project_urks, PyPI doesn't do
anything special like show the App Store icon for URL values with specific
key prefixes in project_urls.

Here's an example of specifying multiple project_urls:
https://github.com/pypa/sampleproject/blob/master/setup.py#L196-L201

Would there need to be a PEP to specify specific key prefixes? for e.g.

- prefix, store name
- stores:fdroid, F-Droid
- stores:playstore, Google Play Store
- stores:appleappstore, Apple App Store
- please advise regarding (URI) keys and stores

On Fri, Nov 20, 2020, 12:08 PM Ricky Teachey  wrote:

> On Fri, Nov 20, 2020, 11:00 AM Paul Moore  wrote:
>
>> On Fri, 20 Nov 2020 at 15:44, Ricky Teachey  wrote:
>> >
>> > I was reading the pyinstaller thread and had this idea but didn't want
>> to hijack.
>> >
>> > Maybe a wild idea, and very possible totally impractical or hopelessly
>> complex, but: could the existing pypi infrastructure be leveraged into a
>> set of platform-specific app stores? Maybe maybe we could make it as simple
>> as a single line in a pyproject.toml file.
>>
>> It could be done, but I'm not sure what you are thinking of when you
>> say "the existing PyPI infrastructure".
>
>
> I was thinking that the pypi website could potentially act as the "home"
> of the store and the index could provide the basis of the store index. But
> I guess now that you mention it there's not necessarily a very compelling
> reason to marry the idea to pypi. Aside from making it "official".
>
> My main thought is python could really use an easy story to tell for
> platform installable apps. Pypi and pip feels like it is almost already
> exactly what is needed in terms of an app store, it just doesn't yet have a
> way to install on platforms without a bunch of upfront work. An app store
> tied to pypi and pip might be able to totally remove that friction.
>
> I get that you're saying it's not something you can do yourself. So I
>>
> guess let's see if anyone wants to take it on :-)
>>
>> Paul
>>
>
> Yeah I'm definitely not the guy.  Only hope here was to inspire someone
> else.
>
>> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZGWMO4LNWW56P5A5K7HGJ53MYAJUV5AU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WSXR2BUKS42KLAAAFPED7T3US2FZCIJG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Sat, Nov 21, 2020 at 07:16:22AM -0500, Edwin Zimmerman wrote:
> On 11/20/2020 11:53 PM, Chris Angelico wrote:
> > [snip]
> > Use the simpler options until you can't use them. Then use the more
> > complicated options.

> Yea, use the simpler options.  This is why I have switched from Python 
> to C# when writing desktop apps, simply because distributing a single 
> exe file is easier at all levels than distributing a complete install 
> of Python.

Decrease in effort packaging your app as an exe file: -10%

Increase in effort writing your app in C# in the first place: +800%

*semi-wink*

But seriously...

1. *None of* the stdlib freeze tool, or any of the third-party projects 
cx_Freeze, py2app, py2exe or PyInstaller, work for you?

2. Python is pre-installed on pretty much all Linux and BSD systems, and 
Mac OS, and is trivially installed on Windows from the Microsoft 
app store. Getting a complete install of Python couldn't be simpler. 
Where does the process let you down?


-- 
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZQZRB5OM6V4OSCFSO22GQRVGZETO4R6C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Edwin Zimmerman]

On 11/20/2020 11:53 PM, Chris Angelico wrote:
> [snip]
> Use the simpler options until you can't use them. Then use the more
> complicated options.
Yea, use the simpler options.  This is why I have switched from Python to C# 
when writing desktop apps, simply because distributing a single exe file is 
easier at all levels than distributing a complete install of Python.

--Edwin
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4DHGJH2NQCANRURLD52RX4DDCRTZ2J4A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: A pypi-based app store solution for platform specific installation

[Ronald Oussoren via Python-ideas]

> On 20 Nov 2020, at 16:42, Ricky Teachey  wrote:
> 
> I was reading the pyinstaller thread and had this idea but didn't want to 
> hijack.
> 
> Maybe a wild idea, and very possible totally impractical or hopelessly 
> complex, but: could the existing pypi infrastructure be leveraged into a set 
> of platform-specific app stores? Maybe maybe we could make it as simple as a 
> single line in a pyproject.toml file. 
> 
> Imagine if all the end user does is install the store, and clicks the link to 
> the project app. The store takes care of the rest. The developer marks their 
> package as an installable program to be published to the store, optionally 
> specifying things like specific platforms if needed. All the project website 
> does for users to install is provide a url to their app in the store. 
> 
> Very very rough idea of how it might work: a store app API would provide an 
> installation GUI if desired, and the store would build the environment needed 
> for installing the package and dependencies. Once the specified environment 
> is built, pip would take care of installing the package as usual. 
> 
> If this is an awful idea feel free to just say so. I have given it no deep 
> thought and do not have the expertise to even think through what would be 
> needed to create such a thing. 

In some sense PyPI already is such a store, if you don’t mind launching 
applications from the command line.

That said, using PyPI in this way is not necessarily useful even ignoring 
platforms where side-loading is frowned upon or even impossible. As a user of 
applications I don’t really care in what language an application is written in, 
I don’t wan to look in the Python App Store, or the C# App Store, I just wan to 
use application A.Russel Keith-MacKee has a PyCon talk about Black Swans 
that talks (amongst others) about the problem of app distribution in particular 
on systems that aren’t desktop systems. 

Ronald
—

Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KGCUDPRZUFEZ3FEESY7U44QVVMD7WAGX/
Code of Conduct: http://python.org/psf/codeofconduct/