Python, Be Bold! - The Draft

[Abdur-Rahmaan Janhangeer]

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.

Abstract
==

This original proposal outlines 3 points to enhance app making in Python,
namely:

-- The formulation of a Python-specific single-file executable (Archive)
-- Better integration of the VM with the OS
-- Features to be supported by the native Gui library

This proposal aims at working to boost the dissemination of Python apps
and help further promote Python as the language of choice for developing
apps. It explores beyond performance, what can be improved? But since
the previous thread focused on the archive, we'll focus on it in this draft.

Aim Expansion


One area where there remains some difficulty in Python is packaging for
end-user consumption. To that effect either the code is distributed in pure
Python form with installers or native executables are built for each target
Os. Currently by default, Python does not provide such utilities. This pro-
posal aims at finalising a Python-specific archive as the default VM exec-
utable.

To further support the above, the proposals explores the impacts on the
interpreter: how should it be modified. Modifications explored don't
touch the parser in any way. Instead of discussing how to better integrate
the official dist with the System, this will discuss only archive-specific
mod-
ifications.

A push to choose Python might be providing better GUI options, so that
apps become more powerful, more beautiful and with even faster develop-
ment time. The proposal aimed to show the limitations of the current GUI
option  (tkinter) and what features can make app-making using default uti-
lities a class above. But, it is bulky enough to be discussed in a
different
draft.

In the light of the above, this draft's topic will be:

Python-specific Executable Archive.


Python-specific Executable Archive
===

Inspiration
--

Java has a file format called .jar which allows bundled programs to be run
with
a simple click.

Defining Executable
---

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. This is
made
possible by file association. The closest example existent is the .pyz file
format.
Although for example .jar files are not native executables, they are
nonetheless
referred to in common language as executable as in question like these:
How to create an executable jar in java
.

Closest Python Implementation
-

Python already has an archive bundling module called zipapp which allow a
project to be bundled as a zip archive which has __main__.py as an point.

Advantages of zip-executables
-

PEP441  states one of the
advantage as: "These archives provide a great way to
publish software that needs to be distributed as a single file script but
is complex
enough to need to be written as a collection of modules."

Oracle Docs

state the advantage of archive executables in the following term:

"JAR files are packaged with the ZIP file format, so you can use them for
tasks
such as lossless data compression, archiving, decompression, and archive
unpacking.
These tasks are among the most common uses of JAR files, and you can
realize many JAR file benefits using only these basic features.

Even if you want to take advantage of advanced functionality provided by the
JAR file format such as electronic signing ..."

Other advantages include
- Portability
- Security
- Versioning
- Dependency freezing

which will be discussed when discussing specific examples.

How a .jar can help?


Both Java and Python share similarities in having a VM, bytecodes and being
labelled as cross-platform languages. Java has a .jar format for
distribution.
The .jar file gave rise to many formats such as the .apk


Brief


This proposal proposes to alter  zipapp with enhanced security and
versioning
among others. It can have a .pyz extention or choose another extention.


Existing solutions
==

In this section we give an overview of existing file formats.

1) .Jar
-

An official intro
 runs
like this: "JAR file is a file format based on the popular ZIP
file format and is used for aggregating many files into one. A  JAR file is
essentially a zip file that contains an optional META-INF directory. A JAR
file can be created by the command-line jar tool, or by 

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: Dataset training using Kmeans

[Rhodri James]

On 05/01/2020 12:56, hanan lamaazi wrote:

Dear all,

I'm actually using the K-means algorithm for clustering, and scikit-learn
machine learning in python.

when I want to print my "score_accuarcy" using this command


print(metrics.accuracy_score(y_test, y_pred))


I get the following error :

"Classification metrics can't handle a mix of continuous-multioutput and
binary targets"


This is probably an exception from metrics.accuracy_score() (you've 
shorn off too much context for me to be certain).  Googling the text 
gives me no shortage of links; you are far more likely than me to 
recognise which of them are relevant to your circumstances.


--
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!

[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

[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! - 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

[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, 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!

[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

Python, Be Bold! - The Draft

[Abdur-Rahmaan Janhangeer]

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


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.

On Mon, 6 Jan 2020, 10:39 pm 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
>
-- 
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: Hi!! im searching for a ready app of python for pdf combiner

[Rob Gaddi]

On 1/6/20 8:13 AM, alon.naj...@gmail.com wrote:

Hi!! im searching for a ready app of python for pdf combiner
what I need exactly is a pdf combiner for 20 + pdfs to combine them as one, do 
a merge



Why does this need to be in Python?  Just download a copy of pdftk (which I 
think is written in Java?) and move on with your life.

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

Re: (no subject)

[Rob Gaddi]

On 1/4/20 2:29 PM, William Johnsson wrote:

Hello! My name is William and im 14 years old and live in sweden.  Im pretty 
new to programing in python and i need some help with code, (That’s why i’m 
here). But i couldn’t really find what i was searching for on the internet. I’m 
trying to write code that can check only the first line in a .txt file and 
check if it’s the same as the int 1000.   I preferably want it to be an if 
satement but anything works, i just don’t know how i should write it. I’ve been 
browsing the internet for a solution but sadly can’t seem to find a solution to 
it.

I don’t really know if this is the right way to get help or even if this email 
is for something else. Hopefully i will get some kind of response.

Best regards, William



It won't be; it can't be.  A text file contains only text.  The line you read 
from it might be the string '1000' (or more likely '1000\n', which is 4 digits 
followed by a newline character), but it cannot be the int 1000 because data has 
types.


str(1000) gives you '1000', because ints can be converted to strings. 
int('1000') gives you 1000 because and strings consisting only of digits can be 
converted to ints.  So the two types are convertible into one another.  But 
that's a thing you need to do explicitly.  If x is a thing you just read from a 
text file then


if x == 1000:

can never be true.
--
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

[no subject]

[AAKASH JANA]

Julia is a rapidly progressing language directly attacking python's sweet
spot in a.i , m.l and other computational areas. I love python and want it
to remain undefeated . I think its time we create a compiler for python .
So that python can be compiled and interpreted at will . Its time we make
our snake go faster than the world.(and most importantly Julia)
-- 
https://mail.python.org/mailman/listinfo/python-list

Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Note: draft simplified

Abstract
==

This extracts aims at proposing enhancements to the generated zipapp
executable

Rationale
===

One area where there remains some difficulty in Python is packaging for
end-user consumption. To that effect either the code is distributed in pure
Python form with installers [1] or native executables are built for each
target
Os [2]. Currently by default, Python does not provide such utilities. This
pro-
posal aims at finalising a Python-specific archive as the default VM exec-
utable built on zipapp.

In simple terms, it proposes to enhance zipapp from plain archive to
app-level
archive.

Advantages of archives
==

Archives provide a great way to publish software that needs to be
distributed as
a single file script but is complex enough to need to be written as a
collection of
modules [3]

You can use archives for tasks such as lossless data compression,
archiving,
decompression, and archive unpacking. [4] Adding capabilities like digital
signing is used to verify integrity and authenticity.

Zip archives as apps


If we are to treat zip archives as app, here are some recommended features

- [x] Main entry point

A main entry point specifies which file to launch. Zipapp already solves
this
problem by either having a __main__.py [5] or specifying the entry point at
the
commandline ENTRYPOINT_MODULE:ENTRYPOINT_FUNCTION [6]

- [  ] App info file

An info file can have info such as author name, archiving date, company name
etc.

- [  ] Signing mechanism

Mechanisms can be added to detect the integrity of the app. App hash can be
used to check if the app has been modified and per-file hash can be used to
detect what part has been modified. This can be further enhanced if needed.

- [  ] Protecting meta data

Metadata are not protected by basic signing. There existing ways to protect
metadata and beyond [7]

 - [x] Pure-Python 3rd party package bundling

In Python, as long as the 3rd party packages are pure-python packages, we
can bundle and use them [6]. The user can maybe just include a
requirements.txt

- [  ] C-based 3rd party packages

Zipapp by default was not meant to include packages at all.

<< The executable zip format is specifically designed for standalone use,
without needing to be installed. They are in effect a multi-file version of
a
standalone Python script >>

Though the previous point shows that this can be done. Now remains the
issue of C-based packages. Distributing wheels might be the answer [8].
A zip archive is supposed to be standalone. A possible  solution might be
to
include wheels and the wheels are installed in a site-packages folder.

When running such an app, the interpreter will check first if the
app-specific
site-packages folder is empty, if not, install the wheels. This provides
package-
freezing ability. The only downside is longer first-run time.

Only specifying packages to be installed is not an option as if you really
want
stand-alone apps, using the internet etc defeats the purpose.

FAQ


Why not a package manager?
---
The zipapp pep was introduced for a reason, for easing the running of
archives.
Maybe the package manager idea came from listening to people talking about
packaging and pex and comparing it with package-managers like homebrew
and concluded that pex and hence zipapp is not worth it and people would
better off not complicate their lives with some zip utility.

This proposal is not solving any problem at all
--
This proposal aims at enhancing zipapp. Zipapp solved the problem. Zipapp
had an aim. This proposal aims at helping zipapp better accompplish it's
aim.


References

[1] https://pynsist.readthedocs.io/en/latest/

[2] https://www.pyinstaller.org

[3] https://www.python.org/dev/peps/pep-0441/

[4] https://docs.oracle.com/javase/tutorial/deployment/jar/basicsindex.html

[5] https://docs.python.org/3/library/zipapp.html

[6] https://gist.github.com/lukassup/cf289fdd39124d5394513a169206631c

[7] https://source.android.com/security/apksigning

[8] https://pythonwheels.com



Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

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

Hi!! im searching for a ready app of python for pdf combiner

[alon . najman]

Hi!! im searching for a ready app of python for pdf combiner
what I need exactly is a pdf combiner for 20 + pdfs to combine them as one, do 
a merge
-- 
https://mail.python.org/mailman/listinfo/python-list

Re:

[Chris Angelico]

On Tue, Jan 7, 2020 at 6:35 AM AAKASH JANA  wrote:
>
> Julia is a rapidly progressing language directly attacking python's sweet
> spot in a.i , m.l and other computational areas. I love python and want it
> to remain undefeated . I think its time we create a compiler for python .
> So that python can be compiled and interpreted at will . Its time we make
> our snake go faster than the world.(and most importantly Julia)

If you're that green with envy, go and create one. See whether it
improves things. You'll learn a lot in the process.

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

Re: [Python-ideas] Enhancing Zipapp

[Chris Angelico]

On Tue, Jan 7, 2020 at 6:37 AM Abdur-Rahmaan Janhangeer
 wrote:
> When running such an app, the interpreter will check first if the app-specific
> site-packages folder is empty, if not, install the wheels. This provides 
> package-
> freezing ability. The only downside is longer first-run time.

Where is this directory? What if it already contains content?

Are you proposing that *any* zipapp archive is capable of downloading
arbitrary code from the internet and then running it, without any
prompting from the user?

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

Re: [Python-ideas] Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

Mauritius


On Mon, Jan 6, 2020 at 11:53 PM Chris Angelico  wrote:

> On Tue, Jan 7, 2020 at 6:37 AM Abdur-Rahmaan Janhangeer
>  wrote:
> Where is this directory? What if it already contains content?
>

It's sometimes typical for extracted zips to be in temporary folders. If we
are including
wheels maybe we can have a permanent folder for extracting the wheels and
the
interpreter looks for those in it

Are you proposing that *any* zipapp archive is capable of downloading
> arbitrary code from the internet and then running it, without any
> prompting from the user?
>

Exactly the opposite, the archive bundler includes all that have to be
included so that
the app runner does not have to do it. Proposing to include pa

If we are talking about the scenario where a malware already lying in wait
in the
packages folder then it's the same as malware entering the interpreter's
site-packages

If we are talking about malicious code in a package that gets called when
running the zipapp
without prompt, then that's the same issue with all executables (like apps
built with pyinstaller).
If ever we want to mitigate that risk, it depends if we trust the sender.
That's also where the
proposed security features come into play.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Tue, Jan 7, 2020 at 12:15 AM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

> Proposing to include pa
>

please ignore that part
-- 
https://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-5.3: YAML parser and emitter for Python

[Tina Müller]

===
Announcing PyYAML-5.3
===

A new release of PyYAML is now available:
https://pypi.org/project/PyYAML/

This release contains some bugfixes (handling of slots, enable unicode for
maxunicode < 0x, enable large files), enhancements (create timezone
aware datetimes) and some other small enhancements.

Changes
===

* https://github.com/yaml/pyyaml/pull/290 -- Use `is` instead of equality for 
comparing with `None`
* https://github.com/yaml/pyyaml/pull/270 -- fix typos and stylistic nit
* https://github.com/yaml/pyyaml/pull/309 -- Fix up small typo
* https://github.com/yaml/pyyaml/pull/161 -- Fix handling of __slots__
* https://github.com/yaml/pyyaml/pull/358 -- Allow calling 
add_multi_constructor with None
* https://github.com/yaml/pyyaml/pull/285 -- Add use of safe_load() function in 
README
* https://github.com/yaml/pyyaml/pull/351 -- Fix reader for Unicode code points 
over 0x
* https://github.com/yaml/pyyaml/pull/360 -- Enable certain unicode tests when 
maxunicode not > 0x
* https://github.com/yaml/pyyaml/pull/359 -- Use full_load in yaml-highlight 
example
* https://github.com/yaml/pyyaml/pull/244 -- Document that PyYAML is 
implemented with Cython
* https://github.com/yaml/pyyaml/pull/329 -- Fix for Python 3.10
* https://github.com/yaml/pyyaml/pull/310 -- increase size of index, line, and 
column fields
* https://github.com/yaml/pyyaml/pull/260 -- remove some unused imports
* https://github.com/yaml/pyyaml/pull/163 -- Create timezone-aware datetimes 
when parsed as such
* https://github.com/yaml/pyyaml/pull/363 -- Add tests for timezone


Resources
=

PyYAML IRC Channel: #pyyaml on irc.freenode.net
PyYAML homepage: https://github.com/yaml/pyyaml
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation
Source and binary installers: https://pypi.org/project/PyYAML/
GitHub repository: https://github.com/yaml/pyyaml/
Bug tracking: https://github.com/yaml/pyyaml/issues

YAML homepage: http://yaml.org/
YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages. PyYAML is a YAML parser and emitter for
Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support,
capable extension API, and sensible error messages. PyYAML supports standard
YAML tags and provides Python-specific tags that allow to represent an
arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex configuration
files to object serialization and persistence.


Example
===


import yaml



yaml.full_load("""

... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: https://github.com/yaml/pyyaml
... keywords: [YAML, serialization, configuration, persistence, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistence',
'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}


print(yaml.dump(_))

name: PyYAML
homepage: https://github.com/yaml/pyyaml
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistence, pickle]


Maintainers
===

The following people are currently responsible for maintaining PyYAML:

* Ingy döt Net
* Tina Mueller
* Matt Davis

and many thanks to all who have contribributed!
See: https://github.com/yaml/pyyaml/pulls


Copyright
=

Copyright (c) 2017-2019 Ingy döt Net 
Copyright (c) 2006-2016 Kirill Simonov 

The PyYAML module was written by Kirill Simonov .
It is currently maintained by the YAML and Python communities.

PyYAML is released under the MIT license.
See the file LICENSE for more details.






--
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:

[Michael Torrie]

On 1/6/20 10:06 AM, AAKASH JANA wrote:
> Julia is a rapidly progressing language directly attacking python's sweet
> spot in a.i , m.l and other computational areas. I love python and want it
> to remain undefeated . I think its time we create a compiler for python .
> So that python can be compiled and interpreted at will . Its time we make
> our snake go faster than the world.(and most importantly Julia)

Why is it so important for "python to remain undefeated?" Furthermore
what do you suppose Python is "undefeated" at?  If Julia is better
suited to certain computational areas, then more power to it.  As I
posted just a few minutes ago, languages come and go, and specialize in
certain things.  Python certainly is popular right now and good at lots
of things, but something else might come along and relegate it to a fond
memory.

Besides, for obvious reasons, Python doesn't lend itself to compiling.
It's too dynamic.  Either you get slow executables where some code can
be compiled and other bits are interpreted (nuitka), or you get a
language that is a subset of python that compiles to a very fast
executable or library (Cython).

Honestly, for what most people use Python for, compiling is of little
value.  Even math people who use Python, rely on numpy or similar
high-speed libraries which are written in a compiled language and used
from Python.  This is, in my opininon, what Python excels at.  It's an
easy-to-use glue for connecting parts.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Enhancing Zipapp

[Barry Scott]

> On 6 Jan 2020, at 19:34, Abdur-Rahmaan Janhangeer  
> wrote:
> 
> Note: draft simplified

Please cover the pro's and con's of the alernatives that have been raised as 
comments
on this idea, as is usually done for a PEP style document.

Also beware that zip file format does not include the encoding of the files 
that are in the
zip file. This means that for practical purposes only ASCII filenames are 
portable across
systems. Is this limitation a problem for this proposal?

Barry

-- 
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-ideas] Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

On Tue, 7 Jan 2020, 01:57 Barry Scott,  wrote:

>
>
> Please cover the pro's and con's of the alernatives that have been raised
> as comments
> on this idea, as is usually done for a PEP style document.
>

Thanks, i don't have much experience writing peps and
if i don't bug you may i ask what "alternatives" refer to?

Also beware that zip file format does not include the encoding of the files
> that are in the
> zip file.


For the encoding of the contents, well since we are
packaging python code files, it's handling will be the same
as handling outside the zip file. It's handling is the
same as how zipapp handles things.

This means that for practical purposes only ASCII filenames are portable
> across
> systems. Is this limitation a problem for this proposal?
>

If we are talking about filenames, then i guess
ascii filenames are the way to go as you'd
unnecessarily break things otherwise.

>
-- 
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]

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-ideas] Re: Enhancing Zipapp

[Christopher Barker]

I’m a bit unclear on how far this goes: is it just a bit more specific with
more meta-data standards?

Or are you aiming for something that will run without a Python install?

Other issues:

Are you aiming for a bundle that can run on multiple platforms? If so, then
it’ll have to have a way to bundle multiple compiled extensions and select
the right ones at runtime.

If this Is essentially just zipapp with the ability to bundle dependencies,
then you could probably just do some sys.path hackery.

In any case, thus seems like something you could implement, and then see if
people find it useful.

BTW- I’m pretty sure we could simply specify that filenames are utf-8 and
we’d be good to go.

-CHB





On Mon, Jan 6, 2020 at 5:50 PM Abdur-Rahmaan Janhangeer <
arj.pyt...@gmail.com> wrote:

>
>
> On Tue, 7 Jan 2020, 01:57 Barry Scott,  wrote:
>
>>
>>
>> Please cover the pro's and con's of the alernatives that have been raised
>> as comments
>> on this idea, as is usually done for a PEP style document.
>>
>
> Thanks, i don't have much experience writing peps and
> if i don't bug you may i ask what "alternatives" refer to?
>
> Also beware that zip file format does not include the encoding of the
>> files that are in the
>> zip file.
>
>
> For the encoding of the contents, well since we are
> packaging python code files, it's handling will be the same
> as handling outside the zip file. It's handling is the
> same as how zipapp handles things.
>
> This means that for practical purposes only ASCII filenames are portable
>> across
>> systems. Is this limitation a problem for this proposal?
>>
>
> If we are talking about filenames, then i guess
> ascii filenames are the way to go as you'd
> unnecessarily break things otherwise.
>
>> ___
> Python-ideas mailing list -- python-id...@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-id...@python.org/message/RVGFMDP3PG6TXFQGH7ISRLYM4FS5CO64/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
-- 
https://mail.python.org/mailman/listinfo/python-list

Python ABI typeslots for buffer protocol

[nerdynelsons]

Hello, 

I am trying to implement the buffer API for the JPype Python module.  
Unfortunately the required type slots (Py_bf_getbuffer, Py_bf_releasebuffer) 
are currently disabled due to the long since closed issue #10181.  JPype is a 
bridge module between Java and Python and as such it is required to create a 
many dynamic types.  Thus I am forced to use the ABI interface.  

I read through all of Issue #10181 in which the developers were discussing 
various problems with the implementation of the buffer interface for Python 
3.3.  At some point they decided to disable that part of the ABI, but then they 
closed the issue leaving the ABI interface disabled with a reference to the 
closed issue.

I have read through the CPython code and do not see anyway short of hacking the 
tables to implement the buffer interface for dynamically created types. Is 
there an alternative way to use the buffer feature?  Is the PyBuffer protocol 
actually usable or is it intended to be disabled?

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

Understanding bytecode arguments: 1 byte versus 2 bytes

[adam . preble]

I'm trying to understand the difference in disassemblies with 3.6+ versus older 
versions of CPython. It looks like the basic opcodes like LOAD_FAST are 3 bytes 
in pre-3.6 versions, but 2 bytes in 3.6+. I read online somewhere that there 
was a change to the argument sizes in 3.6: it became 2 bytes when it used to be 
just one. I wanted to verify that. For 3.6, if an opcode takes an argument, can 
I always assume that argument is just one byte?

I can think of some situations where that doesn't sounds right. For example, 
JUMP_ABSOLUTE would be a problem, although I have yet to see that opcode in the 
wild. Actually, I'd be worried about more involved jumps because it sounds like 
with just a single-byte offset that I'd have to sometimes make trampolines to 
jump to where I ultimately need to be. Again, I haven't really hit that, but 
I'm also use 2-byte opcodes.

What I have works, but it looks ... fairly simple for me to reduce the opcode 
size so I wanted to understand some of the decisions that were made go to a 
single-byte argument size in 3.6.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Understanding bytecode arguments: 1 byte versus 2 bytes

[Chris Angelico]

On Tue, Jan 7, 2020 at 5:01 PM  wrote:
>
> I'm trying to understand the difference in disassemblies with 3.6+ versus 
> older versions of CPython. It looks like the basic opcodes like LOAD_FAST are 
> 3 bytes in pre-3.6 versions, but 2 bytes in 3.6+. I read online somewhere 
> that there was a change to the argument sizes in 3.6: it became 2 bytes when 
> it used to be just one. I wanted to verify that. For 3.6, if an opcode takes 
> an argument, can I always assume that argument is just one byte?
>
> I can think of some situations where that doesn't sounds right. For example, 
> JUMP_ABSOLUTE would be a problem, although I have yet to see that opcode in 
> the wild. Actually, I'd be worried about more involved jumps because it 
> sounds like with just a single-byte offset that I'd have to sometimes make 
> trampolines to jump to where I ultimately need to be. Again, I haven't really 
> hit that, but I'm also use 2-byte opcodes.
>
> What I have works, but it looks ... fairly simple for me to reduce the opcode 
> size so I wanted to understand some of the decisions that were made go to a 
> single-byte argument size in 3.6.
>

There was an extensive discussion about it. If you want to go poking
around, the keyword to search for is "wordcode". It's quite an
interesting read if you are in no hurry to go anywhere else. :)

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

Re: [Python-ideas] Re: Enhancing Zipapp

[Abdur-Rahmaan Janhangeer]

Yours,

Abdur-Rahmaan Janhangeer
pythonmembers.club  | github

Mauritius


On Tue, Jan 7, 2020 at 6:40 AM Christopher Barker 
wrote:

> I’m a bit unclear on how far this goes: is it just a bit more specific
> with more meta-data standards?
>

- More metadata
- Integrity check with hashing
- Protecting the meta data
- Bundling 3rd party packages

Or are you aiming for something that will run without a Python install?
>

Aie aie Mr. Christopher, zipapp requires a Python install

Other issues:
>
> Are you aiming for a bundle that can run on multiple platforms? If so,
> then it’ll have to have a way to bundle multiple compiled extensions and
> select the right ones at runtime.
>

According to the discussion on the Python, Be Bold thread, it became
clear that it will be a pain to generate and will have an unnecessary
size but sure this a most stable idea

Suggesting instead to include wheels. The wheels are installed. The
interpreter looks for packages in that app-specific folder

If this Is essentially just zipapp with the ability to bundle dependencies,
> then you could probably just do some sys.path hackery.
>

Could you please explain more. Thanks?

In any case, thus seems like something you could implement, and then see if
> people find it useful.
>

That's a nice idea to have a working demo. I'm not a security
expert but i'll try!

Anyone interested in this thread can view this tool
 built by LinkedIn which
attempts dependencies bundling.

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