Hello,
I have a question about PEP 384: can undocumented functions ever be
considered as part of the stable ABI? With undocumented, I mean not
appearing in the "Python/C API Reference Manual".
Whatever the answer to this question is, it would be good to make it
explicit in PEP 384.
I am in
Apologies if this is not the correct place to report this, but I am seeing
outages on bugs.python.org.
I am in the Chicago area so maybe this is a regional issue or possibly the
site is being update, but I wanted to report it.
Matt Eaton (Agnosticdev)
_
It would be helpful if you explained the context of your request. E.g. did
you have some code that broke due to a change in one of these functions, or
are you contemplating a change to one of them? And specifics of what broke
or what you're contemplating.
On Wed, Apr 4, 2018 at 1:58 AM, Jeroen Dem
On Apr 4, 2018, at 07:21, Agnostic Dev wrote:
> Apologies if this is not the correct place to report this, but I am seeing
> outages on bugs.python.org.
> I am in the Chicago area so maybe this is a regional issue or possibly the
> site is being update, but I wanted to report it.
You are not al
On Apr 4, 2018, at 12:59, Ned Deily wrote:
> On Apr 4, 2018, at 07:21, Agnostic Dev wrote:
>> Apologies if this is not the correct place to report this, but I am seeing
>> outages on bugs.python.org.
>> I am in the Chicago area so maybe this is a regional issue or possibly the
>> site is being
There are a bunch of open issues regarding gdb support including one with a PR
in need of review for 3.6+. I imagine that there are duplicates at least among
the more recent open issues. If you use and are familiar with the gdb macros,
it would be really swell if you could take some time to re
API question.
Background:
--
When doing checks such as
--> 3 in [4, 5, 6]
--> 'test' in {'test':True, 'live':False}
the result is True or False.
When doing checks such as
--> 3 in 'hello world'
--> [4, 5, 6] in {'test':True, 'live':False}
the result is a TypeError.
The general rule
On Wed, 4 Apr 2018 at 11:30 Ethan Furman wrote:
> API question.
>
> Background:
> --
>
> When doing checks such as
>
> --> 3 in [4, 5, 6]
> --> 'test' in {'test':True, 'live':False}
>
> the result is True or False.
>
> When doing checks such as
>
> --> 3 in 'hello world'
> --> [4, 5, 6] i
On Apr 4, 2018, at 11:32, Ethan Furman wrote:
>
> (A) A standard Enum class is a container of Enum members. It cannot hold
> anything else. However, it has been returning False both in cases where the
> in-question object was an Enum of a different class (a Fruit in a Color, for
> example) a
I expect that for IntFlag `x in flags` is equivalent either to
bool(x | flags.value)
or to
(x | flags.value) == x
It should return some result only if x is an integer (or compatible with
integers) and raise a TypeError otherwise.
Don't add any special checks unless there are good re
On 04/04/2018 12:40 PM, Barry Warsaw wrote:
On Apr 4, 2018, at 11:32, Ethan Furman wrote:
(A) A standard Enum class is a container of Enum members. It cannot hold
anything else...
(B) The waters get even more muddied when Fruit has a str mixin, so
`Fruit.APPLE == 'apple' is True`...
Are
Hi,
I like to share the story of a critical security bug with you. Contrary
to other issues in TLS/SSL, it's a story with happy ending. Nobody was
harmed. The bug was fixed before it affected the general population.
Introduction
Python's ssl.match_hostname() function was a source o
On 4/4/2018 11:32 AM, Ethan Furman wrote:
API question.
Background:
--
When doing checks such as
--> 3 in [4, 5, 6]
--> 'test' in {'test':True, 'live':False}
the result is True or False.
When doing checks such as
--> 3 in 'hello world'
--> [4, 5, 6] in {'test':True, 'live':False}
t
On 04/04/2018 01:24 PM, Glenn Linderman wrote:
I think the "in" test should raise TypeError if tested against _anything_ that
is not an Enum member.
Why? I see a parallel between Enum and mappings.
x = {'test':True, 'live':False}
So it is True that 'test' in x and 'live' in x and False
I don't think of "in" as an equality test -- it's special just like <, <=,
>, >= are special, and those can certainly raise TypeError.
On Wed, Apr 4, 2018 at 2:07 PM, Ethan Furman wrote:
> On 04/04/2018 01:24 PM, Glenn Linderman wrote:
>
> I think the "in" test should raise TypeError if tested a
On 04/04/2018 02:12 PM, Guido van Rossum wrote:
I don't think of "in" as an equality test -- it's special just like <, <=,
> >, >= are special, and those can certainly raise TypeError.
Good to know, thank you!
--
~Ethan~
___
Python-Dev mailing list
Hi all,
It's that time yet again: I'm planning to release 2.7.15 release candidate 1 on
April 14 and a final release two weeks later on April 28.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubs
On 2018-04-04 17:56, Guido van Rossum wrote:
It would be helpful if you explained the context of your request.
The context is PEP 575. I guess my question is mostly about
PyCFunction_Check(). I will not be able to keep it 100% backwards
compatible simply because the goal of that PEP is precis
18 matches
Mail list logo
