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

2016-03-15 Thread Ben Finney
Guido van Rossum  writes:

> I agree that the spirit of the PEP is to stop at the first coding
> cookie found. Would it be okay if I updated the PEP to clarify this?
> I'll definitely also update the docs.

+1, it never occurred to me that the specification could mean otherwise.
On reflection I can't see a good reason for it to mean otherwise.

-- 
 \ “Alternative explanations are always welcome in science, if |
  `\   they are better and explain more. Alternative explanations that |
_o__) explain nothing are not welcome.” —Victor J. Stenger, 2001-11-05 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-03-15 Thread Guido van Rossum
I agree that the spirit of the PEP is to stop at the first coding
cookie found. Would it be okay if I updated the PEP to clarify this?
I'll definitely also update the docs.

On Tue, Mar 15, 2016 at 2:04 PM, Brett Cannon  wrote:
>
>
> On Tue, 15 Mar 2016 at 13:31 Guido van Rossum  wrote:
>>
>> I came across a file that had two different coding cookies -- one on
>> the first line and one on the second. CPython uses the first, but mypy
>> happens to use the second. I couldn't find anything in the spec or
>> docs ruling out the second interpretation. Does anyone have a
>> suggestion (apart from following CPython)?
>>
>> Reference: https://github.com/python/mypy/issues/1281
>
>
> I think the spirit of PEP 263 is for the first specified encoding to win as
> the support of two lines is to support shebangs and not multiple encodings
> :) . I also think the fact that tokenize.detect_encoding() doesn't
> automatically read two lines from its input also suggests the intent is
> "first encoding wins" (and that is the semantics of the function).



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-03-15 Thread MRAB

On 2016-03-15 20:53, MRAB wrote:

On 2016-03-15 20:30, Guido van Rossum wrote:

I came across a file that had two different coding cookies -- one on
the first line and one on the second. CPython uses the first, but mypy
happens to use the second. I couldn't find anything in the spec or
docs ruling out the second interpretation. Does anyone have a
suggestion (apart from following CPython)?

Reference: https://github.com/python/mypy/issues/1281


I think it should follow CPython.

As I see it, CPython allows it to be on the second line because the
first line might be needed for the shebang.

If the first two lines both had an encoding, and then you inserted a
shebang line, the second one would be ignored anyway.

A further thought: is mypy just assuming that the first line contains 
the shebang?


If there's only one encoding line, and it's the first line, does mypy 
still get it right?


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-03-15 Thread Jon Ribbens
On Tue, Mar 15, 2016 at 01:30:08PM -0700, Guido van Rossum wrote:
> I came across a file that had two different coding cookies -- one on
> the first line and one on the second. CPython uses the first, but mypy
> happens to use the second. I couldn't find anything in the spec or
> docs ruling out the second interpretation. Does anyone have a
> suggestion (apart from following CPython)?
> 
> Reference: https://github.com/python/mypy/issues/1281

If it helps, what 'vim' appears to do is to read the first 'n' lines
in order and then last 'n' lines in reverse order, stopping if the
second stage reaches a line already processed by the first stage.
So with 'modelines=5', the following file:

  /* vim: set ts=1: */
  /* vim: set ts=2: */
  /* vim: set ts=3: */
  /* vim: set ts=4: */
  /* vim: set sw=5 ts=5: */
  /* vim: set ts=6: */
  /* vim: set ts=7: */
  /* vim: set ts=8: */

sets sw=5 and ts=6.

Obviously CPython shouldn't be going through all that palaver!
But it would be a bit more vim-like to use the second line rather than
the first if both lines have the cookie.

Take that as you will - I'm not saying being 'vim-like' is an inherent
virtue ;-)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-03-15 Thread Brett Cannon
On Tue, 15 Mar 2016 at 13:31 Guido van Rossum  wrote:

> I came across a file that had two different coding cookies -- one on
> the first line and one on the second. CPython uses the first, but mypy
> happens to use the second. I couldn't find anything in the spec or
> docs ruling out the second interpretation. Does anyone have a
> suggestion (apart from following CPython)?
>
> Reference: https://github.com/python/mypy/issues/1281


I think the spirit of PEP 263 is for the first specified encoding to win as
the support of two lines is to support shebangs and not multiple encodings
:) . I also think the fact that tokenize.detect_encoding()

doesn't automatically read two lines from its input also suggests the
intent is "first encoding wins" (and that is the semantics of the function).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-03-15 Thread MRAB

On 2016-03-15 20:30, Guido van Rossum wrote:

I came across a file that had two different coding cookies -- one on
the first line and one on the second. CPython uses the first, but mypy
happens to use the second. I couldn't find anything in the spec or
docs ruling out the second interpretation. Does anyone have a
suggestion (apart from following CPython)?

Reference: https://github.com/python/mypy/issues/1281


I think it should follow CPython.

As I see it, CPython allows it to be on the second line because the 
first line might be needed for the shebang.


If the first two lines both had an encoding, and then you inserted a 
shebang line, the second one would be ignored anyway.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-03-15 Thread Guido van Rossum
I came across a file that had two different coding cookies -- one on
the first line and one on the second. CPython uses the first, but mypy
happens to use the second. I couldn't find anything in the spec or
docs ruling out the second interpretation. Does anyone have a
suggestion (apart from following CPython)?

Reference: https://github.com/python/mypy/issues/1281

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Bug in build system for cross-platform builds

2016-03-15 Thread Martin Panter
On 15 March 2016 at 08:04, Nick Coghlan  wrote:
> On 15 March 2016 at 15:15, Martin Panter  wrote:
>> _freeze_importlib.o: _freeze_importlib.c Makefile
>>
>> _freeze_importlib: _freeze_importlib.o [. . .]
>> $(LINKCC) [. . .]
>>
>> importlib_external.h: _bootstrap_external.py _freeze_importlib
>> _freeze_importlib _bootstrap_external.py importlib_external.h
>>
>> importlib.h: _bootstrap.py _freeze_importlib
>> _freeze_importlib _bootstrap.py importlib.h
>
> Ah, I understand now - the fundamental problem is with a checked in
> file depending on a non-checked-in file, so if you clean out all the
> native build artifacts when cross-compiling, the makefile will attempt
> to create target versions of all the helper utilities (pgen,
> _freeze_importlib, argument clinic, etc).
>
> Would it help to have a "make bootstrap" target that touched all the
> checked in generated files with build dependencies on non-checked-in
> files, but only after first touching the expected locations of the
> built binaries they depend on?

That sounds similar to “make touch”, with a couple differences. One
trouble I forsee is the conflict with shared prerequisites. E.g. “make
bootstrap” would have to create some dummy object files as
prerequisites of the pgen program, but we would first have build
others e.g. Parser/acceler.o properly for the main Python library. It
all feels way too complicated to me. The Python build system is
complicated enough as it is.

Maybe it is simplest to just add something in the spirit of Xavier’s
suggested patch. This would mean that we keep the generated files
checked in (to help with Windows and cross compiled builds), we keep
the current rules that force normal makefile builds to blindly
regenerate the files, but we add some flag or configure.ac check to
disable this regeneration if desired.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] New OpenSSL - has anyone ever looked at (in)compatibility with LibreSSL

2016-03-15 Thread Cory Benfield

> On 15 Mar 2016, at 01:08, Jim Baker  wrote:
> 
> I have no vested interest in this, other than the continuing work we have 
> done to make Jython compatible with OpenSSL's model, warts and all.
> 
> But the fact that BoringSSL cleans up the OpenSSL API 
> (https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md), at the cost 
> of possible backwards breaking API changes looks reasonable. I suppose there 
> is some risk - perhaps the maintainers will decide that returning 1 should 
> mean OK, but that's not going to happen, is it. The real issue here is that 
> no direct exposure of BoringSSL to other packages. I don't think that happens 
> with CPython. (Ironically it happens with Jython, due to how signed jars 
> poorly interact with shading/Java namespace remapping.)
> 
> Maintaining security means dealing with the inevitable churn. Did I mention 
> Jython's support of Python-compatible SSL? I think I did :p

It is *possible* to support BoringSSL: curl does. However, the BoringSSL 
developers *really* only target Chromium when they consider the possibility of 
breakage, so it costs curl quite a bit of development time[0]. curl accepts 
that cost because it supports every TLS stack under the sun: given that CPython 
currently supports exactly one, widening it to two is a very big risk indeed.

Cory


[0]: See https://github.com/curl/curl/issues/275, 
https://github.com/curl/curl/pull/524, https://github.com/curl/curl/pull/640



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Bug in build system for cross-platform builds

2016-03-15 Thread Nick Coghlan
On 15 March 2016 at 15:15, Martin Panter  wrote:
> The problem is not the reference to Makefile. The graminit files do
> not depend on Makefile. The bigger problem is that the checked-in
> files depend on compiled programs. This is a summary of the current
> rules for importlib:
>
> _freeze_importlib.o: _freeze_importlib.c Makefile
>
> _freeze_importlib: _freeze_importlib.o [. . .]
> $(LINKCC) [. . .]
>
> importlib_external.h: _bootstrap_external.py _freeze_importlib
> _freeze_importlib _bootstrap_external.py importlib_external.h
>
> importlib.h: _bootstrap.py _freeze_importlib
> _freeze_importlib _bootstrap.py importlib.h
>
> So importlib.h depends on the _freeze_importlib compiled program (and
> only indirectly on Makefile). The makefile says we have to compile
> _freeze_importlib before checking if importlib.h is up to date.

Ah, I understand now - the fundamental problem is with a checked in
file depending on a non-checked-in file, so if you clean out all the
native build artifacts when cross-compiling, the makefile will attempt
to create target versions of all the helper utilities (pgen,
_freeze_importlib, argument clinic, etc).

Would it help to have a "make bootstrap" target that touched all the
checked in generated files with build dependencies on non-checked-in
files, but only after first touching the expected locations of the
built binaries they depend on?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com