16.05.19 04:23, Victor Stinner пише:
The first implementation of my API used sys.unraisablehook(exc_type,
exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
to add a new error message field which breaks the API: the API is not
future-proof.
I modified my API to create an obje
On 5/15/2019 4:10 PM, Victor Stinner wrote:
> Hi,
>
> Thanks to the constructive discussions, I enhanced my PEP 587. I don't
> plan any further change, the PEP is now ready to review (and maybe
> even for pronouncement, hi Thomas! :-)).
>
> The Rationale now better explains all challenges and the
On Wed, May 15, 2019 at 6:25 PM Victor Stinner wrote:
> I proposed a different approach: add a new sys.unraisablehook hook
> which is called to handle an "unraisable exception". To handle them
> differently, replace the hook. For example, I wrote a custom hook to
> log these exceptions into a file
Hi,
I recently modified Python 3.8 to start logging I/O error in io
destructors when using the development mode (-X dev) or when Python is
built in debug mode. This change allows to debug bpo-18748 very
strange crash in PyThread_exit_thread(), when a thread closes an
arbitrary file descriptor by m
Hi,
Thanks to the constructive discussions, I enhanced my PEP 587. I don't
plan any further change, the PEP is now ready to review (and maybe
even for pronouncement, hi Thomas! :-)).
The Rationale now better explains all challenges and the complexity of
the Python Initialization Configuration.
T
On 5/15/2019 6:06 PM, Mariatta wrote:
If you have FOMO (fear of missing out) of Python Language Summit 2019,
worry no more.
We invited A. Jesse Jiryu Davis to cover for the language summit, and
the blog posts are starting to appear in The PSF's official blog.
Starts here:
http://pyfound.blo
On Wed, 15 May 2019 at 21:34, Chris Barker - NOAA Federal via
Python-Dev wrote:
>
> Frankly, multiple long meandering threads in s single mailing list are
> not s very good archive either.
They aren't, I agree. But in my view, they constitute the *source
material* that the summaries in the PEP sh
If you have FOMO (fear of missing out) of Python Language Summit 2019,
worry no more.
We invited A. Jesse Jiryu Davis to cover for the language summit, and the
blog posts are starting to appear in The PSF's official blog.
Starts here:
http://pyfound.blogspot.com/2019/05/the-2019-python-language-s
On Wed, May 15, 2019 at 1:10 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
[SNIP]
>
> While I'm here, is there a place where general Pythonistas can bring
> matters to the attention of the Council?
>
https://github.com/python/steering-council is where we're asking people
Le mer. 15 mai 2019 à 20:46, Guido van Rossum a écrit :
> But trust me that the SC didn't take this decision lightly. It was unanimous,
> and we have all thought about this a great deal (and listened to long
> arguments pro and con). It's also impossible to satisfy everyone -- some
> people fin
Frankly, multiple long meandering threads in s single mailing list are
not s very good archive either.
Ideally, the PEP is updated with a summary of the issues discussed as
the discussion unfolds.
(And links to the main discussion threads?)
It founds like that didn’t happen in this case, but it’
Stripping the list of addressees, since I'm pretty sure all the
people who will *make* the decision read Python-Dev regularly, except
perhaps Carol.
Paul Moore writes:
> Thanks for all of these. I appreciate the time you took locating them
> for me. But I do have to say that I still can't reall
On 15May2019 1248, Nathaniel Smith wrote:
I don't care about the deprecation either way. But can we fix the
individual decorators so both orders work? Even if it requires a special
case in the code, it seems worthwhile to remove a subtle user-visible
footgun.
The classmethod and staticmethod
I don't care about the deprecation either way. But can we fix the
individual decorators so both orders work? Even if it requires a special
case in the code, it seems worthwhile to remove a subtle user-visible
footgun.
On Wed, May 15, 2019, 12:39 Ethan Furman wrote:
> In issue 11610* abstractclas
In issue 11610* abstractclassmethod and abstractstaticmethod were deprecated,
apparently because they were redundant with the new technique of calling
`classmethod` or `staticmethod` followed by a call to `abstractmethod`. To put
it in code:
# deprecated
class Foo(ABC):
@abstractclassme
IMO the text of PEP 581 could use some improvements to capture more of the
debate. For example:
- If people want to submit PRs to the peps repo that correct *factual*
mistakes in PEP 581, they're welcome to (and I will personally see that
they will be merged). For example, IIRC you *can* reply to
On Wed, May 15, 2019 at 9:53 AM Steve Dower wrote:
> On 15May2019 0240, Paul Moore wrote:
> > On Wed, 15 May 2019 at 09:51, Antoine Pitrou
> wrote:
> >>
> >> On Tue, 14 May 2019 18:11:14 -0700
> >> Barry Warsaw wrote:
> >>
> >>> As the BDFL-Delegate for PEP 581, and with the unanimous backing o
Hello,
On Wed, May 15, 2019 at 5:18 PM Paul Moore wrote:
>
> On Wed, 15 May 2019 at 15:56, Victor Stinner wrote:
> >
> > Hi Paul,
> > Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit :
> > > Also, is there an archive of the discussions anywhere? The PEP says
> > > discussions happened on Zulip,
On 15May2019 0240, Paul Moore wrote:
On Wed, 15 May 2019 at 09:51, Antoine Pitrou wrote:
On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw wrote:
As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of
the Steering Council, I hereby Accept this PEP.
For future refer
On Wed, May 15, 2019 at 5:38 AM Victor Stinner wrote:
> Le mer. 15 mai 2019 à 11:31, Christian Heimes a
> écrit :
> > What are the next step? Will there be another PEP that explores how we
> > are going to deal with migration, workflow changes, and how we plan to
> > map current BPO features to
On Wed, May 15, 2019 at 8:18 AM Paul Moore wrote:
> On Wed, 15 May 2019 at 15:56, Victor Stinner wrote:
> >
> > Hi Paul,
> > Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit :
> > > Also, is there an archive of the discussions anywhere? The PEP says
> > > discussions happened on Zulip, but I don
On Wed, 15 May 2019 at 15:56, Victor Stinner wrote:
>
> Hi Paul,
> Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit :
> > Also, is there an archive of the discussions anywhere? The PEP says
> > discussions happened on Zulip, but I don't follow that and I don't
> > know where I can find an archived
On Tue, May 14, 2019, 19:52 Steve Dower wrote:
> It looks like Py_DecodeLocale() is available very early on - why
> wouldn't we recommend using this function? It seems to be nearly a
> drop-in replacement for mbtowcs in the samples, and if memory allocation
> is a big deal perhaps we could just a
Hi Paul,
Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit :
> Also, is there an archive of the discussions anywhere? The PEP says
> discussions happened on Zulip, but I don't follow that and I don't
> know where I can find an archived copy of the discussions.
Well, the PEP has been discussed a lot
As someone involved in the packaging side of this, I think while we'd
eventually /appreciate/ a TOML parser in the standard library, I agree
with Victor that there's no rush, for two reasons:
1. setuptools and pip have a decent number of dependencies that we
vendor /anyway/, so vendoring one more
H Bastian,
IMHO we should wait until the format reach version 1.0, since the
stdlib has a slow release cycle (one release every 18 months). Too
slow for a "fast moving" standard.
In the meanwhile, I'm sure setuptools and pip will manage to install a
toml parser/generator for their needs, as they
Le mer. 15 mai 2019 à 11:31, Christian Heimes a écrit :
> What are the next step? Will there be another PEP that explores how we
> are going to deal with migration, workflow changes, and how we plan to
> map current BPO features to Github?
Yes, it's the:
PEP 588 -- GitHub Issues Migration Plan
h
On Wed, May 15, 2019 at 09:35:16PM +1000, Steven D'Aprano wrote:
> It isn't very long (only about a dozen or so quite short posts) but you
> probably ought to be at least familiar with it, and if possibly respond
> to any opposing comments.
Sorry, to clarify, I don't mean respond on the Python-I
On Wed, May 15, 2019 at 10:44:35AM +0200, Bastian Venthur wrote:
> Hi,
>
> I'd like to discuss the idea to add a module to parse TOML [toml-lang]
> to Python's standard library.
You ought to read this thread here:
https://mail.python.org/pipermail/python-ideas/2018-October/054101.html
It isn't
On Wed, 15 May 2019 at 11:49, Bastian Venthur wrote:
>
> On 15.05.19 11:33, Antoine Pitrou wrote:
> > How stable is the TOML format? Is it bound to change significantly in
> > the coming years?
> >
> > If the format is stable enough, then I think it's a good idea.
>
>
> The last update to the spe
On 15.05.19 11:33, Antoine Pitrou wrote:
How stable is the TOML format? Is it bound to change significantly in
the coming years?
If the format is stable enough, then I think it's a good idea.
The last update to the spec [1] was 10 months ago and added a few
features. The version before that
On Wed, 15 May 2019 at 09:51, Antoine Pitrou wrote:
>
> On Tue, 14 May 2019 18:11:14 -0700
> Barry Warsaw wrote:
>
> > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the
> > rest of the Steering Council, I hereby Accept this PEP.
>
> For future reference, is it possible to p
On Wed, 15 May 2019 10:44:35 +0200
Bastian Venthur wrote:
> Hi,
>
> I'd like to discuss the idea to add a module to parse TOML [toml-lang]
> to Python's standard library.
How stable is the TOML format? Is it bound to change significantly in
the coming years?
If the format is stable enough, th
On 15/05/2019 10.55, Ivan Pozdeev via Python-Dev wrote:
> On 15.05.2019 11:48, Antoine Pitrou wrote:
>> On Tue, 14 May 2019 18:11:14 -0700
>> Barry Warsaw wrote:
>>
>>> As the BDFL-Delegate for PEP 581, and with the unanimous backing of
>>> the rest of the Steering Council, I hereby Accept this PE
Hi,
I'd like to discuss the idea to add a module to parse TOML [toml-lang]
to Python's standard library.
PEP-0518 -- Specifying Minimum Build System Requirements for Python
Projects [pep] suggests to store build system dependencies in
`pyproject.toml`, yet Python itself does not support this
On 15.05.2019 11:48, Antoine Pitrou wrote:
On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw wrote:
As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of
the Steering Council, I hereby Accept this PEP.
For future reference, is it possible to post the Steering Council'
On Tue, 14 May 2019 18:11:14 -0700
Barry Warsaw wrote:
> As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest
> of the Steering Council, I hereby Accept this PEP.
For future reference, is it possible to post the Steering Council's
reflection and rationale on the PEP?
Th
On Wed, 15 May 2019 08:40:58 +0100
Steve Holden wrote:
> As a mere user I'd like to thank the developer team for biting this bullet.
> Remembering the transition to Git I am sure that the further
> democratisation (?) of the development process will similarly increase the
> diversity and scope of
As a mere user I'd like to thank the developer team for biting this bullet.
Remembering the transition to Git I am sure that the further
democratisation (?) of the development process will similarly increase the
diversity and scope of the development effort.
It will indeed be a significant effort
39 matches
Mail list logo
