> While the SC's decision to keep the syntax uniform is certainly laudable,
> it's creating the issue of packaging new complexities into a very limited
> syntactic & semantic space (e.g. no new magic symbols like "->", which I
> agree with BTW), leaving only very verbose solutions that the
Thank you PEP authors for producing a very well written and laid out PEP.
That made it easy to understand the proposal, rationale, and alternatives
considered. We agree that the existing typing.Callable syntax, while
capable, is less than ideal for humans. That said, we deliberated last week
and
On Thu, Feb 10, 2022 at 3:49 AM Brett Cannon wrote:
> On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote:
>> On 09. 02. 22 4:39, h.vetin...@gmx.com wrote:
>>
>> That's an interesting idea -- what's keeping us from C11?
>
> No one asking before, probably because we have been trying to get to C99
Andrew Svetlov schrieb am 09.02.22 um 19:40:
Stefan, do you really need to emulate call stack with positions?
Could the __note__ string with generated Cython part of exception traceback
solve your needs (https://www.python.org/dev/peps/pep-0678/) ?
Thanks for the link, but I think it would be
On Wed, Feb 9, 2022 at 8:54 AM Victor Stinner wrote:
> On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin wrote:
> > > Right now, a large number of macros cast their argument to a type. A
> > > few examples:
> > >
> > > #define PyObject_TypeCheck(ob, type)
> > > PyObject_TypeCheck(_PyObject_CAST(ob),
Penny for your thoughts on those questions, Brett? Protocols are new to me.
I see importlib.abc.Traversable is a Protocol, and I'm giving PEP 544 a
read now.
I reckon only stat(), open() and iterdir() would be essential for users to
implement.
On Wed, 9 Feb 2022 at 19:02, Brett Cannon wrote:
>
Guido van Rossum schrieb am 09.02.22 um 19:36:
On Wed, Feb 9, 2022 at 9:41 AM Pablo Galindo Salgado wrote:
On Wed, 9 Feb 2022 at 17:38, Stefan Behnel wrote:
Pablo Galindo Salgado schrieb am 09.02.22 um 17:40:
Should there be a getter/setter for co_positions?
We consider the representation
One thing to discuss (and which has been brought up on the PR), is whether
this should be an ABC to force people to explicitly raise
`NotImplementedError`?
The next question is whether any of this should be a (very wide) protocol
instead of an ABC?
On Wed, Feb 9, 2022 at 7:05 AM Barney Gale
That is on pourpose and is the public API for Python. In Python it returns
an iterable of tuples,
which is processed from the actual internal form.
On Wed, 9 Feb 2022 at 18:56, Victor Stinner wrote:
> On Wed, Feb 9, 2022 at 5:48 PM Pablo Galindo Salgado
> wrote:
> > We consider the
On Tue, Feb 8, 2022 at 10:20 PM Steven D'Aprano wrote:
> On Tue, Feb 08, 2022 at 05:48:46PM -0800, Gregory P. Smith wrote:
> > On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano
> wrote:
>
> > > If the answer to those questions are Yes, that rules out using Unums,
> > > posits, sigmoid numbers etc
On Wed, Feb 9, 2022 at 5:48 PM Pablo Galindo Salgado
wrote:
> We consider the representation of co_postions private, so we don't want (for
> now) to ad
> getters/setters. If you want to get the position of a instruction, you can
> use PyCode_Addr2Location
The code.co_positions() method is
Hi,
It's already possible to call PyObject_CallMethod(code,
"co_positions", NULL) and then use the iterator in C. Is there an use
case where performance of reading co_positions is critical? If not,
there is no need to add a specialized function.
Victor
On Wed, Feb 9, 2022 at 5:23 PM Petr
On Wed, Feb 9, 2022 at 4:19 AM Petr Viktorin wrote:
>
>
> On 09. 02. 22 4:39, h.vetin...@gmx.com wrote:
> >> Maybe a more practical approach would be to use C99 "except of
> > features not supported by MSVC of Visual Studio 2019"?
> >
> > This could be formulated in a more neutral way by saying
Stefan, do you really need to emulate call stack with positions?
Could the __note__ string with generated Cython part of exception traceback
solve your needs (https://www.python.org/dev/peps/pep-0678/) ?
On Wed, Feb 9, 2022 at 7:46 PM Pablo Galindo Salgado
wrote:
> I can only say that
It might require a detailed API design proposal coming from outside CPython
(e.g. from Cython) to get this to change. I imagine for co_positions in
particular this would have to use a "builder" pattern.
I am unclear on how this would work though, given that Cython generates C
code, not CPython
On Wed, 9 Feb 2022 at 15:46, Ethan Furman wrote:
> On 2/9/22 6:59 AM, Barney Gale wrote:
>
> > I've now submitted a PR that adds an initial underscore-prefixed
> implementation of this class:
>
> Why the iniitial underscore? What could change between now and the future?
>
A few things:
I can only say that currently, I am not confident to expose such an API,
at least for co_positions, as the internal implementation is very likely to
heavily change and we want to have the possibility of changing it between
patch versions if required (to address bugs and other things like that).
On 2/9/22 8:40 AM, Pablo Galindo Salgado wrote:
> Petr Viktorin wrote:
>> Should there be a getter/setter for co_positions?
>
> We consider the representation of co_postions private, so we don't want (for
now) to ad
> getters/setters.
Isn't the whole point of getters/setters is to allow public
Pablo Galindo Salgado schrieb am 09.02.22 um 17:40:
Should there be a getter/setter for co_positions?
We consider the representation of co_postions private
Yes, and that's the issue.
so we don't want (for now) to ad
getters/setters. If you want to get the position of a instruction, you
I think you skimmed over "A floating point expert can probably look at this ...
"
I remember a time when I just assumed more bits was better, and a later time
when I figured smaller was better, and a still later time when I wanted to
match the published requirements for bitsize. So that was
On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin wrote:
> > Right now, a large number of macros cast their argument to a type. A
> > few examples:
> >
> > #define PyObject_TypeCheck(ob, type)
> > PyObject_TypeCheck(_PyObject_CAST(ob), type)
> > #define PyTuple_GET_ITEM(op, i)
> Should there be a getter/setter for co_positions?
We consider the representation of co_postions private, so we don't want
(for now) to ad
getters/setters. If you want to get the position of a instruction, you can
use PyCode_Addr2Location
On Wed, 9 Feb 2022 at 16:22, Petr Viktorin wrote:
> On
On 04. 02. 22 15:23, Stefan Behnel wrote:
Petr Viktorin schrieb am 03.02.22 um 13:47:
On 02. 02. 22 11:50, Stefan Behnel wrote:
Maybe we should advertise the two modes more. And make sure that both
work. There are certainly issues with the current state of the
"limited API" implementation,
On 2/9/22 6:59 AM, Barney Gale wrote:
> Over the last couple of years I've been tidying up the pathlib internals,
with a view
> towards adding an AbstractPath class to the hierarchy. Users would be able to
subclass
> AbstractPath to implement other kinds of filesystems: s3, google cloud
Over the last couple of years I've been tidying up the pathlib internals,
with a view towards adding an AbstractPath class to the hierarchy. Users
would be able to subclass AbstractPath to implement other kinds of
filesystems: s3, google cloud storage, pandas, ftp, git, zip and tar files,
etc. By
On 2/8/2022 9:54 PM, Steven D'Aprano wrote:
Regarding your second point, about domain-specific tasks, I don't
understand. If your domain-specific task doesn't need to use floats,
just don't use floats. There's surely no need to invent a whole new
language for some task because your app only
On 08. 02. 22 12:07, Erlend Aasland wrote:
Petr, SC, thanks for your time and response! Just a quick comment:
On 8 Feb 2022, at 11:32, Petr Viktorin wrote:
In effect, the SC accepts the first part of the PEP, except cases where:
What status does that put the PEP in?
Still draft. It's
On 09. 02. 22 4:39, h.vetin...@gmx.com wrote:
Maybe a more practical approach would be to use C99 "except of
features not supported by MSVC of Visual Studio 2019"?
This could be formulated in a more neutral way by saying
"C99 without the things that became optional in C11", or perhaps
On 08. 02. 22 17:27, Victor Stinner wrote:
Hi Petr,
Thanks for the SC review, it's very helpful! I know that it's a big PEP :-)
On Tue, Feb 8, 2022 at 11:33 AM Petr Viktorin wrote:
*All other things being equal, static inline functions are better than
macros.*
Specifically, inline static
29 matches
Mail list logo
