Hello,
There's a simple function that I use many times, and I think may be a good
fit to be added to itertools. A function that gets an iterator, and if it
has exactly one element returns it, and otherwise raises an exception. This
is very useful for cases where I do some sort of query that I expect to get
exactly one result, and I want an exception to be raised if I'm wrong. For
example:
jack = one(p for p in people if p.id == '1234')
sqlalchemy already has such a function for queries:
https://docs.sqlalchemy.org/en/13/orm/query.html#sqlalchemy.orm.query.Query…
more-itertools has this exact function:
https://more-itertools.readthedocs.io/en/latest/api.html#more_itertools.one
Here is a simple implementation:
def one(iterable):
it = iter(iterable)
try:
first = next(it)
except StopIteration:
raise ValueError("Iterator is empty")
try:
second = next(it)
except StopIteration:
return first
else:
raise ValueError("Iterator has more than one item")
I brought this up on python-dev, but it should be discussed here.
Here is the discussion:
https://mail.python.org/archives/list/python-dev@python.org/thread/D52MPKLI…
Brett Cannon said that this idea has been brought up at least twice before.
I found:
https://mail.python.org/archives/list/python-ideas@python.org/thread/FTJ6JR…https://mail.python.org/archives/list/python-ideas@python.org/thread/REYDJF…
The first thread hasn't reached any operative conclusion. The second thread
was very long, and seemed to focus mostly on another function, first(),
that doesn't check if there is more than one item. Joao S. O Bueno said
that it passed "general approval". I think that perhaps a new discussion,
focused just on one (no pun intended) function in the itertools module may
reach a conclusion.
It was suggested that instead of an additional function, one can use
iterator unpacking:
jack, = (p for p in people if p.id == '1234')
or
[jack] = (p for p in people if p.id == '1234')
I still think that having a one() function would be useful, since:
1. I think it spells the intention more clearly. It is not symbols that you
need to understand their meaning in order to understand that I expect the
iterable to have exactly one item, it's spelled in code.
2. The exception would be easier to understand, since errors in tuple
unpacking usually mean something else.
3. The one() function allows you to use the result inside an expression
without assigning it to a variable. Therefore, I think it encourages
writing better code. It's very easy to write:
print([p for p in people if p.id == '1234][0])
(which has the problem of not verifying the assumption that there's no more
than one result), and I find it easier to replace _[0] with one(_) than to
be required to name a new variable, and instead of having an operation on
the iterable, change the way I'm assigning to it.
WDYT?
Cheers,
Noam
There's been a discussion of the "for ... else ..." construction in Python.
Here's a suggestion as to how we might improve matters, and perhaps
usefully extend the language. I hope it might benefit some, without harming
anyone else.
Aside: I've not read the whole of the previous discussion, and it may be
that some or all of what I say has already been expressed there. So
apologies for any missing credits to others. The errors, I'm responsible
for.
Here's what happens at present.
for i in items:
LOOP_BODY
else:
print('exit via StopIteration')
I find the following clearer (where 'if break' is a new language 'compound
keyword').
for i in items:
LOOP_BODY
if break:
pass
else:
print('exit via StopIteration')
This would now allow us to write
for i in items:
LOOP_BODY
if break:
print('exit via break')
else:
print('exit via StopIteration')
Sometimes a loop has multiple break commands, which have different
purposes. So a further extension might be
for i in items:
LOOP_BODY
if break left:
print('exit via break left')
elif break right:
print('exit via break right')
elif break:
print('exit via some other break')
else:
print('exit via StopIteration')
To allow this to work, we extend the language to allow commands such as
break left
break right
as well as the usual
break
Here the identifiers 'left' and 'right' look like variable names, but in
fact they are labels. The compiler can, and I think should, produce a
hard-coded jump from command
break right
to the code block under
elif break right:
This is the basic idea, keeping the syntax close to Python as it now is
(but of course adding to the semantics). Some programmers, and I think I'm
one, might want a clearer distinction between
for i in items:
LOOP_BODY
if break:
do_something
and
for i in items:
LOOP_BODY
if broke:
do_something
For this reason I tentatively suggest instead
for i in items:
LOOP_BODY
case:
break left:
print('exit via break left')
break right:
print('exit via break right')
break:
print('exit via some other break')
else:
print('exit via StopIteration')
Some people have asked a built-in means to detect, at the end of the
iteration, whether theitems was empty to begin with. The syntax could
easily provide this, for example via
case:
zero:
print('no items to process')
However, if we adopt this perhaps we'd also like to retain the simpler for
... if break ... else ... construct.
I hope this helps.
--
Jonathan
Hi All,
Apologies if this has already been discussed to death.
Python 3 allows Unicode characters in strings and identifiers but the actual quotation marks are only accepted in plain ASCII, i.e. the following all successfully initialise strings:
```
S1 = "Double Quoted" # Opened and closed with chr(34)0x22
S2 = 'Single Quoted' # Opened and closed with chr(39)0x27
```
But the following all result in an error - "SyntaxError: invalid character in identifier":
```
S1 = "Double Quoted" # Opened with \u201c and closed with \u201d
S2 = 'Single Quoted' # Opened with \u2018 and closed with \u2019
```
To the experienced eye, and depending on the character font used, it is "obvious" what the problem is! The wrong quotation marks were used. The big problem, especially for beginners, is that the same keys were typed, just in the "wrong" editor or even the wrong editor mode or context I have found that in Outlook if the font is FixSys or I am replying to a plain text email it is fine but otherwise it is "helpful" - unfortunately, especially on Windows, "wrong" editors abound and include, but are not limited to, MS-Outlook, MS-Word, some online editing environments such as Quora.
On top of that is the helpful substitution of a m-hyphen for minus when you press space a word later so:
A = 3 - 2 # With a space syntax error due to \u2013
A = 3 - 2 # No Space or CR after I last typed it is OK as 0x2d
Use cases that catch people out:
1. Sending a code snipped by email using Outlook
2. User manuals written in MS-Word - (many peoples work environment)
3. Articles published on Quora - people expect to be able to copy and paste the code for some reason.
I am sure that many us have encountered these issues or similar.
What can be done?
1. Persuade Microsoft, and others, to stop being so helpful by default - good luck with that!
2. Tell all users that they need to use a "proper" editor or IDE - This seems like adding an additional barrier to new & casual users.
3. Better yet tell them to use a "proper" OS like .... - At the very least many of us have to use Windows at work.
4. Start accepting hyphens as minus & Unicode quotation marks - this would be the ideal answer for pasted code but has a lot of possible things to iron out such as do we require that the quotes match and are in the typographically correct order. It is also quite a big & complex change to the python interpreter.
5. Normalise the input to the python interpreter (at least for these characters and possibly a few others) so that entering or reading from a file S1 = "Double Quoted" becomes S1 = "Double Quoted", etc. - this should be a easier change to the interpreter but, from a purist point of view, could be said to make us as bad as the others because we are not honouring what the user entered.
6. Change the error message "SyntaxError: invalid character in identifier" to include which character and it's Unicode value so that it becomes "SyntaxError: invalid character 0x201c " in identifier" - this is almost certainly the easiest change and fits well with explicit is better than implicit but still leaves it to the user to correct the erroneous input (which could be argued is both good and bad).
I would like to suggest that an incremental approach might be the best - clarifying the existing error message being the thing that should not break anything and either substituting for problem characters or processing them "properly" as a later enhancement.
Steve Barnes
Hi Rob
You wrote:
So: You're asking that the bytecode generated for the for-loop depends
> on something that happens (or not) after the end of the for-loop body
> (which could be arbitrarily long).
>
> I speak from ignorance, but I suspect that even with the new parser,
> which I am reliably informed can make the tea and implement world peace,
> that would be asking a lot.
>
I'm also speaking from ignorance. However, here I'm the optimist. Ignorance
is bliss. You're the pessimist. The devil is in the details.
Until we have knowledge and wisdom on this, I think we need both points of
view. So I'm grateful for your
https://en.wikipedia.org/wiki/Grain_of_salt (American
English, pinch of salt in British English). I hope it makes my dish taste
better!
--
Jonathan
Date: Fri, 26 Jun 2020 18:47:44 +0200
From: Hans Ginzel <hans(a)matfyz.cz>
To: Hans Ginzel <hans(a)artax.karlin.mff.cuni.cz>
Subject: Access (ordered) dict by index; insert slice
Hello,
thank you for making dict ordered.
Is it planned to access key,value pair(s) by index? See https://stackoverflow.com/a/44687752/2556118 for example. Both for reading and (re)writing?
Is it planned to insert pair(s) on exact index? Or generally to slice? See splice() in Perl, https://perldoc.perl.org/functions/splice.html.
Use case: Represent database table metadata (columns). It is useful as to access columns both by name and by index as to insert column on specific position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or table storage size optimisation by aligning).
Thank you in advance,
Hans
PS1: Named tuples cannot be used, are immutable.
PS2: See https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash
Hello!
I'm not sure I'm addressing the right audience here, so please direct me
to the appropriate channel if that's the case...
My name is Andras Tantos and I'm working on a Python library desscribing
HW designs. I came across this problem of __getitem__ and co. not
supporting kwargs. Apparently this extension was proposed and rejected
as PEP 472.
Apart from my use-case, which is arguably a corner-case and not worth
modifying the language for, I believe there are two important use-cases
that are worth considering with the latest improvements in the language:
1. With the recent type-hint support, the feature could be made way more
descriptive if this PEP got implemented.
For example, instead of doing the following:
def func(in: Dict[str, int])
one could write:
def func(in: Dict[key=str, value=int])
2. It would also make 'generic classes' much cleaner to implement,
similar to the way type-hints look. Consider the following code:
class_Generic(object):
Specializations = []
@classmethod
def__getitem__(cls, *args):
name = f"Generic_{len(cls.Specializations)}"
Specialized = type(name, (cls,), {"specials": tuple(args)})
cls.Specializations.append(Specialized)
returnSpecialized
def__init__(self, value= None):
self.value = value
def__str__(self):
ifhasattr(self, "specials"):
return(f"[{type(self)}- "+ ",".join(str(special) forspecial
inself.specials) + f"] - {self.value}")
else:
return(f"[{type(self)}- GENERIC"+ f"] - {self.value}")
Generic = _Generic()
#g = Generic() - fails because of no specialization is given
s1 = Generic[12]()
s2 = Generic[42]("Hi!")
print(s1)
print(s2)
Running this simple example results in:
python3 -i python_test.py
[<class '__main__.Generic_0'> - 12] - None
[<class '__main__.Generic_1'> - 42] - Hi!
You can see how the specialized parameters got passed as well as the
ones to '__init__'. Obviously, in real code the idea would be to
filter generic parameters and set up 'Specialized' with the right
set of methods and arguments.
Now, without kwargs support for __getitem__, it's impossible to pass
named arguments to the specialization list, which greatly limits the
usability of this notation.
I don't know how convincing these arguments and use-cases are for you,
but could you advise me about how to start the 'ball rolling' to drum-up
support for re-activating this PEP?
Thanks again,
Andras Tantos
Hey all,
What are thoughts about implementing an object-compare function in the
unittest package? (Compare two objects recursively, attribute by
attribute.) This seems like a common use case in many testing scenarios,
and there are many 3rd party solutions solving the same problem. (Maybe we
can promote standardization by implementing it in the standard library?)
Apologies ahead of time if this idea has already been proposed; I was not
able to find similar posts in the archive.
Best,
-Henry
On Wed, 22 Jul 2020 at 15:35, Antoine Pitrou <solipsis(a)pitrou.net> wrote:
> The deltas also look small for a micro-benchmark. I certainly don't
> think this is a sufficient reason to add a new datatype to Python.
>
I think some of the optimizations can be experimented with dict itself.
Deltas seem to be small, because I divide them by the number of timeit
runs. I think that a 30-45% gain in constructor speed is not something
small. The benchmarks in question have the Name that starts with
"constructor".
PS: sorry for double mail, I sent this message to only you by mistake.
On Wed, 22 Jul 2020 at 18:26, Guido van Rossum <guido(a)python.org> wrote:
> Did you study PEP 416 (frozendict) and PEP 603 (frozenmap)?
>
Yes. About frozenmap, at the very start I added to the benchmarks also
immutables.Map, but I removed it when I realized that it was slower than
frozendict in every bench. Maybe this is because immutables.Map is a C
extension and not a builtin type.
About PEP 416, yes, I tried to follow it. Indeed hash is calculated using
the strategy described in the PEP. I also take a look to frozenset and
tuple code.
Frankly I must admit that the rejection of PEP 416 was a good idea. Indeed
I started to implement an immutable dict only for a symmetry reason, and
because I am somewhat fascinated by functional programming and immutables,
without a rational reason.
I suppose I would have given up and admitted that a frozendict is quite
useless in Python, if I did not see that the constructor speed can be
faster.
I'm not sure 100% of the result. This is why I'm suggesting to try to
implement the speed optimizations to the constructor of dict first:
1. the optimizations could be not safe. Indeed recently I got a segfault
that I have to investigate
2. maybe dict can be really optimized further. After that, the difference
between dict and frozendict performance could be minimal
That said, maybe there are four good use cases for a frozendict:
1. they could be used for __annotations__ of function objects, and similar
cases
2. they could be used to implement "immutable" modules or classes
3. frozendict can be easily cached, like tuples.
4. as I said, as an alternative to MappingProxyType, since it's very slow
and it's used also in the C code of CPython and in the Python stdlib. This
maybe is not useful because:
a. the speed of MappingProxyType can be improved
b. MappingProxyType can't be replaced because you *really* want and
need a proxy
Hello,
The idea here is to use the same operator already used to type-hint the
return of functions `->` to define the return of a Callable.
* Current syntax:
Callable[[ArgumentList], ReturnType]
eg.
def x(method: Callable[[int, dict], None]) -> None:
pass
* Proposed syntax:
Callable[ArgumentList] -> ReturnType
eg.
def x(method: Callable[int, dict] -> None) -> None:
pass
Do you think this is more intuitive? Is it viable?
Kind regards,
Thiago
