Re: [Python-Dev] bitfields - short - and xlc compiler

2016-03-20 Thread Terry Reedy
On 3/20/2016 4:04 PM, Andrew Barnert via Python-Dev wrote: Agreed. But I think the test is reasonable on at least MSVC, gcc, clang, and icc. So what you need is some way to run the test on those compilers, but not on compilers that can't handle it. The test could be conditioned on the

Re: [Python-Dev] bitfields - short - and xlc compiler

2016-03-20 Thread Andrew Barnert via Python-Dev
On Mar 20, 2016, at 09:07, Michael Felt wrote: > >> On 2016-03-18 05:57, Andrew Barnert via Python-Dev wrote: >> Yeah, C99 (6.7.2.1) allows "a qualified or unqualified version of _Bool, >> signed int, unsigned int, or some other implementation-defined type", and >> same

Re: [Python-Dev] Counting references to Py_None

2016-03-20 Thread Tim Peters
[Facundo Batista ] > I'm seeing that our code increases the reference counting to Py_None, > and I find this a little strange: isn't Py_None eternal and will never > die? Yes, but it's immortal in CPython because its reference count never falls to 0 (it's created with a

Re: [Python-Dev] Counting references to Py_None

2016-03-20 Thread Brett Cannon
On Sun, 20 Mar 2016 at 09:44 Facundo Batista wrote: > Hello! > > I'm seeing that our code increases the reference counting to Py_None, > and I find this a little strange: isn't Py_None eternal and will never > die? > Semantically yes, but we have to technically make

Re: [Python-Dev] Counting references to Py_None

2016-03-20 Thread David Wilson
On Sun, Mar 20, 2016 at 01:43:27PM -0300, Facundo Batista wrote: > Hello! > > I'm seeing that our code increases the reference counting to Py_None, > and I find this a little strange: isn't Py_None eternal and will never > die? > > What's the point of counting its references? Avoiding a branch

[Python-Dev] Counting references to Py_None

2016-03-20 Thread Facundo Batista
Hello! I'm seeing that our code increases the reference counting to Py_None, and I find this a little strange: isn't Py_None eternal and will never die? What's the point of counting its references? Thanks! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr:

Re: [Python-Dev] bitfields - short - and xlc compiler

2016-03-20 Thread Michael Felt
On 2016-03-18 05:57, Andrew Barnert via Python-Dev wrote: Yeah, C99 (6.7.2.1) allows "a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type", and same for C11. This means that a compiler could easily allow an implementation-defined

Re: [Python-Dev] What does a double coding cookie mean?

2016-03-20 Thread Guido van Rossum
On Thu, Mar 17, 2016 at 9:50 AM, Serhiy Storchaka wrote: > On 17.03.16 16:55, Guido van Rossum wrote: >> >> On Thu, Mar 17, 2016 at 5:04 AM, Serhiy Storchaka >> wrote: Should we recommend that everyone use tokenize.detect_encoding()? >>> >>>

Re: [Python-Dev] What does a double coding cookie mean?

2016-03-20 Thread Ethan Furman
On 03/17/2016 04:54 PM, Glenn Linderman wrote: On 3/16/2016 12:59 AM, Serhiy Storchaka wrote: Actually "must match the regular expression" is not correct, because re.match() implies anchoring at the start. I have proposed more correct regular expression in other branch of this thread.

Re: [Python-Dev] What does a double coding cookie mean?

2016-03-20 Thread Nick Coghlan
On 20 March 2016 at 07:46, Glenn Linderman wrote: > Diagnosing ambiguous conditions, even including my example above, might be > useful... for a few files... is it worth the effort? What % of .py sources > have coding specifications? What % of those have two? And there's a

Re: [Python-Dev] What does a double coding cookie mean?

2016-03-20 Thread M.-A. Lemburg
On 17.03.2016 15:02, Serhiy Storchaka wrote: > On 17.03.16 15:14, M.-A. Lemburg wrote: >> On 17.03.2016 01:29, Guido van Rossum wrote: >>> Should we recommend that everyone use tokenize.detect_encoding()? >> >> I'd prefer a separate utility for this somewhere, since >> tokenize.detect_encoding()