[Python-Dev] How about updating OrderedDict in csv and configparser to regular dict?
Hi, csv.DictReader uses OrderedDict by default, from Python 3.6. But it doesn't make sense anymore, like namedtuple._asdict(). How about changing default dict type back to regular dict. Python is widely used for handling learge data. So I think changing default dict type to OrderedDict was performance and memory usage regression in 3.6. Additionally, configparser uses OrderedDict by default from Python 3.6 too. I am not sure about `parser['section1'] == parser['section2']` is not used yet. But we broke it once in 3.6 by changing dict to OrderedDict. Are there any issue report caused by this backward incompatibility? And I think performance and memory efficiency is not so important for configparser, unlike csv. I'm * +1 about changing csv.DictReader's default dict type * +0.5 about changing configparser's default dict type. How do you think? Regards, -- INADA Naoki ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
On 1/30/2019 8:45 PM, Raymond Hettinger wrote: On Jan 30, 2019, at 3:41 PM, Glenn Linderman wrote: Would it be practical to add deprecated methods to regular dict for the OrderedDict reordering methods that raise with an error suggesting "To use this method, convert dict to OrderedDict." (or some better wording). That's an interesting idea. Regular dicts aren't well suited to the reordering operations (like lists, repeated inserts at the front of the sequence wouldn't be performant relative to OrderedDict which uses double-linked lists internally). My instinct is to leave regular dicts alone so that they can focus on their primary task (being good a fast lookups). My goal was just to give a meaningful error message if someone misses the implications in What's New, and has code that actually does expect named_tuple.as_dict to have the ordering operations. The added, deprecated methods could be removed after a couple of versions. ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
> On Jan 30, 2019, at 9:11 PM, Tim Delaney wrote: > > Alternatively, would it be viable to make OrderedDict work in a way that so > long as you don't use any reordering operations it's essentially just a very > thin layer on top of a dict, There's all kinds of tricks we could do but none of them are worth it. It took Eric Snow a long time to write the OrderedDict patch and it took years to get most of the bugs out of it. I would really hate to go through a redesign and eat up our time for something that probably won't be much used any more. I'm really just aiming for something as simple as s/OrderedDict/dict in namedtuple :-) Raymond ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
On Thu, 31 Jan 2019 at 15:46, Raymond Hettinger wrote: > > > Would it be practical to add deprecated methods to regular dict for the > OrderedDict reordering methods that raise with an error suggesting "To use > this method, convert dict to OrderedDict." (or some better wording). > > That's an interesting idea. Regular dicts aren't well suited to the > reordering operations (like lists, repeated inserts at the front of the > sequence wouldn't be performant relative to OrderedDict which uses > double-linked lists internally). My instinct is to leave regular dicts > alone so that they can focus on their primary task (being good a fast > lookups). > Alternatively, would it be viable to make OrderedDict work in a way that so long as you don't use any reordering operations it's essentially just a very thin layer on top of a dict, but if you do use any reordering operations, it adds in the additional heavyweight structure required to support that? I'm pretty sure something similar has been considered before, but thought I should bring it up in the context of this discussion (if only to have to shot down). Tim Delaney ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
> On Jan 30, 2019, at 6:00 PM, David Mertz wrote: > > Ditto +1 option 4 > > On Wed, Jan 30, 2019, 5:56 PM Paul Moore On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger > wrote: > > My recommendation is Option 4 as being less disruptive and more beneficial > > than the other options. In the unlikely event that anyone is currently > > depending on the reordering methods for the output of _asdict(), the > > remediation is trivially simple: nt._asdict() -> > > OrderedDict(nt.as_dict()). > > > > What do you all think? >> >> +1 from me on option 4. >> >> Paul Thanks everyone. I'll move forward with option 4. In Barry's word, JFDI :-) > On Jan 30, 2019, at 6:10 PM, Nathaniel Smith wrote: > > How viable would it be to make OrderedDict smaller, faster, and give > it a cleaner looking repr? Not so much. The implementations substantially different because they have different superpowers. A regular dict is really good at being a dict while retaining order but it isn't good at reordering operations such as popitem(False), popitem(True), move_to_end(), and whatnot. An OrderedDict is a heavier weight structure (a hash table augmented by a doubly-linked link) -- it is worse at being a dictionary but really good at intensive reordering operations typical in cache recency tracking and whatnot. Also, there are long-standing API differences including weak references, ability to assign attributes, an equality operation that requires exact order when compared to another ordered dict etc, as well as the reordering methods. If it was easy, clean, and desirable, it would have already been done :-) Overall, I think the OrderedDict is increasingly irrelevant except for use cases requiring cross-version compatibility and for cases that need heavy reordering. Accordingly, I mostly expect to leave it alone and fall into the not-much-used category like UserDict, UserList, and UserString. > On Jan 30, 2019, at 3:41 PM, Glenn Linderman wrote: > Would it be practical to add deprecated methods to regular dict for the > OrderedDict reordering methods that raise with an error suggesting "To use > this method, convert dict to OrderedDict." (or some better wording). That's an interesting idea. Regular dicts aren't well suited to the reordering operations (like lists, repeated inserts at the front of the sequence wouldn't be performant relative to OrderedDict which uses double-linked lists internally). My instinct is to leave regular dicts alone so that they can focus on their primary task (being good a fast lookups). Raymond ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
On Wed, Jan 30, 2019 at 2:34 PM Raymond Hettinger wrote: > Now that regular dicts are ordered and compact, it makes more sense for the > _asdict() method to create a regular dict (as it did in its early days) > rather than an OrderedDict. The regular dict is much smaller, much faster, > and has a much cleaner looking repr. How viable would it be to make OrderedDict smaller, faster, and give it a cleaner looking repr? -n -- Nathaniel J. Smith -- https://vorpus.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] How to update namedtuple asdict() to use dict instead of OrderedDict
Ditto +1 option 4 On Wed, Jan 30, 2019, 5:56 PM Paul Moore On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger > wrote: > > My recommendation is Option 4 as being less disruptive and more > beneficial than the other options. In the unlikely event that anyone is > currently depending on the reordering methods for the output of _asdict(), > the remediation is trivially simple: nt._asdict() -> > OrderedDict(nt.as_dict()). > > > > What do you all think? > > +1 from me on option 4. > > Paul > ___ > 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/mertz%40gnosis.cx > ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
On Jan 30, 2019, at 14:32, Raymond Hettinger wrote: > > Now that regular dicts are ordered and compact, it makes more sense for the > _asdict() method to create a regular dict (as it did in its early days) > rather than an OrderedDict. The regular dict is much smaller, much faster, > and has a much cleaner looking repr. It would also help namedtuple() stay in > sync with dataclasses which already take advantage of the ordering feature of > regular dicts. Thanks for the excellent write up, Raymond. > Option 1) Add a deprecation notice to 3.8 […] In general, I don’t favor deprecation notices for things that are not actionable by the end user or the consumer of the API in question. It ends up being just noise, and that’s one of the big reasons why they are silenced by default (i.e. the end user of a Python application can’t do anything about the deprecation, so why scare them?). Maybe we need something like a MinorBehavioralChangeWarning which would be surfaced similar to PendingDeprecationWarning, but which says “Hey, we changed this in the current version of Python. Be aware of that change, but you probably don’t need to do anything about it”. At least such warnings could be reviewed, documented, and audited. I suppose in this case, there is something the consumer of the API can do (as you point out, they can wrap their code), but in all likelihood there’s really nothing they *need* to do. I think it will be rare that a Python 3.8 user will get bitten by this. Therefore... > Option 4) Just make the change directly in 3.8, JFDI! -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] How to update namedtuple asdict() to use dict instead of OrderedDict
On Wed, Jan 30, 2019 at 2:32 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > Now that regular dicts are ordered and compact, it makes more sense for > the _asdict() method to create a regular dict (as it did in its early days) > rather than an OrderedDict. The regular dict is much smaller, much faster, > and has a much cleaner looking repr. It would also help namedtuple() stay > in sync with dataclasses which already take advantage of the ordering > feature of regular dicts. > > The question is how to be go about making the change in a way gives the > most benefit to users as soon as possible and that creates the least > disruption. > > Option 1) Add a deprecation notice to 3.8, make no code change in 3.8, and > then update the code in 3.9. This has several issues: a) it doesn't > provide an executable DeprecationWarning in 3.8, b) it isn't really a > deprecation, and c) it defers the benefits of the change for another > release. > > Option 2) Add a deprecation notice to 3.8, add a DeprecationWarning to the > _asdict() method, and make the actual improvement in 3.9. The main issue > here is that it will create a lot of noise for normal uses of the _asdict() > method which are otherwise unaffected by the change. The typical use cases > for _asdict() are to create keyword arguments and to pass named tuple data > into functions or methods that expect regular dictionaries. Those use > cases would benefit from seeing the change made sooner and would suffer in > the interim from their code slowing down for warnings that aren't useful. > > Option 3). Add a deprecation notice to 3.8 and have the _asdict() method > create a subclass of OrderedDict that issues warnings only for the methods > and attributes that will change (move_to_end, popitem, __eq__, __dict__, > __weakref__). This is less noisy but it adds a lot of machinery just to > make a notification of a minor change. Also, it fails to warn that the > data type will change. And it may create more confusion than options 1 and > 4 which are simpler. > > Option 4) Just make the change directly in 3.8, s/OrderedDict/dict/, and > be done will it. This gives users the benefits right away and doesn't > annoy them with warnings that they likely don't care about. There is some > precedent for this. To make namedtuple class creation faster, the > *verbose* option was dropped without any deprecation period. It looks like > no one missed that feature at all, but they did get the immediate benefit > of faster import times. In the case of using regular dicts in named > tuples, people will get immediate and significant space savings as well as > a speed benefit. > > My recommendation is Option 4 as being less disruptive and more beneficial > than the other options. In the unlikely event that anyone is currently > depending on the reordering methods for the output of _asdict(), the > remediation is trivially simple: nt._asdict() -> > OrderedDict(nt.as_dict()). > +1 on option 4. I agree with everyone else. Because the remediation that keeps code compatible across all versions is that simple, just go with option 4. We document that in What's New and be done with it. :) -gps ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
On 1/30/2019 2:32 PM, Raymond Hettinger wrote: Now that regular dicts are ordered and compact, it makes more sense for the _asdict() method to create a regular dict (as it did in its early days) rather than an OrderedDict. ... Option 4) Just make the change directly in 3.8, s/OrderedDict/dict/, and be done will it. This gives users the benefits right away and doesn't annoy them with warnings that they likely don't care about. There is some precedent for this. To make namedtuple class creation faster, the *verbose* option was dropped without any deprecation period. It looks like no one missed that feature at all, but they did get the immediate benefit of faster import times. In the case of using regular dicts in named tuples, people will get immediate and significant space savings as well as a speed benefit. My recommendation is Option 4 as being less disruptive and more beneficial than the other options. In the unlikely event that anyone is currently depending on the reordering methods for the output of _asdict(), the remediation is trivially simple: nt._asdict() -> OrderedDict(nt.as_dict()). What do you all think? Option 4 sounds good to me. Would it be practical to add deprecated methods to regular dict for the OrderedDict reordering methods that raise with an error suggesting "To use this method, convert dict to OrderedDict." (or some better wording). ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
On 01/30/2019 02:55 PM, Paul Moore wrote: On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger wrote: My recommendation is Option 4 as being less disruptive and more beneficial than the other options. In the unlikely event that anyone is currently depending on the reordering methods for the output of _asdict(), the remediation is trivially simple: nt._asdict() -> OrderedDict(nt.as_dict()). What do you all think? +1 from me on option 4. From me as well. -- ~Ethan~ ___ 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] Summer of Code 2019 Mentors
Hi Python community folk!
As we've done for the past many years, Python is hoping to participate
in Google Summer of Code. This is a neat program where students write
code over the (northern hemisphere) summer under the tutelage of open
source mentors and get paid: we provide the project ideas, mentors and
choose the students, Google provides the program framework and the money
to pay students. You can read more about GSoC here:
https://summerofcode.withgoogle.com/
Python participates as an "umbrella org" where many different smaller
projects ("sub orgs") that use Python can take part under our banner.
You can also participate separately, but for people who've never done it
before and want help or for whom the paperwork is a hassle, you're
welcome to join up with us and let us show you the ropes!
It's really fun, and we've gotten lots of new contributors to
Python-based projects over the years, taking in as many as 70+ students
in a single year. Last year we only had 15, though, so we've got lots
of space for new mentors and new projects.
We didn't have any projects for core python last year as there were no
mentors
for the projects, so if anyone is interested in mentoring this year let us
know asap!
You can also send questions to gsoc-adm...@python.org (or just hit reply
to this email!)
___
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] How to update namedtuple asdict() to use dict instead of OrderedDict
On Wed, 30 Jan 2019 at 22:35, Raymond Hettinger wrote: > My recommendation is Option 4 as being less disruptive and more beneficial > than the other options. In the unlikely event that anyone is currently > depending on the reordering methods for the output of _asdict(), the > remediation is trivially simple: nt._asdict() -> OrderedDict(nt.as_dict()). > > What do you all think? +1 from me on option 4. Paul ___ 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] How to update namedtuple asdict() to use dict instead of OrderedDict
Now that regular dicts are ordered and compact, it makes more sense for the _asdict() method to create a regular dict (as it did in its early days) rather than an OrderedDict. The regular dict is much smaller, much faster, and has a much cleaner looking repr. It would also help namedtuple() stay in sync with dataclasses which already take advantage of the ordering feature of regular dicts. The question is how to be go about making the change in a way gives the most benefit to users as soon as possible and that creates the least disruption. Option 1) Add a deprecation notice to 3.8, make no code change in 3.8, and then update the code in 3.9. This has several issues: a) it doesn't provide an executable DeprecationWarning in 3.8, b) it isn't really a deprecation, and c) it defers the benefits of the change for another release. Option 2) Add a deprecation notice to 3.8, add a DeprecationWarning to the _asdict() method, and make the actual improvement in 3.9. The main issue here is that it will create a lot of noise for normal uses of the _asdict() method which are otherwise unaffected by the change. The typical use cases for _asdict() are to create keyword arguments and to pass named tuple data into functions or methods that expect regular dictionaries. Those use cases would benefit from seeing the change made sooner and would suffer in the interim from their code slowing down for warnings that aren't useful. Option 3). Add a deprecation notice to 3.8 and have the _asdict() method create a subclass of OrderedDict that issues warnings only for the methods and attributes that will change (move_to_end, popitem, __eq__, __dict__, __weakref__). This is less noisy but it adds a lot of machinery just to make a notification of a minor change. Also, it fails to warn that the data type will change. And it may create more confusion than options 1 and 4 which are simpler. Option 4) Just make the change directly in 3.8, s/OrderedDict/dict/, and be done will it. This gives users the benefits right away and doesn't annoy them with warnings that they likely don't care about. There is some precedent for this. To make namedtuple class creation faster, the *verbose* option was dropped without any deprecation period. It looks like no one missed that feature at all, but they did get the immediate benefit of faster import times. In the case of using regular dicts in named tuples, people will get immediate and significant space savings as well as a speed benefit. My recommendation is Option 4 as being less disruptive and more beneficial than the other options. In the unlikely event that anyone is currently depending on the reordering methods for the output of _asdict(), the remediation is trivially simple: nt._asdict() -> OrderedDict(nt.as_dict()). What do you all think? Raymond ___ 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] Add more SyntaxWarnings?
Stefan Behnel wrote: So … are you suggesting to use the webbrowser module inside of the REPL to look up the exception message of the previously printed stack trace in stack overflow when a user types "why()"? "Python is searching for an answer to your question..." -- Greg ___ 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] Add more SyntaxWarnings?
On Wed, Jan 30, 2019 at 07:12:21PM +0100, Stefan Behnel wrote: > > I have a vague recollection that a certain computer system (Amiga?) had a > > 'why' command. If it reported an error, you could type "why" and it would > > give you more details. > > > > I suspect that all that was happening was that when the error occurred it > > would store the additional details somewhere that the 'why' command would > > simply retrieve. > > So ??? are you suggesting to use the webbrowser module inside of the REPL to > look up the exception message of the previously printed stack trace in > stack overflow when a user types "why()"? > > I faintly recall someone implementing something in that direction. It's > probably in some package on PyPI. It doesn't have to be all web. Compare how ``help()`` works at the python REPL, ``pydoc name`` at the command line, and ``pydoc -p`` + a browser. > Stefan Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] Add more SyntaxWarnings?
On 2019-01-30 18:12, Stefan Behnel wrote: MRAB schrieb am 29.01.19 um 19:55: On 2019-01-29 13:44, Nick Coghlan wrote: FWIW, we have pretty decent evidence that error messages don't have to provide a wonderful explanation on their own in order to be helpful: they just need to be distinctive enough that a web search will reliably get you to a page that gives you relevant information. Pre-seeded answers on Stack Overflow are excellent for handling the second half of that approach (see [1] for a specific example). [1] https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python I have a vague recollection that a certain computer system (Amiga?) had a 'why' command. If it reported an error, you could type "why" and it would give you more details. I suspect that all that was happening was that when the error occurred it would store the additional details somewhere that the 'why' command would simply retrieve. So … are you suggesting to use the webbrowser module inside of the REPL to look up the exception message of the previously printed stack trace in stack overflow when a user types "why()"? No, I was just suggesting it as a possible way of providing newbies with more information about an error without annoying more experienced users with excessively long messages every time. I faintly recall someone implementing something in that direction. It's probably in some package on PyPI. ___ 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] Add more SyntaxWarnings?
MRAB schrieb am 29.01.19 um 19:55: > On 2019-01-29 13:44, Nick Coghlan wrote: >> FWIW, we have pretty decent evidence that error messages don't have to >> provide a wonderful explanation on their own in order to be helpful: >> they just need to be distinctive enough that a web search will >> reliably get you to a page that gives you relevant information. >> >> Pre-seeded answers on Stack Overflow are excellent for handling the >> second half of that approach (see [1] for a specific example). >> [1] >> https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python > > I have a vague recollection that a certain computer system (Amiga?) had a > 'why' command. If it reported an error, you could type "why" and it would > give you more details. > > I suspect that all that was happening was that when the error occurred it > would store the additional details somewhere that the 'why' command would > simply retrieve. So … are you suggesting to use the webbrowser module inside of the REPL to look up the exception message of the previously printed stack trace in stack overflow when a user types "why()"? I faintly recall someone implementing something in that direction. It's probably in some package on PyPI. Stefan ___ 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] [ANN] "compiler" package resurrected
Hello, I'm sorry for posting here and not to python-announce, somehow I think (perhaps naively) that it may be of interest to people who are interested in Python development. At the very least, creation of the original package is (very likely, I didn't trace up to that) was discussed on python-dev, its removal was discussed on python-dev, so why revival of it can't be noted here? Because, turns out, in old good times, there was a bytecode compiler written in Python, and even as a part of stdlib. Well, actually it's still there in the latest 2.7 release, with a proud notice: "Remove in Python3". The point is that I'm with Python since 1.5 times, and never knew about this package. I'd generally consider that to be something to be ashamed and hush of, but unfortunately I found that to be recurring pattern: people interested in playing with a Python compiler discover "by a chance" and "suddenly" that they should look no beyond the stdlib for their (usually pretty simple for starters) needs - oftentimes, after they already started on the more effortful path (I faithfully spent 2 days on trying to extract a bytecode compiler from PyPy first). With that intro, here's it - the port of Python2 compiler package (https://docs.python.org/2/library/compiler.html) to Python3: https://github.com/pfalcon/python-compiler Currently, it generates bytecode compatible with CPython3.5, and is able to compile its entire Lib/ (which includes not just stdlib modules per se, but also tests, and the real "teeth-cracking" stuff is there of course), except for test_super.py, for which current implementation's teeth are indeed too weak yet. Now that it passes the compile-stdlib test, the idea is to refactor it into something which can be easily played with and extended. We'll see how it goes. As one of the example of what's intended to be easily done with it, see thread https://mail.python.org/pipermail/python-dev/2019-January/155991.html . I started it when updating the codegen for Python3, but also shows the intended purpose - it would easy to analyze if an except handler body contains "del exc" and if not, skip generating superfluous bytecode. -- Best regards, Paul mailto:pmis...@gmail.com ___ 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
