Hello there,
If I have simply missed a double colon starting a for loop
File "./bbq.py", line 160
for config_file in config_files
^
SyntaxError: invalid syntax
the message is not as straightforward.
I am not sure what the status quo of these messages are, but: could it
be enhanced?
Ντέντος Σταύρος
Absolute seeking on a StringIO treats the offset as a character count regardless of the contents, so given that there is no "pretend it's UTF-8 and advance a given number of 'bytes'" machinery anyway, there's no reason not to allow seeking relative to the current location or the end of the 'file'. The error message is also misleading: "Can't do nonzero cur-relative seeks" even when the seek is relative to the end.
Hi folks,
I have a few decades of experience with software engineering using
assembler, C, FORTRAN, Pascal, Ada and a fair number of other languages.
I've been using Python as well for a number of years now.
Both Pascal and Ada have "end" statements, which make the code (at least
for me :-) ) a lot more readable and maintainable, especially if the
code within if/while/for statements gets longer and nested deeper. These
statements exist in these languages for a good reason.
I had a look in the archives to see if someone else already proposed
this but couldn't find anything, so here goes.
Please let me know whether you think this idea is worth to convert to a PEP.
thanks,
Jan
Idea:
To include optional "end if", "end while", "end for" and "end <function
name>", "end <class name>" in the language. The Python interpreter would
test that any "end" matches with the correct corresponding statements
and have the correct indentation, in other words throw an error if you
would write "end if" where an "end while" should be. This will be a
great help preventing errors with procedural logic, that I now have to
painstakingly debug at runtime, especially after moving bits of code around.
Python editors would ideally highlight "if" and "end if" just like they
now highlight "if". By default different colors could be picked for "if"
and "end if", "while" and "end while" etc.
All this is completely optional of course, so it won't break any
existing code.
Advantages:
- better readability and maintainability
- help prevent procedural logic mistakes
- editors could use this for improved highlighting of code
Disadvantages:
- none :-) it's optional, just like the typing that was introduced in
Python 3
Code example:
def func (i: int, j: int, k: int) -> None:
if (i == 3):
while (i < 15):
i += 1
if (k == 8):
lots of other code (think a page or more)
lots of other code
here is more code <- to which if or while does this belong?
and a bit more
further code
The code could be rewritten like this:
def func (i: int, j: int, k: int) -> None:
if (i == 3):
while (i < 15):
i += 1
if (k == 8):
lots of other code (think a page or more)
lots of other code
end if
end while (writing "end if" would throw an error at parse time)
here is more code
and a bit more
end if
end func
further code
Looking forward to your feedback!
regards,
Jan
NEW ZEALAND
Hey everyone,
I recently used list.count() in a coding interview and the question arose
about how scale-able this solution was for sufficiently large input.
Currently, list.count iterates through the list, incrementing the count as
it goes and returning the value at the end. This does not lend itself well
to large inputs.
I propose either modifying the list struct to include a map of item ->
count, or implementing a new structure with this information that is
allocated separately when a list is instantiated.
Maybe I'm just seeing this since it's an edge case that I recently dealt
with, but I believe it would be a useful enhancement overall.
Thoughts?
Hi,
I think it would be very helpful to have an additional argument (cancel for example) added to Executor.shutdown that cancels all pending futures submitted to the executor. Then context manager would gain the ability to abort all futures incase of a exception, additionally this would also implement the missing cuterpart of the multiprocessing module terminate, currently we only have close.
We have importlib resources. We should put it to use.
Imagine if you could separate your docs from your code and yet include
them in your package.
```
f"""{from mymodule.docs include main.rst}"""
def foo():
f"""{from mymodule.docs include foo.rst}"""
pass
class Bar:
f"""{from mymodule.docs include bar.rst}"""
pass
template = f"{from mymodule.templates include index.html}"
```
etc. I think this would be pretty cool!
Hi, all.
I believe UTF-8 should be chosen by default for text encoding.
* The default encoding for Python source file is UTF-8.
* VS Code and even notepad uses UTF-8 by default.
* Text files downloaded from the Internet is probably UTF-8.
* UTF-8 is used when you use WSL regardless your system code page.
* Windows 10 (1903) adds per-process option to change active code page
to UTF-8 and call the system code page "legacy". [1]
But it is difficult to change the default text encoding of Python
for backward compatibility. So I want to recommend the UTF-8 mode:
* The default text encoding become UTF-8
* When you need to use legacy ANSI code page, you can
use "mbcs" codec.
* You can disable it when you need to run Python application
relying on the legacy system encoding.
But it is not well known yet. And setting the environment variable
is a bit difficult for people who are learning programming with Python.
So I want to propose this:
1. Recommend it in the official document "Using Python on Windows" [2].
2. Show the UTF-8 mode status in the command line mode header [3] on Windows.
3. Show the link to the UTF-8 mode document in the command line mode header too.
4. Add checkbox to set "PYTHONUTF8=1" environment variable in the installer.
How do you think?
If setting "PYTHONUTF8=1" environment variable is too danger
to recommend widely, we may be able to add per-installation
(and per-venv if needed) option file (site.cfg in the directory same to
python.exe) to enable UTF-8 mode.
But it may make Python startup process more complex...
Regards,
[1]: https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-co…
[2]: https://docs.python.org/3/using/windows.html
[3]: Currently, Python version and "Type "help",..." are printed.
--
Inada Naoki <songofacandy(a)gmail.com>
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 <http://www.pythonmembers.club/> | github
<https://github.com/Abdur-rahmaanJ>
Mauritius
currently python -m requires you to cwd to the desired package root. I'd
like to suggest the ability to python -m
relative/path/to/package/root/module.submodule and python -m
/absolute/path/to/package/root/module.submodule
thoughts?
-----Original Message-----
From: Steven D'Aprano <steve(a)pearwood.info>
Sent: 11 January 2020 04:39
To: python-ideas(a)python.org
Subject: [Python-ideas] Re: python -m quality of life improvements
On Fri, Jan 10, 2020 at 11:53:10PM -0300, Soni L. wrote:
> currently python -m requires you to cwd to the desired package root.
> I'd like to suggest the ability to python -m
> relative/path/to/package/root/module.submodule and python -m
> /absolute/path/to/package/root/module.submodule
Oh, a further thought comes to mind... if your modules aren't on the PYTHONPATH, just drop the -m and you can execute any legal Python file, even if the name isn't a legal identifier.
[steve@ando tmp]$ cp ~/python/spam/eggs.py /tmp/"some name".foo
[steve@ando tmp]$ python3.5 "some name.foo"
some name.foo
So as I understand it, the functionality you want already exists, both for running scripts on the path using -m and scripts with arbitrary file names without -m.
Have I missed some subtlety in your proposal?
[Steve Barnes]
I did notice one anomaly in the behaviour of python -m:
taking your code structure above and using :
> py -mzipfile -c eggs.zip spam\__init__.py spam\__main__.py spam\eggs.py
to create eggs.zip I can run:
> py eggs.zip
Renaming eggs.zip to eggs.py I can run:
>eggs.py
E:\toolbuild\eggs.py\__main__.py
Or
>py eggs.py
E:\toolbuild\eggs.py\__main__.py
But get problems when I try:
> py -meggs.py
Traceback (most recent call last):
File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "C:\Python38_64\lib\runpy.py", line 109, in _get_module_details
__import__(pkg_name)
ValueError: source code string cannot contain null bytes
Gadget@GADGETLAPTOP E:\toolbuild
> py -meggs
Traceback (most recent call last):
File "C:\Python38_64\lib\runpy.py", line 183, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "C:\Python38_64\lib\runpy.py", line 153, in _get_module_details
code = loader.get_code(mod_name)
File "<frozen importlib._bootstrap_external>", line 916, in get_code
File "<frozen importlib._bootstrap_external>", line 846, in source_to_code
File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
ValueError: source code string cannot contain null bytes
Is this expected behaviour or worth a ticket and some time investigating further?
This was on Windows 10/64 with 3.8-64 but I get exactly the same with 3.7-64/32 & 2.7 and with python rather than py.
Gadget/Steve
