Matt Gilson wrote:
I think that
it was mentioned that it might be possible for a user to _register_ a
callable that would then be used when this syntax was envoked -- But
having a global setting like that leads to contention.
I think for that to fly it would have to be a per-module
thing. The
Random832 wrote:
For me, it's the fact that:
[[a for a in b] for b in ['uvw', 'xyz']] == [['u', 'v', 'w'], ['x', 'y',
'z']]
which makes me want to write:
[a for a in b for b in ['uvw', 'xyz']]
You're not alone! Lately I've been becoming convinced that
this is the way we should have done it righ
Steven D'Aprano wrote:
Your example shows the proposed:
[*(language, text) for language, text in fulltext_tuples if language ==
'english']
which can be written as:
[x for language, text in fulltext_tuples for x in (language, text) if
language == 'english']
which is only ten charact
David Mertz wrote:
>>> three_inf = (count(), count(), count())
>>> comp = (x for x in flatten(three_inf))
>>> next(comp)
0
>>> next(comp)
1
It's hard to see how that won't blow up under the new syntax (i.e.
generally for all infinite sequences).
It won't blow up, because * in a generator
Steven D'Aprano wrote:
What I don't believe is:
(1) that the majority of Python programmers (or even a large minority)
regularly and consistently think of comprehensions as syntactic sugar
for a completely unrolled list display; rather, I expect that they
usually think of them as sugar for a
Mikhail V wrote:
Those things cannot be easiliy measured, if at all,
If you can't measure something, you can't be sure
it exists at all.
> In my case I am looking at what I've achieved
during years of my work on it and indeed there some
interesting things there.
Have you *measured* anything
Steven D'Aprano wrote:
This thread is a huge, multi-day proof that people do not agree that
this is a "reasonable" interpretation.
So far I've seen one very vocal person who disgrees, and
maybe one other who isn't sure.
This proposal only makes even a little
bit of sense if you imagine list
Mikhail V wrote:
Also I can only hard imagine that special purpose
of some language can ignore readability,
Readability is not something absolute that stands on its
own. It depends a great deal on what is being expressed.
even if it is assembler or whatever,
it can be made readable without mu
Steven D'Aprano wrote:
Are you now supporting my argument that starring the list comprehension
expression isn't meaningful?
The context it's in (a form of list display) has a clear
meaning for a comma-separated list of values, so there
is a reasonable interpretation that it *could* be given.
Martti Kühne wrote:
You brush over the fact that *t is not limited to a replacement by a
comma-separated sequence of items from t, but *t is actually a
replacement by that comma-separated sequence of items from t INTO an
external context.
Indeed. In situations where there isn't any context for
Steven D'Aprano wrote:
t = (1, 2, 3)
iterable = [t]
[*t for t in iterable]
If you do the same manual replacement, you get:
[1, 2, 3 for t in iterable]
Um, no, you need to also *remove the for loop*, otherwise
you get complete nonsense, whether * is used or not.
Let's try a l
Steven D'Aprano wrote:
That's because some sequence of characters
is being wrongly interpreted as an emoticon by the client software.
The only thing wrong here is that the client software
is trying to interpret the emoticons.
Emoticons are for *humans* to interpret, not software.
Subtlety and
Mikhail V wrote:
if "\u1230" <= c <= "\u123f":
and:
o = ord (c)
if 100 <= o <= 150:
Note that, if need be, you could also write that as
if 0x64 <= o <= 0x96:
So yours is a valid code but for me its freaky,
and surely I stick to the second variant.
The thing is, where did you get those
Steven D'Aprano wrote:
So why would yield *t give us this?
yield a; yield b; yield c
By analogy with the function call syntax, it should mean:
yield (a, b, c)
This is a false analogy, because yield is not a function.
However, consider the following spelling:
l = [from f(t) fo
אלעזר wrote:
I think it is an unfortunate accident of syntax, the use of "yield from
foo()" instead of "yield *foo()".
I think that was actually discussed back when yield-from
was being thrashed out, but as far as I remember we didn't
have * in list displays then, so the argument for it was
wea
Paul Moore wrote:
3. *fn(x) isn't an expression, and yet it *looks* like it should be ...
> To me, that suggests it would be hard to teach.
It's not an expression in any of the other places it's
used, either. Is it hard to to teach in those cases as
well?
--
Greg
__
Paul Moore wrote:
PS I can counter a suggestion of using *f(t) rather than from f(t) in
the above, by saying that it adds yet another meaning to the already
heavily overloaded * symbol.
We've *already* given it that meaning in non-comprehension
list displays, though, so we're not really adding
Paul Moore wrote:
Where in [fn(x) for x in lst if cond] is the *
allowed? fn(*x)? *fn(x)?
Obviously you're *allowed* to put fn(*x), because that's
already a valid function call, but the only *new* place
we're talking about, and proposing new semantics for, is
in front of the expression represen
Paul Moore wrote:
please can you explain how to modify that translation rule to
incorporate the suggested syntax?
It's quite simple: when there's a '*', replace 'append'
with 'extend':
[*fn(x) for x in lst if cond]
expands to
result = []
for x in lst:
if cond:
result.extend(fn(x))
Sjoerd Job Postmus wrote:
I think the suggested spelling (`*`) is the confusing part. If it were
to be spelled `from ` instead, it would be less confusing.
Are you suggesting this spelling just for generator
comprehensions, or for list comprehensions as well?
What about dict comprehensions?
--
Neil Girdhar wrote:
At the end of this discussion it might be good to get a tally of how
many people think the proposal is reasonable and logical.
I think it's reasonable and logical.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
http
Random832 wrote:
[*map(math.exp, t) for t in [(1, 2), (3, 4)]]
[*(math.exp(x) for x in t) for t in [(1, 2), (3, 4)]]
Or more simply,
[math.exp(x) for t in [(1, 2), (3, 4)] for x in t]
I think this brings out an important point. While it
would be nice to allow * unpacking in comprehensions
David Mertz wrote:
it would always be "Here's a Python wart to look out
for if you see it in other code... you should not ever use it yourself."
Do you currently tell them the same thing about the use
of * in a list display?
--
Greg
___
Python-ideas
Steven D'Aprano wrote:
py> def gen():
... for t in [(1, 'a'), (2, 'b'), (3, 'c')]:
... yield *t
File "", line 3
yield *t
^
SyntaxError: invalid syntax
Even if it was allowed, what would it mean? It could only mean "unpack
the sequence t, and collect the values i
Mikhail V wrote:
But: you claim to see bit patterns in hex numbers? Then I bet you will
see them much better if you take binary notation (2 symbols) or quaternary
notation (4 symbols), I guarantee.
Nope. The meaning of 0xC001 is much clearer to me than
1101, because I'd have to coun
Mikhail V wrote:
Eee how would I find if the character lies in certain range?
>>> c = "\u1235"
>>> if "\u1230" <= c <= "\u123f":
... print("Boo!")
...
Boo!
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman
Mikhail V wrote:
Ok, but if I write a string filtering in Python for example then
obviously I use decimal everywhere to compare index ranges, etc.
so what is the use for me of that label? Just redundant
conversions back and forth.
I'm not sure what you mean by that. If by "index ranges"
you're
Mikhail V wrote:
I am not against base-16 itself in the first place,
but rather against the character set which is simply visually
inconsistent and not readable.
Now you're talking about inventing new characters, or
at least new glyphs for existing ones, and persuading
everyone to use them. Tha
Mikhail V wrote:
Did you see much code written with hex literals?
From /usr/include/sys/fcntl.h:
/*
* File status flags: these are used by open(2), fcntl(2).
* They are also used (indirectly) in the kernel file structure f_flags,
* which is a superset of the open/fcntl flags. Open flags an
Mikhail V wrote:
Consider unicode table as an array with glyphs.
You mean like this one?
http://unicode-table.com/en/
Unless I've miscounted, that one has the characters
arranged in rows of 16, so it would be *harder* to
look up a decimal index in it.
--
Greg
Mikhail V wrote:
And decimal is objectively way more readable than hex standard character set,
regardless of how strong your habits are.
That depends on what you're trying to read from it. I can
look at a hex number and instantly get a mental picture
of the bit pattern it represents. I can't do
Paul Moore wrote:
What I'm *not* quite clear on is why Python 3's change to reject
comparisons between unrelated types makes this optimisation possible.
I think the idea was that it's likely to be *useful* a higher
proportion of the time, because Python 3 programmers have to
be careful that the
Elliot Gorokhovsky wrote:
I will be able to rule that out
when I implement this as a patch instead of an extension module and test
my own build.
You could test it against a locally built Python without
having to go that far.
--
Greg
___
Python-ideas
Elliot Gorokhovsky wrote:
if the list is all
floats, just copy all the floats into a seperate array, use the standard
library quicksort, and then construct a sorted PyObject* array.
My question would be whether sorting list of just floats
(or where the keys are just floats) is common enough to
Yury Selivanov wrote:
To start, no matter how exactly you want to approach this, it would
require us to do a *complete rewrite* of CPython internals. This is so
complex that we wouldn't be able to even estimate how long it would take
us.
You could ask the author of Stackless -- he did exactl
Nick Coghlan wrote:
When a language usage pattern is supported for that long, but folks
still don't grok how it might benefit them, you have a UX problem, and
one of the ways to address it is to take the existing pattern and give
it dedicated syntax, which is exactly what PEP 492 did.
However,
Nick Coghlan wrote:
The pay-off that CPython gets from this is that we get to delegate
99.9% of the work for supporting different CPU architectures to C
compiler developers, and we get a lot of capabilities "for free" when
it comes to stack management.
One of the main benefits is that it's very
Nathaniel Smith wrote:
The core distinguishing feature between
async/await and gevent is the visibility of suspension points, so it
might as well be the case that async/await is designed for exactly
those people who want visible suspension points.
They're not quite independent axes, though. Gev
Nathaniel Smith wrote:
It wasn't that we created these keywords to solve some
implementation problem and then inflicted them on users.
I disagree -- looking at the history of how we
ended up with async/await, it looks to me like
this is exactly what *did* happen.
First we had generators. Then
Paul Moore wrote:
I don't know *that* much about Erlang, but Python's model is that of a
single shared address space with (potentially multiple) threads of
code running, having access to that address space.
I don't know much about Erlang either, but from what I
gather, it's a functional languag
Paul Moore wrote:
It's also worth noting that the obvious response "but I don't want to
have to run a preprocessor against my code" is another indication that
this isn't solving a significant enough problem to warrant a language
change.
There are valid reasons for disliking preprocessors other
Yann Kaiser wrote:
The way I see it, the great thing about async/await as opposed to
threading is that it is explicit about when execution will "take a
break" from your function or resume into it.
Another thing is that async/await tasks are very lightweight
compared to OS threads, so you can a
Erik Bray wrote:
Then following my own logic it
would be desirable to also allow the nested for loop syntax of list
comprehensions outside them as well.
The only use for such a syntax would be to put
an inadvisable amount of stuff on one line.
When describing a procedural series of steps,
the
David Mertz wrote:
I guess once in a while we'll see e.g.
`Sequence[CustomThing]`, but it will be uncommon for that typing
involving `CutomThing` to be within CustomThing itself
I think that depends on what kind of software you're
writing. Anything involving any kind of trees or graphs
will h
אלעזר wrote:
it feels like a
placeholder for this meaning would be better. E.g.:
class A:
def __add__(self, other: CLS) -> CLS: ...
That's fine for a class that refers to itself, but
what about classes that refer to each other? This
only addresses a small part of the probl
Terry Reedy wrote:
In the default
mode with user code executed in a separate no-window process, there is
currently no way for the child process to know the current size of
Shell's tk text window in the parent process.
On unix it should be possible to let the child know if it's
connected throu
אלעזר wrote:
@partial(partial, partial(partial, partial))
def add(a, b, c): return a + b + c
For large numbers of arguments, it's much clearer if you
write it this way:
>>> from functools import partial as badger, partial as mushroom
>>> @badger(badger, badger(badger, badger(badger, mushroom))
Arek Bulski wrote:
def __glob_eq__(a,b):
if not a == b:
raise FoundInequalityError(a,b)
return True
assert obj1 == obj2 #<-- using eq above
How would you ensure that this overriding only applied in
the places you want it? You don't want to change the meaning
of == in the code under
Chris Angelico wrote:
Yes. You could tweak that by looking at cls.__module__ and grab it
from sys.modules, but I kept the example simple. However, I would NOT
use the standard name lookup mechanism.
Most classes in builtins won't let you monkeypatch them
anyway, so I'm not sure it's worth the
Chris Angelico wrote:
It's a little bit magical, in that it looks up the original class
using globals();
The way you've written it, monkeypatch() will only work
if you call it from the module it's defined in.
--
Greg
___
Python-ideas mailing list
Py
Pim Schellart wrote:
This PEP proposes the introduction of new syntax to create a community standard,
readable way to continue a definition for classes which are already defined.
-1. Monkeyatching is something that should be disccouraged
rather than encouraged, since it makes code very hard to
Sven R. Kunze wrote:
I already noted that
Python can detect when to make the switch without a marker. And you fail
to explain where the issue with this point of view is.
The issue is that Guido wants to see where all the
potential suspension points are.
--
Greg
___
Stephen J. Turnbull wrote:
But "forcing" won't happen. Just ignore the warning.
If I'm using a static type checker at all, I'm going
to be treating its warnings as errors and doing something
to make them go away. So effectively it would force me
to deal explicitly with every instance of int-fl
On 2016-08-31 17:19, Guido van Rossum wrote:
I guess we need to debate what it should do if the value is
way out of range of the SI scale system -- what's it going to do when
I pass it 1e50? I propose that it should fall back to 'g' style then,
but use "engineering" style where exponents are alw
Guido van Rossum wrote:
Would this be enforced in the grammar or by the lexer? Since you say
you expect the indentation to be enforced, that suggests it would be
done by the grammar,
I think it could be done by having the lexer enter a mode
where it swallows a newline that is followed by an ind
Nikolaus Rath wrote:
There's also the important nitpick if 32e7 is best rendered as 320 M or
0.32 G. There's valid applications for both.
If you want 0.32 G it's probably because you're showing it
alongside other values >= 1 G, so you're really getting into
the business of letting the user choo
Random832 wrote:
One thing to consider is that this is very likely to be used with a unit
(e.g. "%hA" intending to display in amperes), so maybe it should put a
space after it? Though really people are probably going to want "1 A" vs
"1 kA" in that case, rather than "1 A" vs "1kA".
I don't thin
Steven D'Aprano wrote:
On Tue, Aug 30, 2016 at 09:08:01PM -0700, Ken Kundert wrote:
My thinking was that r stands for real like f stands for float.
The next available letter in the e, f, g sequence would
be 'h'.
If you want it to stand for something, it could be
"human-readable" or "human-o
Steven D'Aprano wrote:
Why is it obvious that you're expecting a float and not
a decimal in that case?
Because if you search the list archives you'll see that, in the short
term at least, I'm not in favour of changing the default floating point
type from binary floats to decimal floats *wink
Steven D'Aprano wrote:
Obviously if I write 1.1K then I'm expecting a float.
Why is it obvious that you're expecting a float and not
a decimal in that case?
The SI units are all decimal, and I think if we support these, we should
insist that K == 1000, not 1024. For binary scale factors, the
Chris Angelico wrote:
If units are retained, what you have is no longer a simple number, but
a value with a unit, and is a quite different beast. (For instance,
addition would have to cope with unit mismatches (probably by throwing
an error), and multiplication would have to combine the units (le
Ian Kelly wrote:
Should 1m be interpreted as 1 meter or 0.001 (unitless)?
I've never seen anyone use a scale factor prefix on
its own with a dimensionless number.
Sometimes informally the unit is omitted when it can
be inferred from context (e.g. "1k" written next to
a resistor symbol obviousl
Chris Angelico wrote:
f"This is a number: {13:0\u07c4}"
If I understand correctly, the proposal intends to make
it easier for a syntax hightlighter to treat
f"This is a number: {foo[42]:0\u07c4}"
as
f"This is a number: {foo[42] :0\u07c4}"
----
Guido van Rossum wrote:
Note that all these alternatives still send email notifications (to
those who want them), and trackers (including GitHub) also allow replies
by email.
Can you start a new topic by email, or only reply to
existing ones?
--
Greg
__
Oleg Broytman wrote:
From the recent and not so recent discussions of Moxi Marlinspike
about centralized vs decentralized solutions (unfederated messaging vs
email/jabber): "Indeed, cannibalizing a federated application-layer
protocol into a centralized service is almost a sure recipe for a
s
אלעזר wrote:
class Starship(tuple):
damage: int = 0
captain: str = "Kirk"
Is an obvious syntax for
Starship = NamedTuple('Starship', [('damage', int), ('captain', str)])
But the untyped version of that already has a meaning --
it's a tuple subclass with two extra class attri
801 - 866 of 866 matches
Mail list logo
