:
On 7 November 2017 at 18:53, Guido van Rossum <guido(a)python.org> wrote:
> I find it dubious to claim that these functions are dangerous to beginners.
> The dangers are related to attacks on servers that are exposed to the
> internet and beginners have no business running servers.
I can't be the only one whose experience is that it's very often those
with the least business running servers that actually do run them,
surely?
+1
-[]z.
[A copy from https://github.com/python/typing/issues/495 to get more
people's attention to this issue.]
I'm wondering if we should remove typing from the stdlib. Now's the time to
think about this, as the feature freeze for 3.7 is about 12 weeks away.
Cons:
- People have to depend on a PyPI package to use typing (but they do
anyway for typing_extensions)
- It's a backward incompatibility for users of Python 3.5 and 3.6 (but
the typing module was always provisional)
Pros:
- The typing module can evolve much faster outside the stdlib
- We could get rid of typing_extensions (and maybe even mypy_extensions)
If we don't do this I worry that we're entering a period where many new
typesystem features end up in typing_extensions and users will be confused
about which items are in typing and which in typing_extensions (not to
mention mypy_extensions). Anything new to be added to typing (e.g. Const,
Final, Literal, or changing ABCs to Protocols) would have to be added to
typing_extensions instead, and users would be confused about which features
exist in which module. Moving typing out of the stdlib can make things
potentially simpler, at the cost of an extra pip install (but they'll need
one anyway for mypy).
Thoughts?
--
--Guido van Rossum (python.org/~guido)
Hello,
one of my long standing ideas to improve Python is to adjust the
release cycle and version number handling. In short, to simplify it.
This is the first draft of the idea:
Proposal to change Python version release cycle
===============================================
Goal
----
Increment the major version number more frequently for every new language
feature release.
Change Python feature version counting from "major.minor" to "major".
This is simpler, better to handle compatibility and allows adding new
library features more frequently.
The current Python version scheme is Major.Minor.Patch this will be kept
but the major version number will be incremented faster and for every
language feature release as it is now for the minor number.
For example today the minor version number is increased for every big release
done in 1,5 year cycle. In this new language features with new keywords can
appear, new libraries can be included and other C level API changes can happen.
There backward compatible feature improvements and new features also backward
incompatible can happen.
I suggest to change this to increment the major version for every new release
of the 1,5 year cycle.
And allow new Python standard library backward compatible changes for every
minor release cycle every 6 months.
Start with this from Python version 4 on.
Benefit
-------
Clear separation of new language features and C API changes and new
backward compatible feature additions.
So for a major version on Python level new keywords can be added, build ins
can be added or removed and the C API can be changed (new features or other
incompatible changes).
For a minor version new standard libraries can be added and API can be improved
in a backward compatible way. This can be done more frequently for example in
a 0,5 year cycle. Allowing the Python library part to improve in a higher rate.
For a patch version only none breaking bug and security fixes are allowed.
(Same as it is now, or even a little bit stricter)
With this change there is a clear separation of new language Features which
are also tracked by other Python implementations and new library features.
This can be seen very easy by only looking at the Python major version.
The C API level is included in this standard and is not allowed to change
in a minor version as it is now. This is because booth the Python language
and the C API of CPython implementation is a standard and tracked by other
implementations. For them it is easy to say I am compatible to Version 4.
For everyone in computer business it is clear what is meant.
The Python standard library can be improved in a higher rate because backward
compatible feature changes are allowed in a higher rate for minor versions.
Also provisional libraries can be improved in a faster rate for every minor
version. (for example every 6 months instead of 1,5 years)
For Unix in the Python executable the major version can be appended and this
specifies the Python language standard used. This is done already but most of
the time only EXECUTABLEmajor.minor is useful. Also more complicated to handle
as a simple Number. Can be problematic on some platforms because of the dot ".".
Python major version every 1,5 years (same as it is now for major.minor).
Python minor version every 6 months (to allow faster standard library changes).
Python patch version as needed (to fix only bugs and security related stuff)
This can solve the problem of adding something as a standard library and then
this is the dead of the library because it cannot be improved any further
in a higher update rate.
The Python standard library should not be a dead end for a library after
inclusion. This allows Python code to improve faster than the C code.
This is needed to include new features faster and because we have more
people capable in Python programming than for C in the Python community.
On C level the compatibility distinction is simple only track the major
version and no longer a mixture between major and major.minor compatibility.
Risk
----
Minimal because to track features the major.minor version already has to be
tracked.
It is a change some assumptions about Python versions are at this point no
longer valid.
On C level external libraries and wrappers must adopt it and changes are
needed.
Open questions
--------------
The exact release cycle for minor, can also be every 4 months if needed.
Clear separation what is part of the language standard and what is part
of the C API.
Some modules, for example "sys" can also be part of the language Standard
and should not change between minor versions.
The difference between the stable C API and that for every minor version
can be removed. There is only one C API guarantee for a major version
and it does not change for a minor version.
None goals
----------
Change the release cycle of 1,5 years for new big releases.
Change the versioning scheme to something other than "major.minor.patch".
New big ground breaking changes to everything.
To complicate something.
Regards,
Wolfgang
Hi all,
Here is in somewhat more detail my earlier proposal for
having in the interactive Python interpreter a `pip` function to
install packages from Pypi.
Motivation: it appears to me that there is a category of newbies
for which "open a shell and do `pip whatever`" is a bit too much.
It would, in my opinion, simplify things a bit if they could just
copy-and-paste some text into the Python interpreter and have
some packages from pip installed.
That would simplify instructions on how to install package xyz,
without going into the vagaries of how to open a shell on various
platforms, and how to get to the right pip executable.
I think this could be as simple as:
def pip(args):
import sys
import subprocess
subprocess.check_call([sys.executable, "-m", "pip"] + args.split())
print("Please re-start Python now to use installed or upgraded
packages.")
Note that I added the final message about restarting the interpreter
as a low-tech solution to the problem of packages being already
imported in the current Python session.
I would imagine that the author of package xyz would then put on
their webpage something like:
To use, enter in your Python interpreter:
pip("install xyz --user")
As another example, consider prof. Baldwin from Woolamaloo university
who teaches a course "Introductory Python programming for Sheep Shavers".
In his course material, he instructs his students to execute the
following line in their Python interpreter.
pip("install woolamaloo-sheepshavers-goodies --user")
which will install a package which will in turn, as dependencies,
pull in a number of packages which are relevant for sheep shaving but
which have nevertheless irresponsibly been left outside the stdlib.
Stephan
Hello,
I noticed that array.index() method takes single argument in python 3.6,
while Sequence protocol specifies 2 optional arguments after the first.
example from list:
L.index(value, [start, [stop]]) -> integer -- return first index of value.
I propose adding start and stop arguments to array.index()
Regards,
Niki
I recently came across a bug where checking negative membership (__contains__ returns False) of an infinite iterator will freeze the program.
It may seem a bit obvious, but you can check membership in range for example without iterating over the entire range.
`int(1e100) in range(int(1e101))` on my machine takes about 1.5us
`int(1e7) in itertools.count()` on my machine takes about 250ms (and gets worse quite quickly).
Any membership test on the infinite iterators that is negative will freeze the program as stated earlier, which is odd to me.
itertools.count can use the same math as range
itertools.cycle could use membership from the underlying iterable
itertools.repeat is even easier, just compare to the repeatable element
Does anyone else think this would be useful?
On 30.10.2017 9:29, python-ideas-request(a)python.org wrote:
> If I have understood your use-case, you have a function that returns a
> list of results (or possibly an iterator, or a tuple, or some other
> sequence):
>
> print(search(haystack, needle))
> # prints ['bronze needle', 'gold needle', 'silver needle']
>
> There are times you expect there to be a single result, and if there are
> multiple results, that is considered an error. Am I correct so far?
Correct.
> If so, then sequence unpacking is your friend:
>
> result, = search(haystack, needle)
>
> <...>
>
> I *think* this will solve your problem.
>
> If not, can you please explain what "single()" is supposed to do, why it
> belongs in itertools, and show an example of how it will work.
That works. Too arcane in my book though (and others' too according to
https://stackoverflow.com/a/473337/648265), and the error messages are
cryptic in this use case.
It also cannot be a part of an expression, unlike next().
The initial post on the above link summarizes the suggested
implementation pretty well.
--
Regards,
Ivan
Over on python-dev, the question of recommending MRAB's "regex" module over
the standard library's "re" module for more advanced regular expressions
recently came up again.
Because of various logistical issues and backwards compatibility risks,
it's highly unlikely that we'll ever be able to swap out the current _sre
based re module implementation in the standard library for an
implementation based on the regex module.
At the same time, it would be beneficial to have a way to offer an even
stronger recommendation to redistributors that we think full-featured
general purpose Python scripting environments should offer the regex module
as an opt-in alternative to the baseline re feature set, since that would
also help with other currently difficult cases like the requests module.
What I'm thinking is that we could make some relatively simple additions to
the `ensurepip` and `venv` modules to help with this:
1. Add a ensurepip.RECOMMENDED_PACKAGES mapping keyed by standard library
module names containing dependency specifiers for recommended third party
packages for particular tasks (e.g. "regex" as an enhanced alternative to
"re", "requests" as an enhanced HTTPS-centric alternative to
"urllib.request")
2. Add a new `install_recommended` boolean flag to ensurepip.bootstrap
3. Add a corresponding `--install-recommended flag to the `python -m
ensurepip` CLI
4. Add a corresponding `--install-recommended flag to the `python -m venv`
CLI (when combined with `--without-pip`, this would run pip directly from
the bundled wheel file to do the installations)
We'd also need either a new informational PEP or else a section in the
developer guide to say that the contents of
`ensurepip.RECOMMENDED_PACKAGES` are up to the individual module
maintainers (hence keying the mapping by standard library module name,
rather than having a single flat list for the entire standard library).
For redistributors with weak dependency support, these reference
interpreter level recommendations could become redistributor level
recommendations. Redistributors without weak dependency support could still
make a distinction between "default" installations (which would include
them) and "minimal" installations (which would exclude them).
Folks writing scripts and example code for independent distribution (i.e.
no explicitly declared dependencies) could then choose between relying on
just the standard library (as now), or on the standard library plus
independently versioned recommended packages.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Hello everyone,
The python-dev website said I should introduce myself before lurking around
for a while. So hi! I've been using python for 7 or so years now, live on
the east coast of the U.S., grew up in Nebraska, and occasionally play the
tuba and table-top games (through rarely together). I'm looking forward to
hearing where the language is going and hope I can be of use after I lurk
in the shadows for a while.
Cheers,
Brent
