Python-Dev April 2018

python-dev@python.org

103 participants
90 discussions

by Benjamin Peterson

Hi all, It's that time yet again: I'm planning to release 2.7.15 release candidate 1 on April 14 and a final release two weeks later on April 28.

2 years, 8 months

Enum, Flag, __contains__, and False vs TypeError

by Ethan Furman

API question. Background: ---------- When doing checks such as --> 3 in [4, 5, 6] --> 'test' in {'test':True, 'live':False} the result is True or False. When doing checks such as --> 3 in 'hello world' --> [4, 5, 6] in {'test':True, 'live':False} the result is a TypeError. The general rule seems to be that if it is impossible for the in-question object to be in the container object then a TypeError is raised, otherwise True or False is returned. Question 1: ---------- (A) A standard Enum class is a container of Enum members. It cannot hold anything else. However, it has been returning False both in cases where the in-question object was an Enum of a different class (a Fruit in a Color, for example) and when the in-question object was not even an Enum ('apple' in Fruit, for example). (B) The waters get even more muddied when Fruit has a str mixin, so `Fruit.APPLE == 'apple' is True` -- in that case, should `'orange' in Fruit` return True, False, or raise TypeError? Question 2: ---------- (A) The new Flag type allows `in` tests on the members themselves; so, for example: --> SomeFlag.ONE in SomeFlag.One|SomeFlag.TWO True The question, of course, is what to do when a non-Flag member is tested for: --> 'apple' in SomeFlag.ONE # False or TypeError? --> 2 in SomeFlag.TWO # True or TypeError? (B) And, of course, the same muddier question arises with IntFlag, where SomeFlag.TWO == 2 is True. My thoughts: ----------- For question 1A (pure Enum): I'm thinking a TypeError should be raised when the in-question object is not an Enum member of any kind -- it simply is not possible for that object to ever be in an Enum, and is surely a bug. For question 1B (mixed Enum): if 1A is TypeError, then 1B should also be TypeError at least for non-mixin in-question types (so checking for 1 in StrEnum would be a TypeError), but I'm torn between TypeError and True/False for cases where the in-question type matches the mixin type ('apple' in StrEnum).... On the one hand, even though an Enum member might be equal to some other type, that other type will not have the Enum attributes, etc, and a True answer would lead one to believe you could access `.name` and `.value`, etc., while a False answer would lead one to believe there was no match even though equality tests pass; on the other hand, how strong is the "container" aspect of a mixed Enum? How often is the test `'apple' in Fruit` meant to discover if you have a Fruit member vs whether you have something that could be a Fruit member? Also, how important is it to be consistent with IntFlag, which I definitely think should return True/False for int checks? For question 2A (pure Flag): I'm comfortable sticking with a TypeError (assuming we switch to TypeError for 1A). For question 2B (int Flag): I think a TypeError if the in-question object is not an int is appropriate (assuming TypeError for 1A and 2A), but if it is an int, True/False seems the better path. My reasoning being that Flag and IntFlag are more similar to sets than lists, and IntFlag is specifically meant to work with ints, and a test of `2 in some_int_flags` is more concerned with a flag being set than with .name or .value attributes that may or may not exist on the in-question object. Any and all thoughts appreciated. -- ~Ethan~

2 years, 8 months

Python Bug Tracker

by Agnostic Dev

Apologies if this is not the correct place to report this, but I am seeing outages on bugs.python.org. I am in the Chicago area so maybe this is a regional issue or possibly the site is being update, but I wanted to report it. Matt Eaton (Agnosticdev)

2 years, 8 months

Are undocumented functions part of the stable ABI?

by Jeroen Demeyer

Hello, I have a question about PEP 384: can undocumented functions ever be considered as part of the stable ABI? With undocumented, I mean not appearing in the "Python/C API Reference Manual". Whatever the answer to this question is, it would be good to make it explicit in PEP 384. I am in particular asking about functions starting with PyCFunction_ appearing in Include/methodobject.h Thanks, Jeroen.

2 years, 8 months

Hi, I am amar :)

by amar

Hi, all. Quick joke, Do you know why all functional programmers are anarchists? Because they want to get rid of the state! :D I know there are a lot more important issues than this, but i feel this is important too. I wish some people could take a look at Python/Cpython pull request #6343[1] and the reopened PR #6362[2]. Little background here, I am a science student working on GIS(Geospatial Information Systems) Web Processing Service as a hobby project. I am a human too, i like jokes. But not at the expense of truth. I hope i can make more meaningful contributions in the future! [1]https://github.com/python/cpython/pull/6343 [2] https://github.com/python/cpython/pull/6362#issuecomment-378174084

2 years, 8 months

by Ethan Furman

This behavior was recently brought to my attention [1]: --> 1 in 'hello' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'in <string>' requires string as left operand, not int However, in any other collection (set, dict, list, tuple, etc), the answer would be False. Does anyone remember the reason why an exception is raised in the string instance instead of returning False? -- ~Ethan~ [1] https://bugs.python.org/msg314900

2 years, 8 months

building extensions as builtins is broken in 3.7

by Pablo Galindo Salgado

Hi, I am working on the release blocker https://bugs.python.org/issue32232. I tried to apply the patch proposed by Matthias Klose and I found that it works on Unix but it fails to build on Windows (probably because circular imports). I tried to add some tests but after some work on the problem and some comments by Ned Deily I am starting to think that the test for this is basically compiling the whole interpreter with static linking of the built-ins and run the whole test suite. This has to be done as a new build target on Travis. I did some experiments with this following: https://wiki.python.org/moin/BuildStatically But I run into multiple linking errors. The Travis build hangs forever and then fails in the best case. Here is an example of what I am talking: https://github.com/pablogsal/cpython/pull/1 In this PR you can see the patch and the static linking configured as per above and the Travis output. I am happy to work on this as long as someone can tell me what is the appropriate course of action. Thank you very much for your time!

2 years, 8 months

IDLE colorizer

by MRAB

A thread on python-ideas is talking about the prefixes of string literals, and the regex used in IDLE. Line 25 of Lib\idlelib\colorizer.py is: stringprefix = r"(?i:\br|u|f|fr|rf|b|br|rb)?" which looks slightly wrong to me. The \b will apply only to the first choice. Shouldn't it be more like: stringprefix = r"(?:\b(?i:r|u|f|fr|rf|b|br|rb))?" ?

2 years, 8 months

[Crosspost from python-committers] Announcing: signups are open for the 2018 Python Language Summit

by Larry Hastings

It’s that time again: time to start thinking about the Python Language Summit! The 2018 summit will be held on Wednesday, May 9, from 10am to 4pm, at the Huntington Convention Center in Cleveland, Ohio, USA. Your befezzled and befuddled hosts Barry and Larry will once more be behind the big desk in front. The summit’s purpose is to disseminate information and spark conversation among core Python developers. It’s our yearly opportunity to get together for an in-person discussion, to review interesting developments of the previous year and hash out where we’re going next. And we have lots to talk about! 3.7 is in beta, and we've all collectively started work on 3.8 too. As before, we’re using Google Forms to collect signups. Signups are open now; the deadline to sign up is Wednesday April 18th, 2018 (AoE). Please do us a favor and sign up sooner rather than later. The signup form is simpler this year--I bet most people can be done in less than two minutes! One difference from last year: there are now *two* forms. The first form is for signing up to attend (the "Request For Invitation" form), and the second form is for proposing a talk. Please note: if you want to present, you still need to fill out the Request For Invitation form too. (Yes, it's more complicated this way, sorry. But having both on the same form kind of enforced a one-to-one mapping, and it's really a many-to-many mapping: one person might propose multiple talks, and one talk might have multiple presenters. Overall this should be less complicated.) You can find links to *both* forms on the official Python Language Summit 2018 page: https://us.pycon.org/2018/events/language-summit/ A few notes: * There will be lightning talks! Signups will only be available during the Language Summit itself. * You don’t need to be registered for PyCon in order to attend the summit! * We’ll have badge ribbons for Language Summit participants, which we’ll hand out at the summit room in the morning. * We're inviting Jake Edge from Linux Weekly News to attend the summit and provide press coverage again. Jake’s done a phenomenal job of covering the last few summits, providing valuable information not just for summit attendees, but also for the Python community at large. Jake’s coverage goes a long way toward demystifying the summit, while remaining respectful of confidential information that’s deemed “off the record” ahead of time by participants. One big final note (please read this!): When using Google Forms, you /can/ edit your responses later! When you fill out the form and hit Submit, the submission complete page (the one that says "Thanks for playing!") will have a link on it labeled "Edit your response". BOOKMARK THIS LINK! You can use this link at /any time/ to edit your response, up to the point that signups close on April 18th. Keep in mind, you'll need to bookmark each response independently: once for signing up to attend ("Request For Invitation"), and once for each talk proposal you submit. Again, /please/ be sure to save this bookmark yourself--we don't know how to find the link for you later if you don't save it. We hope to see you at the summit! [BL]arry

2 years, 8 months

How can we use 48bit pointer safely?

by INADA Naoki

Hi, As far as I know, most amd64 and arm64 systems use only 48bit address spaces. (except [1]) [1] https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging… It means there are some chance to compact some data structures. I point two examples below. My question is; can we use 48bit pointer safely? It depends on CPU architecture & OS memory map. Maybe, configure option which is available on only (amd64, amd64) * (Linux, Windows, macOS)? # Possible optimizations by 48bit pointer ## PyASCIIObject [snip] unsigned int ready:1; /* Padding to ensure that PyUnicode_DATA() is always aligned to 4 bytes (see issue #19537 on m68k). */ unsigned int :24; } state; wchar_t *wstr; /* wchar_t representation (null-terminated) */ } PyASCIIObject; Currently, state is 8bit + 24bit padding. I think we can pack state and wstr in 64bit. ## PyDictKeyEntry typedef struct { /* Cached hash code of me_key. */ Py_hash_t me_hash; PyObject *me_key; PyObject *me_value; /* This field is only meaningful for combined tables */ } PyDictKeyEntry; There are chance to compact it: Use only 32bit for hash and 48bit*2 for key and value. CompactEntry may be 16byte instead of 24byte. Regards, -- INADA Naoki <songofacandy(a)gmail.com>

2 years, 8 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev April 2018