Mailman 3 November 2020 - Python-Dev

Python.org downloads page and javascript
by Michael Felt Nov. 12, 2020

Nov. 12, 2020

Hi, Not clear on where to report this - so I hope someone else sees the same and can notify whoever needs to be notified. The main URL for downloads: https://www.python.org/downloads/ Opens with message : *Notice:* While Javascript is not essential for this website, your interaction with the content will be limited. Please turn Javascript on for the full experience. However, javascript is enabled in my browser (FF latest). Also tried with Chrome - same (messy) layout. The main page, and selected pages (e.g., https://www.python.org/doc/) work as expected. Hope this helps!, Michael

3 2

My thoughts on Pattern Matching.
by Thomas Wouters Nov. 12, 2020

Nov. 12, 2020

Apologies that this is a long email, but I want to make sure I get my points across and it's difficult to do it in a short email. I touched on some of these things in a blogpost I wrote ( https://pyrandom.blogspot.com/2020/11/my-view-of-python-steering-council.ht…) but I wanted to make the main points in detail in a way that made it easy for people to provide feedback if they wanted, so it's an email instead of a blog post. We haven't broadly announced it, but the current SC has decided not to make the final decision <https://github.com/python/steering-council/issues/39#issuecomment-720677712> on Structural Pattern Matching (PEPs 634/635/636) and the additional/competing PEPs (640 and 642), because it's so close to the election of the next SC. Instead, we're going to make our decision and then leave it as a strong recommendation for the 2021 SC, as they will actually be in charge for the release of the next version of Python. The 2021 SC will then have to make the final decision. I understand this may be disappointing to some, and I'm sorry, but even after the SC election there's more than five months before the final decision has to be made for the feature to make it into Python 3.10. I hope the next SC doesn't take that long, but there's no rush to get it in before they are seated. I also imagine this means the Structural Pattern Matching proposal may be a voting issue for some, and since I will be running for the next SC, I want to make it clear where I stand and why. Note that this is *my* point of view, not the SC's. I don't think any of the SC have made up their mind yet, and we all approach this differently. We're continuing the discussion between us to come to our decision-cum-recommendation. I would also like to hear (in private or public, I don't mind) whether people even remotely agree with me, because my mind can still be changed on some of these issues -- especially if it turns out I'm alone in my concerns. First of all, I am honestly excited about pattern matching. The impact on existing code or the examples in the PEPs may not feel impressive, but I can see how it would change how we think about certain problems, how we design APIs around them, much like for example decorators and the `with` statement has in the past. Like both of those changes, the pattern matching design gives us convenient inversion of control. I don't usually write code using isinstance(), but I realise switching on types is something people want to do and sometimes might even be the best thing to do. The Structural Pattern Matching proposal solves this by allowing the types to decide what they match against in a way that's easier to use and *much* more purpose-driven than the existing hammers of `__isinstance__` and `__issubclass__`. My concerns about the proposal all stem from the differences with the rest of the language. Some are very minor -- for example, I wish there was a better way to deal with the indentation of 'match' and 'case', but all of the proposed alternatives are clearly worse to me, so the double indentation is fine. I'm satisfied all my minor concerns have been addressed in the Structural Pattern Matching proposal, one way or another. I also have some small but significant concerns that keep nagging at me, but I'm not sure how much of a big deal they will be in practice. I don't know whether these will be a problem, but I'm worried they _might turn out to be_, and that in hindsight we should've made a different choice. Ideally, we make decisions that allow us to correct the mistake (like removing u'' strings in Python 3) rather than make it hard to ever change (like indexing bytes producing integers). Those concerns are (although I may have forgotten one or two minor ones): - Mapping patterns ignoring extra items. In the proposal, unpacking "into" a dict automatically ignores extra items.There is syntax readily available (and explicitly disallowed) for ignoring extra items. There are also ways to check for extra keys, like a guard on the case, but if the program doesn't think about adding it, extra items are just silently ignored. I'm just not sure that the don't-care-about-extra-items use-case is common enough to warrant silently doing the wrong thing, especially since it's so very easy to write the code for that use-case. - The mixture of assignment, evaluation and matching in case clauses. I keep worrying that it will be difficult to see what's being assigned to, what's being called, and what's being matched against. I think the current proposal has enough safe-guards to make it hard to *write* the wrong thing, but readability still counts. The competing proposals for solving this issue do not seem like improvements to me, however, for reasons I'll get to below. - The use of `|` instead of `or`, which falls in the same boat as the previous point: to my eyes `or` makes it much easier to parse the more complex cases in the examples. For the simple case of 'case 0|1:' versus 'case 0 or 1:' it's not as big a deal, but it's not like `|` is somehow better, either. My primary hesitation, however, is much wider than those issues. It's the incongruity between pattern matching and the rest of the language. And it's not just because it makes it harder to teach, or harder to read or maintain, or require some kind of mental mode switch as you go through the code -- I *am* worried about those things, but to me they are not the main problem. The primary reason I care about the integration with the rest of Python is because it limits the future expansion of the language. Pattern matching can be (and frequently is) seen to be an expansion of iterable unpacking -- or, depending on your point of view, iterable unpacking is a basic, limited form of pattern matching. Making the two _unnecessarily_ different makes it harder to unify them, and makes it harder to unify _future_ changes to either of them. For example, if pattern matching indeed takes off and we start seeing APIs and conventions designed around it, we may want to consider (or reconsider) adding mapping-unpacking to iterable unpacking as well: `{'spam': spam_var, 'ham': ham_var} = ...`. Or we may want simplified typed unpacking if we find it's very common to write short match expressions, and instead write `Viking(spam, ham) = ...`. We won't know which of those -- or of things we can't imagine right now -- will make sense until after pattern matching is accepted and has seen plenty of use. We've seen that with `with`, with decorators, with generators, with generator-style coroutines, etc. And it also goes the other way: there may be changes to other parts of Python that we want to make work with pattern matching, even the bits of pattern matching that aren't exactly like the rest of Python -- we may end up expanding the assignment syntax to add some feature, and then find we want that feature in match cases, which aren't exactly like other assignment targets. To me, that's the big reason to make sure any new proposal lines up well with the rest of Python. In the Structural Pattern Matching proposal, as I see it, the main incongruities are the big expansion of assignment (which is part and parcel to pattern matching) with its subtle differences between stores and loads, and the special semantics for `_`. It doesn't matter that we can live with those differences; what matters is what's going to happen in the long run with those differences. If we want to copy some of the semantics and syntax from pattern matching to other parts of Python, can we? We can do that with the expanded assignment targets to some extent, perhaps even to the fullest sensible extent. We can't really do that with the special semantics of `_`. It would mean some significant confusion around the use of _ for i18n, even if we figured out a way of handling the conflict. This is why I proposed PEP 640. By using '?' -- or whatever else that isn't a valid identifier -- we avoid an insurmountable problem in the future, and by applying it to iterable unpacking we're already closing the gap. The entire cost of this proposal is using something other than what other languages use, which is hardly unique in Python. But failing that, I want to see _some_ way towards closing the gap between pattern matching and existing assignment semantics. If `_` becomes special in pattern matching, we should have a long-term plan for making it special everywhere, or we're left with a gap we can only ever widen, not close. It's also why I'm not in favour of PEP 642 and other proposals for solving some of the problems in the Structural Pattern Matching proposal (sigils, etc): it widens the gap instead of closing it. It creates more special syntax that will be harder to apply to other parts of Python. I think we need something that fits well with the rest of Python, not a separate sub-language. Like I said, I haven't made up my mind either way, and I don't want to turn this into the single issue on which to vote _for_ me -- the SC has a lot of other, important stuff on its plate, and you can disagree with me on any of them! -- but I want to be entirely clear on where I stand on this issue, lest people _regret_ voting for me because of it. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

6 6

When to remove BytesWarning?
by Inada Naoki Nov. 11, 2020

Nov. 11, 2020

Hi, all. To avoid BytesWarning, the compiler needs to do some hack when they need to store bytes and str constants in one dict or set. BytesWarning has maintenance costs. It is not huge, but significant. When can we remove it? My idea is: 3.10: Deprecate the -b option. 3.11: Make the -b option no-op. Bytes warning never emits. 3.12: Remove the -b option. BytesWarning will be deprecated in the document, but not to be removed. Users who want to use the -b option during 2->3 conversion need to use Python ~3.10 for a while. Regards, -- Inada Naoki <songofacandy(a)gmail.com>

6 12

Re: Who is target reader of tutorial?
by Federico Salerno Nov. 7, 2020

Nov. 7, 2020

I think it's important to remember that many novice programmers today learn python as their first language. While i don't think the python tutorial is the right place for teaching how to program, i also think it would be best if it didn't make too many assumptions on the reader's knowledge. When it comes to the basics, assuming one already knows another language isn't very beneficial anyway, in my opinion. If all one is looking for is a table comparing a known thing with its python equivalent, there are many of those on the internet already and in much more compact form.

3 2

Who is target reader of tutorial?
by Inada Naoki Nov. 7, 2020

Nov. 7, 2020

Hi, all. Since "How To" guide is not organized well, it is very tempting to write all details in tutorial. I have seen may pull requests which "improve" tutorial by describe more details and make the tutorial more perfect. But adding more and more information into tutorial makes it slower to learn Python by reading tutorial. 10+ years ago, Python is far less popular in Japan and reading tutorial is the best way to learn Python to me. But now Python is popular and there are many free/paid good books and tutorials on the Web. Some of them would be more new user friendly than official tutorial. Then, should official Python tutorial become detailed guide to Python? Or should we keep new user learning Python as targeted reader? There is ongoing issue for example: https://bugs.python.org/issue42179 Chaining exception was added in tutorial. Current tutorial mention to `__cause__` attribute. https://docs.python.org/3/tutorial/errors.html#exception-chaining bpo-42179 proposes to add mention to `__context__` to make the tutorial more accurate about implicit chaining. And https://github.com/python/cpython/pull/23160 is the pull request to mention `__context__`. On the other hand, I want to remove confusion by removing mention to `__cause__`. Because I don't think `__context__` and `__cause__` is important for new users. See https://github.com/python/cpython/pull/23162 for my proposal. Regards, -- Inada Naoki <songofacandy(a)gmail.com>

12 16

Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python
by Garrett D'Amore Nov. 7, 2020

Nov. 7, 2020

I’m not on this list. But I have offered to help - if there are tasks that need to be done to help this I can help put the weight of a commercial entity behind it whether that involves assigning our developers to work on this, helping pay for external developers to do so, or assisting with access to machine resources. For the record there are multiple illumos distributions and most are both free and run reasonably well in virtual machines. Claiming that developers don’t have access as a reason to discontinue the port is a bit disingenuous. Anyone can get access if they want and if they can figure out how to login and use Linux then this should be pretty close to trivial for them. What’s more likely is that some group of developers aren’t interested in supporting stuff they don’t actively use. I get it. It’s easier to work in a monoculture. But in this case there are many many more users of this that would be impacted than a naive examination of downloads will show. Of course this all presumes that the core Python team still places value on being a cross platform portable tool. I can help solve most of the other concerns - except for this one. - Garrett

3 3

Summary of Python tracker Issues
by Python tracker Nov. 6, 2020

Nov. 6, 2020

ACTIVITY SUMMARY (2020-10-30 - 2020-11-06) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7617 ( -9) closed 46397 (+75) total 54014 (+66) Open issues with patches: 3062 Issues opened (43) ================== #37319: Deprecate using random.randrange() with non-integers https://bugs.python.org/issue37319 reopened by serhiy.storchaka #42160: unnecessary overhead in tempfile https://bugs.python.org/issue42160 reopened by vstinner #42213: Get rid of cyclic GC hack in sqlite3.Connection and sqlite3.Ca https://bugs.python.org/issue42213 opened by erlendaasland #42215: urlparse with a Windows path returns the drive name as the sch https://bugs.python.org/issue42215 opened by rangelspam #42217: compiler: merge co_code and co_lnotab https://bugs.python.org/issue42217 opened by methane #42220: Argparse: wildcards processing https://bugs.python.org/issue42220 opened by Andrew #42222: Modernize integer test/conversion in randrange() https://bugs.python.org/issue42222 opened by rhettinger #42225: Tkinter hangs or crashes when displaying astral chars https://bugs.python.org/issue42225 opened by terry.reedy #42228: Activate.ps1 clears PYTHONHOME https://bugs.python.org/issue42228 opened by mathstuf #42231: test_zipimport failure https://bugs.python.org/issue42231 opened by vstinner #42232: mmap module add Darwin specific madvise options https://bugs.python.org/issue42232 opened by devnexen #42233: GenericAlias does not support union type expressions https://bugs.python.org/issue42233 opened by kj #42234: pathlib relative_to behaviour change https://bugs.python.org/issue42234 opened by armins.bagrats #42235: [macOS] Use --enable-optimizations in build-installer.py https://bugs.python.org/issue42235 opened by ronaldoussoren #42237: test_socket.SendfileUsingSendfileTest fails on illumos https://bugs.python.org/issue42237 opened by wiedi #42238: Deprecate suspicious.py? https://bugs.python.org/issue42238 opened by mdk #42239: IDLE: Restore or keep calltip when needed https://bugs.python.org/issue42239 opened by terry.reedy #42243: Don't access the module dictionary directly https://bugs.python.org/issue42243 opened by erlendaasland #42244: TimedRotatingFileHandler doesn’t handle the switch to/from D https://bugs.python.org/issue42244 opened by Cristian Martinez de Morentin #42245: concurrent.futures.ProcessPoolExecutor freezes depending on co https://bugs.python.org/issue42245 opened by DanilZ #42246: Implement PEP 626 https://bugs.python.org/issue42246 opened by Mark.Shannon #42247: unittest hides traceback frames in chained exceptions https://bugs.python.org/issue42247 opened by dseomn #42248: Raised exception in Enum keeping user objects alive unnecessar https://bugs.python.org/issue42248 opened by efroemling #42252: Embeddable Python indicates that it uses PYTHONPATH https://bugs.python.org/issue42252 opened by teeks99 #42253: xml.dom.minidom.rst missed informations https://bugs.python.org/issue42253 opened by jedie2 #42255: webbrowser.MacOSX is unused, untested and undocumented https://bugs.python.org/issue42255 opened by ronaldoussoren #42256: BaseCookie.__parse_string() doesn't work with expires= between https://bugs.python.org/issue42256 opened by paulie4 #42257: platform.libc_ver() doesn't consider in case of executable is https://bugs.python.org/issue42257 opened by kurochan #42258: argparse: show choices once per argument https://bugs.python.org/issue42258 opened by mendelmaleh #42259: pprint: infinite recursion for saferepr() when using nested ob https://bugs.python.org/issue42259 opened by danbst #42260: [C API] Add PyInterpreterState_SetConfig(): reconfigure an int https://bugs.python.org/issue42260 opened by vstinner #42261: Windows legacy I/O mode mistakenly ignores the device encoding https://bugs.python.org/issue42261 opened by eryksun #42264: Deprecate or remove sqlite3.OptimizedUnicode https://bugs.python.org/issue42264 opened by erlendaasland #42267: Python 3.9 broken installer https://bugs.python.org/issue42267 opened by JackSkellington #42268: ./configure failing when --with-memory-sanitizer specified https://bugs.python.org/issue42268 opened by JaonHax #42269: Add ability to set __slots__ in dataclasses https://bugs.python.org/issue42269 opened by eric.smith #42270: libregrtest BrokenPipeError on OpenEmbedded builds https://bugs.python.org/issue42270 opened by threexc #42271: Remove the error and the zipfile.ZipFile.BadZipfile aliases https://bugs.python.org/issue42271 opened by PedanticHacker #42272: Warning filter message/module documentation is misleading https://bugs.python.org/issue42272 opened by kevinoid #42273: Using LazyLoader leads to AttributeError https://bugs.python.org/issue42273 opened by KevKeating #42275: Jupyter Lab Terminals not available (error was No module named https://bugs.python.org/issue42275 opened by shakir_juolay #42277: Solaris & PEP 3149: start using ABI version tagged .so files https://bugs.python.org/issue42277 opened by kulikjak #42278: Remove usage of tempfile.mktemp in stdlib https://bugs.python.org/issue42278 opened by epaine Most recent 15 issues with no replies (15) ========================================== #42278: Remove usage of tempfile.mktemp in stdlib https://bugs.python.org/issue42278 #42277: Solaris & PEP 3149: start using ABI version tagged .so files https://bugs.python.org/issue42277 #42273: Using LazyLoader leads to AttributeError https://bugs.python.org/issue42273 #42272: Warning filter message/module documentation is misleading https://bugs.python.org/issue42272 #42271: Remove the error and the zipfile.ZipFile.BadZipfile aliases https://bugs.python.org/issue42271 #42270: libregrtest BrokenPipeError on OpenEmbedded builds https://bugs.python.org/issue42270 #42269: Add ability to set __slots__ in dataclasses https://bugs.python.org/issue42269 #42264: Deprecate or remove sqlite3.OptimizedUnicode https://bugs.python.org/issue42264 #42258: argparse: show choices once per argument https://bugs.python.org/issue42258 #42257: platform.libc_ver() doesn't consider in case of executable is https://bugs.python.org/issue42257 #42255: webbrowser.MacOSX is unused, untested and undocumented https://bugs.python.org/issue42255 #42253: xml.dom.minidom.rst missed informations https://bugs.python.org/issue42253 #42248: Raised exception in Enum keeping user objects alive unnecessar https://bugs.python.org/issue42248 #42247: unittest hides traceback frames in chained exceptions https://bugs.python.org/issue42247 #42244: TimedRotatingFileHandler doesn’t handle the switch to/from D https://bugs.python.org/issue42244 Most recent 15 issues waiting for review (15) ============================================= #42277: Solaris & PEP 3149: start using ABI version tagged .so files https://bugs.python.org/issue42277 #42272: Warning filter message/module documentation is misleading https://bugs.python.org/issue42272 #42264: Deprecate or remove sqlite3.OptimizedUnicode https://bugs.python.org/issue42264 #42260: [C API] Add PyInterpreterState_SetConfig(): reconfigure an int https://bugs.python.org/issue42260 #42258: argparse: show choices once per argument https://bugs.python.org/issue42258 #42257: platform.libc_ver() doesn't consider in case of executable is https://bugs.python.org/issue42257 #42246: Implement PEP 626 https://bugs.python.org/issue42246 #42243: Don't access the module dictionary directly https://bugs.python.org/issue42243 #42239: IDLE: Restore or keep calltip when needed https://bugs.python.org/issue42239 #42237: test_socket.SendfileUsingSendfileTest fails on illumos https://bugs.python.org/issue42237 #42235: [macOS] Use --enable-optimizations in build-installer.py https://bugs.python.org/issue42235 #42233: GenericAlias does not support union type expressions https://bugs.python.org/issue42233 #42222: Modernize integer test/conversion in randrange() https://bugs.python.org/issue42222 #42217: compiler: merge co_code and co_lnotab https://bugs.python.org/issue42217 #42213: Get rid of cyclic GC hack in sqlite3.Connection and sqlite3.Ca https://bugs.python.org/issue42213 Top 10 most discussed issues (10) ================================= #42225: Tkinter hangs or crashes when displaying astral chars https://bugs.python.org/issue42225 20 msgs #42173: Drop Solaris support https://bugs.python.org/issue42173 17 msgs #42179: Clarify chaining exceptions in tutorial/errors.rst https://bugs.python.org/issue42179 10 msgs #1635741: Py_Finalize() doesn't clear all Python objects at exit https://bugs.python.org/issue1635741 10 msgs #42222: Modernize integer test/conversion in randrange() https://bugs.python.org/issue42222 8 msgs #37193: Memory leak while running TCP/UDPServer with socketserver.Thre https://bugs.python.org/issue37193 7 msgs #42195: Inconsistent __args__ between typing.Callable and collections. https://bugs.python.org/issue42195 6 msgs #42245: concurrent.futures.ProcessPoolExecutor freezes depending on co https://bugs.python.org/issue42245 6 msgs #42252: Embeddable Python indicates that it uses PYTHONPATH https://bugs.python.org/issue42252 5 msgs #42260: [C API] Add PyInterpreterState_SetConfig(): reconfigure an int https://bugs.python.org/issue42260 5 msgs Issues closed (69) ================== #8988: import + coding = failure (3.1.2/win32) https://bugs.python.org/issue8988 closed by iritkatriel #11346: Generator object should be mentioned in gc module document https://bugs.python.org/issue11346 closed by methane #12739: read stuck with multithreading and simultaneous subprocess.Pop https://bugs.python.org/issue12739 closed by iritkatriel #14379: Several traceback docs improvements https://bugs.python.org/issue14379 closed by iritkatriel #15128: inspect raises exception when frames are misleading about sour https://bugs.python.org/issue15128 closed by iritkatriel #15626: unittest.main negates -bb option and programmatic warning conf https://bugs.python.org/issue15626 closed by ncoghlan #16855: traceback module leaves off module name in last line of format https://bugs.python.org/issue16855 closed by iritkatriel #24380: Got warning when compiling _scproxy.c on Mac https://bugs.python.org/issue24380 closed by ronaldoussoren #26031: Add stat caching option to pathlib https://bugs.python.org/issue26031 closed by gvanrossum #26377: Tkinter dialogs will not close if root window not packed. https://bugs.python.org/issue26377 closed by terry.reedy #26389: Expand traceback module API to accept just an exception as an https://bugs.python.org/issue26389 closed by pablogsal #26789: logging: Trying to log during Python finalization with NameErr https://bugs.python.org/issue26789 closed by vstinner #27377: Add socket.fdtype() https://bugs.python.org/issue27377 closed by nascheme #29566: binhex() creates files with mixed line endings https://bugs.python.org/issue29566 closed by ronaldoussoren #30384: traceback.TracebackException.format shouldn't format_exc_only( https://bugs.python.org/issue30384 closed by iritkatriel #34106: Add --with-module-config=<file> to 'configure' script https://bugs.python.org/issue34106 closed by nascheme #34704: Do not access ob_type directly, introduce Py_TP https://bugs.python.org/issue34704 closed by nascheme #40511: IDLE: properly handle '(' and ')' within calls https://bugs.python.org/issue40511 closed by terry.reedy #40514: [subinterpreters] Add --experimental-isolated-subinterpreters https://bugs.python.org/issue40514 closed by vstinner #40814: Update typing module documentation based on PEP 585 https://bugs.python.org/issue40814 closed by gvanrossum #40816: Add missed AsyncContextDecorator to contextlib https://bugs.python.org/issue40816 closed by asvetlov #41435: Allow to retrieve ongoing exception handled by every threads https://bugs.python.org/issue41435 closed by serhiy.storchaka #41796: _ast module state should be made per interpreter https://bugs.python.org/issue41796 closed by vstinner #41832: PyType_FromSpec() should accept tp_doc=NULL https://bugs.python.org/issue41832 closed by vstinner #41835: Speed up dict vectorcall creation using keywords https://bugs.python.org/issue41835 closed by methane #42049: Add image/webp to list of media types in mimetypes.py https://bugs.python.org/issue42049 closed by methane #42100: Add _PyType_GetModuleByDef https://bugs.python.org/issue42100 closed by petr.viktorin #42108: HTTPSConnection hangs forever when the percentage completed of https://bugs.python.org/issue42108 closed by Tiger-222 #42126: Optimize BUILD_CONST_KEY_MAP for distinct keys https://bugs.python.org/issue42126 closed by methane #42131: [zipimport] Update zipimport to use specs https://bugs.python.org/issue42131 closed by brett.cannon #42146: subprocess.Popen() leaks cwd in case of uid/gid overflow https://bugs.python.org/issue42146 closed by gregory.p.smith #42162: The license page for Python 3.0.1 is messed up https://bugs.python.org/issue42162 closed by terry.reedy #42177: Improving KeyError exception https://bugs.python.org/issue42177 closed by terry.reedy #42196: Python Windows Installation Error 0x800705aa https://bugs.python.org/issue42196 closed by shakir_juolay #42198: Clean up docs for Union and GenericAlias https://bugs.python.org/issue42198 closed by gvanrossum #42201: Priority queue realization issue https://bugs.python.org/issue42201 closed by rhettinger #42205: Add image/webp to list of non-standard mimetypes https://bugs.python.org/issue42205 closed by methane #42207: Python 3.9 testing fails when building with clang and optimiza https://bugs.python.org/issue42207 closed by vstinner #42208: Using logging or warnings during Python finalization does cras https://bugs.python.org/issue42208 closed by vstinner #42209: Incorrect line reported in syntax error https://bugs.python.org/issue42209 closed by eric.smith #42210: float.hex discards sign from -nan https://bugs.python.org/issue42210 closed by mark.dickinson #42211: CRASH https://bugs.python.org/issue42211 closed by vstinner #42214: Parser/pegen.c:68: _PyPegen_check_barry_as_flufl: Assertion `t https://bugs.python.org/issue42214 closed by pablogsal #42216: Optimize dict.popitem() & insert use case. https://bugs.python.org/issue42216 closed by methane #42218: SystemError in compile builtin function https://bugs.python.org/issue42218 closed by lys.nikolaou #42219: Typo in comment of listobject.h https://bugs.python.org/issue42219 closed by akshayj398p #42221: Potential memory leak in resize_compact() (for unicode objects https://bugs.python.org/issue42221 closed by dralley #42223: List repetition operator gives unexpected results https://bugs.python.org/issue42223 closed by steven.daprano #42224: test_format:test_locale fails when locale does not set groupin https://bugs.python.org/issue42224 closed by lys.nikolaou #42226: imghdr.what is missing docstring, has a logic error, and is ov https://bugs.python.org/issue42226 closed by jph00 #42227: Unexpected sharing of list/set/dict between instances of the s https://bugs.python.org/issue42227 closed by steven.daprano #42229: Fix SQLite warnings on macOS https://bugs.python.org/issue42229 closed by samuelmarks #42230: Document that asyncio's wait() and as_completed() accept arbit https://bugs.python.org/issue42230 closed by asvetlov #42236: os.device_encoding() doesn't respect the UTF-8 Mode https://bugs.python.org/issue42236 closed by vstinner #42240: Add Maxheap version of a heappush into heapq module https://bugs.python.org/issue42240 closed by rhettinger #42241: Backport SQLite trace API v2 https://bugs.python.org/issue42241 closed by corona10 #42242: Backport SQLite trace API v2 https://bugs.python.org/issue42242 closed by corona10 #42249: Plistlib cannot create binary Plist file larger than 4GiB https://bugs.python.org/issue42249 closed by serhiy.storchaka #42250: test_ast leaked [23640, 23636, 23640] references https://bugs.python.org/issue42250 closed by vstinner #42251: Add threading.gettrace and threading.getprofile https://bugs.python.org/issue42251 closed by pablogsal #42254: inspect.getmembers iterator version https://bugs.python.org/issue42254 closed by signing_agreement #42262: [C API] Add Py_NewRef() function to get a new strong reference https://bugs.python.org/issue42262 closed by vstinner #42263: Removing thread reference in thread results in leaked referenc https://bugs.python.org/issue42263 closed by jaraco #42265: Remove binhex module following PEP-594 https://bugs.python.org/issue42265 closed by steven.daprano #42266: LOAD_ATTR cache does not fully replicate PyObject_GetAttr beha https://bugs.python.org/issue42266 closed by pablogsal #42274: Imaplib hangs up infinitely when performing append operation https://bugs.python.org/issue42274 closed by eric.smith #42276: Bug in adfuller test and a suggested fix https://bugs.python.org/issue42276 closed by ronaldoussoren #1633941: for line in sys.stdin: doesn't notice EOF the first time https://bugs.python.org/issue1633941 closed by iritkatriel #1643712: Emphasize buffering issues when sys.stdin is used https://bugs.python.org/issue1643712 closed by iritkatriel

1 0

Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python
by Victor Stinner Nov. 6, 2020

Nov. 6, 2020

Hi, I propose to drop the Solaris support in Python to reduce the Python maintenance burden: https://bugs.python.org/issue42173 I wrote a draft PR to show how much code could be removed (around 700 lines in 65 files): https://github.com/python/cpython/pull/23002/files In 2016, I asked if we still wanted to maintain the Solaris support in Python, because Solaris buildbots were failing for longer than 6 months and nobody was able to fix them. It was requested to find a core developer volunteer to fix Solaris issues and to set up a Solaris buildbot. https://mail.python.org/archives/list/python-dev@python.org/thread/NOT2RORS… Four years later, nothing has happened. Moreover, in 2018, Oracle laid off the Solaris development engineering staff. There are around 25 open Python bugs specific to Solaris. I see 3 options: * Current best effort support (no change): changes only happen if a core dev volunteers to review and merge a change written by a contributor. * Schedule the removal in 2 Python releases (Python 3.12) and start to announce that Solaris support is going to be removed * Remove the Solaris code right now (my proposition): Solaris code will have to be maintained outside the official Python code base, as "downstream patches" Solaris has a few specific features visible at the Python level: select.devpoll, os.stat().st_fstype and stat.S_ISDOOR(). While it's unclear to me if Oracle still actively maintains Solaris (latest release in 2018, no major update since 2018), Illumos and OpenSolaris (variants or "forks") still seem to be active. In 2019, a Solaris blog post explains that Solaris 11.4 still uses Python 2.7 but plans to migrate to Python 3, and Python 3.4 is also available. These two Python versions are no longer supported. https://blogs.oracle.com/solaris/future-of-python-on-solaris The question is if the Python project has to maintain the Solaris specific code or if this code should now be maintained outside Python. What do you think? Should we wait 5 more years? Should we expect a company will offer to maintain the Solaris support? Is there a motivated core developer to fix Solaris issue? As I wrote, nothing has happened in the last 4 years... Victor -- Night gathers, and now my watch begins. It shall not end until my death.

12 20

Contribution to github repos.
by Manak Wadhwa Nov. 6, 2020

Nov. 6, 2020

Hey Guys, I am Manak Wadhwa. I have a good hand in python language, ML Algorithms, Web Dev (HTML5, CSS3, JS, PHP, AJAX, Bootstrap, JQuery). I want to contribute to python org can someone help as which repository should i start with or work on.

2 1

[RELEASE] Python 3.10.0a2 available for testing
by Pablo Galindo Salgado Nov. 4, 2020

Nov. 4, 2020

The engines of the secret release manager machine have finished producing a new pre-release. Go get it here: https://www.python.org/downloads/release/python-3100a2/ *Major new features of the 3.10 series, compared to 3.9* Python 3.10 is still in development. This releasee, 3.10.0a2 is the second of six planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2021-05-03) and, if necessary, may be modified or deleted up until the release candidate phase (2021-10-04). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.10 are still being planned and written. Among the new major new features and changes so far: PEP 623 -- Remove wstr from Unicode PEP 604 -- Allow writing union types as X | Y PEP 612 -- Parameter Specification Variables PEP 626 -- Precise line numbers for debugging and other tools. (Hey, fellow core developer, if a feature you find important is missing from this list, let Pablo know.) The next pre-release of Python 3.10 will be 3.10.0a3, currently scheduled for 2020-12-07. *And now for something completely different * The cardinality (the number of elements) of infinite sets can be one of the most surprising results of set theory. For example, there are the same amount of even natural numbers than natural numbers (which can be even or odd). There is also the same amount of rational numbers than natural numbers. But on the other hand, there are more real numbers between 0 and 1 than natural numbers! All these sets have infinite cardinality but turn out that some of these infinities are bigger than others. These infinite cardinalities normally are represented using aleph numbers. Infinite sets are strange beasts indeed. Regards from cold London, Pablo Galindo Salgado

2 1