[ANN] MicroPython 1.6
Hello, MicroPython is a lean and efficient Python implementation for microcontrollers, embedded, and mobile systems (which also runs just as fine on desktops, servers, and clouds). https://github.com/micropython/micropython https://github.com/micropython/micropython/releases/tag/v1.6 There're following major changes since 1.5: 1. LwIP module support for embedded TCP/IP networking. 2. IPv6 support in the Unix port. 3. Beta support for persistent bytecode (similar to CPython's .pyc) 4. 64-bit NaN boxing (improved floating-point performance if enabled). 5. Support for new official PyBoards PYBv1.1 and PYBLITEv1.0. 6. Long int constant folding during bytecode compilation (glad that CPython will catch up in that area thanks to FAT Python project). 7. There's a ongoing crowdfunding campaign to fund complete and well-maintained MicroPython port to ubiquitous ESP8266 WiFi SoC, and improve networking and IoT support in MicroPython in general: https://www.kickstarter.com/projects/214379695/micropython-on-the-esp8266-beautifully-easy-iot -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] MicroPython 1.5
Hello, On Sun, 8 Nov 2015 12:08:20 -0700 paul.hermeneu...@gmail.com wrote: > What is the possibility that MicroPython could be another build from > the base python.org sources? Python already gets built for a variety > of architectures. Could a MicroPython be another one? In that way, it > would always be up to date on language changes. There's zero possibility for this - MicroPython is from-scratch implementation carefully optimized for code size and memory usage, that's how it's up to 50 times smaller than CPython and can run with ~1000 times less RAM than CPython usually runs with. Support for the latest features is not the aim of MicroPython, instead it's being able to use the same great language on systems where CPython simply could never run. That necessitates being on a diet and leaving out not just the latest lesser-known features, but even quite a few of old more widely known ones. That said, the core of the language is there and any Python programmer should feel straight at home. And it's Python*3*, so it's pretty fresh anyway, knowing that half of our community still sits on Python2 and never tried Python3. (Hacking on MicroPython is how I get to use Python3 myself, on my dayjob we still use Python2). [] -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: [ANN] MicroPython 1.5
Hello, On Sun, 08 Nov 2015 10:28:24 -0800 Paul Rubin wrote: > Paul Sokolovsky writes: > > Recent 1.5 release is an important milestone for the project, major > > changes including: > > Thanks for posting this. We don't hear enough about MicroPython on > this newsgroup so it's good to get these announcements. > > Is the language still Python 3.4? Will it implement 3.5 sometime > soon? Yes, we already implement the most important 3.5 feature - ability to format bytes: b"foo%s" % b"bar" ;-). > > 1. Advanced REPL support with smart auto-indent and auto-completion > > Hmm does this make the code footprint significantly bigger? No, as everything else in MicroPython, code implementing this feature is well-optimized, it did cost few hundreds of bytes to implement. > > 2. Support for client SSL connections. > > Nice. Does it check the server certificate? The driving force for adding SSL was being able to download package from PyPI (for builtin upip package manager). Unfortunately, PyPI forces SSL, so previously we had to fallback to wget for downloads, which limited upip to unix-like systems. So, the way we use SSL is as bloated plain HTTP, just to workaround PyPI's maintainers' decision to raise the bar too high to access it. Consequently, nobody yet worked on certificate checking and other stuff. > Is it based on TLSLite by any chance? I had an idea to port TLSLite and even submitted couple of patches to it, I had an idea to write a module titled "insecureSSL" which would just emulate SSL by doing as little as possible processing and using static session keys, etc. - just to prove the point that there can't be security without both parties consenting, and mis-applied "security" is nothing but a denial-of-service. But I gave up in the end, deciding to take that productively and add generic SSL client support using axTLS library (which was also optimized to meet MicroPython code size standards). (You see, these questions touched ranty feelings - thanks for asking ;-) ). > > 5. There're now 2 well-supported microcontroller boards for > > MicroPython, and dozen(s) community-supported ones. > > The PyBoard is very nice, but what is the other one? I don't see > anything about it on the MicroPython web site. (Hmm, maybe you mean > the Micro Bit). It's WiPy, http://wipy.io/ , WiFi-enabled board which had successful kickstarter in the spring and last month shipped ready boards. Micro Bit would take some time before general availability of course. > Btw, I notice that the "store" page doesn't show any products under my > normal adblock settings. It's probably best to make it a normal page > instead of an AJAX one. > > > MicroPython supports growing subset of Python3 standard library > > (including simplified asyncio package) > > This would look much nicer with the new Python 3.5 syntax. There was initial patch to add initial async/await support a week within corresponding PEP was initially posted. But we decided not to haste with it, or we can add feature which nobody really uses (while we have bunch of features which almost everyone would use, but which aren't yet there). So, we decided yo do our homework, and let asyncio/async-await people do theirs on popularizing it (every 10th Python programmer using it seems like good target, now it's probably every 10,000th if not 100,000th). Thanks for the feedback! -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
[ANN] MicroPython 1.5
Hello,
MicroPython is a lean and efficient Python implementation for
microcontrollers, embedded, and mobile systems (which also runs just as
fine on desktops of course).
https://github.com/micropython/micropython
Recent 1.5 release is an important milestone for the project, major
changes including:
1. Advanced REPL support with smart auto-indent and auto-completion for
comfortable interactive typing pf Python code, easily switchable to
paste mode to copy pre-made code snippets.
2. Support for client SSL connections.
3. upip, MicroPython builtin package manager, is now fully standalone
thanks to SSL support.
4. There's new, elaborated API to access hardware features ("machine"
module).
5. There're now 2 well-supported microcontroller boards for
MicroPython, and dozen(s) community-supported ones.
6. MicroPython was selected as one of the languages supported for BBC
micro:bit initiative:
http://ntoll.org/article/story-micropython-on-microbit
7. There's work on native efficient JNI bridge, inspired by Kivy's
PyJNIus module, included into growing Android port.
More detailed changelog for this version is at
https://github.com/micropython/micropython/releases/tag/v1.5
MicroPython supports growing subset of Python3 standard library
(including simplified asyncio package) - not included by default with
an executable, but easily installable per-module using builtin "upip"
package manager:
https://github.com/micropython/micropython-lib
--
Best regards,
Paul mailto:pmis...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
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:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Hello, On Fri, 4 Jul 2014 03:38:27 +1000 Chris Angelico wrote: > On Fri, Jul 4, 2014 at 3:31 AM, Tobiah wrote: > > Coworker takes PEP8 as gospel and uses 4 spaces > > to indent. I prefer tabs. Boss want's us to > > unify. > > 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast > rules. > 2) Tabs let different people display the indents at different > widths. That's exactly the problem with tabs - whatever you think your code looks like with tabs, other people will see quite different picture. Also, most people are not interested in doing mumbo-jumbo with tabs settings, and have them set to standard 8-char tabs. So, any python code which uses only tabs for indentation automatically violates 4-space convention (and mixing tabs and spaces is nowadays prohibited in Python). Summing up: if you care about other human beings, use spaces. If you don't care about other human beings, you may use tabs, but other human beings surely will take how you treat them into account ;-). -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: install software via Python script
Hello, On Wed, 2 Jul 2014 18:01:45 -0400 "Moshe Avraham" wrote: > HI Guys, > > I need to install variety of software (Oracle, SqlServer, upgrade JAVA > version, WAS, WMB, Tomcat, etc.) on both WINDOWS and UNIX/LINUX. > > These are usual daily operation of large IT departments. > > So instead of developing both shell & DOS scripts, I like to develop a > single Python script (for each of these software) to run on all > operation systems. > > Can someone suggest an easy simple way of developing a script for > Oracle (as an example). You should look into Ansible http://www.ansible.com , https://github.com/ansible/ansible > > Thanks, > > Moshe > -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the "right" way to abandon an open source package?
Hello, On 01 Jul 2014 18:40:23 GMT Steven D'Aprano wrote: > On Tue, 01 Jul 2014 20:59:48 +0300, Paul Sokolovsky wrote: > > > Put it on github > > > http://nedbatchelder.com/blog/201405/github_monoculture.html Everyone who (re)posts stuff like that should have mandatory N.B. of "I just bought a server farm to offer an alternative". And come on, the guy asked the *easiest* way to lose an open-source package (apparently, in not an anti-social way). > > Besides, do you really want to give your support to a crowd who built > a replica of the Oval Office in their corporate offices? While git is > a decent DVCS, almost as good as hg, there's something about git > culture which attracts geek wankery. You mix up git and some other things. First is "github, inc.". I'm sure all that publicity is their secret plan to overthrow google and facebook. Bwahaha. Second thing is (young pythonistas, close your eyes and ears!) is Roby. That's where that slight smell of decay which bothers you comes from. Indeed, using software written in Ruby is disgusting. But if you look around, all software written for advanced git project hosting is written in Ruby - gitorious, gitlab. Steven, I hope you have plan how to resolve that situation with Python enlightment too. Until then people will use that ruby stuff, in particular github. (Ah, and if your solution is "hg", sorry, that won't work - for many reasons, including CPython big startup delay :-F. Don't speak about git monoculture though - *BSD folks are still using CVS, so world is safe). > > > -- > Steven > -- > https://mail.python.org/mailman/listinfo/python-list -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the "right" way to abandon an open source package?
Hello, On Tue, 1 Jul 2014 12:30:44 -0500 Skip Montanaro wrote: > This is only Python-related because the package in question (lockfile > at PyPI) is written in Python and hosted (at least in part) on PyPI. I > have not had any interest in maintaining this package for a few years. > I wrote it mostly as an exercise, and while I do happen to use it > ever-so-slightly in my work, its state as of a few years ago is > perfect for my modest needs. Working on it no longer scratches any > itches for me. I'd much rather be out riding my bike. I'm at the point > in my professional career that I no longer want to program at home > after spending all day programming at work. I've tried to find people > to take it over, but so far unsuccessfully. I continue to get bug > reports, some from OS package maintainers or maintainers of > applications which use lockfile. Lots of these people seem demanding > of my time (which makes me even less interested in lockfile > maintenance). Is there a "correct" way to abandon the damn thing? Put it on github and reply to any request with "patches welcome!". That's assuming it's ok for you once a month to go thru pull request queue and press "Merge" or "Close" buttons. If that's too hard, then well, don't press those buttons - someone else will pick those pulls into one's own fork and will maintain it. > > Thx, > > Skip > -- > https://mail.python.org/mailman/listinfo/python-list -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: What can Nuitka do?
Hello, On Fri, 27 Jun 2014 16:25:02 -0700 (PDT) CM wrote: > (Trying again, simpler and cleaner post) > > Can I use Nuitka to transform a wxPython > GUI application in Python that uses several > 3rd party modules into a small and faster > compiled-to-C executable? Yes, you can. So, please try that, and report how that went. We're eager to know how that would go very much. But unlike you, we don't have need to transform wxPython GUI application in Python into an executable. So, you are in the best position to answer your question. And surprisingly, both Nuitka and PyPy are free, so you won't need to shell out few $Ks to try it, or wear your suit, hop on the plane, and go to another side of the country (or world) and spend many hours in negotiations to get an evaluation license. Just download and try. Unbelievable, how world has changed in some 30-40 years! -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Asymmetry in globals __getitem__/__setitem__
Hello,
On Fri, 13 Jun 2014 12:53:54 +0200
Peter Otten <__pete...@web.de> wrote:
[]
> > exec(fun.__code__, {}, Namespace())
> >
> >
> > Neither __getitem__ nor __setitem__ seem to be called on the local
> > variables.
>
> Accessing fun.__code__ is clever, but unfortunately the compiler
> produces different bytecodes for loading/storing variables inside a
> function. Compare:
Compiler produces different bytecodes, and allocates local variables on
stack (just like C) very fortunately, steps like that allowed Python to
drop moniker of "ridiculously slow language". And people should decide
what they really want - fast language which can stand against the
competition, or language with dynamicity and reflection capabilities
beyond any practical need. I make first choice any time. And then it
makes sense to just accept that any function can be JIT (or AOT)
compiled, and there's nothing to fish inside of it (but for the raw
machine code of unknown architecture).
--
Best regards,
Paul mailto:pmis...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: None in string => TypeError?
Hello, On Mon, 9 Jun 2014 08:34:42 -0700 (PDT) Roy Smith wrote: > We noticed recently that: > > >>> None in 'foo' > > raises (at least in Python 2.7) > > TypeError: 'in ' requires string as left operand, not NoneType > > This is surprising. The description of the 'in' operatator is, 'True > if an item of s is equal to x, else False '. From that, I > would assume it behaves as if it were written: > > for item in iterable: > if item == x: > return True > else: > return False > > why the extra type check for str.__contains__()? That seems very > unpythonic. Duck typing, and all that. -- This is very Pythonic, Python is strictly typed language. There's no way None could possibly be "inside" a string, so if you're trying to look for it there, you're doing something wrong, and told so. Also, it's not "extra check", it's "extra checks less", just consider that "in" operator just checks types of its arguments for sanity once at the start, and then just looks for a substring within string. You suggest that it should check for each element type in a loop, which is great waste, as once again, nothing but a string can be inside another string. -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Hello, On Sun, 08 Jun 2014 18:56:47 +0300 Marko Rauhamaa wrote: > Paul Sokolovsky : > > > Python already has that - like, len(x) calls x.__len__() if it's > > defined > > In fact, what's the point of having the duality? > >len(x) <==> x.__len__() > >x < y <==> x.__lt__(y) > >str(x) <==> x.__str__() > > etc. > > I suppose the principal reason is that people don't like UFCS. Plus > some legacy from Python1 days. I personally don't see it as "duality". There're few generic operators - the fact that they are really generic (apply to wide different classes of objects) is exactly the reason why the're defined in global namespace, and not methods. And yep, I see things like "len" as essentially an operator, even though its name consists of letters, and it has function call syntax. Then, there's just a way to overload these operators for user types, that's it. You *can* use x.__len__() but that's not how Python intends it. And like with any idea, one should not forget implementation side and efficiency - these operators are really core and expected to be used in performance-tight contexts, so they are implemented specially (optimized). Extending that handling to any function would cost either high memory usage, or high runtime cost. > Lisp & co. rigorously follow its UFCS. I think it works great, but > that is what people most ridicule Lisp for. Exactly my thinking - there're bunch of languages which follow that UFCS-like idea, likely most homoiconic (or -like) do. Or you can use plain old C ;-). So, I don't see why people want to stuff this into Python - there're lot of ready alternatives. And Python provides very intuitive and obvious separation between generic functions and object methods IMHO, so there's nothing to "fix". > > What do you think? Would you rather write/read: > >if size + len(data) >= limit: "How else could it be?" > > or UFCS-ly: > >if size.__add__(data.__len__()).__le__(limit): "OMG!" > Marko > -- > https://mail.python.org/mailman/listinfo/python-list -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Hello, On Sun, 8 Jun 2014 01:26:04 -0700 (PDT) jongiddy wrote: > On Sunday, 8 June 2014 02:27:42 UTC+1, Gregory Ewing wrote: > > > > Also it doesn't sit well with Python's "one obvious > > way to do it" guideline, because it means there are > > *two* equally obvious ways to call a function. > > This provides a way to do something new (add class-optimized > implementations for existing general-purpose functions). Python already has that - like, len(x) calls x.__len__() if it's defined (for objects where it makes sense for it to be defined). Many builtin functions have such behavior. For your custom functions, you can add similar conventions and functionality very easily (if you'll want to apply it to "not your" types, you'll need to subclass them, as expected). Getting x.foo() to call foo(x) is what's bigger problem, which has serious performance and scoping confusion implications, as discussed in other mails. > It also adds > significant readability improvements by putting function-call chains > in order. Not sure what exactly you mean, but the order is usually pretty obvious - Python follows mathematical notation for function calls, and OO standard notation for method calls, one known from primary school, another from secondary (hopefully). They can be reordered with parentheses, which is also well-known basic math technique. -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Uniform Function Call Syntax (UFCS)
Hello, On Sun, 8 Jun 2014 01:15:43 -0700 (PDT) jongiddy wrote: > Thanks for the extensive feedback. Here's my thoughts on how to > address these issues. > > On Saturday, 7 June 2014 20:20:48 UTC+1, Ian wrote: > > > > It's a nice feature in a statically typed language, but I'm not sure > > how well it would work in a language as dynamic as Python. There > > are some questions that would need to be addressed. > > > > 1) Where should the function (or perhaps callable) be looked for? > > The most obvious place is the global scope. I think it would be a > > bit too far-reaching and inconsistent with other language features > > to reach directly inside imported modules (not to mention that it > > could easily get to be far too slow in a module with lots of > > imports). As a result it would have to be imported using the "from > > module import function" syntax, rather than the somewhat cleaner > > "import module" syntax. > > > > While there's nothing wrong with such imports, I'm not sure I like > > the thought of the language encouraging them any more than > > necessary. > > It would only work on functions in scope. x.len() would only work if > len(x) would work. In other words, you propose you add yet another check for each function call. But what many people has to say about Python is that it's "slow". There should be lookout for how to make it faster, not yet slower. [] > > The bigger problem I find is reading other code that uses UFCS and > not realising that a "method" is not actually a method of the class, > but requires importing a module. That can cause confusion when > trying to use it in your own code. Indeed, this UFCS idea adds inefficiency and confusion, but doesn't appear to solve any reasonable problem or add any firm benefit. -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Micro Python -- a lean and efficient implementation of Python 3
Hello,
On Wed, 4 Jun 2014 03:08:57 +1000
Chris Angelico wrote:
[]
> With that encouragement, I just cloned your repo and built it on amd64
> Debian Wheezy. Works just fine! Except... I've just found one fairly
> major problem with your support of Python 3.x syntax. Your str type is
> documented as not supporting Unicode. Is that a current flaw that
> you're planning to remove, or a design limitation? Either way, I'm a
> bit dubious about a purported version 1 that doesn't do one of the
> things that Py3 is especially good at - matched by very few languages
> in its encouragement of best practice with Unicode support.
I should start with saying that it's MicroPython what made me look at
Python3. So for me, it already did lot of boon by getting me from under
the rock, so now instead of "at my job, we use python 2.x" I may report
"at my job, we don't wait when our distro will kick us in the ass, and
add 'from __future__ import print_function' whenever we touch some
code".
With that in mind, I, as many others, think that forcing Unicode bloat
upon people by default is the most controversial feature of Python3.
The reason is that you go very long way dealing with languages of the
people of the world by just treating strings as consisting of 8-bit
data. I'd say, that's enough for 90% of applications. Unicode is needed
only if one needs to deal with multiple languages *at the same time*,
which is fairly rare (remaining 10% of apps).
And please keep in mind that MicroPython was originally intended (and
should be remain scalable down to) an MCU. Unicode needed there is even
less, and even less resources to support Unicode just because.
>
> What is your str type actually able to support? It seems to store
> non-ASCII bytes in it, which I presume are supposed to represent the
> rest of Latin-1, but I wasn't able to print them out:
There's a work-in-progress on documenting differences between CPython
and MicroPython at
https://github.com/micropython/micropython/wiki/Differences, it gives
following account on this:
"No unicode support is actually implemented. Python3 calls for strict
difference between str and bytes data types (unlike Python2, which has
neutral unified data type for strings and binary data, and separates
out unicode data type). MicroPython faithfully implements str/bytes
separation, but currently, underlying str implementation is the same as
bytes. This means strings in MicroPython are not unicode, but 8-bit
characters (fully binary-clean)."
>
> Micro Python v1.0.1-144-gb294a7e on 2014-06-04; UNIX version
> >>> print("asdf\xfdqwer")
>
> Python 3.5.0a0 (default:6a0def54c63d, Mar 26 2014, 01:11:09)
> [GCC 4.7.2] on linux
> >>> print("asdf\xfdqwer")
> asdfýqwer
>
> In fact, printing seems to work with bytes:
>
> >>> print("asdf\xc3\xbdqwer")
> asdfýqwer
>
> (my terminal uses UTF-8, this is the UTF-8 encoding of the above
> string)
>
> I would strongly recommend either implementing all of PEP 393, or at
> least making it very clear that this pretends everything is bytes -
> and possibly disallowing any codepoint >127 in any string, which will
> at least mean you're safe on all ASCII-compatible encodings.
MicroPython is not the first "tiny" Python implementation. What differs
MicroPython is that it's neither aim or motto to be a subset of
language. And yet, it's not CPython rewrite either. So, while Unicode
support is surely possible, it's unlikely to be done as "all of
PEPxxx". If you ask me, I'd personally envision it to be implemented as
UTF-8 (in this regard I agree with (or take an influence from)
http://lucumr.pocoo.org/2014/1/9/ucs-vs-utf8/). But I don't have plans
to work on Unicode any time soon - applications I envision for
MicroPython so far fit in those 90% that live happily without Unicode.
But generally, there's no strict roadmap for MicroPython features.
While core of the language (parser, compiler, VM) is developed by
Damien, many other features were already contributed by the community
(project went open-source at the beginning of the year). So, if someone
will want to see Unicode support up to the level of providing patches,
it gladly will be accepted. The only thing we established is that we
want to be able to scale down, and thus almost all features should be
configurable.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
--
Best regards,
Paul mailto:pmis...@gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: Micro Python -- a lean and efficient implementation of Python 3
Hello, On Tue, 3 Jun 2014 23:11:46 +1000 Chris Angelico wrote: > On Tue, Jun 3, 2014 at 10:27 PM, Damien George > wrote: > > - Supports almost full Python 3 syntax, including yield (compiles > > 99.99% of the Python 3 standard library). > > - It supports a growing subset of Python 3 types and operations. > > - Part of the Python 3 standard library has already been ported to > > Micro Python, and work is ongoing to port as much as feasible. > > I don't have an actual use-case for this, as I don't target > microcontrollers, Please let me chime in, as one of MicroPython contributors. I also don't have immediate usecase for a Python microcontroller (but seeing how fast industry moves, I won't be surprised if in half-year it will seem just right). Instead, I treat MicroPython as a Python implementation which scales *down* very well. With current situation in the industry, people mostly care about scaling up - consume more gigabytes and gigahertz, catch more clouds and include heavier and heavier batteries. MicroPython goes another direction. You don't have to use it on a microcontroller. It's just if you want/need it, you'll be able - while still staying with your favorite language. I'm personally interested in using MicroPython on a small embedded Linux systems, like home routers, Internet-of-Thing devices, etc. Such devices usually have just few hundreds of megahertz of CPU power, and 2-4MB of flash. And to cut cost, the lower bound decreases all the time. > but I'm curious: What parts of Py3 syntax aren't > supported? And since you say "port as much as feasible", presumably > there'll be parts that are never supported. Are there some syntactic > elements that just take up way too much memory? Syntax-wise, all Python 3.3 syntax is supported. This includes things like yield from, annotations, etc. For example: $ micropython Micro Python v1.0.1-139-g411732e on 2014-06-03; UNIX version >>> def foo(a:int) -> float: ... return float(a) ... >>> foo(4) 4.0 "99.9%" statement is due to fact that there were some problems parsing couple of files in CPython 3.3/3.4 stdlib. Note that above talks about syntax, not semantics. Though core language semantics is actually now implemented pretty well. For example, "yield from" works pretty well, so asyncio could work ;-). (Except my analysis showed that CPython's implementation is a bit bloated for MicroPython requirements, so I started to write a simplified implementation from scratch). As can be seen from the dump above, MicroPython perfectly works on a Linux system, so we encourage any pythonista to touch a little bit of Python magic and give it a try! ;-) And we of course interested to get feedback how portable it is, etc. (As a side note, it's of course possible to compile and run MicroPython on Windows too, it's a bit more complicated than just "make".) > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of asyncio
Hello, On Mon, 02 Jun 2014 21:51:35 -0400 Terry Reedy wrote: > To all the great responders. If anyone thinks the async intro is > inadequate and has a paragraph to contribute, open a tracker issue. Not sure about intro (where's that?), but docs (https://docs.python.org/3/library/asyncio.html) are pretty confusing and bugs are reported, with no response: http://bugs.python.org/issue21365 > > -- > Terry Jan Reedy -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
