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~
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)
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.
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
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
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!
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))?"
?
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
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>