Re: Python 3.8.2 on MacOSX Sierra?

bitten by the same underlying issue. I'm going to try again with XCode 8, which purportedly comes with a 10.12 SDK, and see if that fixes it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Python 3.8.2 on MacOSX Sierra?

? Is Python 3.8 only intended work on very recent versions of MacOSX? -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: How does the super type present itself and do lookups?

type slot, which corresponds to __getattribute__. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: `async def` breaks encapsulation?

switching a function between coroutine and non-coroutine would still have just as much of a ripple effect on the rest of your code. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: encapsulating a global variable

ion, while ensuring that there really is only one instance, and making this fact clear to anyone reading the code. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: encapsulating a global variable

need to be addressed by appropriate use of locks, etc. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Asyncio question

of asyncio is to make tasks very lightweight, so you can use as many of them as is convenient without worries. One task per client sounds like the right thing to do here. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: JavaScript's void operator in Python?

On 3/02/20 3:38 am, Stefan Ram wrote: void( ( print( 2 ), print( 3 ))) If the functions you're calling all return None, you can do this: >>> print(2); print(3) 2 3 -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: How to read the original data line by line from stdin in python 3 just like python 2?

On 29/01/20 6:27 pm, Peng Yu wrote: Suppose that I use this to read from stdin. But `line` contains decoded data in python 3. In python 2, it contains the original data. What is the best way to get the original data in python 3? Read from stdin.buffer, which is a stream of bytes. -- Greg

Re: Nested Loop Code Help

. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Sandboxing eval()

'+'ort__']", {"__builtins__":{}}) You can probably find a way to block that particular loophole. But then there will be another one, and another, and another... You'll never be sure that you've found all of them. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: IDLE, TCP/IP problem.

from being opened. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Extension type inherit from Python int

needs to be something with a sufficiently int-like interface. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

zipextimporter into the standard library, and developing versions of it for Linux and MacOS, would be a useful improvement? -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: A small quiz

advanced topics, to be tackled after your students are familiar with the basics. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python, Be Bold!

It looks like what the OP is after already exists: https://docs.python.org/3/library/zipapp.html "This module provides tools to manage the creation of zip files containing Python code, which can be executed directly by the Python interpreter." -- Greg -- https://mail.python.o

Re: Friday Finking: Source code organisation

the bottom of the file and work backwards. But it's not so easy for classes if you have more than one class in a file. That might be part of the reason I do things the opposite way in classes. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Friday Finking: Source code organisation

to go out of your way to get things in a different order. But strangely, I tend to do the opposite for methods of a class. I don't really know why. My instinctive idea of the "right" ordering just seems to flip over somehow between modules and classes. -- Greg -- https://mail.python.org/mai

Re: Friday Finking: Source code organisation

in the file in either order, -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: How to extend an object?

: for s in 'abc'.like( '(.)' ): I would recommend making it a stand-alone function instead, so that you would write for s in like('abc', '(.)'): -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Cython, producing different modules from the same .pyx

PyInit_XXX(), where XXX is computed from the .pyx name, You could try creating a set of top-level .pyx stubs, each of which just 'include' the real code. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python3 - How do I import a class from another file

On 14/12/19 5:13 pm, boB Stepp wrote: is it true that CPython itself is free to implement these behaviors differently in its own future versions? Yes. That's why it's not a good idea to rely on them even if you only intend to run your code on CPython. -- Greg -- https://mail.python.org

Re: Python3 - How do I import a class from another file

, all the details are unique to Python. Some other languages have a "with" statement, but it does something completely different. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python3 - How do I import a class from another file

lying on __del__ for anything that needs to be done promptly. There are always alternatives: e.g. file objects have a close() method, and the "with" statement was invented to make it easy to do these kinds of things properly. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python3 - How do I import a class from another file

to be run on a different implementation of Python that didn't use reference counting, such as Jython. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python3 - How do I import a class from another file

. Python differs from VBScript and other VB-family languages in that names are case-sensitive. So it's common to use case to distinguish between things such as a class and an instance. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python3 - How do I import a class from another file

statement that creates a class object and binds it to a name. There's nothing stopping you from subsequently rebinding that name to some other object, or deleting it altogether. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Python3 - How do I import a class from another file

something noticeable. You'll find that *any* form of import executes all the top-level code. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: python 2 to 3 converter

an automated process. It sounds like an interesting project, but be aware that it's probably an AI-complete problem. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: stuck on time

, but it is designed for very low resolution, so it's probably a reasonable choice for use on a small display. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: Aw: Re: stuck on time

it. We can offer advice, but ultimately you're the one who has to work it out. If you don't think the project is worth that much effort, that's up to you. But you asked for help, and we're doing our best to give it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

[issue29298] argparse fails with required subparsers, un-named dest, and empty argv

Greg added the comment: while waiting for a fix, would it be possible to document in the argparse documentation that the 'dest' parameter is required (at least temporarily) for add_subparsers()? (somewhere near file:///usr/share/doc/python/html/library/argparse.html#sub-commands

Re: Python Resources related with web security

others and doing it themselves, so nobody writes anything down about it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: low-level csv

and safer to use the csv module for csv. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Greg Price added the comment: > labeling long-stable code as "evil". Let me apologize about this bit -- I was thinking of the term in quotes (referring to the earlier comment), but I didn't write it clearly that way. I don't think any of this code is evil, past or present,

[issue16684] Unicode property value abbreviated names and long names

Greg Price added the comment: I've gone and implemented a version of this that's integrated into Tools/unicode/makeunicodedata.py , and into the unicodedata module. Patch attached. Demo: >>> import unicodedata, pprint >>> pprint.pprint(unicodedata.property_value_aliase

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Greg Price added the comment: I hesitate to come back to this thread, because as Raymond says it's consumed a lot of time already. But I think this point is of broader interest than the specific few lines we've been discussing: > When small integer are disabled at compilation t

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Greg Price added the comment: Thanks Benjamin for reviewing and merging this series! -- ___ Python tracker <https://bugs.python.org/issue37760> ___ ___ Pytho

[issue18236] str.isspace should use the Unicode White_Space property

Change by Greg Price : -- keywords: +patch pull_requests: +15849 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/16254 ___ Python tracker <https://bugs.python.org/issu

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Greg Price added the comment: > We're wasted a lot of dev time on something that never promised much value in > the first place. So, I'll revert and close this tracker issue OK, so be it. I'll certainly agree that this series of threads consumed a lot more time than I anticipated or

[issue38015] inline function generates slightly inefficient machine code

Greg Price added the comment: See followup at https://bugs.python.org/issue38205 and https://bugs.python.org/issue37812#msg352670 . The patch in GH-15710 had a side effect of introducing a call to `Py_UNREACHABLE` inside a comma-expression. A subsequent commit 3ab61473b changed

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Greg Price added the comment: > if using a static inline function is causing issues Separately from whether there was or wasn't such an issue here, I think it's interesting to note that the build failure bpo-38205 is an example of exactly the opposite! It was caused by a combinat

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Greg Price added the comment: Thanks Victor for linking that issue back here. > A first change converted a macro to a static inline function. The second > change converted the static inline fnuction to a macro Not quite. The first change converted a macro `CHECK_SMALL_INT` to an equi

[issue27970] ssl: can't verify a trusted site with imcomplete certificate chain

Change by Greg Lindahl : -- nosy: +wumpus ___ Python tracker <https://bugs.python.org/issue27970> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37936] gitignore file is too broad

Greg Price added the comment: Thanks @zach.ware for the review and merge of GH-15451! That was the "minimal" fix, fixing rules that apply to files we have in the repo now. So `rg` will no longer ignore `PC/pyconfig.h`. :-) I've just sent GH-15823 with the "more thoro

[issue37936] gitignore file is too broad

Change by Greg Price : -- pull_requests: +15472 pull_request: https://github.com/python/cpython/pull/15823 ___ Python tracker <https://bugs.python.org/issue37

[issue38079] _PyObject_VAR_SIZE should avoid arithmetic overflow

Greg Price added the comment: (The tracker just linked GH-14838 to this issue because I mentioned it in a comment there, but it's not for this issue -- it's that recent fix for an 11-year-old bug in a callsite's overflow check.) -- ___ Python

[issue38079] _PyObject_VAR_SIZE should avoid arithmetic overflow

New submission from Greg Price : Currently `_PyObject_VAR_SIZE` effectively has a precondition that it must not be passed arguments which would overflow in its arithmetic. If that's violated, it overflows... which is undefined behavior already, and in fact the likely next thing that happens

[issue38015] inline function generates slightly inefficient machine code

Greg Price added the comment: (Just to help keep discussions together: some earlier discussion was on GH-15216 .) Because is_small_int / IS_SMALL_INT is so small, there's not much cost in the source code to making it a macro (as GH-15710 did). But I think it'd be a mistake to go a lot

[issue38043] small cleanups in Unicode normalization code

Change by Greg Price : -- pull_requests: +15368 pull_request: https://github.com/python/cpython/pull/15558 ___ Python tracker <https://bugs.python.org/issue38

[issue38043] small cleanups in Unicode normalization code

Change by Greg Price : -- pull_requests: +15367 pull_request: https://github.com/python/cpython/pull/15712 ___ Python tracker <https://bugs.python.org/issue38

[issue38043] small cleanups in Unicode normalization code

Change by Greg Price : -- keywords: +patch pull_requests: +15366 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15711 ___ Python tracker <https://bugs.python.org/issu

[issue38043] small cleanups in Unicode normalization code

New submission from Greg Price : Benjamin noticed in reviewing GH-15558 (for #37966) several points where the existing code around Unicode normalization can be improved: * on the `QuickcheckResult` enum: > Maybe `makeunicodedata.py` should output this enum (with better name namespac

[issue37837] add internal _PyLong_FromUnsignedChar() function

Greg Price added the comment: Ah OK, that makes sense of it then :) > But the most important thing is that using PyLong_FromUnsignedLong() instead > of _PyLong_FromUnsignedChar() on top of GH-15192 is producing the same > results: striter_next() uses small_ints[] directly. Howev

[issue6331] Add unicode script info to the unicode database

Change by Greg Price : -- nosy: +Greg Price ___ Python tracker <https://bugs.python.org/issue6331> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37966] is_normalized is much slower at "no" than the standard's algorithm

Greg Price added the comment: Fix posted, as GH-15558. Adding cc's for the folks in the thread on #32285, where this function was originally added. -- components: +Unicode nosy: +Maxime Belanger, benjamin.peterson, ezio.melotti, steven.daprano, vstinner title: is_normalized is much

[issue37966] is_normalized is much slower than the standard's algorithm

Change by Greg Price : -- keywords: +patch pull_requests: +15231 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15558 ___ Python tracker <https://bugs.python.org/issu

[issue37966] is_normalized is much slower than the standard's algorithm

New submission from Greg Price : In 3.8 we add a new function `unicodedata.is_normalized`. The result is equivalent to `str == unicodedata.normalize(form, str)`, but the implementation uses a version of the "quick check" algorithm from UAX #15 as an optimization to try to av

[issue37936] gitignore file is too broad

Greg Price added the comment: > I have a minimal fix which takes care of all the files above. I'll post that > shortly, and I may also write up a more thorough fix that tries to make it > easy not to fall into the same Git pitfall again. Both now done. * GH-15451 is that minimal fi

[issue37936] gitignore file is too broad

Change by Greg Price : -- pull_requests: +15219 pull_request: https://github.com/python/cpython/pull/15542 ___ Python tracker <https://bugs.python.org/issue37

[issue37837] add internal _PyLong_FromUnsignedChar() function

Greg Price added the comment: Very interesting, thanks! It looks like with LTO enabled, this optimization has no effect at all. This change adds significant complexity, and it seems like the hoped-for payoff is entirely in terms of performance on rather narrowly-focused microbenchmarks

[issue18236] str.isspace should use the Unicode White_Space property

Greg Price added the comment: > I've gone and made a patch for this change Update: * The preparatory changes in #37760 are now almost all merged; GH-15265 is the one piece remaining, and I'd be grateful for a review. It's a generally straightforward and boring change that converts the m

[issue37837] add internal _PyLong_FromUnsignedChar() function

Greg Price added the comment: > Is there a particular reason to specifically call PyLong_FromSize_t? Seems > like PyLong_FromLong is the natural default (and what we default to in the > rest of the code), and it's what this ends up calling anyway. Ah I see, the patch is meant to

[issue37837] add internal _PyLong_FromUnsignedChar() function

Greg Price added the comment: Oh also: * What compiler, and what compilation flags, are you using in your benchmarking? That seems relevant :) -- ___ Python tracker <https://bugs.python.org/issue37

[issue37837] add internal _PyLong_FromUnsignedChar() function

Greg Price added the comment: Hmm, I'm a bit confused because: * Your patch at GH-15251 replaces a number of calls to PyLong_FromLong with calls to the new _PyLong_FromUnsignedChar. * That function, in turn, just calls PyLong_FromSize_t. * And that function begins: PyObject

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Greg Price added the comment: > May I suggest directing your efforts towards fixing known bugs or > implementing requested features. Well, I would certainly be grateful for a review on my fix to #18236. ;-) There's also a small docs bug at GH-15301. I do think there's significant

[issue37936] gitignore file is too broad

Change by Greg Price : -- keywords: +patch pull_requests: +15143 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15451 ___ Python tracker <https://bugs.python.org/issu

[issue37936] gitignore file is too broad

New submission from Greg Price : There are a number of files that we track in the repo, but are nevertheless covered by `.gitignore`. This *mostly* doesn't change anything, because Git itself only cares what `.gitignore` has to say about files that aren't already tracked. But: * It affects

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Greg Price added the comment: Thanks, Raymond, for the review on GH-15216! Shortly after posting this issue, I noticed a very similar story in CHECK_BINOP. I've just posted GH-15448 to similarly make returns explicit there. It basically consists of a number of repetitions

[issue37812] Make implicit returns explicit in longobject.c (in CHECK_SMALL_INT)

Change by Greg Price : -- pull_requests: +15140 pull_request: https://github.com/python/cpython/pull/15448 ___ Python tracker <https://bugs.python.org/issue37

[issue36375] PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules

Change by Greg Price : -- nosy: +Greg Price ___ Python tracker <https://bugs.python.org/issue36375> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Greg Price added the comment: (A bit easy to miss in the way this thread gets displayed, so to highlight in a comment: GH-15265 is up, following the 5 other patches which have now all been merged. That's the one that replaces the length-18 tuples with a dataclass

[issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore

Greg Price added the comment: I ran across this test when looking at especially slow files in the test suite: it turns out that not only is this service currently down, but the snakebite.net domain still exists, and as a result the test can end up waiting 20-30s before learning

[issue35518] test_timeout uses blackhole.snakebite.net domain which doesn't exist anymore

Change by Greg Price : -- keywords: +patch pull_requests: +15063 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15349 ___ Python tracker <https://bugs.python.org/issu

[issue36502] str.isspace() for U+00A0 and U+202F differs from document

Greg Price added the comment: Thanks Victor for the reviews and merges! (Unmarking 2.7, because https://docs.python.org/2/library/stdtypes.html seems to not have this issue.) -- versions: -Python 2.7 ___ Python tracker <https://bugs.python.

[issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file

Change by Greg Price : -- components: +Interpreter Core ___ Python tracker <https://bugs.python.org/issue37872> ___ ___ Python-bugs-list mailing list Unsub

[issue37872] Move _Py_IDENTIFIER statics in Python/import.c to top of the file

Change by Greg Price : -- title: Move statics in Python/import.c to top of the file -> Move _Py_IDENTIFIER statics in Python/import.c to top of the file ___ Python tracker <https://bugs.python.org/issu

[issue37872] Move statics in Python/import.c to top of the file

Change by Greg Price : -- nosy: +Greg Price ___ Python tracker <https://bugs.python.org/issue37872> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints

Change by Greg Price : -- pull_requests: +15027 pull_request: https://github.com/python/cpython/pull/15302 ___ Python tracker <https://bugs.python.org/issue37

[issue36502] str.isspace() for U+00A0 and U+202F differs from document

Change by Greg Price : -- pull_requests: +15026 pull_request: https://github.com/python/cpython/pull/15301 ___ Python tracker <https://bugs.python.org/issue36

[issue37864] Correct and deduplicate docs on "printable" characters

Change by Greg Price : -- keywords: +patch pull_requests: +15025 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15300 ___ Python tracker <https://bugs.python.org/issu

[issue37864] Correct and deduplicate docs on "printable" characters

New submission from Greg Price : While working on #36502 and then #18236 about the definition and docs of str.isspace(), I looked closely also at its neighbor str.isprintable(). It turned out that we have the definition of what makes a character "printable" documented in three plac

[issue37758] unicodedata checksum-tests only test 1/17th of Unicode's codepoints

Change by Greg Price : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue37758> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32771] merge the underlying data stores of unicodedata and the str type

Greg Price added the comment: > About the RSS memory, I'm not sure how Linux accounts the Unicode databases > before they are accessed. Is it like read-only memory loaded on demand when > accessed? It stands for "resident set size", as in "resident in memory&quo

[issue36502] str.isspace() for U+00A0 and U+202F differs from document

Change by Greg Price : -- pull_requests: +15019 pull_request: https://github.com/python/cpython/pull/15296 ___ Python tracker <https://bugs.python.org/issue36

[issue37848] More fully implement Unicode's case mappings

Greg Price added the comment: (I should add that it was only after doing the reading that produced the OP that I had a clear idea what I thought the priority of the issue was -- before doing that work I didn't have a clear sense of the scope of what it affects. Based

[issue37848] More fully implement Unicode's case mappings

Greg Price added the comment: > Maintaining Python is already expensive [...] There are already enough bugs > waiting for you to be fixed ;-) BTW I basically agree with this. I think this is not a high-priority issue, and I have my eye on some of those bugs. :-) I think the fact tha

[issue37848] More fully implement Unicode's case mappings

Greg Price added the comment: > I believe that all locale specific things should be in the locale module, not > in the str class. The locale module is all about doing things with the current process-global Unix locale. I don't think that'd be an appropriate interface for this -- if

[issue32771] merge the underlying data stores of unicodedata and the str type

Greg Price added the comment: OK, I forked off the discussion of case-mapping as #37848. I think it's probably good to first sort out what we want, before returning to how to implement it (if it's agreed that changes are desired.) Are there other areas of functionality that would be good

[issue37848] More fully implement Unicode's case mappings

Greg Price added the comment: Another previous discussion is #4610. -- ___ Python tracker <https://bugs.python.org/issue37848> ___ ___ Python-bugs-list mailin

[issue37848] More fully implement Unicode's case mappings

New submission from Greg Price : Splitting this out from #32771 for more specific discussion. Benjamin writes there that it would be good to: > implement the locale-specific case mappings of > https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt and §3.13 of > the U

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Change by Greg Price : -- pull_requests: +14985 pull_request: https://github.com/python/cpython/pull/15265 ___ Python tracker <https://bugs.python.org/issue37

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Greg Price added the comment: > From my perspective, the main problem with using type annotations is that > there's nothing checking them in CI. Yeah, fair concern. In fact I think I'm on video (from PyCon 2018) warning everyone not to do that in their codebases, because what you

[issue32771] merge the underlying data stores of unicodedata and the str type

Greg Price added the comment: Speaking of improving functionality: > Having unicodedata readily accessible to the str type would also permit > higher a fidelity unicode implementation. For example, implementing > language-tailored str.lower() requires having canonical combin

[issue32771] merge the underlying data stores of unicodedata and the str type

Greg Price added the comment: > Loading it dynamically reduces the memory footprint. Ah, this is a good question to ask! First, FWIW on my Debian buster desktop I get a smaller figure for `import unicodedata`: only 64 kiB. $ python Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Greg Price added the comment: > This is good. But the title mentioned dataclasses, and they are 3.7+. Ahh, sorry, I think now I understand you. :-) Indeed, when I switch to the branch with that change (https://github.com/gnprice/cpython/commit/2b4aec4dd -- it comes after the patch tha

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Greg Price added the comment: > What is the minimal Python version for developing CPython? The system Python > 3 on current Ubuntu LTS (18.04) is 3.6, so I think it should not be larger. Ah, I think my previous message had an ambiguous parse: the earliest that *uses* of the typing

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Greg Price added the comment: > BTW: Since when do we use type annotations in Python's stdlib ? Hmm, interesting question! At a quick grep, it's in a handful of places in the stdlib: asyncio, functools, importlib. The earliest it appeared was in 3.7.0a4. It's in more places in the t

[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass

Greg Price added the comment: > I like to run pyflakes time to time on the Python code base. Please avoid > "import *" since it prevents pyflakes (and other code analyzers) to find bugs. Ah fair enough, thanks! Pushed that change to the next/curr

[issue32771] merge the underlying data stores of unicodedata and the str type

Change by Greg Price : -- nosy: +Greg Price ___ Python tracker <https://bugs.python.org/issue32771> ___ ___ Python-bugs-list mailing list Unsubscribe:

<    1   2   3   4   5   6   7   8   9   10   >