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

[Glenn Linderman]

On 3/15/2016 11:07 PM, Chris Angelico wrote:

On Wed, Mar 16, 2016 at 5:03 PM, Serhiy Storchaka  wrote:

On 15.03.16 22: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


There is similar question. If a file has two different coding cookies on the
same line, what should win? Currently the last cookie wins, in CPython
parser, in the tokenize module, in IDLE, and in number of other code. I
think this is a bug.

Why would you ever have two coding cookies in a file? Surely this
should be either an error, or ill-defined (ie parsers are allowed to
pick whichever they like, including raising)?

ChrisA


From the PEP 263:


To define a source code encoding, a magic comment must
be placed into the source files either as first or second
line in the file, such as:


So clearly there is only one magic comment. "either" the first or second 
line, not both.  Both, therefore, should be an error.



From the PEP 263:


More precisely, the first or second line must match the regular
expression "coding[:=]\s*([-\w.]+)". The first group of this
expression is then interpreted as encoding name. If the encoding
is unknown to Python, an error is raised during compilation. There
must not be any Python statement on the line that contains the
encoding declaration.


Clearly the regular expression would only match the first of multiple 
cookies on the same line, so the first one should always win... but 
there should only be one, from the first PEP quote "a magic comment".


Glenn
___
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?

[Jonathan Goble]

On Wed, Mar 16, 2016 at 2:07 AM, Chris Angelico  wrote:
> Why would you ever have two coding cookies in a file? Surely this
> should be either an error, or ill-defined (ie parsers are allowed to
> pick whichever they like, including raising)?
>
> ChrisA

+1. If multiple coding cookies are found, and all do not agree, I
would expect an error to be raised. That it apparently does not raise
an error currently is surprising to me.

(If multiple coding cookies are found but do agree, perhaps raising a
warning would be a good idea.)
___
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?

[Chris Angelico]

On Wed, Mar 16, 2016 at 5:03 PM, Serhiy Storchaka  wrote:
> On 15.03.16 22: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
>
>
> There is similar question. If a file has two different coding cookies on the
> same line, what should win? Currently the last cookie wins, in CPython
> parser, in the tokenize module, in IDLE, and in number of other code. I
> think this is a bug.

Why would you ever have two coding cookies in a file? Surely this
should be either an error, or ill-defined (ie parsers are allowed to
pick whichever they like, including raising)?

ChrisA
___
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?

[Serhiy Storchaka]

On 15.03.16 22: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


There is similar question. If a file has two different coding cookies on 
the same line, what should win? Currently the last cookie wins, in 
CPython parser, in the tokenize module, in IDLE, and in number of other 
code. I think this is a bug.



___
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] Really sketchy Core Python GSoC 2016 ideas page up

[Terri Oda]

Hey all,

I've put up an incredibly sketchy, terrible ideas page up for Summer of 
Code with core python:


https://wiki.python.org/moin/SummerOfCode/2016/python-core

I'm pretty much the worst person to do this since I'm always swamped 
with admin stuff and particularly out of touch with what's needed in 
Core Python around this time of year, so I'm counting on you all to tell 
me that it's terrible and how to fix it. :)


If you don't already have edit privileges on the python wiki and need 
them for this, let me know your wiki username and I can get you set up. 
(Or similarly, just tell me what needs fixing and make it my problem.)


We're also still looking for more volunteers who can help mentor 
students. Let me know if this interests you -- we have a few folk who 
can do higher level code reviews, but we need more day-to-day mentors 
who can help students keep on track and help them figure out who to ask 
for help if they get stuck. I can also find folk who will provide 
mentoring for mentors if you'd like to try but don't think you could be 
a primary mentor without help!


If you're interested in mentoring, email gsoc-adm...@python.org and we 
can get you the link to sign up. And if you emailed before and didn't 
get a response or haven't found a group to work with, feel free to email 
again!


Terri
___
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?

[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?

[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?

[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?

[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?

[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?

[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?

[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

[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

[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

[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