Good point, I hadn't considered that it was regular common ref count 0
dealloc chaining. The processes unfortunately didn't have faulthandler
enabled so there wasn't much info from where in the python code it happened
(now fixed). I'll see if anything looks particularly unusual next time I
hear
Victor Stinner writes:
> I just fixed the mojibake issue in Python 3.8 by disabling C locale
> coercion and UTF-8 Mode by default. I'm not sure if nor how Python 3.7
> should be fixed in a minor 3.7.x release.
That sounds like a potential regression. Those two features were
added *and turned
On Mar 27, 2019, at 22:37, Ned Deily wrote:
> On Mar 27, 2019, at 21:59, Dima Tisnek wrote:
>> Correct BPO is https://bugs.python.org/issue36256
> Thanks for the report! I'll see that it gets fixed.
https://github.com/python/cpython/pull/12600
There were also a couple more in master/3.8:
On Thu, Mar 28, 2019 at 12:26 AM Steve Dower wrote:
>
[snip]
> 2. Do we want everyone else to stop using it for their own purposes?
[snip]
>
> The second question is harder to answer, and in the absence of input
> from those who are already using it (or the absence of evidence that
> nobody else
Hi list,
Sorry, I'm not sure where to post this.
The Changelog reads:
bpo-12477: Fix bug in parsermodule when parsing a state in a DFA that
has two or more arcs with labels of the same type. Patch by Pablo
Galindo.
The `12477` is actually a master github pull request number, not a
Python bug
Ah, I forgot to say that a major enhancement for the implementation is
that I wrote a lot of new unit tests for the existing Python
Initialization API. Python 3.7 has most of these tests. I wrote even
more tests for my new private initialization API ;-)
I wrote these tests to specify and validate
Le mer. 27 mars 2019 à 19:35, Alexander Belopolsky
a écrit :
> Would you consider making _Py_UnixMain public as well?
>
> It is useful for high level embedding and not trivial for 3rd parties to
> reimplement.
Right, Py_Main() is causing a lot of practice issues, especially
mojibake because of
Hi,
Since Steve Dower asked me to write a formal PEP for my proposal of a
new C API to initialize Python, here you have!
This new PEP will be shortly rendered as HTML at:
https://www.python.org/dev/peps/pep-0587/
The Rationale might be a little bit weak at this point and there are
still 3 small
[Gregory P. Smith ]
> ...
> A situation came up the other day where I believe this could've helped.
>
> Scenario (admittedly not one most environments run into): A Python process
> with a C++ extension module implementing a threaded server (threads
> spawned by C++) that could call back into
https://www.python.org/dev/peps/pep-0556/
This PEP is currently Deferred as nobody is actively working on a test
implementation.
A situation came up the other day where I *believe* this could've helped.
Scenario (admittedly not one most environments run into): A Python process
with a C++
https://www.python.org/dev/peps/pep-0502/
Thanks to Mike G. Miller for the informational PEP, but since the PEP was
written with an opinionated voice and the details of the PEP aren't
critical as they should be captured by PEP 498 anyway, we didn't think it
was worth trying to touch the PEP up
On 2019-03-27 14:50, Petr Viktorin wrote:
The pre-PEP claims speedups of 2% in initial experiments, with
expected overall performance gain of 4% for the standard benchmark
suite. That's pretty big.
I re-did my earlier benchmarks for PEP 580 and these are the results:
On Wed, Mar 27, 2019 at 12:39 PM Steve Dower wrote:
> On 27Mar2019 1048, Victor Stinner wrote:
> > Since November 2017, I'm refactoring the Python Initialization code to
> > cleanup the code and prepare a new ("better") API to configure Python
> > Initialization. I just fixed the last issues
On 27Mar2019 1048, Victor Stinner wrote:
Since November 2017, I'm refactoring the Python Initialization code to
cleanup the code and prepare a new ("better") API to configure Python
Initialization. I just fixed the last issues that Nick Coghlan asked
me to fix (add a pre-initialization step:
> To make the API public, _PyWstrList, _PyInitError, _PyPreConfig,
> _PyCoreConfig and related functions should be made public.
Would you consider making _Py_UnixMain public as well?
It is useful for high level embedding and not trivial for 3rd parties to
reimplement.
Hi,
I would like to add a new C API to initialize Python. I would like
your opinion on the whole API before making it public. The code is
already implemented. Doc of the new API:
https://pythondev.readthedocs.io/init_config.html
To make the API public, _PyWstrList, _PyInitError,
On Wed, Mar 27, 2019 at 3:26 AM Inada Naoki wrote:
> On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki
> wrote:
> >
> > C, Rust, Java, Ruby, PHP, don't have PendingDeprecation.
> > Programmers only need Deprecation. Why programmers need
> PendingDeprecation
> > only in Python?
> >
>
> Any comments
On Wed, 27 Mar 2019 at 15:29, Steve Dower wrote:
> If someone can show that either no third-parties are using it, or all
> those that do will probably never explicitly support Python 3.8 or
> later, or all those that do would prefer to stop using it, then I'll
> happily change my mind here. But
On 27Mar2019 0324, Inada Naoki wrote:
On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki wrote:
C, Rust, Java, Ruby, PHP, don't have PendingDeprecation.
Programmers only need Deprecation. Why programmers need PendingDeprecation
only in Python?
Any comments about this?
I want to document
By lack of a better name, I'm using the name PEP 576bis to refer to
https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst
(This is why this should get a PEP number soon, even if the PEP is not
completely done yet).
On 2019-03-27 14:50, Petr Viktorin wrote:
The pre-PEP
On Sun, Mar 24, 2019 at 4:22 PM Mark Shannon wrote:
>
> Hi Petr,
>
> Regarding PEPs 576 and 580.
> Over the new year, I did a thorough analysis of possible approaches to
> possible calling conventions for use in the CPython ecosystems and came
> up with a new PEP.
> The draft can be found here:
>
On Mon, Mar 25, 2019 at 10:11 PM Inada Naoki wrote:
>
> C, Rust, Java, Ruby, PHP, don't have PendingDeprecation.
> Programmers only need Deprecation. Why programmers need PendingDeprecation
> only in Python?
>
Any comments about this?
I want to document PendingDeprecationWarning is deprecated
22 matches
Mail list logo
