Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Mariatta Wijaya]

Starting with core-mentorship and then core-workflow sounds good.

Let me first find out what it's going to take to do the migration. (I
actually have no idea!)
I've sent an email to postmaster and asked for more details :)

Hope it's not too complicated...

Mariatta Wijaya
___
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] Migrate python-dev to Mailman 3?

[Guido van Rossum]

Another one is core-mentorship, which satisfies the same criteria; and in
my view this has the added and useful property that its beneficiaries are
non-core members. After that I'd do core-workflow. Honestly I'd leave
python-committers alone for a while, we're a curmudgeonly group. :-)

On Wed, Nov 1, 2017 at 7:54 PM, Barry Warsaw  wrote:

> On Nov 1, 2017, at 19:42, Guido van Rossum  wrote:
> >
> > Maybe we should try it on some other list too? I know it works "in
> principle" and I'd love for all Python mailing lists to migrate, but I'd
> like to have some more experience with community mailing lists before
> tackling python-dev.
>
> What about core-workflow or committers?  I think some of the criteria are:
>
> * Gets a fair bit of traffic, but not too much
> * Is okay with a little bit of downtime for the migration
> * Willing to put up with any transient migration snafus
> * Amenable to trying the new UI
> * Has the BDFL as a member :)
>
> -Barry
>
>
> ___
> 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/
> guido%40python.org
>
>


-- 
--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] Migrate python-dev to Mailman 3?

[Lukasz Langa]

+1 committers

> On Nov 1, 2017, at 7:54 PM, Barry Warsaw  wrote:
> 
> On Nov 1, 2017, at 19:42, Guido van Rossum  wrote:
>> 
>> Maybe we should try it on some other list too? I know it works "in 
>> principle" and I'd love for all Python mailing lists to migrate, but I'd 
>> like to have some more experience with community mailing lists before 
>> tackling python-dev.
> 
> What about core-workflow or committers?  I think some of the criteria are:
> 
> * Gets a fair bit of traffic, but not too much
> * Is okay with a little bit of downtime for the migration
> * Willing to put up with any transient migration snafus
> * Amenable to trying the new UI
> * Has the BDFL as a member :)
> 
> -Barry
> 
> ___
> 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/lukasz%40langa.pl



signature.asc
Description: Message signed with OpenPGP
___
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] Migrate python-dev to Mailman 3?

[Barry Warsaw]

On Nov 1, 2017, at 19:42, Guido van Rossum  wrote:
> 
> Maybe we should try it on some other list too? I know it works "in principle" 
> and I'd love for all Python mailing lists to migrate, but I'd like to have 
> some more experience with community mailing lists before tackling python-dev.

What about core-workflow or committers?  I think some of the criteria are:

* Gets a fair bit of traffic, but not too much
* Is okay with a little bit of downtime for the migration
* Willing to put up with any transient migration snafus
* Amenable to trying the new UI
* Has the BDFL as a member :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] Migrate python-dev to Mailman 3?

[Guido van Rossum]

Maybe we should try it on some other list too? I know it works "in
principle" and I'd love for all Python mailing lists to migrate, but I'd
like to have some more experience with community mailing lists before
tackling python-dev.

On Wed, Nov 1, 2017 at 7:31 PM, Barry Warsaw  wrote:

> On Nov 1, 2017, at 18:49, Mariatta Wijaya 
> wrote:
> >
> > Anything I can do to help make the migration to MM3 + HyperKitty happen?
> :)
>
> Thanks for the offer Mariatta!  Assuming this is something we want to go
> through with, probably the best way to get there is to work with the
> postmaster, especially Mark Sapiro, on the migration.
>
> Cheers,
> -Barry
>
>
> ___
> 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/
> guido%40python.org
>
>


-- 
--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] Migrate python-dev to Mailman 3?

[Barry Warsaw]

On Nov 1, 2017, at 18:49, Mariatta Wijaya  wrote:
> 
> Anything I can do to help make the migration to MM3 + HyperKitty happen? :)

Thanks for the offer Mariatta!  Assuming this is something we want to go 
through with, probably the best way to get there is to work with the 
postmaster, especially Mark Sapiro, on the migration.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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] [edk2] Official port of Python on EDK2

[Richardson, Brian]

Thiebaud:

Thank you. I have started discussions within Intel for updating the UEFI 
CPython implementation to Python 3.x. The TianoCore community would appreciate 
contributions by people with Python experience to bring this code up to current 
standards.

Please review the contribution guidelines for TianoCore and let me know if you 
have any questions.
http://www.tianocore.org/contrib/ 

Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson
 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Thiebaud 
Weksteen
Sent: Wednesday, November 1, 2017 5:07 AM
To: python-dev@python.org
Cc: edk2-de...@lists.01.org
Subject: [edk2] Official port of Python on EDK2

Hi,

UEFI has become the standard for firmware (BIOS) interface. Intel has provided 
an open source implementation under the name EDK2 (part of the TianoCore 
initiative) [1] for some time. This implementation has evolved significantly 
and now provides the functionalities of a small OS with a standard library 
similar to POSIX.

In 2011, a port of Python 2.7.1 was added to the EDK2 repository [2].
This port then evolved to 2.7.2 which is still defined as the reference port 
[3]. In 2015, another port was added of Python 2.7.10 in parallel of 2.7.2 [4]. 
Since then, both implementations have diverged from upstream and know 
vulnerabilities have not been fixed.

I would like to bring support for edk2 in the official Python repository to 
remediate this situation, that is officially support
edk2 as a platform. Technically, there would be three main aspects for the 
on-boarding work:

1) Fix headers and source to resolve definition conflicts, similarly to ABS 
definition in [5];
2) Add the edk2module.c [6] to handle platform-specific functionalities, 
similarly to the posixmodule.c;
3) Add the build configuration file [7] and necessary modifications within 
Python to handle the edk2 toolchain;

This work would target the master branch (that is Python 3). I would be 
interested in hearing your thoughts on this idea.

Thanks,
Thiebaud

[1] https://github.com/tianocore/edk2
[2] 
https://github.com/tianocore/edk2/commit/006fecd5a177b4b7b6b36fab6690bf2b2fa11829
[3] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonReadMe.txt
[4] 
https://github.com/tianocore/edk2/commit/c8042e10763bca064df257547d04ae3dfcdfaf91
[5] https://gist.github.com/tweksteen/ed516ca7ab7dfa8d18428f59d9c22a3e
[6] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/Efi/edk2module.c
[7] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonCore.inf
___
edk2-devel mailing list
edk2-de...@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
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] PEP 511 (code transformers) rejected

[Nick Coghlan]

On 2 November 2017 at 09:16, Lukasz Langa  wrote:

> I find this sad. In the JavaScript community the existence of Babel is
> very important for the long-term evolution of the language independently
> from the runtime. With Babel, JavaScript programmers can utilize new
> language syntax while being able to deploy on dated browsers. While there's
> always some experimentation, I doubt our community would abuse the new
> syntactic freedom that the PEP provided.
>
> Then again, maybe we should do what Babel did, e.g. release a tool like it
> totally separately from the runtime.
>

Right, I think python-modernize and python-future provide a better model
for Babel equivalents in Python than anything built directly into CPython
would.

In many ways, python-future's pasteurize already *is* that kind of
polyfill, where you get to write nice modern Python yourself, and then ask
pasteurize to mess it up so it also works on Python 2.7:
http://python-future.org/pasteurize.html

The piece that we're currently missing to make such workflows easier to
manage is an equivalent of JavaScript's source maps (
http://blog.teamtreehouse.com/introduction-source-maps), together with
debugging tools that are able to use source map information to generate
nice tracebacks, even when the original sources are unavailable.

Source maps could also potentially help with getting meaningful tracebacks
in other contexts, like bytecode-only deployments and Cython extension
modules (for example, the traceback problem is the main reason Red Hat's
Python container images still have the source code in them - when that was
last measured, you could get an image size reduction of around 15% by
including only the pyc files and omitting the original sources, but it
wasn't worth it when it came at the cost of making tracebacks unreadable).

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

Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Mariatta Wijaya]

Anything I can do to help make the migration to MM3 + HyperKitty happen? :)

Mariatta Wijaya
___
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] [python-committers] Reminder: 12 weeks to 3.7 feature code cutoff

[Nick Coghlan]

On 2 November 2017 at 07:47, Ned Deily  wrote:

> Happy belated Halloween to those who celebrate it; I hope it wasn't too
> scary!  Also possibly scary: we have just a little over 12 weeks remaining
> until Python 3.7's feature code cutoff, 2018-01-29.  Those 12 weeks include
> a number of traditional holidays around the world so, if you are planning
> on writing another PEP for 3.7 or working on getting an existing one
> approved or getting feature code reviewed, please plan accordingly.
> If you have something in the pipeline, please either let me know or, when
> implemented, add the feature to PEP 537, the 3.7 Release Schedule PEP.


My two main open items for 3.7 are:

- PEP 558 (formally defining expected semantics for local namespaces)
- making the points where we check for asynchronous signals more
deterministic (https://bugs.python.org/issue29988)

For 558, I'm finally happy with the proposed design, so I just need to sit
down and actually make a working write-through proxy implementation.

For the signal handling checks, the problem is that
https://bugs.python.org/issue29988#msg301869 makes me nervous about
adjusting the typical locations where interrupts get raised without also
making it easier to temporarily disable such checks (and having with
statements do so while calling cleanup functions).

Cheers,
Nick.

P.S. Work on the latter issue provided the primary motivation for the new
per-opcode tracing feature: it lets us reliably inject expections at "bad"
times, so otherwise rare race conditions can be deliberately provoked.

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

Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Lukasz Langa]

> On Oct 30, 2017, at 4:00 AM, Victor Stinner  wrote:
> 
> Except of Antoine Pitrou, does everybody else like the new UI? :-)

I also much prefer MM3 and HyperKitty.

The old pipermail tree looks more inviting (I like the concise tree) but it's 
deceiving. When you actually start going through an entire discussion, it's 
easy to lose track unless posters use quotations neatly.

The search functionality of HyperKitty alone is worth it.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
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] PEP 530

[Lukasz Langa]

The original poster is an elementary school student. To keep the list clean, I 
responded 1:1 in a more inviting manner. Hopefully the person will succeed 
installing and learning Python :-)

- Ł

> On Oct 28, 2017, at 2:33 PM, Terry Reedy  wrote:
> 
> On 10/27/2017 4:43 PM, London wrote:
>> can you help me get idol for my computer
> 
> Post questions about using python on python-list and include information 
> about what OS you are running and what version of Python you want.
> 
> --
> Terry Jan Reedy
> 
> ___
> 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/lukasz%40langa.pl



signature.asc
Description: Message signed with OpenPGP
___
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] PEP 511 (code transformers) rejected

[Lukasz Langa]

I find this sad. In the JavaScript community the existence of Babel is very 
important for the long-term evolution of the language independently from the 
runtime. With Babel, JavaScript programmers can utilize new language syntax 
while being able to deploy on dated browsers. While there's always some 
experimentation, I doubt our community would abuse the new syntactic freedom 
that the PEP provided.

Then again, maybe we should do what Babel did, e.g. release a tool like it 
totally separately from the runtime.

- Ł

> On Oct 17, 2017, at 1:23 PM, Victor Stinner  wrote:
> 
> Hi,
> 
> I rejected my own PEP 511 "API for code transformers" that I wrote in
> January 2016:
> 
> https://github.com/python/peps/commit/9d8fd950014a80324791d7dae3c130b1b64fdace
> 
> Rejection Notice:
> 
> """
> This PEP was rejected by its author.
> 
> This PEP was seen as blessing new Python-like programming languages
> which are close but incompatible with the regular Python language. It
> was decided to not promote syntaxes incompatible with Python.
> 
> This PEP was also seen as a nice tool to experiment new Python features,
> but it is already possible to experiment them without the PEP, only with
> importlib hooks. If a feature becomes useful, it should be directly part
> of Python, instead of depending on an third party Python module.
> 
> Finally, this PEP was driven was the FAT Python optimization project
> which was abandonned in 2016, since it was not possible to show any
> significant speedup, but also because of the lack of time to implement
> the most advanced and complex optimizations.
> """
> 
> Victor
> ___
> 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/lukasz%40langa.pl



signature.asc
Description: Message signed with OpenPGP
___
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] PEP 563: Postponed Evaluation of Annotations

[Lukasz Langa]

Based on positive feedback on python-ideas back in September,
I'm publishing the second draft for consideration on python-dev.
I hope you like it!

A nicely formatted rendering is available here:
https://www.python.org/dev/peps/pep-0563/

(Just make sure you're looking at the version that has
"Post-History: 1-Nov-2017" as you might have an older version
cached by your browser, or you might be seeing a newer
version if you get to this e-mail in the future.)

- Ł



PEP: 563
Title: Postponed Evaluation of Annotations
Version: $Revision$
Last-Modified: $Date$
Author: Łukasz Langa 
Discussions-To: Python-Dev 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 8-Sep-2017
Python-Version: 3.7
Post-History: 1-Nov-2017
Resolution:


Abstract


PEP 3107 introduced syntax for function annotations, but the semantics
were deliberately left undefined.  PEP 484 introduced a standard meaning
to annotations: type hints.  PEP 526 defined variable annotations,
explicitly tying them with the type hinting use case.

This PEP proposes changing function annotations and variable annotations
so that they are no longer evaluated at function definition time.
Instead, they are preserved in ``__annotations__`` in string form.

This change is going to be introduced gradually, starting with a new
``__future__`` import in Python 3.7.


Rationale and Goals
===

PEP 3107 added support for arbitrary annotations on parts of a function
definition.  Just like default values, annotations are evaluated at
function definition time.  This creates a number of issues for the type
hinting use case:

* forward references: when a type hint contains names that have not been
  defined yet, that definition needs to be expressed as a string
  literal;

* type hints are executed at module import time, which is not
  computationally free.

Postponing the evaluation of annotations solves both problems.

Non-goals
-

Just like in PEP 484 and PEP 526, it should be emphasized that **Python
will remain a dynamically typed language, and the authors have no desire
to ever make type hints mandatory, even by convention.**

This PEP is meant to solve the problem of forward references in type
annotations.  There are still cases outside of annotations where
forward references will require usage of string literals.  Those are
listed in a later section of this document.

Annotations without forced evaluation enable opportunities to improve
the syntax of type hints.  This idea will require its own separate PEP
and is not discussed further in this document.

Non-typing usage of annotations
---

While annotations are still available for arbitrary use besides type
checking, it is worth mentioning that the design of this PEP, as well
as its precursors (PEP 484 and PEP 526), is predominantly motivated by
the type hinting use case.

With Python 3.7, PEP 484 graduates from provisional status.  Other
enhancements to the Python programming language like PEP 544, PEP 557,
or PEP 560, are already being built on this basis as they depend on
type annotations and the ``typing`` module as defined by PEP 484.

With this in mind, uses for annotations incompatible with the
aforementioned PEPs should be considered deprecated.


Implementation
==

In Python 4.0, function and variable annotations will no longer be
evaluated at definition time.  Instead, a string form will be preserved
in the respective ``__annotations__`` dictionary.  Static type checkers
will see no difference in behavior, whereas tools using annotations at
runtime will have to perform postponed evaluation.

If an annotation was already a string, this string is preserved
verbatim.  In other cases, the string form is obtained from the AST
during the compilation step, which means that the string form preserved
might not preserve the exact formatting of the source.

Annotations need to be syntactically valid Python expressions, also when
passed as literal strings (i.e. ``compile(literal, '', 'eval')``).
Annotations can only use names present in the module scope as postponed
evaluation using local names is not reliable (with the sole exception of
class-level names resolved by ``typing.get_type_hints()``).

Note that as per PEP 526, local variable annotations are not evaluated
at all since they are not accessible outside of the function's closure.

Enabling the future behavior in Python 3.7
--

The functionality described above can be enabled starting from Python
3.7 using the following special import::

from __future__ import annotations


Resolving Type Hints at Runtime
===

To resolve an annotation at runtime from its string form to the result
of the enclosed expression, user code needs to evaluate the string.

For code that uses type hints, the
``typing.get_type_hints(obj, globalns=None, localns=None)`` function
correctly 

[Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

[Ned Deily]

Happy belated Halloween to those who celebrate it; I hope it wasn't too scary!  
Also possibly scary: we have just a little over 12 weeks remaining until Python 
3.7's feature code cutoff, 2018-01-29.  Those 12 weeks include a number of 
traditional holidays around the world so, if you are planning on writing 
another PEP for 3.7 or working on getting an existing one approved or getting 
feature code reviewed, please plan accordingly.If you have something in 
the pipeline, please either let me know or, when implemented, add the feature 
to PEP 537, the 3.7 Release Schedule PEP.  As you may recall, the release 
schedule calls for 4 alpha preview releases prior to the feature code cutoff 
with the first beta release.  We have already produced the first two alphas.  
Reviewing the schedule recently, I realized that I had "front-loaded" the 
alphas, leaving a bigger gap between the final alphas and the first beta.  So I 
have adjusted the schedule a bit, pushing alpha 3 and 4 out.  The new d
 ates are:

- 3.7.0 alpha 3: 2017-11-27 (was 2017-11-13)
- 3.7.0 alpha 4: 2018-01-08 (was 2017-12-18)
- 3.7.0 beta 1:  2018-01-29 (feature freeze - unchanged)

I hope the new dates give you a little bit more time to get your bits finished 
and get a little bit of exposure prior to the feature freeze.

Considering how quickly and positively it has been adopted, 3.6 is going to be 
a tough act to follow.  But we can do it again.  Thank you all for your ongoing 
efforts!

--Ned

--
  Ned Deily
  n...@python.org -- []

___
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] [edk2] Official port of Python on EDK2

[Brett Cannon]

The official guidelines on what it takes to add official support for a
platform is https://www.python.org/dev/peps/pep-0011/#supporting-platforms.
Basically it's a core dev willing to sponsor and maintain the work, a
buildbot, and implicitly at least a 5 year commitment.

On Wed, 1 Nov 2017 at 05:55 Antoine Pitrou  wrote:

> On Wed, 1 Nov 2017 13:46:27 +0100
> Christian Heimes  wrote:
> >
> > > This work would target the master branch (that is Python 3). I would
> > > be interested in hearing your thoughts on this idea.
> >
> > In general your proposal sounds like a good idea. A new platform may
> > require a PEP, though.
>
> It would also require a maintainer and a maintenance promise for
> several years (5 or 10? I don't know).  I doubt any other core
> developers are interested in/equipped for dealing with EDK2 issues,
> regressions and subtleties.
>
> > You can start now by submitting pull requests for the header fixes. Even
> > in the case we decide not to support EDK2, we make your life easier by
> > reducing the amount of extra patches.
>
> Agreed.
>
> Regards
>
> Antoine.
>
>
> ___
> 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/brett%40python.org
>
___
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] Review for bpo-30140: fix binop dispatch for subclasses

[Stephan Hoyer]

Hi python-dev,

It's been over a month without any activity and over a week since my ping,
and I'm still waiting for a review on my pull request:
https://bugs.python.org/issue30140
https://github.com/python/cpython/pull/1325

I would greatly appreciate if someone has time to take a look. This is my
first pull request to CPython.

Thanks,
Stephan
___
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] Official port of Python on EDK2

[Thiebaud Weksteen via Python-Dev]

Hi,

UEFI has become the standard for firmware (BIOS) interface. Intel has
provided an open source implementation under the name EDK2 (part of
the TianoCore initiative) [1] for some time. This implementation has
evolved significantly and now provides the functionalities of a small
OS with a standard library similar to POSIX.

In 2011, a port of Python 2.7.1 was added to the EDK2 repository [2].
This port then evolved to 2.7.2 which is still defined as the
reference port [3]. In 2015, another port was added of Python 2.7.10
in parallel of 2.7.2 [4]. Since then, both implementations have
diverged from upstream and know vulnerabilities have not been fixed.

I would like to bring support for edk2 in the official Python
repository to remediate this situation, that is officially support
edk2 as a platform. Technically, there would be three main aspects for
the on-boarding work:

1) Fix headers and source to resolve definition conflicts, similarly
to ABS definition in [5];
2) Add the edk2module.c [6] to handle platform-specific
functionalities, similarly to the posixmodule.c;
3) Add the build configuration file [7] and necessary modifications
within Python to handle the edk2 toolchain;

This work would target the master branch (that is Python 3). I would
be interested in hearing your thoughts on this idea.

Thanks,
Thiebaud

[1] https://github.com/tianocore/edk2
[2] 
https://github.com/tianocore/edk2/commit/006fecd5a177b4b7b6b36fab6690bf2b2fa11829
[3] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonReadMe.txt
[4] 
https://github.com/tianocore/edk2/commit/c8042e10763bca064df257547d04ae3dfcdfaf91
[5] https://gist.github.com/tweksteen/ed516ca7ab7dfa8d18428f59d9c22a3e
[6] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/Efi/edk2module.c
[7] 
https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonCore.inf
___
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] [edk2] Official port of Python on EDK2

[Antoine Pitrou]

On Wed, 1 Nov 2017 13:46:27 +0100
Christian Heimes  wrote:
> 
> > This work would target the master branch (that is Python 3). I would
> > be interested in hearing your thoughts on this idea.  
> 
> In general your proposal sounds like a good idea. A new platform may
> require a PEP, though.

It would also require a maintainer and a maintenance promise for
several years (5 or 10? I don't know).  I doubt any other core
developers are interested in/equipped for dealing with EDK2 issues,
regressions and subtleties.

> You can start now by submitting pull requests for the header fixes. Even
> in the case we decide not to support EDK2, we make your life easier by
> reducing the amount of extra patches.

Agreed.

Regards

Antoine.


___
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] [edk2] Official port of Python on EDK2

[Christian Heimes]

On 2017-11-01 10:07, Thiebaud Weksteen wrote:
> Hi,
> 
> UEFI has become the standard for firmware (BIOS) interface. Intel has
> provided an open source implementation under the name EDK2 (part of
> the TianoCore initiative) [1] for some time. This implementation has
> evolved significantly and now provides the functionalities of a small
> OS with a standard library similar to POSIX.
> 
> In 2011, a port of Python 2.7.1 was added to the EDK2 repository [2].
> This port then evolved to 2.7.2 which is still defined as the
> reference port [3]. In 2015, another port was added of Python 2.7.10
> in parallel of 2.7.2 [4]. Since then, both implementations have
> diverged from upstream and know vulnerabilities have not been fixed.
>
> I would like to bring support for edk2 in the official Python
> repository to remediate this situation, that is officially support
> edk2 as a platform. Technically, there would be three main aspects for
> the on-boarding work:
> 
> 1) Fix headers and source to resolve definition conflicts, similarly
> to ABS definition in [5];

https://gist.github.com/tweksteen/ed516ca7ab7dfa8d18428f59d9c22a3e is a
low-hanging fruit, e.g. ABS() should be replaced with Py_ABS() from
pymacro.h.

Why did you have to replace non-ASCII chars in comments? Does your build
chain not support comments with UTF-8 chars?

> 2) Add the edk2module.c [6] to handle platform-specific
> functionalities, similarly to the posixmodule.c;

edk2module.c duplicates a lot of functionality that is also exposed by
posixmodule.c. We try to reduce duplicated code and functionality as
much as possible. IMO the edk2 module should be folded into posixmodule.c.

> 3) Add the build configuration file [7] and necessary modifications
> within Python to handle the edk2 toolchain;

Once you are able to build master for EDK2, we need to figure out how to
integrate the new build flavor into our CI and buildbot system. Is the
EDK2 build chain available for free on Linux?

> This work would target the master branch (that is Python 3). I would
> be interested in hearing your thoughts on this idea.

In general your proposal sounds like a good idea. A new platform may
require a PEP, though.

You can start now by submitting pull requests for the header fixes. Even
in the case we decide not to support EDK2, we make your life easier by
reducing the amount of extra patches.

Christian
___
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