[Python-ideas] Packaging Apps (Was Adding PyInstaller to the stdlib)

[Abdur-Rahmaan Janhangeer]

Greetings list,

> Then I would suggest starting a new thread,

Long overdue i guess. My view on the topic is like
Mr Moore with the exception that i'm for native
capabilities to be in the stdlib. Since Zipapp does
not seem to go the C-extension route, i propose
a new tool that turn projects into independent executables

This solves the issue of Gui etc etc etc etc etc etc

Mr Moore's mail of Nov 24, 2020 has ton of ideas
and a lot of potential

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

github 
Mauritius
___
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/HWGQHOKW3IWFYIQ4ILMXNRH2MYSZX2E3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Wes Turner]

>From "[Distutils] pip and missing shared system system library"
https://mail.python.org/archives/list/distutils-...@python.org/message/7TCZJT2RDE36BJKUDU6JVTIUYHGVDVQY/
:

> Existing workarounds for building and distributing portable binaries:
>
> W/ shared library dependencies:
> - auditwheel & manylinux
> - package managers which support arbitrary binary packages in languages
other than python:
>  - conda
>  - RPM / DEB / ...
>  - bdist_rpm
>  - bdist_deb
>   - FPM
>
> W/ static dependencies:
> - zipapp
> - bazel / buck build / pants build (BUILD files)
> - py2app, py2exe, pyinstaller,
>
> https://github.com/vinta/awesome-python#distribution

To py2app, py2exe, and pyinstaller, I'd add conda constructor:

> Constructor is a tool which allows constructing an installer for a
collection of conda packages. It solves needed packages using user-provided
specifications, and bundles those packages. It can currently create 3 kinds
of installers, which are best thought of as delivery vehicles for the
bundled packages. There are shell installers, MacOS .pkg installers, and
Windows .exe installers. Each of these will create an environment on the
end user's system that contains the specs you provided, along with any
necessary dependencies. These installers are similar to the Anaconda and
Miniconda installers, and indeed constructor is used to create those
installers.

https://github.com/conda/constructor

https://docs.python-guide.org/shipping/freezing/#freezing-your-code could
be updated

On Tue, Nov 24, 2020, 9:29 PM Oscar Benjamin 
wrote:

> On Sat, 21 Nov 2020 at 09:30, Ronald Oussoren via Python-ideas
>  wrote:
> >
> >
> >
> > > 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.
>
> Maybe a good solution could be if it was easy to put a Python-based
> application into something like the Microsoft Store. It would be
> useful if there was a library that could easily produce the
> appropriate format for that (I don't know if one already exists) with
> all dependencies bundled.
>
> --
> Oscar
> ___
> 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/XPBM6YAPZRY5OF6IDN27R6HW5I7RKZLI/
> 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/BSYXLRQD4BECPA5CGTRUWVVL3NDL45XR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Circular Indexing and FOR loop minimization

[Mathew M. Noel via Python-ideas]

As discussed earlier on the post on 'Circular Indexing', considering 
interpreting indices that lie outside the range 0 to n-1 modulo n for list 
indexing. Thus element n corresponds to element 0, n+1 to element 1 and so on. 
This has two consequences:


1.) Makes the Python convention of interpreting index -1 as the last element 
more logical since -1 is the same as n-1 when taken modulo n. If -1 is the 
first element then to be logically consistent we have to interpret index n as 
the element 0 as well!


Obviously this does allow certain errors to slip but if you are going to allow 
an index of -1 (indices that occur before 0) then you might just as well allow 
indices above n-1 to be logically consistent.


2.) If circular indexing is used then instead of using a double FOR loop to go 
through a loop twice we can iterate from 0 to 2n !


Although trivial for the case of one dimensional lists/arrays, cylindrical 
indexing (for 2D arrays) and toroidal  indexing (2D, 3D and nD arrays) schemes 
might be worth exploring for n-dimensional NumPy arrays.


Circular and in general cylindrical or toroidal indexing schemes might simplify 
coding by reducing the number of FOR loops when iterating over nD arrays in 
NumPy.

___
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/A5D6P2G26NYMZAV4WZGFTWYDI5UA25KZ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ethan Furman]

On 11/20/20 8:41 PM, Brendan Barnwell wrote:

On 2020-11-20 01:51, Steven D'Aprano wrote:



If that's really what you want, you probably should look at making a way
to run Python apps in the browser. Everyone has an OS, everyone has a
browser, GUI browsers have similar looking look-and-feels, the days when
devs assumed Internet Explorer are long gone.


I'm as steadfastly negative about browser apps as Chris A. is about native 
executables.  :-)


+1000

--
~Ethan~
___
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/G5XTX7IRHXLACMEKWEIIWG67J774HXAW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Oscar Benjamin]

On Sat, 21 Nov 2020 at 09:30, Ronald Oussoren via Python-ideas
 wrote:
>
>
>
> > 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.

Maybe a good solution could be if it was easy to put a Python-based
application into something like the Microsoft Store. It would be
useful if there was a library that could easily produce the
appropriate format for that (I don't know if one already exists) with
all dependencies bundled.

-- 
Oscar
___
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/XPBM6YAPZRY5OF6IDN27R6HW5I7RKZLI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Wed, Nov 25, 2020 at 12:03 PM Brendan Barnwell  wrote:
>
> On 2020-11-24 16:47, Chris Angelico wrote:
> > On Wed, Nov 25, 2020 at 10:29 AM Brendan Barnwell  
> > wrote:
> >>
> >> On 2020-11-24 00:05, Chris Angelico wrote:
> >> >> >
> >> >> >I'm still confused what the point is of a zipapp, if it can't be a 
> >> >> >proper point and click GUI thing, and it can't use any compiled 
> >> >> >extensions. How it is it better than a console_script and a 
> >> >> >pip-installed package??
> >> >> >
> >> > It CAN be a proper point-and-click GUI thing. You can have a fully
> >> > executable Python script if it has no dependencies (just distribute a
> >> > single .py file with a shebang at the top), and if you can't do that,
> >> > bundle it into a .pyz with zipapp and, again, put a shebang for posix
> >> > platforms. Windows, if the py.exe launcher is installed, will happily
> >> > let you double-click on a .py or .pyz and it'll run just fine.
> >>
> >> I think by "proper point-and-click GUI thing" he meant the app 
> >> itself
> >> is a GUI app, not just "can be launched via the OS GUI".  At least, that
> >> is what I would mean by that, and that is what can't be done without C
> >> extensions, because most GUI toolkits require C extensions.
> >>
> >
> > Python ships with one GUI toolkit (Tkinter). If you can't install
> > anything else, you at least get that.
>
> That's not even close to sufficient.
>
> I realize that we're diverging a bit from the original thread here, 
> but
> basically my position on this is that what would be good is a full
> solution.

Then I would suggest starting a new thread, because this one is
specifically about something being added to the stdlib, and I honestly
have no idea whether you're asking for such a full solution to be in
the stdlib or not. I've always been arguing from the POV of a stdlib
feature, not a third party tool.

ChrisA
___
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/D2YR7IXBSNBZQPLRUTF2GFL6QRJV4J73/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[MRAB]

On 2020-11-25 00:42, Greg Ewing wrote:

On 25/11/20 12:14 pm, Chris Angelico wrote:

If you want a perfectly out-of-the-box app, you're probably
going to have to stick to Tkinter.


Which is only bundled with Python on Windows, as far
as I know.


It's also bundled with Python on Raspbian.
___
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/PJNWTQLVS3LC642JW4HFUSL6HRBAJRDK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brendan Barnwell]

On 2020-11-24 16:47, Chris Angelico wrote:

On Wed, Nov 25, 2020 at 10:29 AM Brendan Barnwell  wrote:


On 2020-11-24 00:05, Chris Angelico wrote:
>> >
>> >I'm still confused what the point is of a zipapp, if it can't be a proper 
point and click GUI thing, and it can't use any compiled extensions. How it is it better 
than a console_script and a pip-installed package??
>> >
> It CAN be a proper point-and-click GUI thing. You can have a fully
> executable Python script if it has no dependencies (just distribute a
> single .py file with a shebang at the top), and if you can't do that,
> bundle it into a .pyz with zipapp and, again, put a shebang for posix
> platforms. Windows, if the py.exe launcher is installed, will happily
> let you double-click on a .py or .pyz and it'll run just fine.

I think by "proper point-and-click GUI thing" he meant the app itself
is a GUI app, not just "can be launched via the OS GUI".  At least, that
is what I would mean by that, and that is what can't be done without C
extensions, because most GUI toolkits require C extensions.



Python ships with one GUI toolkit (Tkinter). If you can't install
anything else, you at least get that.


That's not even close to sufficient.

	I realize that we're diverging a bit from the original thread here, but 
basically my position on this is that what would be good is a full 
solution.  Not another half solution or three-quarters solution.  What I 
mean by a full solution is I should be able to write any Python app 
using any libraries I want and anyone can install it on any OS without 
knowing anything about Python or any of those libraries, with no 
limitations except that the libraries my app uses have to exist for the 
platform they install it on.  So if, say, PyQt actually isn't available 
for your platform, okay, you're out of luck, but if it is available 
there should be no packaging/distribution/installation obstacle that 
prevents it from being used in an app that appears to the user as an 
ordinary native OS app.


	These other alternatives of "well no but you can do X. . ." are, from 
my perspective, pointless.  There are already lots of half-solutions 
that allow some combinations of things but not others, and we don't need 
another one of those.  What we need is a full solution.  The great thing 
about Python is ALL the things you can with Python, and what would be 
good is a solution that lets you do ALL the things you can do with 
Python, but as regular transparently-OS-installable-and-usable apps.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
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/RHRK5T2GZUAV4GGPH5AKWDA3FE3ICRLK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Wed, Nov 25, 2020 at 10:29 AM Brendan Barnwell  wrote:
>
> On 2020-11-24 00:05, Chris Angelico wrote:
> >> >
> >> >I'm still confused what the point is of a zipapp, if it can't be a proper 
> >> >point and click GUI thing, and it can't use any compiled extensions. How 
> >> >it is it better than a console_script and a pip-installed package??
> >> >
> > It CAN be a proper point-and-click GUI thing. You can have a fully
> > executable Python script if it has no dependencies (just distribute a
> > single .py file with a shebang at the top), and if you can't do that,
> > bundle it into a .pyz with zipapp and, again, put a shebang for posix
> > platforms. Windows, if the py.exe launcher is installed, will happily
> > let you double-click on a .py or .pyz and it'll run just fine.
>
> I think by "proper point-and-click GUI thing" he meant the app itself
> is a GUI app, not just "can be launched via the OS GUI".  At least, that
> is what I would mean by that, and that is what can't be done without C
> extensions, because most GUI toolkits require C extensions.
>

Python ships with one GUI toolkit (Tkinter). If you can't install
anything else, you at least get that.

(On Linux systems, it's sometimes in a separate package, but so are
other parts of Python too, so it's hard to predict. I generally assume
that, if you have to depend on the standard library only, you can at
least depend on python3-all or the equivalent.)

ChrisA
___
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/CBDDNM7A5JYXSXY4HQQCE4MWUDIPYIMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 25/11/20 12:14 pm, Chris Angelico wrote:

If you want a perfectly out-of-the-box app, you're probably
going to have to stick to Tkinter.


Which is only bundled with Python on Windows, as far
as I know.

--
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/EPBQERNLPU2P4CALRQUEPNLABENSNSNK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 25/11/20 11:48 am, Steven D'Aprano wrote:

In a language without declarations, how do you know that something is
unused?


Personally, I don't mind if I have to *tell* it what I'm
using. I don't insist on the stripping-out being automatic,
and I would actually prefer it not to be.

To support that, I want a system that lets me specify exactly
what I'm using, during development *and* packaging, both working
off the same information. That way I can be sure that if it
runs for me, it will also run for my users.


 # Module eggs
 from spam import bunchofstuff
 re = bunchofstuff['re']

I trust you're not going to say that if you write obfuscated code like
that, you deserve whatever pain you get :-)


With the scheme described above, I'll find out during testing
if I've forgotten to add re as a dependency. And if I don't,
then it's my fault for not testing thoroughly enough.

--
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/NYAU56Z32FHVWYVU4U4B6MCTFPYUTTP3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brendan Barnwell]

On 2020-11-24 00:05, Chris Angelico wrote:

>
>I'm still confused what the point is of a zipapp, if it can't be a proper 
point and click GUI thing, and it can't use any compiled extensions. How it is it 
better than a console_script and a pip-installed package??
>

It CAN be a proper point-and-click GUI thing. You can have a fully
executable Python script if it has no dependencies (just distribute a
single .py file with a shebang at the top), and if you can't do that,
bundle it into a .pyz with zipapp and, again, put a shebang for posix
platforms. Windows, if the py.exe launcher is installed, will happily
let you double-click on a .py or .pyz and it'll run just fine.


	I think by "proper point-and-click GUI thing" he meant the app itself 
is a GUI app, not just "can be launched via the OS GUI".  At least, that 
is what I would mean by that, and that is what can't be done without C 
extensions, because most GUI toolkits require C extensions.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
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/TVBYWQ3WS4A6HZN3KBWE7VWCURO24IYU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

On Wed, Nov 25, 2020 at 10:13 AM Greg Ewing  wrote:
>
> On 24/11/20 9:05 pm, Chris Angelico wrote:
> > It CAN be a proper point-and-click GUI thing. You can have a fully
> > executable Python script if it has no dependencies (just distribute a
> > single .py file with a shebang at the top) ...
>
> But to most people a "proper point and click GUI thing"
> includes having an actual GUI, which is somewhere between
> very difficult and impossible to do well without C extensions
> that don't come with a standard Python installation.
>

True. If you want a perfectly out-of-the-box app, you're probably
going to have to stick to Tkinter.

ChrisA
___
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/LVBC5Y3NV6CEWOBOBPUZ5VK7MHGTJLMD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

On 24/11/20 9:05 pm, Chris Angelico wrote:

It CAN be a proper point-and-click GUI thing. You can have a fully
executable Python script if it has no dependencies (just distribute a
single .py file with a shebang at the top) ...


But to most people a "proper point and click GUI thing"
includes having an actual GUI, which is somewhere between
very difficult and impossible to do well without C extensions
that don't come with a standard Python installation.

--
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/KCJQMTVCQGPLFGRSIEDVJKOZZ4ORD5ET/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Mon, Nov 23, 2020 at 11:56:47AM +1300, Greg Ewing wrote:
> On 22/11/20 4:31 pm, Christopher Barker wrote:
> >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.
> 
> Something needs to change about how Python packages are set up,
> then. Most other software development systems manage to strip
> out unused stuff without needing a bunch of flakey heuristics
> for each individual library.

In a language without declarations, how do you know that something is 
unused?

One can, I guess, look for imports, but the presence of even a single 
eval or exec opens the flood-gates.

And then there could be code that looks at sys.modules directly. 
Possibly via an alias:

# Module spam
from sys import modules as bunchofstuff

# Module eggs
from spam import bunchofstuff
re = bunchofstuff['re']

I trust you're not going to say that if you write obfuscated code like 
that, you deserve whatever pain you get :-)

-- 
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/2DUJWXFYZW4VHW6KEYC4QDQ4KN6E2OAI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Circular Indexing

[Richard Damon]

On 11/24/20 2:36 PM, Mathew M. Noel via Python-ideas wrote:
>
> Python uses an index of -1 to index the last element in a list. Since
> -1 occurs before 0 we might think of the elements of the linear list
> are being bent into a circle making the last element occur before the
> 0th element. Consider a list with n elements: it would be perfectly
> reasonable to address the element 0 of the list using an index of n
> since n occurs after n-1 (if we assume that the list is bent into a
> circle). This feature can prove to be extremely useful. Consider the
> following example:
>
>
> days_of_the_week = 
> ["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"]
> It would be nice if
> days_of_the_week[0]
>  is the same as
> days_of_the_week[7] is the same as
> days_of_the_week[14] etc In other words use modular indexing. In other
> words if the index is outside the range 0 to n-1, we simply take the
> remainder when the index is divided by n as the index. Because of the
> close relationship between finite length sequences and periodic
> sequences this feature might simplify scientific computing(circular
> convolution etc).

If I wanted this sort of indexing, using % works very well. Losing the
error detection of out of bounds indexing would be very bad in most cases.

As I think about this, the only cases that I would likely do this will
have a fixed sized list (like the 7 days of the week) it makes it fairly
trivial.

-- 
Richard Damon
___
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/4JY7TYHM3FZYEFSPVTOGBXZQETAWZPSZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Circular Indexing

[Steele Farnsworth]

I believe this would be simple to implement when it's needed by subclassing
`collections.UserList` and wrapping this functionality around
`__getitem__`, `__setitem__`, and `__delitem__`.

On Tue, Nov 24, 2020, 2:38 PM Mathew M. Noel via Python-ideas <
python-ideas@python.org> wrote:

> Python uses an index of -1 to index the last element in a list. Since -1
> occurs before 0 we might think of the elements of the linear list are being
> bent into a circle making the last element occur before the 0th element.
> Consider a list with n elements: it would be perfectly reasonable to
> address the element 0 of the list using an index of n since n occurs after
> n-1 (if we assume that the list is bent into a circle). This feature can
> prove to be extremely useful. Consider the following example:
>
>
> days_of_the_week = 
> ["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"]
>
> It would be nice if
>
> days_of_the_week[0]
>
> is the same as
>
> days_of_the_week[7]
>
> is the same as
>
> days_of_the_week[14] etc
>
> In other words use modular indexing.
> In other words if the index is outside the range 0 to n-1, we simply take the 
> remainder when the index is divided by n as the index.
> Because of the close relationship between finite length sequences and 
> periodic sequences this feature might simplify scientific computing(circular 
> convolution etc).
>
>
>
> ___
> 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/ZEH5W2XBYSHKU733WSLGQEIIPOFSVBIU/
> 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/3X5M357XO5P6E5JPFARIXDDTRM3PJYOD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Circular Indexing

[edwin]

November 24, 2020 2:36 PM, "Mathew M. Noel via Python-ideas" 
mailto:python-ideas@python.org?to=%22Mathew%20M.%20Noel%20via%20Python-ideas%22%20)>
 wrote:
[snip]
This feature can prove to be extremely useful. It can also prove to be 
extremely dangerous. "list index out of range" errors can often be indicators 
of a bug elsewhere, and this would cause those bugs to silently pass.
--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/PSHFMFFU4IB2DLZAH7WH6D4QIDB6SR5M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Circular Indexing

[Mathew M. Noel via Python-ideas]

Python uses an index of -1 to index the last element in a list. Since -1 occurs 
before 0 we might think of the elements of the linear list are being bent into 
a circle making the last element occur before the 0th element. Consider a list 
with n elements: it would be perfectly reasonable to address the element 0 of 
the list using an index of n since n occurs after n-1 (if we assume that the 
list is bent into a circle). This feature can prove to be extremely useful. 
Consider the following example:


days_of_the_week = 
["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"]

It would be nice if

days_of_the_week[0]

is the same as

days_of_the_week[7]

is the same as

days_of_the_week[14] etc

In other words use modular indexing.
In other words if the index is outside the range 0 to n-1, we simply take the 
remainder when the index is divided by n as the index.
Because of the close relationship between finite length sequences and periodic 
sequences this feature might simplify scientific computing(circular convolution 
etc).


___
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/ZEH5W2XBYSHKU733WSLGQEIIPOFSVBIU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ronald Oussoren via Python-ideas]

> On 24 Nov 2020, at 11:58, Antoine Pitrou  wrote:
> 
> On Tue, 24 Nov 2020 10:23:10 +
> Paul Moore  wrote:
>> On Tue, 24 Nov 2020 at 10:18, Antoine Pitrou  wrote:
>>> 
>>> On Mon, 23 Nov 2020 08:09:07 +
>>> Paul Moore  wrote:  
 
 But it's not as limiting as you suggest - it *does* preclude most
 scientific use (because of numpy etc) but (for example) a large number
 of web libraries are pure Python.  
>>> 
>>> Not sure what you mean here, but while Web frameworks themselves may be
>>> pure Python, you can have C accelerators in a template engine or in a
>>> ORM layer.  Also, the database driver most likely isn't in pure Python
>>> (if you want it to be performant anyway).  
>> 
>> All I meant was that how limiting it is depends on what type of
>> application you're trying to write.
> 
> Sure, but the number of applications which don't depend whatsoever on
> non-stdlib C extensions is probably much smaller than you were trying
> to say.  You should not fool yourself: the suggested "zipapp" (does it
> exist already? I lost track of the number of weird things that have
> been implemented in core Python in the name of packaging) would mostly
> be a non-solution.

This already exists, see >

It is basically a zipped up directory with an ``__main__.py``. This works for
some applications, but is not comparable to py2exe/py2app/pyinstaller/…. 

IMHO any changes to CPython for this should be solutions for clear problems
that are best fixed in the core, preferably along side changes to the 
prospective
users of those changes to ensure that the changes are actually useful. 

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/H3B4JD6YMK4FRWIJLTXRVS42J3AI3EU2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] JSON loading

[Stestagg]

I was thinking about the "Load JSON file as single line" thread from a bit
back, and had an idea for a neat solution, albeit one that has potential
stylistic issues.

Idea:
Create two new methods on pathlib.Path objects:

Path.load(loader, **kwargs)
and
Path.dump(dumper, obj, **kwargs)

Here, `loader` should be an object that implements a method `load(fileobj:
BinaryIO, *args, **kwargs) -> object`
and `dumper` should be an object that implements `dump(obj: object,
fileobj: BinaryIO, *args, **kwargs)`

This approach takes advantage of the standard `dump/load` pattern used by
json, pickle and other serialization libraries.

Example usage:
data = Path("/path/to/file.json").load(json)
Path("/dest.json").dump(json, my_obj, indent=2)

The implementation should look something like:

def load(self, loader, *args, **kwargs):
with self.open('rb') as fh:
return loader.load(fh, *args, **kwargs)

and the equivalent for `dump`

Reasons I like this:

 * Reading the code, the intent seems clear (generally unambiguous)
 * It's explicit in naming the serialization method
 * The code boilerplate is quite low (compared to context managers etc)
 * Implementation is simple & decoupled
 * Using other serialization is trivial:

my_path.load(json)
# vs.
my_path.load(pickle)
my_path.load(msgpack)
...

 * Unlike other similar proposals, this doesn't force the solution to read
the entire file into memory before decoding (although optional support for
`loads`/`dumps` could be added if desired)

Reasons I don't like it:
---
 * Relying on the dump/load convention isn't something I've seen much of
elsewhere
 * It may be hard to type-check (is this a concern?)
 * We're just replacing 2 lines of code with one (previous discussions
around this topic seemed to suggest that consensus was that this pattern is
so common, that maybe this is a good-enough reason).
 * The load/dump naming pattern clashes with pathlib's read/write naming.
I'm not concerned about exactly what these methods are called but this
feels like it's a side-effect of either: "read/write and dump/load being
slightly different operations", or "a tiny existing inconsistency in the
standard library" either way, the problem here is we're bringing these
existing things into the same module, which seems fairly minor.

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/AQWL35DPLJNNAYQEXF2HK3RHQ27P3D7E/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

On Tue, 24 Nov 2020 10:23:10 +
Paul Moore  wrote:
> On Tue, 24 Nov 2020 at 10:18, Antoine Pitrou  wrote:
> >
> > On Mon, 23 Nov 2020 08:09:07 +
> > Paul Moore  wrote:  
> > >
> > > But it's not as limiting as you suggest - it *does* preclude most
> > > scientific use (because of numpy etc) but (for example) a large number
> > > of web libraries are pure Python.  
> >
> > Not sure what you mean here, but while Web frameworks themselves may be
> > pure Python, you can have C accelerators in a template engine or in a
> > ORM layer.  Also, the database driver most likely isn't in pure Python
> > (if you want it to be performant anyway).  
> 
> All I meant was that how limiting it is depends on what type of
> application you're trying to write.

Sure, but the number of applications which don't depend whatsoever on
non-stdlib C extensions is probably much smaller than you were trying
to say.  You should not fool yourself: the suggested "zipapp" (does it
exist already? I lost track of the number of weird things that have
been implemented in core Python in the name of packaging) would mostly
be a non-solution.

Regards

Antoine.

___
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/7KYQ7SLTNNFIOEUHQSV2X64FNGFVGXEW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On Tue, 24 Nov 2020 at 10:18, Antoine Pitrou  wrote:
>
> On Mon, 23 Nov 2020 08:09:07 +
> Paul Moore  wrote:
> >
> > But it's not as limiting as you suggest - it *does* preclude most
> > scientific use (because of numpy etc) but (for example) a large number
> > of web libraries are pure Python.
>
> Not sure what you mean here, but while Web frameworks themselves may be
> pure Python, you can have C accelerators in a template engine or in a
> ORM layer.  Also, the database driver most likely isn't in pure Python
> (if you want it to be performant anyway).

All I meant was that how limiting it is depends on what type of
application you're trying to write. But there's no question that not
being able to use C extensions limits use (I work on pip, which cannot
rely on C extensions for other reasons, so I'm pretty familiar with
(a) how much of a nuisance it is, and (b) how far you can get even
with that limitation).

Paul
___
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/O7NHRQGTOMJAF52AWYNJHT2II2L3ZIFJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Antoine Pitrou]

On Mon, 23 Nov 2020 08:09:07 +
Paul Moore  wrote:
> 
> But it's not as limiting as you suggest - it *does* preclude most
> scientific use (because of numpy etc) but (for example) a large number
> of web libraries are pure Python.

Not sure what you mean here, but while Web frameworks themselves may be
pure Python, you can have C accelerators in a template engine or in a
ORM layer.  Also, the database driver most likely isn't in pure Python
(if you want it to be performant anyway).

Regards

Antoine.

___
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/ACRDB4NL3Y7D6E6YSFFD42DSZQ67OABI/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

On Tue, 24 Nov 2020 at 07:47, Christopher Barker  wrote:
> indeed I am. But also, where I need this sort of thing is for desktop GUIs 
> (wxPython in my case), another heavy user of compiled extensions.
>
> I'm still confused what the point is of a zipapp, if it can't be a proper 
> point and click GUI thing, and it can't use any compiled extensions. How it 
> is it better than a console_script and a pip-installed package??

For me (on a purely personal basis) it would allow me to install
command line tools *without* having them tied to a specific Python
installation. So, for example, I can install a tool like tox or nikola
and *not* need to reinstall it every time I upgrade my main Python
installation. (Even if I put it in a virtualenv, or something like
pipx, that's tied to the system Python). I don't (personally) want a
Python interpreter bundled (more accurately, I sometimes do, but not
always). But zipapps fail for me because they aren't exes - and I
regularly trip up over that problem.

To give a very explicit example of what I'm personally thinking of,
imagine writing the "diff" command in Python. How would you deploy it
so that people could use it as easily as a native executable build?
Languages like go and rust are competing in this area, and I'd like to
be able to use Python for this sort of thing.

> Hmm --maybe 'cause you can bundle specific dependency versions?

That's part of it, as well. But I don't often hit version conflicts,
so it's minor.

> In that case, conda-execute should be part of the discussion. What it does is 
> fire up a conda environment, and then run your script in it.

The problem is for me, that I actively dislike conda. If I can set up
conda-execute as a standalone Python application and use it without
knowing it's conda under the hood, then it might be useful. If I
can't, then it's basically demonstrated that it can't bundle *itself*
the way I want it to bundle my code, so I guess that answers my
question as to whether it's useful for me :-)

But that does raise a good point. What I'm looking for is essentially
the equivalent of `cl /Femyapp.exe myapp.c`. A standalone command that
I can run, which creates an executable from my Python code, which I
can copy and run anywhere. I don't mind "needing a Python runtime"
installed on the target, but I *do* mind if it has to be a specific
version (If I write my code on Python 3.8, I want the same exe to run
when I upgrade my PC to 3.9). If I try to describe my personal
checklist of features, it basically comes down to:

* The installer itself must be bundled as a standalone command. I
don't want to have to install the installer into every project's venv.
* An installer that can't bundle itself makes me suspicious. I don't
*actually* insist on "the installer must have created its own
executable", but I'd want to know why if it wasn't...
* The resulting compiled apps must be Windows native exes (I don't
currently have a need for other platforms, but I'd want whatever
"native binary" meant there as well).
* The compiled apps must depend on nothing but a Python interpreter
(and must not be tied to a specific version - only the app's own
constraints should apply there).
* Must be relatively mature/robust - I don't want to interrupt
deploying my script to raise a bug on the installer and wait for a
fix.

Things I'd like to have:

* A mode that *does* use a separately-installed Python interpreter.
Most of the time I don't need the interpreter bundled, and I'd like to
avoid the extra overheads.
* Support for C extensions. Pure python only *is* a real limitation.
* A "robust" mode that doesn't try to strip out "unused stuff". I
don't need this to be the default, but I want it available. I have no
wish to find out months after I deployed the script that a dependency
used some weird dynamic loading feature that the installer didn't know
about, and my app broke because a plugin was missing.
* Related to this, I don't need the installer to guess what packages
I'm using. I'm perfectly willing to tell it. And I definitely don't
want the installer to look at my currently active environment - there
could be all sorts of junk in there.

A tool like PyInstaller is pretty close to this. The major problems
for me are that it doesn't come as a standalone tool, and it has no
"depend on a system Python" mode.

> BTW, this all reminds me of a discussion a long while back in the wxPython 
> community -- we thought it would be nice to have a wxPython run-time -- 
> essentially a Python install with wxPython bundled in, so you could make 
> little GUI apps without bundling that massive package. But one trick was that 
> while wxPython was the big one, any given application might require who knows 
> what other dependency as well. I suppose sipassp could help there.
>
> And none of us got around to actually implementing it anyway :-(

... and that's the main problem with *all* of these ideas. No-one is
actually implementing them. (FWIW, over the weekend I lo

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

[Chris Angelico]

On Tue, Nov 24, 2020 at 6:47 PM Christopher Barker  wrote:
>
> 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 package and run your scripts.
>> >
>> > If they can't do that, then they likely need a full bundle.
>> >
>> > But I could be wrong there.
>>
>> You're more or less right, although your perspective on what's useful
>> may be biased a little by the fact that (I believe) you're a heavy
>> numpy user.
>
>
> indeed I am. But also, where I need this sort of thing is for desktop GUIs 
> (wxPython in my case), another heavy user of compiled extensions.
>
> I'm still confused what the point is of a zipapp, if it can't be a proper 
> point and click GUI thing, and it can't use any compiled extensions. How it 
> is it better than a console_script and a pip-installed package??
>

It CAN be a proper point-and-click GUI thing. You can have a fully
executable Python script if it has no dependencies (just distribute a
single .py file with a shebang at the top), and if you can't do that,
bundle it into a .pyz with zipapp and, again, put a shebang for posix
platforms. Windows, if the py.exe launcher is installed, will happily
let you double-click on a .py or .pyz and it'll run just fine.

(Annoyingly, you cannot simply exec to this sort of thing on Windows,
since it's only a GUI feature. But I believe you can use ShellExecute
to invoke them. Can't wait on their output though.)

ChrisA
___
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/WUEVMLFXXYQCA7WJUHBCHFMBTJAJJC67/
Code of Conduct: http://python.org/psf/codeofconduct/