Chris,
Could you please add a link to the email where the PEP was accepted?
Thanks,
Yury
On 2015-05-16 10:12 PM, chris.angelico wrote:
https://hg.python.org/peps/rev/f876276ce076
changeset: 5854:f876276ce076
user:Chris Angelico
date:Sun May 17 12:12:19 2015 +1000
summary:
On Mon, May 18, 2015 at 1:04 AM, Yury Selivanov wrote:
> Chris,
>
> Could you please add a link to the email where the PEP was accepted?
Sure. A Resolution: header is the right way to do this? Done.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.
On 5/17/2015 1:57 AM, Serhiy Storchaka wrote:
On 17.05.15 02:44, Ned Deily wrote:
In article <20150516183940.21146.77...@psf.io>,
serhiy.storchaka wrote:
https://hg.python.org/cpython/rev/7b350f712c0e
changeset: 96099:7b350f712c0e
parent: 96096:f0c94892ac31
parent: 96098:955dffec
On Sat, May 16, 2015 at 1:31 AM, Nick Coghlan wrote:
> On 16 May 2015 at 07:35, Nathaniel Smith wrote:
>> On Thu, May 14, 2015 at 11:53 PM, Nathaniel Smith wrote:
>>> On Thu, May 14, 2015 at 9:29 PM, Guido van Rossum wrote:
I expect you can make something that behaves like list by defining
Looking at PEP 484, I came up with two use cases that I felt were not
catered for:
1. Specifying that a parameter should be a subclass of another
(example: Type[dict] would match dict or OrderedDict; plain "Type"
would equal "type" from builtins)
2. Specifying that a callable should take a
Folks,
After a huge delay, I finally found the time to implement the PEP 485
isclose() function, in C. I tihnk it's time for some review. I appologise
for the fact that I have little experience with C, and haven't used the raw
C API for years, but it's a pretty simple function, and there's lots of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-05-18 01:02, Chris Barker wrote:
> * Is there a better way to create a False or True than::
>
> PyBool_FromLong(0) and PyBool_FromLong(1)
You can use the macros Py_RETURN_TRUE and Py_RETURN_FALSE instead of
return PyBool_FromLong(0).
> *
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
wrote:
> Looking at PEP 484, I came up with two use cases that I felt were not
> catered for:
>
>1. Specifying that a parameter should be a subclass of another
>(example: Type[dict] would match dict or OrderedDict; plain "Type" would
>eq
