On Sat, Apr 6, 2019 at 1:13 AM Victor Stinner wrote:
>
> > > ``PyPreConfig`` fields:
> > >
> > > * ``coerce_c_locale_warn``: if non-zero, emit a warning if the C locale
> > > is coerced.
> > > * ``coerce_c_locale``: if equals to 2, coerce the C locale; if equals to
> > > 1, read the LC_CTYPE t
On 02.04.19 18:10, Steve Dower wrote:
> On 02Apr2019 0817, Calvin Spealman wrote:
>> (I originally posted this to python-ideas, where I was told none of this
>> PEP's
>> authors subscribe so probably no one will see it there, so I'm posting it
>> here
>> to raise the issue where it can get seen a
On Fri, Apr 5, 2019 at 1:11 PM Jeroen Demeyer wrote:
> On 2019-04-05 21:58, Brett Cannon wrote:
> > Then we can consider improving the documentation if there are
> > performance implications.
>
> Sure, we could write in the docs something like "Don't use this, this is
> not what you want. It's sl
On 2019-04-05 21:58, Brett Cannon wrote:
Then we can consider improving the documentation if there are
performance implications.
Sure, we could write in the docs something like "Don't use this, this is
not what you want. It's slow and there are better alternatives like
method descriptors". Sh
On Fri, Apr 5, 2019 at 11:30 AM Jeroen Demeyer wrote:
> On 2019-04-05 17:46, Guido van Rossum wrote:
> > This API is doing no harm, it's not a maintenance
> > burden
>
> What if the following happens?
>
> 1. For some reason (possibly because of this thread), people discover
> instancemethod and s
On 2019-04-05 17:46, Guido van Rossum wrote:
This API is doing no harm, it's not a maintenance
burden
What if the following happens?
1. For some reason (possibly because of this thread), people discover
instancemethod and start using it.
2. People realize that it's slow.
3. It needs to be
ACTIVITY SUMMARY (2019-03-29 - 2019-04-05)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7056 ( +8)
closed 41231 (+55)
total 48287 (+63)
Open issues w
On 2019-04-05 19:53, Serhiy Storchaka wrote:
At Python level we can monkeypatch __gt__, but not tp_richcompare.
Sure, but you're planning to use C anyway so that's not really an argument.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
On 05/04/2019 17.46, Guido van Rossum wrote:
> Let's stop here. This API is doing no harm, it's not a maintenance
> burden, clearly *some* folks have a use for it. Let's just keep it,
> okay? There are bigger fish to fry.
Sounds good to me. My code is 12 years ago and I can't remember any
complain
05.04.19 15:33, Jeroen Demeyer пише:
On 2019-04-05 15:13, Serhiy Storchaka wrote:
It is easy to implement a function in C.
Why does it need to be a PyCFunction? You could put an actual method
descriptor in the class. In other words, use PyDescr_NewMethod() instead
of PyCFunction_New() + PyIn
For the PyMainConfig structure idea, I cannot comment at this point. I
need more time to think about it.
About the "path configuration" fields, maybe a first step to enhance
the API would be to add the the following function:
PyInitError PyConfig_ComputePath(PyConfig *config, const wchar *home);
> I think my biggest point (about halfway down) is that I'd rather use
> argv/environ/etc. to *initialize* PyConfig and then only use the config
> for initializing the runtime. That way it's more transparent for users
> and more difficult for us to add options that embedders can't access.
I chose
> > Example of Python initialization enabling the isolated mode::
> >
> > PyConfig config = PyConfig_INIT;
> > config.isolated = 1;
>
> Haven't we already used extenal values by this point that should have
> been isolated?
On this specific example, "config.isolated = 1;" ensures that
Py_Pr
About PyPreConfig and encodings.
> The appendix is excellent, by the way. Very useful detail to have
> written down.
Thanks. The appendix is based on Include/cpython/coreconfig.h comments
which is now my reference documentation. By the way, this header file
contains more information about PyConfi
Le dim. 31 mars 2019 à 01:49, Steve Dower a écrit :
> Here is my first review of https://www.python.org/dev/peps/pep-0587/ and
> in general I think it's very good.
Ah nice, that's a good start :-) Thanks for reviewing it.
Your email is long, and answer makes it even longer, so I will reply
in mu
Let's stop here. This API is doing no harm, it's not a maintenance burden,
clearly *some* folks have a use for it. Let's just keep it, okay? There are
bigger fish to fry.
On Fri, Apr 5, 2019 at 5:36 AM Jeroen Demeyer wrote:
> On 2019-04-05 15:13, Serhiy Storchaka wrote:
> > It is easy to impleme
On 2019-04-05 15:13, Serhiy Storchaka wrote:
It is easy to implement a function in C.
Why does it need to be a PyCFunction? You could put an actual method
descriptor in the class. In other words, use PyDescr_NewMethod() instead
of PyCFunction_New() + PyInstanceMethod_New(). It's probably goin
05.04.19 14:27, Jeroen Demeyer пише:
On 2019-04-05 14:10, Serhiy Storchaka wrote:
it can be used to
implement accelerated versions of separate methods instead of the whole
class.
Could you elaborate? I'm curious what you mean.
It is easy to implement a function in C. But there is a differenc
On 2019-04-05 14:10, Serhiy Storchaka wrote:
it can be used to
implement accelerated versions of separate methods instead of the whole
class.
Could you elaborate? I'm curious what you mean.
I'm going to use it to further optimize total_ordering.
There are so many ways in which total_orderin
05.04.19 09:07, Jeroen Demeyer пише:
On 2019-04-05 00:57, Greg Ewing wrote:
If it's designed for use by things outside of CPython, how
can you be sure nothing is using it?
Of course I'm not sure. However:
1. So far, nobody in this thread knows of any code using it.
2. So far, nobody in this
20 matches
Mail list logo
