[Python-Dev] MicroPython 1.3.7 released
Hello, MicroPython is a Python3 language implementation which scales down to run on microcontrollers with tens of Ks of RAM and few hundreds of Ks of code size. Besides microcontrollers, it's also useful for small embedded Linux systems, where storage space is limited, for embedding as a scripting engine into standalone applications, where quick startup time is needed, etc. http://micropython.org/ https://github.com/micropython/micropython It went several months since the original announcement of MicroPython 1.0 (https://mail.python.org/pipermail/python-list/2014-June/672994.html), there were number of releases in the meantime, but we were too busy implementing new features, so this announcement provides just high-level overview of changes: * Basic Unicode support added (thanks to Chris Angelico for driving the effort) * More functionality of standard types and functions are implemented (for example, MicroPython can run subset of http.client module functionality from CPython3 stdlib). * Highly optimized for code size implementations of important Python modules are added. There offer subset of functionality and prefixed with "u". For example, ure, uheapq, uzlib, uhashlib, ubinascii are provided. * Lots of microcontroller hardware bindings added and generalized. Besides core interpreter, there's also good progress on modules and applications: * MicroPython standard library project, https://github.com/micropython/micropython-lib , an effort to port/develop as much as possible Python stdlib modules to MicroPython, has good progress, with few dozens of modules available on PyPI already (pip-micropython wrapper is provided to install them). * An asyncio subset implementation, dubbed "uasyncio", is available and should be stable enough. * Proof of concept web microframework, "picoweb", based on uasyncio is being developed: https://github.com/pfalcon/picoweb * Lots of other projects available on github. Reference implementation of MicroPython runs on a microcontroller board with 1Mb Flash and 128Kb RAM, which should offer good platform for people interested in microcontroller usage (more info: http://micropython.org/). MicroPython can also be easily built and supported on Linux, MacOSX, and Windows systems (more info: https://github.com/micropython/micropython) -- Best regards, Paul mailto:[email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
Brett Cannon wrote: > 4. Contributor creates account on bugs.python.org and signs the > [contributor agreement](https://www.python.org/psf/contrib/contrib-form/) Is there an expiration on such forms? If there doesn't need to be (and one form is good for multiple tickets), is there an objection (besides "not done yet") to making "signed the form" part of the bug reporter account, and required to submit to the CI process? (An "I can't sign yet, bug me later" option would allow the current workflow without the "this isn't technically a patch" workaround for "small enough" patches from those with slow-moving employers.) > There's the simple spelling mistake patches and then there's the > code change patches. There are a fair number of one-liner code patches; ideally, they could also be handled quickly. > For the code change patches, contributors need an easy way to get a hold of > the code and get their changes to the core developers. For a fair number of patches, the same workflow as spelling errors is appropriate, except that it would be useful to have an automated state saying "yes, this currently merges fine", so that committers can focus only on patches that are (still) at least that ready. > At best core developers tell a contributor "please send your PR > against 3.4", push-button merge it, update a local clone, merge from > 3.4 to default, do the usual stuff, commit, and then push; Is it common for a patch that should apply to multiple branches to fail on some but not all of them? In other words, is there any reason beyond "not done yet" that submitting a patch (or pull request) shouldn't automatically create a patch per branch, with pushbuttons to test/reject/commit? > Our code review tool is a fork that probably should be > replaced as only Martin von Loewis can maintain it. Only he knows the innards, or only he is authorized, or only he knows where the code currently is/how to deploy an update? I know that there were times in the (not-so-recent) past when I had time and willingness to help with some part of the infrastructure, but didn't know where the code was, and didn't feel right making a blind offer. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
On Mon Dec 08 2014 at 3:27:43 PM Jim J. Jewett wrote: > > > Brett Cannon wrote: > > 4. Contributor creates account on bugs.python.org and signs the > > [contributor agreement](https://www.python. > org/psf/contrib/contrib-form/) > > Is there an expiration on such forms? If there doesn't need to be > (and one form is good for multiple tickets), is there an objection > (besides "not done yet") to making "signed the form" part of the bug > reporter account, and required to submit to the CI process? (An "I > can't sign yet, bug me later" option would allow the current workflow > without the "this isn't technically a patch" workaround for "small enough" > patches from those with slow-moving employers.) > IANAL but I believe that as long as you didn't sign on behalf of work for your employer it's good for life. > > > > There's the simple spelling mistake patches and then there's the > > code change patches. > > There are a fair number of one-liner code patches; ideally, they > could also be handled quickly. > Depends on the change. Syntactic typos could still get through. But yes, they are also a possibility for a quick submission. > > > For the code change patches, contributors need an easy way to get a hold > of > > the code and get their changes to the core developers. > > For a fair number of patches, the same workflow as spelling errors is > appropriate, except that it would be useful to have an automated state > saying "yes, this currently merges fine", so that committers can focus > only on patches that are (still) at least that ready. > > > At best core developers tell a contributor "please send your PR > > against 3.4", push-button merge it, update a local clone, merge from > > 3.4 to default, do the usual stuff, commit, and then push; > > Is it common for a patch that should apply to multiple branches to fail > on some but not all of them? > Going from 3.4 -> 3.5 is almost always clean sans NEWS, but from 2.7 it is no where near as guaranteed. > > In other words, is there any reason beyond "not done yet" that submitting > a patch (or pull request) shouldn't automatically create a patch per > branch, with pushbuttons to test/reject/commit? > Assuming that you specify which branches, then not really. But if it is blindly then yes as that's unnecessary noise and could lead to arguments over whether something should (not) be applied to some specific version. > > > Our code review tool is a fork that probably should be > > replaced as only Martin von Loewis can maintain it. > > Only he knows the innards, or only he is authorized, or only he knows > where the code currently is/how to deploy an update? > Innards. -Brett > > I know that there were times in the (not-so-recent) past when I had > time and willingness to help with some part of the infrastructure, but > didn't know where the code was, and didn't feel right making a blind > offer. > > > -jJ > > -- > > If there are still threading problems with my replies, please > email me with details, so that I can try to resolve them. -jJ > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > brett%40python.org > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My thinking about the development process
On Mon, 08 Dec 2014 12:27:23 -0800, "Jim J. Jewett" wrote: > Brett Cannon wrote: > > 4. Contributor creates account on bugs.python.org and signs the > > [contributor agreement](https://www.python.org/psf/contrib/contrib-form/) > > Is there an expiration on such forms? If there doesn't need to be > (and one form is good for multiple tickets), is there an objection > (besides "not done yet") to making "signed the form" part of the bug > reporter account, and required to submit to the CI process? (An "I > can't sign yet, bug me later" option would allow the current workflow > without the "this isn't technically a patch" workaround for "small enough" > patches from those with slow-moving employers.) No expiration. Whether or not we have a CLA from a given tracker id is recorded in the tracker. People also get reminded to submit a CLA if they haven't yet but have submitted a patch. > > At best core developers tell a contributor "please send your PR > > against 3.4", push-button merge it, update a local clone, merge from > > 3.4 to default, do the usual stuff, commit, and then push; > > Is it common for a patch that should apply to multiple branches to fail > on some but not all of them? Currently? Yes when 2.7 is involved. If we fix NEWS, then it won't be *common* for maint->default, but it will happen. > In other words, is there any reason beyond "not done yet" that submitting > a patch (or pull request) shouldn't automatically create a patch per > branch, with pushbuttons to test/reject/commit? Not Done Yet (by any of the tools we know about) is the only reason I'm aware of. > > Our code review tool is a fork that probably should be > > replaced as only Martin von Loewis can maintain it. > > Only he knows the innards, or only he is authorized, or only he knows > where the code currently is/how to deploy an update? Only he knows the innards. (Although Ezio has made at least one patch to it.) I think Guido's point was that we (the community) shouldn't be maintaining this private fork of a project that has moved on well beyond us; instead we should be using an active project and leveraging its community with our own contributions (like we do with Roundup). > I know that there were times in the (not-so-recent) past when I had > time and willingness to help with some part of the infrastructure, but > didn't know where the code was, and didn't feel right making a blind > offer. Yeah, that's something that's been getting better lately (thanks, infrastructure team), but where to get the info is still not as clear as would be optimal. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Making it possible to accept contributions without CLA (was: My thinking about the development process)
Eric Snow writes: > There's no real way around this, is there? […] the CLA part is pretty > unavoidable. The PSF presently madates that any contributor to Python sign http://legacy.python.org/psf/contrib/contrib-form/contributor-agreement.pdf> the “Contributor Agreement”. This is a unilateral grant from the contributor to the PSF, and is unequal because the PSF does not grant these same powers to the recipients of Python. I raise this, not to start another disagreement about whether this is desirable; I understand that many within the PSF regard it as an unfortunate barrier to entry, even if it is necessary. Rather, I'm asking what, specifically, necessitates this situation. What would need to change, for the PSF to accept contributions to the Python copyrighted works, without requiring the contributor to do anything but license the work under Apache 2.0 license? Is it specific code within the Python code base which somehow creates this need? How much, and how would the PSF view work to re-implement that code for contribution under Apache 2.0 license? Is it some other dependency? What, specifically; and what can be done to remove that dependency? My goal is to see the PSF reach a state where the licensing situation is an equal-footing “inbound = outbound” like most free software projects; where the PSF can happily receive from a contributor only the exact same license the PSF grants to any recipient of Python. For that to happen, we need to know the specific barriers to such a goal. What are they? -- \ “A computer once beat me at chess, but it was no match for me | `\ at kick boxing.” —Emo Philips | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making it possible to accept contributions without CLA
On 12/08/2014 02:31 PM, Ben Finney wrote: > Eric Snow writes: > >> There's no real way around this, is there? […] the CLA part is pretty >> unavoidable. > > The PSF presently madates that any contributor to Python sign > http://legacy.python.org/psf/contrib/contrib-form/contributor-agreement.pdf> > the “Contributor Agreement”. This is a unilateral grant from the > contributor to the PSF, and is unequal because the PSF does not grant > these same powers to the recipients of Python. > > I raise this, not to start another disagreement about whether this is > desirable; I understand that many within the PSF regard it as > an unfortunate barrier to entry, even if it is necessary. > > Rather, I'm asking what, specifically, necessitates this situation. > > What would need to change, for the PSF to accept contributions to the > Python copyrighted works, without requiring the contributor to do > anything but license the work under Apache 2.0 license? > > Is it specific code within the Python code base which somehow creates > this need? How much, and how would the PSF view work to re-implement > that code for contribution under Apache 2.0 license? > > Is it some other dependency? What, specifically; and what can be done to > remove that dependency? > > My goal is to see the PSF reach a state where the licensing situation is > an equal-footing “inbound = outbound” like most free software projects; > where the PSF can happily receive from a contributor only the exact same > license the PSF grants to any recipient of Python. > > For that to happen, we need to know the specific barriers to such a > goal. What are they? Well, this is the wrong mailing list for those questions. Maybe one of these would work instead? About Python-legal-sig (https://mail.python.org/mailman/listinfo/python-legal-sig) English (USA) This list is for the discussion of Python Legal/Compliance issues. Its focus should be on questions regarding compliance, copyrights on core python, etc. Actual Legal decisions, or legal counsel questions, alterations to the Contributor License Agreement for Python the language should be sent to [email protected] Python/PSF trademark questions should be sent to [email protected]. Please Note: Legal decisions affecting the IP, Python license stack, etc *must* be approved by Python Software Foundation legal counsel and the board of directors: [email protected] To see the collection of prior postings to the list, visit the Python-legal-sig Archives. signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making it possible to accept contributions without CLA (was: My thinking about the development process)
On Dec 09, 2014, at 09:31 AM, Ben Finney wrote: >Rather, I'm asking what, specifically, necessitates this situation. > >What would need to change, for the PSF to accept contributions to the >Python copyrighted works, without requiring the contributor to do >anything but license the work under Apache 2.0 license? My understanding is that the PSF needs the ability to relicense the contribution under the standard PSF license, and it is the contributor agreement that gives the PSF the legal right to do this. Many organizations, both for- and non-profit have this legal requirement, and there are many avenues for satisfying these needs, mostly based on different legal and business interpretations. In the scheme of such things, and IMHO, the PSF CLA is quite reasonable and lightweight, both in what it requires a contributor to provide, and in the value, rights, and guarantees it extends to the contributor. Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making it possible to accept contributions without CLA
Ethan Furman writes: > Well, this is the wrong mailing list for those questions. Thanks. I addressed the claim here where it was made; but you're right that a different forum is better for an ongoing discussion about this topic. Barry Warsaw writes: > My understanding is that the PSF needs the ability to relicense the > contribution under the standard PSF license, and it is the contributor > agreement that gives the PSF the legal right to do this. Okay, that's been raised before. If anyone can cite other specific dependencies that would necessitate a CLA for Python, please contact me off-list, and/or in the Python legal-sig https://mail.python.org/mailman/listinfo/python-legal-sig>. > Many organizations, both for- and non-profit have this legal > requirement, and there are many avenues for satisfying these needs, > mostly based on different legal and business interpretations. And many do not. It would be good to shift the PSF into the larger set of organisations that do not require a CLA for accepting contributions. Thanks, all. Sorry to bring the topic up again here. -- \ “When I was born I was so surprised I couldn't talk for a year | `\and a half.” —Gracie Allen | _o__) | Ben Finney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
