Repository navigation
Discussion of Python 3.6 support #2415
Description
Activity
PEP 468, preserving the order of kwargs, is of particular interest to us because it might be hard to implement efficiently. CPython 3.6 will have dict == OrderedDict (ie all dicts are ordered), using the PyPy implementation to make it efficient. Essentially all dicts have 2 tables, one which is the ordered array of (key, value) pairs (ordered by order of insertion), and the other is a (compact) hash table that indexes the ordered array.
I'd love to see "PEP 515 - Underscores in Numeric Literals" implemented. Easy and helpful. The rest, I'm more and more getting disappointed where CPython goes.
I'd love to see "PEP 515 - Underscores in Numeric Literals" implemented
+10. It would be pretty easy to add, and I agree really nice to then write something like
machine.freq(42_000_000).I'd love to see "PEP 515 - Underscores in Numeric Literals" implemented
+10. It would be pretty easy to add, and I agree really nice to then write something like machine.freq(42_000_000).
+1 here too. I've been using that while coding in rust and while a bit odd at first, it makes reading the larger integers easier.
I'd love to see "PEP 515 - Underscores in Numeric Literals" implemented. Easy and helpful.
Oh yes, oh yes. This is one my favourite language features in any language. I love it for hex and binary literals. Interestingly, at PyCon 2016 in Portland a few months ago, when the BDFL was reading over the list of PEP's, I cheered and applauded loudly for this one.... and about 2 thousand other people in the same room with me were dead silent. :/ So I'm thinking us embedded programmer types have different priorities.
As to the rest, I'm thinking that preserving order in kwargs is hardly worth the expense of memory in Micropython, for as often as it is used. OTOH, it may be a forced march if it becomes important for code portability. OTOOH, since we have 'micro' versions of the important libraries anyway, perhaps porting is a given in any case.
PEP530 just tickles me. Not sure it's of great value to Micropython, but I love it.
(Yes, I'm back! Been away from Micropython since about last December. Sometimes, life happens, and good stuff falls below the cut-off line on the to-do list. Hopefully, Micropython can crawl back above the line for a while.)
@dbc Welcome back! I don't follow your point about PEP530 though - improved async support is surely welcome. Many embedded applications rely on asynchronous code.
Reacted by Nils K@peterhinch re: PEP530 -- I should have been more clear about my fear of RAM bloat. Totally agree that asynch is great for embedded, I'm a big fan. I'd use async comprehensions if they were available, certainly -- like a cat on catnip. And of course we want Micropython to be as close to 100% source compatible with CPython as is practical. My fear is the "practical" part in Micropython -- if asynch comprehensions cause the SRAM footprint to grow significantly for programs using non-async list comprehensions or non-async generator expressions, then I'd be wary of it.
Thinking about it... the semantics of an async comprehension are satisfied by just doing a normal comprehension. The completion order is arbitrary, after all. So maybe the syntax can be accepted but the functionality could be a normal comprehension.
@dbc Will the availability of the async keyword affect the bytecode emitted when the keyword is absent? This surely depends on the cleverness of the compiler. But I'll leave this to people who actually understand compilers :)
PEP 498 - Literal String Formatting. It's step forward and "replace both existing % and str.format" looks like best solution for me. Definitely I want it in µpy.
PEP 525 - Asynchronous Generators (provisional). This is just awesome, since this can replace pretty uglyasync forcontext class. It is just same as generator and__enter__/__iter__methods of object. But, this requires too much changes, since this can't be done just as sugar forasync/awaitin µpy right now. And probably no one need this in µpy.PEP 498: I read that in detail now. So.. PEP 498 looks like the future. I never use %-formatting in new code. When PEP 498 strings happen in CPython, I will probably go exclusively to PEP498 format strings for new code and never look back, they are much more readable.
@dpgeorge says " likely too much bloat "
Ignoring PEP 498 means sacrificing CPython compatibility in a very visible way. Removing .format() in favor of literal string formatting is a very visible breaking change. Both of those options hit every user every day.
My naive assumption would be that much of the low-level formatting code could be factored out of .format() and literal string formatting. Pre-processing the PEP 498 strings would add to the compiler, certainly. Or is it RAM bloat and not code bloat that is the concern? An f-string becomes a byte-code expression in RAM instead of a simple string. Is this the concern?
I guess if you twisted my arm, I'd choose dropping %-formatting and .format() in favor of f-strings if I had to choose between f-strings and .format().
You can still do:
>>> s = "{x}" >>> x = 1 >>> s.format(x=x)
I see, I didn't catch that. In any case, they are not getting removed, so more power to you.
Argh, and now I re-read the whole conversation, and see how stupid my comment is, sorry.
If you have only f-strings and got template from somewhere as string you should do something like ...
Yes, that is somewhat klunky.
Removing .format() in favor of literal string formatting is a very visible breaking change. Both of those options hit every user every day.
I agree that removing .format() would be very bad news. Likewise the idea of removing the string modulus operator. In my view such changes would break far too much code and would be a worse departure from cPython compatibility than opting not to support f-strings.
Reacted by stinosReacted by Oleg Korsak+1 For PEP 487 - Simpler customization of class creation
This is deceptively humbly named. It is a MUCH saner and light-weight replacement for metaclasses in many cases. Also, it should be fairly simple to implement given that the machinery will be fairly similar to
__new__.Reacted by Andrew Leech and Scott Danielsf-string is something I'd love to see in MicroPython
PEP 498 -- Literal String InterpolationReacted by spacemanspiff2007, Nicole Parrot, Nikita Melentev, Oleg Korsak, wwj718, Steven Michalske, David Richards, Jasper Poppe, chiliseek, Gregory P. Smith and 12 moreReacted by Nicole Parrot, Oleg Korsak, chiliseek, Gregory P. Smith, Gordan Trevis, Steffen and Alex KKill the .format() , voting for f-strings ! broken code is an abandoned code in 99% cases. I don't see any reason to not update the code for this change.
Reacted by wwj718, nmweizi, Pythonic1985, Alex K and Galen MatsonReacted by Nikita Melentev, Steffen and Fábián VargaI believe PEP-15 is implemented in at least 1.10. I think we can strike it through!
for those looking for another way to get f-strings, I've added better support to
future-fstringsfor use as a preprocessor: https://github.com/asottile/future-fstrings#transform-source-for-micropythonIt has a PEP-498 compliant source transformer that produces equivalent
'...'.format(...)callsReacted by traverseda, Emil 'Skeen' Madsen and Galen Matsonthank you @asottile but sadly it seems, we won't benefit of bpo-36817 since asottile-archive/future-fstrings#40 was closed.
Where is the "Discussion of Python 3 support" status ? i may have missed it. I hardly see any 3.x future support with notimpl on major language features ( including some that exist since 2.x )
i only found 3.5 #1329
that issue is still doable, I just don't really feel motivated to work on it -- if someone wants to pick it up then by all means do so :)
@jimmo no i'm not searching for 3.6/3.7/3.8 totallly optionnal features from #4998
Apart from the warm thanks addressed to the person deserving them for adaptation ( after all he did not have to take the time to add that ) of his usefull tool for use with micropython in replacement of clumsy https://github.com/pmp-p/fstrings_helper my question was :
Where is the "Discussion of Python 3 support" status ? i may have missed it. I hardly see any 3.x future support with notimpl on major language features ( including some that exist since 2.x )
i only found 3.5 #1329, i'm more interested for discussion upon completion of 3.4 and reaching stability.
Any chance to implement PEP 526 (Syntax for Variable Annotations (provisional))?
I understand that it doesn't have any impact beyond the parser but would be hugely beneficial in development (at least to me it would be). I guess if it is too much work then using strip-hints is an option. Running it on each script before uploading/freezing would be an acceptable workaround if it works reliable.
Any chance to implement PEP 526 (Syntax for Variable Annotations (provisional))?
Yes I would like to see this implemented soon. It would then allow more sophisticated type hinting, and can also get use in viper annotations.
Reacted by Kevin Köck, Rick Bartlett, Divagnz, Patrick Arminio and Ryan Peach
Python 3.6 beta 1 was released on 12 Sep 2016, and a summary of the new features can be found here: https://docs.python.org/3.6/whatsnew/3.6.html . Being in beta stage means we can provide feedback on any of the new features/changes if we like.
(See #1329 for Python 3.5 support, which is still pending.)
New syntax features:
New built-in features:
Standard library changes:
CPython internals (not exposed at the Python level so not relevant to uPy):
Linux/Windows changes:
Other Language Changes
globalornonlocalstatement must now textually appear before the first use of the affected name in the same scope. Previously this was a SyntaxWarning.Noneto indicate that the corresponding operation is not available. For example, if a class sets__iter__()toNone, the class is not iterable."[Previous line repeated {count} more times]"ModuleNotFoundErrorwhen it cannot find a module. Code that currently checks for ImportError (in try-except) will still work.super()will now work correctly when called from metaclass methods during class creation.Changes to MicroPython built-in modules
array.arraywill now stay exhausted even if the iterated array is extended.b2a_base64()function now accepts an optional newline keyword argument to control whether the newline character is appended to the return value.cmath.tau(τ) constant has been added.cmath.infandcmath.nanto matchmath.infandmath.nan, and alsocmath.infjandcmath.nanjto match the format used by complex repr.Collectionabstract base class has been added to represent sized iterable container classes.Reversibleabstract base class represents iterable classes that also provide the__reversed__()method.AsyncGeneratorabstract base class represents asynchronous generatorsnamedtuple()function now accepts an optional keyword argument module, which, when specified, is used for the__module__attribute of the returned named tuple class.namedtuple()are now keyword-only.collections.dequeinstances can now be pickled.hashlibsupports OpenSSL 1.1.0. The minimum recommend version is 1.0.2.blake2b()andblake2s()are always available and support the full feature set of BLAKE2.sha3_224(),sha3_256(),sha3_384(),sha3_512(), and SHAKE hash functionsshake_128()andshake_256()were added.scrypt()is now available with OpenSSL 1.1.0 and newer.json.load()andjson.loads()now support binary input. Encoded JSON should be represented using either UTF-8, UTF-16, or UTF-32.mathandcmathmodules.osandos.pathmodules now support path-like objects.close()method allows explicitly closing ascandir()iterator. Thescandir()iterator now supports the context manager protocol.os.urandom()now blocks until the system urandom entropy pool is initialized to increase the security.getrandom()syscall (get random bytes) is now exposed as the newos.getrandom()function.'(?i:p)ython'matches'python'and'Python', but not'PYTHON';'(?i)g(?-i:v)r'matches'GvR'and'gvr', but not'GVR'.__getitem__, which is equivalent togroup(). Somo['name']is now equivalent tomo.group('name').ioctl()function now supports theSIO_LOOPBACK_FAST_PATHcontrol code.getsockopt()constantsSO_DOMAIN,SO_PROTOCOL,SO_PEERSEC, andSO_PASSSECare now supported.setsockopt()now supports thesetsockopt(level, optname, None, optlen: int)form.AF_ALGto interface with Linux Kernel crypto API.ALG_*,SOL_ALGandsendmsg_afalg()were added.TCP_USER_TIMEOUTandTCP_CONGESTIONwere added.sslsupports OpenSSL 1.1.0. The minimum recommend version is 1.0.2.SSLContexthas better default configuration for options and ciphers.SSLSessionclass. TLS session resumption can speed up the initial handshake, reduce latency and improve performance.get_ciphers()method can be used to get a list of enabled ciphers in order of cipher priority.IntEnumandIntFlags.SSLContextwere added.SSLContext.post_handshake_authto enable andssl.SSLSocket.verify_client_post_handshake()to initiate TLS 1.3 post-handshake authentication.'e'format specifier.getfilesystemencodeerrors()function returns the name of the error mode used to convert between Unicode filenames and bytes filenames.compress()anddecompress()functions now accept keyword arguments.(Changes to non-built-in modules will need to be documented elsewhere.)