On behalf of the Python development community and the Python 3.4 and
Python 3.5 release teams, I'm delighted to announce the availability of
Python 3.4.6 and Python 3.5.3.
Python 3.4 is now in "security fixes only" mode. This is the final
stage of support for Python 3.4. Python 3.4 now onl
Oh, I found another recent bug fixed because of the "O" weird behaviour:
http://bugs.python.org/issue26478
"dict views don't implement subtraction correctly"
Victor
2016-12-09 18:46 GMT+01:00 Victor Stinner :
> Hi,
>
> The PyObject_CallFunction() function has a special case when the
> format stri
Hi,
I miss abstract base classes in collections.abc implementing the descriptor
protocol. Any reason why they do not exist?
What do you think of adding NonDataDescriptor and DataDescriptor ABCs?
Best regards,
Roberto
___
Python-Dev mailing list
Python-
On Mon, 16 Jan 2017 at 22:34 INADA Naoki wrote:
> Hi.
>
> ---
> This discussion is started in http://bugs.python.org/issue29259, and
> there is separated issue at http://bugs.python.org/issue29260 .
> But I want to see more comments, before issue 29259 is committed.
> ---
>
> Since Python 3.6, so
Well, these are an example of the purest duck typing. Just implement
__get__ and/or __set__ (and __delete__) and you're good.
What's the situation where you miss them?
--Guido
On Tue, Jan 17, 2017 at 8:51 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
> Hi,
>
> I miss abstract base c
I need to check if some objects obey the descriptor protocol in the
construction of a metaclass. I expect to be able to write something like:
if isinstance(myobj, abc.DataDescriptor):
# do something
The other idea crossing my mind is something like:
if all(hasattr(myobj, attr) for attr in ('_
For this use case I see nothing wrong with hasattr(myobj, '__set__').
On Tue, Jan 17, 2017 at 9:41 AM, Roberto Martínez <
robertomartin...@gmail.com> wrote:
> I need to check if some objects obey the descriptor protocol in the
> construction of a metaclass. I expect to be able to write something
Well, for me having to check both __get__ and __str__ for a data descriptor
feels inelegant.
After read the documentation of collections.abc again "This module provides
abstract base classes that can be used to test whether a class provides a
particular interface; for example, whether it is hashab
But you can never get people to use the new ABCs consistently.
Anyway, I'm not -1, I'm just -0 -- I don't think it'll make any difference
and you're better off just checking for __set__ (if it only has __set__ but
not __get__, do you care what it is?).
On Tue, Jan 17, 2017 at 10:18 AM, Roberto Ma
Avoiding header files would be my only request. As Brett says, the C99
requirement should not be enforced on all embedders or extenders, so we should
try and keep the headers they'll use as compatible as possible.
Cheers,
Steve
Top-posted from my Windows Phone
-Original Message-
From:
Oh, I understand. Maybe is not worth the effort anyway.
Thank you
El mar., 17 ene. 2017 a las 19:40, Guido van Rossum ()
escribió:
But you can never get people to use the new ABCs consistently.
Anyway, I'm not -1, I'm just -0 -- I don't think it'll make any difference
and you're better off just
On 2017-01-17 11:55 AM, Brett Cannon wrote:
So, how widely can we use "designated initializer"?
Only in Modules (_asyncio uses it already)?
Or almost everywhere (Objects/ and Python/)?
I say everywhere we can (and that also means we should probably update the
xx* files in Modules/).
+1.
Yur
On 17 January 2017 at 20:02, Steve Dower wrote:
> Avoiding header files would be my only request. As Brett says, the C99
> requirement should not be enforced on all embedders or extenders, so we
> should try and keep the headers they'll use as compatible as possible.
Agreed, we probably shouldn't
On 01/17/2017 12:02 PM, Steve Dower wrote:
Avoiding header files would be my only request. As Brett says, the C99
requirement should not be enforced on all embedders or extenders, so
we should try and keep the headers they'll use as compatible as possible.
While that's a reasonable policy, u
On 17/01/17 06:32, INADA Naoki wrote:
With designated initializer, it becomes:
0, /* tp_free */
+.tp_fastcall = (fastternaryfunc)attrgetter_call,
};
It's readable, and easy to review.
FWIW, I dislike mixing the two forms (because it still prevents th
On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings wrote:
>
> On 01/17/2017 12:02 PM, Steve Dower wrote:
>
> Avoiding header files would be my only request. As Brett says, the C99
> requirement should not be enforced on all embedders or extenders, so we
> should try and keep the headers they'll use a
On Wed, Jan 18, 2017 at 9:00 AM, Erik wrote:
> On 17/01/17 06:32, INADA Naoki wrote:
>>
>> With designated initializer, it becomes:
>>
>> 0, /* tp_free */
>> +.tp_fastcall = (fastternaryfunc)attrgetter_call,
>> };
>>
>> It's readable, and easy to review.
On 01/17/2017 04:48 PM, INADA Naoki wrote:
On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings wrote:
While that's a reasonable policy, unless we have a way to automatically
detect that I suspect C99 stuff will creep into the header files and break
the non-C99 customers. Maybe we could get some s
2017-01-18 1:59 GMT+01:00 INADA Naoki :
> I think mixing two forms is OK only if new form is used only at bottom.
> (like keyword arguments are allowed after all positional arguments in
> Python function calling)
>
> Complete rewriting makes diff huge. And there is PyVarObject_HEAD_INIT
> already
> On Jan 17, 2017, at 5:16 PM, Victor Stinner wrote:
>
> /* tp_xxx */" lines and make the code much more
> readable! It should help to prevent bugs when the code is modified.
I'm +0 on the change (it is a massive code churn with a huge diff and won't
match any existing C extensions or publish
I'm for allowing the new convention. If it had been supported 20 years ago
I would've used it.
I'm against changing any existing code to use it -- such massive changes
are high risk and low reward. Just do it for new fields or new types.
I recommend being reluctant to add new fields -- the number
On Tue, Jan 17, 2017 at 4:48 PM, INADA Naoki wrote:
> On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings wrote:
>>
>> On 01/17/2017 12:02 PM, Steve Dower wrote:
>>
>> Avoiding header files would be my only request. As Brett says, the C99
>> requirement should not be enforced on all embedders or exte
As well as pre-C99 compilers, there are also C++ compilers to think of.
It may be easier to identify the likely features we want to avoid and regex
find them in the test suite. Combined with code reviews and the fact that we
can change syntax in the header files whenever we want without impact (
> On Jan 17, 2017, at 11:41 AM, Roberto Martínez
> wrote:
>
> Oh, I understand. Maybe is not worth the effort anyway.
FWIW, I'm also in the camp of thinking it is not worth the effort. Until there
is a demonstrated need (something than can't be met by checking for __set__),
the default posi
2017-01-18 3:28 GMT+01:00 Guido van Rossum :
> I recommend being reluctant to add new fields -- the number of type objects
> is larger than you'd think and these are static bytes which I consider a
> relatively expensive resource.
>
> There's also an ABI issue with new fields -- new fields can only
On Tue, Jan 17, 2017, at 15:34, Paul Moore wrote:
> On 17 January 2017 at 20:02, Steve Dower wrote:
> > Avoiding header files would be my only request. As Brett says, the C99
> > requirement should not be enforced on all embedders or extenders, so we
> > should try and keep the headers they'll u
26 matches
Mail list logo
