GeezerVisonThe World Wide Web, restored to 800 pixels of glory. |
| Home|About|Gaming cabinet|Archives|How it works|Starter sites |
GeezerVison is showing mail.python.org — Mailman 3 - Python-Dev - python.org Python-Dev
Threads by month
Hello everyone,
for quite a while now, core discussions have moved to Discourse and
people are obviously enjoying things there:
https://discuss.python.org/c/core-dev/23
The Discourse mailing list mode works reasonably well, so is a suitable
replacement for this mailing list.
Posts to this list are now mostly spam, mailer error reports and the
occasional release postings:
https://mail.python.org/archives/list/[email protected]/latest
(you can't see much of the spam, since we filter most of it)
Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Nov 13 2023)
>>> Python Projects, Coaching and Support ... https://www.egenix.com/
>>> Python Product Development ... https://consulting.egenix.com/
________________________________________________________________________
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
Your message was not delivered due to the following reason:
Your message was not delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message could not be delivered within 5 days:
Server 76.93.23.153 is not responding.
The following recipients could not receive this message:
<python-dev(a)python.org>
Please reply to postmaster(a)python.org
if you feel this message to be in error.
The original message was received at Thu, 5 Oct 2023 09:08:00 +0300
from [87.212.114.230]
----- The following addresses had permanent fatal errors -----
<python-dev(a)python.org>
----- Transcript of session follows -----
... while talking to python.org.:
>>> DATA
<<< 400-aturner; %MAIL-E-OPENOUT, error opening !AS as output
<<< 400-aturner; -RMS-E-CRE, ACP file create failed
<<< 400-aturner; -SYSTEM-F-EXDISKQUOTA, disk quota exceeded
<<< 400
The message was undeliverable due to the following reason:
Your message was not delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within 8 days:
Host 39.68.11.75 is not responding.
The following recipients did not receive this message:
<python-dev(a)python.org>
Please reply to postmaster(a)python.net
if you feel this message to be in error.
Currently, Python doesn't allow non-default arguments after default
arguments:
>>> def foo(x=None, y): pass
File "<stdin>", line 1
def foo(x=None, y): pass
^
SyntaxError: non-default argument follows default argument
I believe that at the time this was introduced, no use cases for this
were known and this is is supposed to prevent a source of bugs. I have
two use cases for this, one fringe, but valid, the other more important:
The fringe use case: Suppose you have a function that takes a 2D
coordinate value as separate "x" and "y" arguments. The "x" argument is
optional, the "y" argument isn't. Currently there are two ways to do
this, none of them particularly great:
def foo(y, x): # reverse x and y arguments, confusing
...
def foo(x, y=None): # Treat the x argument as y if only one argument is
provided
if y is None:
x, y = y, x
...
To me, the "natural" solution looks like this:
def foo(x=None, y): ...
# Called like this:
foo(1, 2)
foo(y=2)
This could also be useful when evolving APIs. For example there is a
function "bar" that takes two required arguments. In a later version,
the first argument gains a useful default, the second doesn't. There is
no sensible way to evolve the API at the moment.
The more important use case involves @overloads. A condensed example of
a function where the return type depends on an "encoding" parameter,
followed by further parameters that could be called like this:
foo(123, "utf-8") # would return bytes
foo(encoding="utf-8")
foo(123, None) # would return str
foo(encoding=None)
foo(x=123) # would return str
foo()
This could ideally be written as:
@overload
def foo(x: int = ..., encoding: None = ...) -> str: ...
@overload
def foo(x: int = ..., encoding: str) -> bytes: ...
# plus the actual implementation
But due to the syntax constraint, this needs to be hacked around with a
third overload:
@overload
def foo(x: int = ... encoding: None = ...) -> str: ...
@overload
def foo(x: int, encoding: str) -> bytes: ... # for foo(123, "utf-8")
@overload
def foo(*, encoding: str) -> bytes: ... # for foo(encoding="utf-8")
Not only is this hard to read, real examples in typeshed are usually
more complex, with many arguments before or after the affected argument
or even multiple affected arguments. This often becomes too complex to
write or maintain. Here is one example from the wild:
https://github.com/python/typeshed/blob/b95b729b9e07ab21d252701af0f5b740467…
Allowing non-default arguments after default arguments would solve both
use cases above and eliminates a special case. I'm also not sure what
exactly the current SyntaxError really protects us from. Adding a
non-default after a default argument can't really lead bugs.
- Sebastian
Hi Python Developers, after some investigation i consider dev the correct
mailing list.
I got python embedded into OpenSCAD and i'd like to make more use out of it.
statements like these do exactly what they should:
width= 3*5
solid = make_nice_solid(width)
other_solid = solid.size(1)
print(" Everything fine")
But i'd like to be able to write lines like these: These are expressions
which create a value,
which is apparently NOT stored in a variable
solid *3
other_solid - solid
instead of wasting them, I'd like to collect them in an array and display
send it to the display engine
after python evaluation has finished.
Is there some way how i can collect the orphaned expressions ?
The message was undeliverable due to the following reason(s):
Your message was not delivered because the destination computer was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message could not be delivered within 1 days:
Host 47.86.183.166 is not responding.
The following recipients did not receive this message:
<python-dev(a)python.org>
Please reply to postmaster(a)skippinet.com.au
if you feel this message to be in error.
The original message was received at Wed, 20 Oct 2021 15:12:36 +0300 from acm.org [25.147.223.204]
----- The following addresses had permanent fatal errors -----
python-dev(a)python.org
----- Transcript of the session follows -----
... while talking to 146.160.159.171:
>>> RCPT To:<python-dev(a)python.org>
<<< 550 5.1.1 <python-dev(a)python.org>... Not known here
Aug. 24, 2023
There’s security content in the releases, let’s dive right in.
gh-108310 <https://github.com/python/cpython/issues/108310>: Fixed an issue where instances of ssl.SSLSocket <https://docs.python.org/release/3.10.13/library/ssl.html#ssl.SSLSocket> were vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data. Security issue reported as CVE-2023-40217 1 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-40217> by Aapo Oksman. Patch by Gregory P. Smith.
Upgrading is highly recommended to all users of affected versions.
<https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.11.5
Get it here: https://www.python.org/downloads/release/python-3115/
This release was held up somewhat by the resolution of this CVE, which is why it includes a whopping 328 new commits since 3.11.4 (compared to 238 commits between 3.10.4 and 3.10.5). Among those, there is a fix for CVE-2023-41105 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-41105>which affected Python 3.11.0 - 3.11.4. See gh-106242 <https://github.com/python/cpython/issues/106242> for details.
There are also some fixes for crashes, check out the change log <https://docs.python.org/release/3.11.5/whatsnew/changelog.html> to see all information.
Most importantly, the release notes on the downloads page <https://www.python.org/downloads/release/python-3115/> include a description of the Larmor precession. I understood some of the words there!
<https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.10.13
Get it here: https://www.python.org/downloads/release/python-31013/
16 commits.
<https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.9.18
Get it here: https://www.python.org/downloads/release/python-3918/
11 commits.
<https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.8.18
Get it here: https://www.python.org/downloads/release/python-3818/
9 commits.
<https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Stay safe and upgrade!
Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.
--
Łukasz Langa @ambv <https://discuss.python.org/u/ambv>
on behalf of your friendly release team,
Ned Deily @nad <https://discuss.python.org/u/nad>
Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower>
Pablo Galindo Salgado @pablogsal <https://discuss.python.org/u/pablogsal>
Łukasz Langa @ambv <https://discuss.python.org/u/ambv>
Thomas Wouters @thomas <https://discuss.python.org/u/thomas>
I'm pleased to announce the release of Python 3.12.0rc1:
https://www.python.org/downloads/release/python-3120rc1/
This is the first release candidate of Python 3.12.0
This release, *3.12.0rc1*, is the penultimate release preview. Entering the
release candidate phase, only reviewed code changes which are clear bug
fixes are allowed between this release candidate and the final release. The
second candidate (and the last planned release preview) is scheduled for
Monday, 2023-09-04, while the official release of 3.12.0 is scheduled for
Monday, 2023-10-02.
There will be *no ABI changes* from this point forward in the 3.12 series,
and the goal is that there will be as few code changes as possible.
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Call
to action
We strongly encourage maintainers of third-party Python projects to prepare
their projects for 3.12 compatibilities during this phase, and where
necessary publish Python 3.12 wheels on PyPI to be ready for the final
release of 3.12.0. Any binary wheels built against Python 3.12.0rc1 will
work with future versions of Python 3.12. As always, report any issues to the
Python bug tracker <https://github.com/python/cpython/issues>.
Please keep in mind that this is a preview release and while it’s as close
to the final release as we can get it, its use is *not* recommended for
production environments.
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Core
developers: time to work on documentation now
- Are all your changes properly documented?
- Are they mentioned in What’s New
<https://docs.python.org/3.12/whatsnew/3.12.html>?
- Did you notice other changes you know of to have insufficient
documentation?
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Major
new features of the 3.12 series, compared to 3.11
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>New
features
- More flexible f-string parsing
<https://docs.python.org/3.12/whatsnew/3.12.html#pep-701-syntactic-formaliza…>,
allowing many things previously disallowed (PEP 701
<https://peps.python.org/pep-0701/>).
- Support for the buffer protocol
<https://docs.python.org/3.12/whatsnew/3.12.html#pep-688-making-the-buffer-p…>
in Python code (PEP 688 <https://peps.python.org/pep-0688/>).
- A new debugging/profiling API (PEP 669
<https://peps.python.org/pep-0669/>).
- Support for isolated subinterpreters
<https://docs.python.org/3.12/whatsnew/3.12.html#pep-684-a-per-interpreter-g…>
with separate Global Interpreter Locks (PEP 684
<https://peps.python.org/pep-0684>).
- Even more improved error messages
<https://docs.python.org/3.12/whatsnew/3.12.html#improved-error-messages>.
More exceptions potentially caused by typos now make suggestions to the
user.
- Support for the Linux perf profiler
<https://docs.python.org/3.12/howto/perf_profiling.html> to report
Python function names in traces.
- Many large and small performance improvements
<https://docs.python.org/3.12/whatsnew/3.12.html#optimizations> (like PEP
709 <https://peps.python.org/pep-0709/>), delivering an estimated 5%
overall performance improvementcitation needed.
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Type
annotations
- New type annotation syntax
<https://docs.python.org/3.12/whatsnew/3.12.html#pep-695-type-parameter-synt…>
for generic classes (PEP 695 <https://peps.python.org/pep-0695/>).
- New override decorator
<https://docs.python.org/3.12/whatsnew/3.12.html#pep-698-override-decorator-…>
for methods (PEP 698 <https://peps.python.org/pep-0698>).
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>
Deprecations
- The deprecated wstr and wstr_length members of the C implementation of
unicode objects were removed, per PEP 623
<https://peps.python.org/pep-0623/>.
- In the unittest module, a number of long deprecated methods and
classes were removed. (They had been deprecated since Python 3.1 or 3.2).
- The deprecated smtpd and distutils modules have been removed (see PEP
594 <https://peps.python.org/pep-0594/> and PEP 632
<https://peps.python.org/pep-0632/>. The setuptools package continues to
provide the distutils module.
- A number of other old, broken and deprecated functions, classes and
methods <https://docs.python.org/3.12/whatsnew/3.12.html#removed> have
been removed.
- Invalid backslash escape sequences in strings now warn with
SyntaxWarning instead of DeprecationWarning, making them more visible.
(They will become syntax errors in the future.)
- The internal representation of integers has changed in preparation for
performance enhancements. (This should not affect most users as it is an
internal detail, but it may cause problems for Cython-generated code.)
(Hey, *fellow core developer,* if a feature you find important is missing
from this list, let Thomas know <thomas(a)python.org>.)
For more details on the changes to Python 3.12, see What’s new in Python
3.12 <https://docs.python.org/dev/whatsnew/3.12.html>. The next pre-release
of Python 3.12 will be 3.12.0rc2, the *final release candidate*, currently
scheduled for 2023-09-04.
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>More
resources
- Online Documentation <https://docs.python.org/3.12/>.
- PEP 693 <https://www.python.org/dev/peps/pep-0693/>, the Python 3.12
Release Schedule.
- Report bugs via GitHub Issues
<https://github.com/python/cpython/issues>.
- Help fund Python and its community
<https://www.python.org/psf/donations/>.
<https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>We
hope you enjoy the new releases!
Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation <https://www.python.org/psf-landing/>.
Your release team,
Thomas Wouters
Ned Deily
Steve Dower
Łukasz Langa
--
Thomas Wouters <thomas(a)python.org>
|
| You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required. |
