Re: Python, Be Bold! - The Draft

[Abdur-Rahmaan Janhangeer]

On Tue, 7 Jan 2020, 05:56 Michael Torrie,  wrote:

>
> My mistake. I see now that it was something you forwarded to the list
> from someone else.
>
> Doesn't change my reply, though.  Whoever said it, it's not very
> relevant.  Who's "us" and what is it the Python gives them that Julia
> will soon take over?
>

Don't worry about it, that's how Python lists are. There's an unwritten law
that tells whatever thread you start, folks around have the ability to
teleport the conversion to higher realms. Here is a Julia ending, another
one ended with running Python in the browser. That got me scratching my
head as to what i started and what folks end up talking about.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Michael Torrie]

On 1/6/20 6:33 PM, Abdur-Rahmaan Janhangeer wrote:
> No, i did not write that, it's not Abdur-Rahmaan Janhangeer wrote rather

My mistake. I see now that it was something you forwarded to the list
from someone else.

Doesn't change my reply, though.  Whoever said it, it's not very
relevant.  Who's "us" and what is it the Python gives them that Julia
will soon take over?

Python is lots of things to lots of different people.  I'm not surprised
it fits some people's needs more than others.  Julia is a fine language
and I encourage the original poster to explore it if it fits his or her
needs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Abdur-Rahmaan Janhangeer]

No, i did not write that, it's not Abdur-Rahmaan Janhangeer wrote rather

-- Forwarded message -
From: *AAKASH JANA* 
Date: Mon, 6 Jan 2020, 21:15
Subject: Re: Python, Be Bold! - The Draft
To: Abdur-Rahmaan Janhangeer 

Please forward it to aakashjana2...@gmail.com

On Tue, 7 Jan 2020, 01:21 Michael Torrie,  wrote:

> On 1/6/20 10:24 AM, Abdur-Rahmaan Janhangeer wrote:
> > Maybe but if you know or have heard of Julia the language. You will
> realise
> > its going to take over what python gives us. So i think there is urgent
> > need for upgrades to newer versions of python to make basic tasks on
> python
> > way quicker.
>
> No it sure won't.  You can't possibly make such a blanket statement.
> Julia might replace python for some users, perhaps those involved in
> data science, but Python stands on its own merits. And currently that
> standing is pretty good.  If that changes in the future, oh well.
> Languages come and go.  Besides all that, if some users find Julia fits
> their need better, why is that a bad thing?  You talk like it's a zero
> sum game. It's not.  I don't see where this urgency is coming from.
>
> Put in another way, Python fills the needs of many users at present.
> This isn't going to magically change because you see something that is
> deficient in your opinion.
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Michael Torrie]

On 1/6/20 10:24 AM, Abdur-Rahmaan Janhangeer wrote:
> Maybe but if you know or have heard of Julia the language. You will realise
> its going to take over what python gives us. So i think there is urgent
> need for upgrades to newer versions of python to make basic tasks on python
> way quicker.

No it sure won't.  You can't possibly make such a blanket statement.
Julia might replace python for some users, perhaps those involved in
data science, but Python stands on its own merits. And currently that
standing is pretty good.  If that changes in the future, oh well.
Languages come and go.  Besides all that, if some users find Julia fits
their need better, why is that a bad thing?  You talk like it's a zero
sum game. It's not.  I don't see where this urgency is coming from.

Put in another way, Python fills the needs of many users at present.
This isn't going to magically change because you see something that is
deficient in your opinion.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

Mauritius


On Mon, Jan 6, 2020 at 9:44 PM DL Neil via Python-list <
python-list@python.org> wrote:

>
> I have not (been following the thread) - with all due apologies.
>
> Podcast of possible interest:
> Episode #245: Python packaging landscape in 2020
> https://talkpython.fm/episodes/show/245/python-packaging-landscape-in-2020


For interested people listen the podcast from time 32:00
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[DL Neil via Python-list]

On 7/01/20 6:10 AM, Abdur-Rahmaan Janhangeer wrote:

On Mon, 6 Jan 2020, 20:50 Rhodri James,  wrote:
No if you read the thread (please do it), that's the 4th time i'm
saying it's a bad idea



I have not (been following the thread) - with all due apologies.

Podcast of possible interest:
Episode #245: Python packaging landscape in 2020
https://talkpython.fm/episodes/show/245/python-packaging-landscape-in-2020
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Mon, 6 Jan 2020, 20:50 Rhodri James,  wrote:

> On 01/01/2020 07:22, Abdur-Rahmaan Janhangeer wrote:
> > -- Self-updating Python distributions
>
> Microsoft have proved time and again that this is a really good thing if
> you want to piss off your customer base.  Let's not.
>

No if you read the thread (please do it), that's the 4th time i'm
saying it's a bad idea


> > -- Distributions which notify about new releases
>
> Surely this is the OS's package management system's job?
>

In windows for example, the interpreter/VM and package manager is referred
to as a dustribution

> -- Easy compilation to python-specific executable (.pyz is a good
> candidate)
>
> Don't we already have .pyc files?
>

See the draft thread where pep441 enounces archives' advantages

> -- More robust native Gui facilities
>
> Why is this a core Python issue?  GUIs are inherently OS-specific
> (including those OSes -- or lack of OSes -- which have no graphical
> interface).
>

This is an issue which requires it's own thread.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Abdur-Rahmaan Janhangeer]

On Mon, 6 Jan 2020, 21:01 Chris Angelico,  wrote:

>
> Don't worry. It's trying to solve a problem that doesn't exist, in a
> platform-specific way, imitating a completely different execution
> model, and ultimately is just reinventing what pip already does. You
> can safely ignore it for plenty of reasons besides the misuse of
> "executable".
>


Hum it proposes to enhance zipapp, well, pip has it's use and i don't think
package managers are a replacement for zip archives.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Abdur-Rahmaan Janhangeer]

On Mon, 6 Jan 2020, 20:46 Rhodri James,  wrote:

>
> I'm an embedded systems programmer.  Congratulations, you have just
> rendered your draft utterly irrelevant to me and those like me.
>

If you followed the previous thread there was some misunderstanding as to
what do i mean by executable, sorry.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Abdur-Rahmaan Janhangeer]

On Mon, 6 Jan 2020, 18:37 o1bigtenor,  wrote:

>
> Maybe I'm just slow but it really seems like what you are trying to
> achieve is
> a java like system.
>
> Wouldn't you find it easier to just use java rather than trying to remake
> Python into Java? (It would be easier imo.)
>

It proposes to enhance zipapp but included relevent info to pull in ideas

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Chris Angelico]

On Tue, Jan 7, 2020 at 3:47 AM Rhodri James  wrote:
>
> On 06/01/2020 10:21, Abdur-Rahmaan Janhangeer wrote:
> > Before we begin, we'd like to define the term executable used in the context
> > of this draft. It means an archive that is run by double-clicking.
>
> I'm an embedded systems programmer.  Congratulations, you have just
> rendered your draft utterly irrelevant to me and those like me.
>

Don't worry. It's trying to solve a problem that doesn't exist, in a
platform-specific way, imitating a completely different execution
model, and ultimately is just reinventing what pip already does. You
can safely ignore it for plenty of reasons besides the misuse of
"executable".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Rhodri James]

On 01/01/2020 07:22, Abdur-Rahmaan Janhangeer wrote:

-- Self-updating Python distributions


Microsoft have proved time and again that this is a really good thing if 
you want to piss off your customer base.  Let's not.



-- Distributions which notify about new releases


Surely this is the OS's package management system's job?


-- Easy compilation to python-specific executable (.pyz is a good candidate)


Don't we already have .pyc files?


-- More robust native Gui facilities


Why is this a core Python issue?  GUIs are inherently OS-specific 
(including those OSes -- or lack of OSes -- which have no graphical 
interface).


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[Rhodri James]

On 06/01/2020 10:21, Abdur-Rahmaan Janhangeer wrote:

Before we begin, we'd like to define the term executable used in the context
of this draft. It means an archive that is run by double-clicking.


I'm an embedded systems programmer.  Congratulations, you have just 
rendered your draft utterly irrelevant to me and those like me.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold! - The Draft

[o1bigtenor]

On Mon, Jan 6, 2020 at 4:23 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> Note: Prepared a draft on the previous discussion, motivated by the vision
> of
> an era where the world swarms in Python apps. This draft is not a PEP, at
> least
> not yet. It's structure approaches a PEP but takes liberties as necessary.
> It
> includes info deemed as essential. Thanking list members for their input.
>


Maybe I'm just slow but it really seems like what you are trying to achieve is
a java like system.

Wouldn't you find it easier to just use java rather than trying to remake
Python into Java? (It would be easier imo.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Error in python installation - was Re: Python, Be Bold!

[Michael Torrie]

On 1/5/20 7:59 AM, Kishor Soni wrote:
> After proceeding installation, few minutes later such error appears 
> "0x80072f7d - unspecified error"
> A log file is generated and attached herewith

I prefer to keep communication on the list.  Where did you download the
installer from?  Python.org or some other distribution like Anaconda?
Are you installing for all users, or just for your current user?  What
has google found about this error message and python?  Does google tell
you whether anyone else has seen this error message while installing
Python before?

I don't have Windows, so I can only speculate, and do the same google
searches you can do.

Finally, have you tried installing Python through the Microsoft Store on
Windows 10?  It's officially released by python.org core devs and should
always be free.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Sun, 5 Jan 2020, 14:38 Marco Sulla, <
mail.python@marco.sulla.e4ward.com> wrote:

>
> Sorry, I do not understand.
> Probably do you mean: I install all the wheels in a machine identical
> to the target I want (maybe using a VM, I don't know if Python support
> cross-compiling). Then I copy the folders of the modules inside my
> app?
>
> The problem is: who will maintain the pre-compiled versions of the
> modules for every OSes? As a programmer, I can assure you I'm not
> really slightly interested to do this work at all :D
>

Nor me, a bad idea, this part is open for discussion.

IMHO the most simple solution is that Python ships, together the

> installer of the interpreter, a C compiler for systems, like Windows,
> where such compiler is not pre-installed. Maybe gcc or Clang. If the
> user wants to use its installer, no problem, (s)he can customize it.
>
> This way you can create a sort of python installer that is nothing
> more that a zip file with the source code of the app, the wheels of
> the dependencies and a setup.py. Where the zip is opened by python, it
> should execute the setup.py, that will create the venv, install the
> app and the wheels. And since Python ships a beautiful C compiler, the
> wheels will be installed without problems (in the best of the
> worlds...)
>

This part is open to discussions. It should be under: Proposed changes to
the interpreter part


> Do you have the link of the PEP you cited?
>

Must look for it, will be a long hunt apparently

The end user it's not interested to have the most updated Python in
> the world.


As you said down below, programs do. The adoption of 3.7 was amazing, i've
seen libs use f strings as though it was an old buddy. People are
interested to build programs using new features available but that's
according to me is bad practise as you always have people lagging behind.
But on the other hand security fixes interpreter side might be a good
upgrade inventive.

The end user probably does not even _know_ what is Python.
>

That's what the Python, Be Bold approach suggests, to make end-users more
and more aware of what a Python distribution is. It should not be a shame
for devs to introduce end-users to a Python installation on their system.

For example, what happens if an user tries to use an executable jar
> than needs a more updated version of java than the one that is
> installed on the user machine? Well, if it's well written, it's the
> program itself that gives him / her an alert: "You need Java version
> Z".


That's a nice idea, but if on interpreter side, might be easier unless
in-built alert mechanism when executing the archive.

The user will snort, and finally will search on Google the Java
> version (s)he needs.No auto update.


No ... auto-update is a bad idea, third time saying that on this thread ^^_
Proposing instead the ability to update not auto-update
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Andrea D'Amore]

On Thu, 2 Jan 2020 at 09:38, Chris Angelico  wrote:

> The wheel does not need to be reinvented.

I see what you did there.


-- 
Andrea
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Sun, Jan 5, 2020 at 7:51 PM Andrea D'Amore  wrote:
>
> On Thu, 2 Jan 2020 at 09:38, Chris Angelico  wrote:
>
> > The wheel does not need to be reinvented.
>
> I see what you did there.
>

If you're talking about the pip-installable "wheel" format, then I
*think* that it's a reference to that expression, but I'm not
positive. More info can be found here:

https://www.python.org/dev/peps/pep-0427/

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Marko Rauhamaa]

Greg Ewing :
> You can pass a zip file with a .pyz extension to the python
> interpreter and it will look for a __main__.py file and run
> it.

This discussion has been interesting, and I've now learned about zipapp.
This is really nice and will likely be a favorite distribution format
for Python applications.

My initial instinct would be to use zipapp as follows:

 * The starting point is a directory containing the Python source files,
   possibly with subdirectories. (A simple, two-file example:
   "myapp.py", "auxmod.py".)

   Be sure that "myapp.py" contains the boilerplate footer:

   if __name__ == '__main__':
   main()

 * Test that the program works:

   $ ./myapp.py
   hello

 * Generate the zipapp:

   $ python3 -m zipapp . -o ../myapp.pyz --main myapp:main \
   -p "/usr/bin/env python3"

 * Try it out:

   $ ../myapp.pyz
   hello


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

<< than some ever-changing feature wish list. >>

^^_ since the beginning it was .jar
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Sat, 4 Jan 2020, 06:49 Michael Torrie,  wrote:

> On 2020-01-03 5:44 p.m., Abdur-Rahmaan Janhangeer wrote:
> > .jar provides more than just compression. It provides app info and has
> > signing ability
>
> This is the first time you've mentioned signing ability in this very
> long thread.  At this point I have no idea what point you are even
> making anymore.  It's all over the place!
>

True. Currently writing a draft.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 2020-01-03 5:44 p.m., Abdur-Rahmaan Janhangeer wrote:
> .jar provides more than just compression. It provides app info and has
> signing ability

This is the first time you've mentioned signing ability in this very
long thread.  At this point I have no idea what point you are even
making anymore.  It's all over the place!

If you coded up something concrete to share with the list, and described
it in the form of a PEP, and then it could be debated on its merits
rather than some ever-changing feature wish list.  Your ideas may well
be good.  But they will need an implementation behind them.  Python core
developers have a lot on their hands; pie in the sky wishes are unlikely
to get on their radar.

Several people have suggested utilities to look at. I suggest you start
there and see if you can modify them to suit your needs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Sat, 4 Jan 2020, 05:23 Chris Angelico,  wrote:

>
> I'm not sure what your proposal is here. Are you trying to make a
> single-file executable, or are you trying to make an archive of Python
> source code (like a jar), or are you trying something different again?
>

a .jar but it can be defined for greater security

U.. so go install Python and then you can install some
> Python app? Isn't that how things already are?
>

Not for the archive-based exec. It does not currently exist.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Sat, Jan 4, 2020 at 12:12 PM Abdur-Rahmaan Janhangeer
 wrote:
>
> On Fri, 3 Jan 2020, 23:49 Barry Scott,  wrote:
>
> >
> > I'm at a lose to understand what the problem is that zipapp is the
> > solution to that is not better served
> > with pip or PyInstall etc.
> >
>
> Well proposing to enhance zipapp, by adding app metadata and signing. By
> pip i understand you mean pure python distribution. Well, an enhanced
> zipapp's advantage would be smaller codebase and easy injection detection
> among others + the improving the ability to prevent reverse engineering for
> those who want it.

Why do you assume pure Python? pip is fully capable of locating and
installing binary packages based on the architecture it's running on.

> Comparing to native executable well, one thing is program size. You must
> have the interpreter on the machine but your program is lighter. 10 python
> programs does not mean inclung 10× the interpreter. The proposal also
> proposes enhancement to the interpreter to make it more non-programmer
> friendly. Also, you must have a dist for every different Os.

I'm not sure what your proposal is here. Are you trying to make a
single-file executable, or are you trying to make an archive of Python
source code (like a jar), or are you trying something different again?

> Python, Be Bold captures the spirit of it should not be a shame to have the
> interpreter/VM installed on end-users machines. It also facilitates the
> work of other python devs. You installed it because of one Python program,
> other programs benefit from it. It also proposes enhancements to the VM to
> better facilitate that.

U.. so go install Python and then you can install some
Python app? Isn't that how things already are?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Sat, 4 Jan 2020, 05:10 Abdur-Rahmaan Janhangeer, 
wrote:

>
> Also, you must have a dist for every different Os.
>

*for native execs

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 23:49 Barry Scott,  wrote:

>
> I'm at a lose to understand what the problem is that zipapp is the
> solution to that is not better served
> with pip or PyInstall etc.
>

Well proposing to enhance zipapp, by adding app metadata and signing. By
pip i understand you mean pure python distribution. Well, an enhanced
zipapp's advantage would be smaller codebase and easy injection detection
among others + the improving the ability to prevent reverse engineering for
those who want it.

Comparing to native executable well, one thing is program size. You must
have the interpreter on the machine but your program is lighter. 10 python
programs does not mean inclung 10× the interpreter. The proposal also
proposes enhancement to the interpreter to make it more non-programmer
friendly. Also, you must have a dist for every different Os.

Python, Be Bold captures the spirit of it should not be a shame to have the
interpreter/VM installed on end-users machines. It also facilitates the
work of other python devs. You installed it because of one Python program,
other programs benefit from it. It also proposes enhancements to the VM to
better facilitate that.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Sat, 4 Jan 2020, 02:55 Greg Ewing,  wrote:

> On 3/01/20 3:31 pm, Abdur-Rahmaan Janhangeer wrote:
>
> You can pass a zip file with a .pyz extension to the python
> interpreter and it will look for a __main__.py file and run
> it.
>
> That seems to give you all the functionality of a jar --
> including the limitations (e.g. you can't bundle extension
> modules or native libraries that way).
>

.jar provides more than just compression. It provides app info and has
signing ability

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Greg Ewing]

On 3/01/20 3:31 pm, Abdur-Rahmaan Janhangeer wrote:


But, this proposal is not about native executables. It's about a .jar like
executable. 


You can pass a zip file with a .pyz extension to the python
interpreter and it will look for a __main__.py file and run
it.

That seems to give you all the functionality of a jar --
including the limitations (e.g. you can't bundle extension
modules or native libraries that way).

Py2exe comes with zipextimporter, which purports to be able
to load .pyd files from zip archives, but I'm not aware of an
equivalent for other platforms.

Perhaps getting zipextimporter into the standard library,
and developing versions of it for Linux and MacOS, would be
a useful improvement?

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Barry Scott]

> On 3 Jan 2020, at 02:31, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> 
> 
> On Fri, 3 Jan 2020, 02:50 Barry Scott,  > wrote:
> Expect for trivial programs you cannot distribute a single file python exe 
> for windows.
> 
> You can, PyInstaller does it. You can have folder-based or single file apps
> 
> As you found zipapp is not a solution.
> 
>  Zipapp is a good candidate. Proposing to improve it

I'm at a lose to understand what the problem is that zipapp is the solution to 
that is not better served
with pip or PyInstall etc.


> 
> 
> Many stdlib modules use DLL's on Windows and you cannot run a DLL from
> inside a zip file.
> 
> PyInstaller's -F mode does it well

Then use that are be happy.


> 
> But, this proposal is not about native executables. It's about a .jar like 
> executable. As a python-specific 'executable', os is not a problem unless of 
> course you are using like curses on windows

Barry

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 06:33 Bob van der Poel,  wrote:

> Oh, now we get the rational. No thank you! Enough of the world is hidden
> away as it is.
>

Zipapp was introduced for a reason, .jar for a reason. This proposal also
adds in the ability of the interpreter to notify of new Python releases.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Bob van der Poel]

Oh, now we get the rational. No thank you! Enough of the world is hidden
away as it is.

On Thu, Jan 2, 2020 at 7:22 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> One of the advantages of single "executable"s is the abstraction of
> details. You don't want users to see what you included. It's an attempt at
> hiding away details for aesthetic purposes. The second reason is
> compression. You get a lighter program. The third reason is to be as
> reverse-engineer resistant as possible.
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 02:50 Barry Scott,  wrote:

> Expect for trivial programs you cannot distribute a single file python exe
> for windows.
>

You can, PyInstaller does it. You can have folder-based or single file apps

As you found zipapp is not a solution.
>

 Zipapp is a good candidate. Proposing to improve it


> Many stdlib modules use DLL's on Windows and you cannot run a DLL from
> inside a zip file.
>

PyInstaller's -F mode does it well

But, this proposal is not about native executables. It's about a .jar like
executable. As a python-specific 'executable', os is not a problem unless
of course you are using like curses on windows
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

One of the advantages of single "executable"s is the abstraction of
details. You don't want users to see what you included. It's an attempt at
hiding away details for aesthetic purposes. The second reason is
compression. You get a lighter program. The third reason is to be as
reverse-engineer resistant as possible.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 02:49 Grant Edwards,  wrote:

>
> Definitely.
>
> Single file executables aren't really "a thing" on Windows.
>


This proposal is about a .jar like file executable, not native executables

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:43 Michael Torrie,  wrote:

> On 1/2/20 2:11 PM, Abdur-Rahmaan Janhangeer wrote:
> > But single file are better suited for distribution.
>
> Maybe.  Most windows applications are distributed with installers.  I've
> made several bundles over the years with Nullsoft's installer builder.
> That's how commercial companies, including those that use Python,
> distribute their applications.  Here's a popular open source application
> build on Python, and it's installer (a single msi file):
> https://calibre-ebook.com/download_windows
>
> I haven't seen very many single-exe windows applications ever.
>

This proposal is not about native executables

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:43 Chris Angelico,  wrote:

>
> Wait, so as well as the single file, you ALSO need a Python
> interpreter? Then what's the point? Why not just distribute a .py
> file?
>

Well let's say a Flask, Django or PyQt app, a single file is not really
feasible.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 03:35 mm0fmf,  wrote:

> On 02/01/2020 09:41, Abdur-Rahmaan Janhangeer wrote:
> > i wonder who uses windows
> >
>
> I do. The man pays me well to write software for Windows and Linux and I
> don't care which . It's just an OS, write the code to do what the spec
> says. Not a difficult concept really.
>

Was a pointing out that people use windows also.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 03:25 Greg Ewing,  wrote:

> It looks like what the OP is after already exists:
>
> https://docs.python.org/3/library/zipapp.html
>
> "This module provides tools to manage the creation of zip files
> containing Python code, which can be executed directly by the Python
> interpreter."
>

Oh my, you did not read from the begining. Please do so. I would really
like to rewrite what i said but it's too long.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[mm0fmf]

On 02/01/2020 09:41, Abdur-Rahmaan Janhangeer wrote:

i wonder who uses windows



I do. The man pays me well to write software for Windows and Linux and I 
don't care which . It's just an OS, write the code to do what the spec 
says. Not a difficult concept really.


apt-get works fine for me on Linux. On Windows I currently have Python 
3.7.3 which comes with a nice installer and uninstalls via the OS apps 
management. (i.e. it has an uninstaller somewhere).



--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Greg Ewing]

It looks like what the OP is after already exists:

https://docs.python.org/3/library/zipapp.html

"This module provides tools to manage the creation of zip files 
containing Python code, which can be executed directly by the Python 
interpreter."


--
Greg

--
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Barry Scott]

> On 2 Jan 2020, at 21:17, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> On Fri, 3 Jan 2020, 01:05 Chris Angelico,  wrote:
> 
>> 
>> They are still FAR better than trying to create a single bloated
>> executable that contains everything and magically knows how and when
>> to update itself.
>> 
> 
> Proposing to freeze things. You distribute a version of the program. The
> single file (not using the word executable as it seemingly leads to
> confusions) is given with the assurance that the only thing you need is an
> interpreter for it to work.

Expect for trivial programs you cannot distribute a single file python exe for 
windows.
As you found zipapp is not a solution.

Many stdlib modules use DLL's on Windows and you cannot run a DLL from
inside a zip file.

As soon as you have a GUI interface you have to install lots of DLLs and
the C++ runtime. The only easy way to support users is by using a
windows installer. I use inno installer for windows which is a very powerful
tool, https://www.jrsoftware.org/isinfo.php 
. And I create the windows app
with https://pypi.org/project/win-app-packager/ 
 (I'm the author).

The situation for the Mac requires you to create a .app bundle.
The way these are distributed is as a compressed .dmg file.
I use py2app and dmgbuild to get the job done on macOS.

As Chris noted its easier on Linux systems. You can make a package
(.deb or .rpm) that uses the already packaged python code and libraries.

There are excellent solutions that have existed for many years to
package python apps for Windows, macOS and Linux. On Windows
and macOS it is necessary to install python, you just bundle it inside the
app.

I support two apps on Windows, macOS and unix that does exactly this.
http://barrys-emacs.org  and 
http://http://scm-workbench.barrys-emacs.org/ 


For command line tools pip knows how to install a .exe for Windows that
runs the tool. On macOS and linux its creates a small boot strap script.

As an example see my https://pypi.org/project/colour-text/ 
 project
that installs the colour-print command.

All the code for the above is open source and you can read the code
used to build the install kits.

Barry



> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Grant Edwards]

On 2020-01-02, Michael Torrie  wrote:
> On 1/2/20 2:11 PM, Abdur-Rahmaan Janhangeer wrote:
>> But single file are better suited for distribution.
>
> Maybe.  Most windows applications are distributed with installers.

Definitely.

Single file executables aren't really "a thing" on Windows.

> [...]
> I haven't seen very many single-exe windows applications ever.

Putty is still made available as a single file executable.  But, it's
the only one I've seen for a couple decades.

AFAICT, 99.999% of Windows apps are distributed as an .msi file or as
a self-extracting installer (e.g. foobar-1.2.3-setup.exe) file.  If
that's what you want to do with your python app, then you can use
cx_freeze et alia.  Packagining something for wide distribution can be
a bit a fiddly to get right: you need to know what you're doing, and
you need to do a lot of testing.

But that's true regardless of OS or language.

-- 
Grant Edwards   grant.b.edwardsYow! Are you the
  at   self-frying president?
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 8:17 AM Abdur-Rahmaan Janhangeer
 wrote:
>
>
>
> On Fri, 3 Jan 2020, 01:05 Chris Angelico,  wrote:
>>
>>
>> They are still FAR better than trying to create a single bloated
>> executable that contains everything and magically knows how and when
>> to update itself.
>
>
> Proposing to freeze things. You distribute a version of the program. The 
> single file (not using the word executable as it seemingly leads to 
> confusions) is given with the assurance that the only thing you need is an 
> interpreter for it to work.
>

Wait, so as well as the single file, you ALSO need a Python
interpreter? Then what's the point? Why not just distribute a .py
file?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 2:11 PM, Abdur-Rahmaan Janhangeer wrote:
> But single file are better suited for distribution.

Maybe.  Most windows applications are distributed with installers.  I've
made several bundles over the years with Nullsoft's installer builder.
That's how commercial companies, including those that use Python,
distribute their applications.  Here's a popular open source application
build on Python, and it's installer (a single msi file):
https://calibre-ebook.com/download_windows

I haven't seen very many single-exe windows applications ever.

Anyway we can argue forever about what ought to be.  But until someone
does it and proves that it's important, it's not going to happen.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:05 Chris Angelico,  wrote:

>
> They are still FAR better than trying to create a single bloated
> executable that contains everything and magically knows how and when
> to update itself.
>

Proposing to freeze things. You distribute a version of the program. The
single file (not using the word executable as it seemingly leads to
confusions) is given with the assurance that the only thing you need is an
interpreter for it to work.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 01:01 Michael Torrie,  wrote:

>
> But a jar file is not executable on Windows and never has been.

 

Maybe it can
> be opened with a file association linking it to a Java runtime
> executable.
>

That's it. See UMLet's distribution mode for example

As Chris said with file associations you can already double-click on a
> py file (or pyw without a console window by convention).
>

But single file are better suited for distribution.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 00:58 Chris Angelico,  wrote:

>
> I linked you to a single file executable of mine. It makes use of...
> oh hey, the system package manager. See? It works.
>

I don't understand this one

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:58 AM Michael Torrie  wrote:
>
> On 1/2/20 1:33 PM, Chris Angelico wrote:
> > Using a package manager means you have ONE copy of the Python
> > interpreter, and all your scripts depend on it. If you update that
> > interpreter, ALL scripts benefit from the update. This is a solved
> > problem.
>
> Except that it's not actually a solved problem.  We thought it was but
> then found the limitations.  Linux distros are actually moving away from
> a pure packager dependency model, especially for applications. System
> components, yes. Makes a lot of sense. Makes less sense for user-facing
> things.  That's why there's a lot of movement going with regards to
> solutions like flatpak, snap, and even AppImage.  RPMs and debs are
> never going to go away, but they do have limitations for the kind of
> thing the OP is talking about.

They are still FAR better than trying to create a single bloated
executable that contains everything and magically knows how and when
to update itself. If you're going to use snaps etc, you do so with
full control of what you're bundling together, rather than hoping that
the publisher of the program will (a) bundle the correct versions, and
(b) keep them up-to-date.

I'm not seeing any Linux distro moving towards a model where every
program author has to include the entire binary and make 32-bit and
64-bit versions available, etc, etc, etc, as is often seen elsewhere.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 1:42 PM, Abdur-Rahmaan Janhangeer wrote:
> I am not proposing native executables, but a .jar like executable. The term
> executable refers to one click run.

But a jar file is not executable on Windows and never has been.  You
can't go to the cmd.exe window and type "myprogram.jar."  Maybe it can
be opened with a file association linking it to a Java runtime
executable. But it's certainly not a Windows executable.  And I've never
ever seen anyone launch a java jar file by double clicking on it.  Most
people provide .bat files to start it, or a lnk file that contains the
necessary java flags.

As Chris said with file associations you can already double-click on a
py file (or pyw without a console window by convention).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:54 AM Abdur-Rahmaan Janhangeer
 wrote:
>>
>> Then we already have this. On Windows, set your file associations
>> appropriately. On Unix-like platforms, have a shebang at the start,
>> and chmod it +x.
>
>
> Not proposing only executable but single file executable.
>

I linked you to a single file executable of mine. It makes use of...
oh hey, the system package manager. See? It works.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 1:33 PM, Chris Angelico wrote:
> Using a package manager means you have ONE copy of the Python
> interpreter, and all your scripts depend on it. If you update that
> interpreter, ALL scripts benefit from the update. This is a solved
> problem.

Except that it's not actually a solved problem.  We thought it was but
then found the limitations.  Linux distros are actually moving away from
a pure packager dependency model, especially for applications. System
components, yes. Makes a lot of sense. Makes less sense for user-facing
things.  That's why there's a lot of movement going with regards to
solutions like flatpak, snap, and even AppImage.  RPMs and debs are
never going to go away, but they do have limitations for the kind of
thing the OP is talking about.  Right now in Fedora land, a very
appropriate way to bundle a python application is in a flatpak, bundled
with the appropriate versions of Python and the libraries you depend on.
 More and more apps on Ubuntu are being delivered via snaps too.
Especially ones that move fast like Firefox, or even LibreOffice.

I use several apps that are flatpaks because my distro is old and stable
(CentOS 7) and doesn't have a lot of the dependent shiny libs modern
apps require. Flatpak lets me run them while keeping the core system
very conservative and stable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

>
> Then we already have this. On Windows, set your file associations
> appropriately. On Unix-like platforms, have a shebang at the start,
> and chmod it +x.
>

Not proposing only executable but single file executable.

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:42 AM Abdur-Rahmaan Janhangeer
 wrote:
>
>
>
> On Fri, 3 Jan 2020, 00:33 Chris Angelico,  wrote:
>>
>> A jar is just an archive of Java class files. It's approximately
>> equivalent to a zip file of .pyc files.
>
>
> Exactly the idea, that's why i said zipapp might be a good candidate
>
>> No, but there are package managers for Windows and Mac too. (I don't
>> think there's any first-party package manager for Macs, but there are
>> some very popular third-party ones eg Homebrew.)
>>
>> ...
>>
>> And that's the problem: the single-file executable requires you to
>> bundle everything, update it yourself, and duplicate all the code
>> everywhere.
>>
>> Using a package manager means you have ONE copy of the Python
>> interpreter, and all your scripts depend on it. If you update that
>> interpreter, ALL scripts benefit from the update. This is a solved
>> problem.
>
>
> I am not proposing native executables, but a .jar like executable. The term 
> executable refers to one click run.
>

Then we already have this. On Windows, set your file associations
appropriately. On Unix-like platforms, have a shebang at the start,
and chmod it +x. Example:

https://github.com/Rosuav/shed/blob/master/steamguard

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 00:33 Chris Angelico,  wrote:

> A jar is just an archive of Java class files. It's approximately
> equivalent to a zip file of .pyc files.
>

Exactly the idea, that's why i said zipapp might be a good candidate

No, but there are package managers for Windows and Mac too. (I don't
> think there's any first-party package manager for Macs, but there are
> some very popular third-party ones eg Homebrew.)
>
> ...
>
> And that's the problem: the single-file executable requires you to
> bundle everything, update it yourself, and duplicate all the code
> everywhere.
>
> Using a package manager means you have ONE copy of the Python
> interpreter, and all your scripts depend on it. If you update that
> interpreter, ALL scripts benefit from the update. This is a solved
> problem.
>

I am not proposing native executables, but a .jar like executable. The term
executable refers to one click run.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 7:22 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> On Fri, 3 Jan 2020, 00:14 Chris Angelico,  wrote:
>>
>>
>> What do you mean by "Python-specific executable"?
>
>
> a Python equivalent of .jar

A jar is just an archive of Java class files. It's approximately
equivalent to a zip file of .pyc files. You can't run a .jar file
without a Java interpreter.

>> Your Python code can go anywhere if you package it up in, say, a .deb
>> or .rpm,
>
> Not everybody uses Linux

No, but there are package managers for Windows and Mac too. (I don't
think there's any first-party package manager for Macs, but there are
some very popular third-party ones eg Homebrew.)

>> I
>> don't understand how "run on any device" relates to "automatically
>> update the Python interpreter",
>
>
> Two unrelated suggestions
>
>> but it's still a solved problem: *use
>> a package manager*.
>
>
> Single-file executables are slick. End-users want to only use the app.

And that's the problem: the single-file executable requires you to
bundle everything, update it yourself, and duplicate all the code
everywhere.

Using a package manager means you have ONE copy of the Python
interpreter, and all your scripts depend on it. If you update that
interpreter, ALL scripts benefit from the update. This is a solved
problem.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

On Fri, 3 Jan 2020, 00:14 Chris Angelico,  wrote:

>
> What do you mean by "Python-specific executable"?
>

a Python equivalent of .jar


> Your Python code can go anywhere if you package it up in, say, a .deb
> or .rpm,


Not everybody uses Linux

I
> don't understand how "run on any device" relates to "automatically
> update the Python interpreter",


Two unrelated suggestions

but it's still a solved problem: *use
> a package manager*.
>

Single-file executables are slick. End-users want to only use the app.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Fri, Jan 3, 2020 at 6:39 AM Abdur-Rahmaan Janhangeer
 wrote:
> Having a Python-specific executable allows you to go to whatever length you
> desire to make project bundling an easy task. The other effort is to get
> your interpreter/VM running on as many hardwares as possible. This includes
> the effort to make it lighter, faster etc. It might entails the complete
> removal of 3rd party packaging interpreter side or not using it when
> running the specific executable.
>
> I believe Python should be able to run on any device. I believe that my
> Python code should go everywhere. It pains me to see a project not choosing
> Python as an add-on scripting language due to the size of the interpreter
> or things of the sort.

What do you mean by "Python-specific executable"?

Your Python code can go anywhere if you package it up in, say, a .deb
or .rpm, and then just depend on a Python interpreter of appropriate
version. You can allow your users to manage their own updates so long
as it's within the dependency range you have chosen to support. I
don't understand how "run on any device" relates to "automatically
update the Python interpreter", but it's still a solved problem: *use
a package manager*.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

Coincidentally, one day before i posted this approach, a user posted on
Idle-dev:

[Idle-dev] Wishlist: Make executables + startup option

which proposes the idea of adding an option to generate a single executable
from Idle. It reflects the profound desire of the community to distribute
their apps professionally.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

Oh auto-3rd party modules is a mess. Suggesting updating only the
interpreter. We can have a pre-scan which warns the user that upgrading
will make the following packages no longer compatible. But that's one aim
of venvs i think, is to confine packages to projects, not to the
interpreter.

No java does not have such a feature, it's a suggestion that's unrelated to
Java.

For distributing to clients, you don't rely on the user interpreter for
packages. As far as I know, some companies select let's say version 1.0.5
of a library, and ... they keep it internal, they might modify it as
desired. It becomes a home pet. They distribute this version with their
project. Even if the library is at 2. they use the modified 1. for
increased stability. That's one extreme.

Having a sort of .jar running with the system interpreter concerns syntax
and enforced standards.

To further ease dist, much work is required to be done on the project
format itself. If i remember well, a PEP proposed to install 3rd party
packages in a folder in the project, which might further enhance the
process.

Having a Python-specific executable allows you to go to whatever length you
desire to make project bundling an easy task. The other effort is to get
your interpreter/VM running on as many hardwares as possible. This includes
the effort to make it lighter, faster etc. It might entails the complete
removal of 3rd party packaging interpreter side or not using it when
running the specific executable.

I believe Python should be able to run on any device. I believe that my
Python code should go everywhere. It pains me to see a project not choosing
Python as an add-on scripting language due to the size of the interpreter
or things of the sort.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Michael Torrie]

On 1/2/20 2:41 AM, Abdur-Rahmaan Janhangeer wrote:
> i wonder who uses windows

If this kind of thing is important to a user , what you propose would
probably be the responsibility of the entity that is producing a Python
distribution, such as Anaconda.  Usually in such cases these
distributions are not targeted at developers per se, but scientific
users who write small programs to solve particular problems.  And it may
be appropriate in that case.

Python is just a language specification and some tools (including a
reference implementation of the interpreter and standard library). It's
not an IDE and it's not a software distribution.  I know that other
languages have turned themselves into such things.  Particularly node.js
with npm, and that has been a real mess on occasion.  I haven't heard
anything about Java being like this, though.  I guess Visual Studio has
added a package manager.  However that's separate from the language
itself (C#, C++, etc).

How would you determine what should be updated? The core libraries are
already updated with the interpreter version, and have some dependency
on the interpreter version.  You seem to be suggesting that third-party
libraries from PyPi or other places should automatically update, and
that seems like a bad idea to me, as they each operate under their own
standards of API compatibility, quality, and so forth.  All you have to
do is look at the mess that is npm in node.js to see what this idea has
some real problems if you were to update everything in one swoop in a
semi-automated fashion.

Personally if I were working on a large Python project that I wanted to
release to clients involving a few third-party packages, I would not be
interested in any sort of automatic updating.  Without testing, such
automatic updates could easily break my program.  And the last thing I'd
want is a client or customer to be updating dependencies on his own!

How would you address these issues?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

i wonder who uses windows

On Thu, 2 Jan 2020, 12:38 Chris Angelico,  wrote:

> On Thu, Jan 2, 2020 at 6:20 PM Abdur-Rahmaan Janhangeer
>  wrote:
> >
> > if not self-updating, at least the ability to update
> >
>
> That's a package manager's job.
>
> $ sudo apt update
> $ sudo apt upgrade
>
> Job done. The wheel does not need to be reinvented.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Chris Angelico]

On Thu, Jan 2, 2020 at 6:20 PM Abdur-Rahmaan Janhangeer
 wrote:
>
> if not self-updating, at least the ability to update
>

That's a package manager's job.

$ sudo apt update
$ sudo apt upgrade

Job done. The wheel does not need to be reinvented.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[Abdur-Rahmaan Janhangeer]

if not self-updating, at least the ability to update

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

Mauritius
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

[o1bigtenor]

On Wed, Jan 1, 2020 at 1:24 AM Abdur-Rahmaan Janhangeer
 wrote:
>
> Greetings list,
>
> I wanted to make some suggestion about the Python interpreter but since
> it's more high-level, i decided to post it here instead of python-ideas.
>
> Well, concerning distributing Python apps, a natural way is to compile to
> native executables. But, another way is to have a python-specific
> executable which specifically requires the Python interpreter to be
> installed on the system. To that end, i propose
>
> -- Self-updating Python distributions
> -- Distributions which notify about new releases
> -- Easy compilation to python-specific executable (.pyz is a good candidate)
> -- More robust native Gui facilities
>
Speaking as just a very newbie very unskilled computer programmer I can tell
you that if Python decided to go to self-updating that that would be
the day that
I stopped using Python. Why?

I spent a considerable amount of time investigating containers and when it
became clear that the version that I was looking into had forced me into
accepting this self-updating I tried to figure out a way to 'control'
that feature.
I won't bore you with the whole mess but the end result was that the only way
that I could regain control over my computer - - - - I couldn't even
delete major
parts of that subsystem - - - - well it was a complete reinstall.

That, imo a very very M$ solution is something I spent many hours trying NOT
to do so anything that wants to take me to such again - - - - it will
get dropped.

To the powers that be - - - - please do NOT program Python to be
self-updating!!

Regards
-- 
https://mail.python.org/mailman/listinfo/python-list