Re: [Python-Dev] Migrate python-dev to Mailman 3?
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?
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?
+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?
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?
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?
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
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
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?
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
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?
> 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
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
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
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 evaluates expressions back from its string fo
[Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff
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
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
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
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
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
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
