On 2018-09-04, Eddie Elizondo wrote:
> Solution:
>
> * Fix the implementation of PyStructSequence_NewType:
>
> The best solution would be to fix the implementation of this
> function. This can easily be done by dynamically creating a
> PyType_Spec and calling PyType_FromSpec
Hello Eddie,
Th
On 2018-09-13, Victor Stinner wrote:
> Right, that's a side effect of the discussion on the C API. It seems
> like Py_TYPE() has to go in the new C API. Sorry, the rationale is not
> written down yet, but Dino convinced me that Py_TYPE() has to go :-)
My understanding is that using Py_TYPE() insid
On 9/13/2018 8:04 PM, Victor Stinner wrote:
Le ven. 14 sept. 2018 à 00:09, Eric V. Smith a écrit :
f'{type(obj)}' becomes type(obj).__format__(''), so you can return
something other than __str__ or __repr__ does. It's only by convention
that an object's __format__ returns __str__: it need not
Le ven. 14 sept. 2018 à 00:09, Eric V. Smith a écrit :
> f'{type(obj)}' becomes type(obj).__format__(''), so you can return
> something other than __str__ or __repr__ does. It's only by convention
> that an object's __format__ returns __str__: it need not do so.
What's New in Python 3.7 contains:
2018年9月13日(木) 18:22 Jeroen Demeyer :
> On 2018-09-13 02:26, Petr Viktorin wrote:
>
> > PyCCall_FASTCALL is not a macro, shouldn't it be named PyCCall_FastCall?
>
> What's the convention for that anyway? I assumed that capital letters
> meant a "really know what you are doing" function which could
On 06/09/2018 07.18, Victor Stinner wrote:
> Hi,
>
> The Python bug tracker is full of bugs, and sadly we don't have enough
> people to take care of all of them. There are 3 open bugs about
> security issues in XML and I simply propose to close it:
>
>https://bugs.python.org/issue17318
>h
On 9/13/2018 5:52 PM, Petr Viktorin wrote:
On 09/13/18 14:08, Victor Stinner wrote:
Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a
écrit :
* Add !t conversion to format string
I'm strongly opposed to this. This !t conversion would not be widely
applicable enough to be generally useful, and w
On 09/13/18 14:08, Victor Stinner wrote:
Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit :
* Add !t conversion to format string
I'm strongly opposed to this. This !t conversion would not be widely
applicable enough to be generally useful, and would need to be exposed
in the f-string and
Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith a écrit :
> > * Add !t conversion to format string
>
> I'm strongly opposed to this. This !t conversion would not be widely
> applicable enough to be generally useful, and would need to be exposed
> in the f-string and str.format() documentation, even t
Hi,
Can I request a review of https://github.com/python/cpython/pull/6641.
It has been open for a few months now.
Cheers,
Mark.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://
On 09/13/2018 07:01 AM, Eric V. Smith wrote:
On 9/12/2018 8:33 PM, Victor Stinner wrote:
Hi,
For the type name, sometimes, we only get a type (not an instance),
and we want to format its FQN. IMHO we need to provide ways to format
the FQN of a type for *types* and for *instances*. Here is my
On 09/13/18 02:22, Jeroen Demeyer wrote:
On 2018-09-13 02:26, Petr Viktorin wrote:
The reference to PEP 573 is premature.
It seems to me that PEP 580 helps with the use case of PEP 573. In fact,
it implements part of what PEP 573 proposes. So I don't see the problem
with the reference to PEP
On 9/12/2018 8:33 PM, Victor Stinner wrote:
Hi,
For the type name, sometimes, we only get a type (not an instance),
and we want to format its FQN. IMHO we need to provide ways to format
the FQN of a type for *types* and for *instances*. Here is my
proposal:
* Add !t conversion to format string
On 2018-09-13 02:26, Petr Viktorin wrote:
The reference to PEP 573 is premature.
It seems to me that PEP 580 helps with the use case of PEP 573. In fact,
it implements part of what PEP 573 proposes. So I don't see the problem
with the reference to PEP 573. Even if the implementation of PEP 57
On 13 Sep 2018, at 2:33, Victor Stinner wrote:
Hi,
For the type name, sometimes, we only get a type (not an instance),
and we want to format its FQN. IMHO we need to provide ways to format
the FQN of a type for *types* and for *instances*. Here is my
proposal:
* Add !t conversion to format str
15 matches
Mail list logo