C Anthony Risinger wrote:
`a, b, ...` to me says "pull out a and b and throw away the rest"...
> The mere presence of more
characters (...) implies something else will *happen* to the remaining
items, not that they will be skipped.
It seems that many people think about unpacking rather
C Anthony Risinger wrote:
Is __len__ a viable option now that __length_hint__ has been identified
for hints?
No, I misremembered that feature, sorry.
But I still don't like the idea of changing behaviour
depending on whether the RHS "looks like" an iterator
or not.
I'm not sure how to
Stephan Houben wrote:
A if is not None else C
Reading that gives me the feeling that something in my
brain has slipped a tooth.
It would read better with some kind of pronoun in there:
A if it is not None else C
Hypercard's Hypertalk had a special variable "it" that
worked sort of like
Stephan Houben wrote:
X or else Y
Sounds like a Python dialect for Mafia use.
customer.repay(loan) or else apply(baseball_bat, customer.kneecaps)
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
Nick Coghlan wrote:
What about more English-like syntax:
X or else Y
The problem with constructs like this is that they look like they
should mean the same thing as "X or Y".
How about:
x otherwise y
It looks different enough from "or" that you're not going
to accidentally read it
Steven D'Aprano wrote:
How does "stop iterating here" equate to a wildcard?
The * means "I don't care what else the sequence has in it".
Because I don't care, there's no need to iterate any further.
--
Greg
___
Python-ideas mailing list
Kirill Balunov wrote:
So someone too perlish
clever can assume that with the proposed syntax:
>>> def gen():
>>> for i in ['a', 'b', 'c', 'd']:
>>> v = x if 'x' in globals() else 'var '
>>> yield v + i
>>> x, y = gen()
>>> x
var a
>>> y
var ab
There's no need for
Guido van Rossum wrote:
Is this problem really important enough that it requires dedicated
syntax? Isn't the itertools-based solution good enough?
Well, it works, but it feels very clumsy. It's annoying to
have to specify the number of items in two places.
Also, it seems perverse to have to
Guido van Rossum wrote:
While it appears to rhyme with the use of a lone
'*' in function signatures, it would actually mean the opposite: in
signatures it means "don't allow any more".
That's the usage that's out of step with the rest -- all
the others can be seen as some form of wildcard.
C Anthony Risinger wrote:
* Perhaps existence of `__len__` should influence unpacking? There is a
semantic difference (and typically a visual one too) between 1-to-1
matching a fixed-width sequence/container on the RHS to identifiers on
the LHS, even if they look similar (ie. "if RHS has a
Chris Angelico wrote:
The problem is that it depends on internal whitespace to
distinguish it from augmented assignment;
Ah, didn't spot that. I guess the ellipsis is the next best
thing then.
An alternative would be to require parens:
(x, y, *) = z
--
Greg
Chris Angelico wrote:
x, y, * = iter # unpack into nothing
I'm surprised this isn't already allowed. It seems like the
One Obvious Way to me.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
Grant Jenks wrote:
The heap algorithm is exposed through a high-level
functional interface so that you can take advantage of duck-typing.
This would also be true of a HeapWrapper class that wrapped
an existing sequence.
There's a difference between the heap functions and sorted().
The latter
Chris Angelico wrote:
Yeah but if it's wrapping an existing list, it's not really
constructing a new object.
That depends on what you consider the object to be. There
are existing examples of objects that wrap other objects
and mutate them, e.g. TextIOWrapper.
If it would make anyone happier,
Chris Angelico wrote:
So the question is more: why, with Python being the way it is, do the
heap functions operate on a list? I think heapq.heapify is the answer:
in linear time, it heapifies a list *in place*.
There's no reason a Heap object couldn't accomodate that
case. E.g. the constructor
Steven D'Aprano wrote:
for i in range(0, 100):
const foo = f(i)
const bar = g(i, foo)
do_something_with(bar)
You are binding some value f(0) to the
constant name "foo" on the first loop, then on the second loop you try
to rebind a new value to the same name "foo".
It could be made to
Mikhail V wrote:
In reality, hyphen and Minus sign are not even closely similar -
Minus is ca. twice as wide,
If you are using a font that distinguishes them that clearly,
and if the human reader is sufficiently typographically aware
to notice the distinction. Both of those are big ifs.
And
In summary, this proposal seems to be: Give two visually
indistinguishible characters different meanings to
improve readability.
I'm not sure, but something about that sentence doesn't
seem quite right.
--
Greg
___
Python-ideas mailing list
Ethan Furman wrote:
If they don't have any clashing attributes, why does order matter?
It doesn't -- that's the point.
Currently it's assumed that the order base classes appear
in a class statement is the order that they must appear
in the MRO. But that's not always true. I'm suggesting that
Steven D'Aprano wrote:
These are not equivalent:
B < S, E
B < E, S
Not in general, but in many cases they will be, e.g. if
E and S have no method names in common. I think the OP is
implying that his case is one of those.
Maybe what's really wanted is a way to say "B inherits from
S and E,
(Reposting this to list -- pushed wrong reply button!)
Koos Zevenhoven
wrote:
|defsingle(i): try: ||v =i.next()
|||exceptStopIteration:raiseException('No
values')|||try: ||i.next() ||exceptStopIteration: ||returnv||else:
||raiseException('Too many values')|||printsingle(name
Nick Coghlan wrote:
since breaking up the current single level loops as nested loops
would be a pre-requisite for allowing these APIs to check for signals
while they're running while keeping the per-iteration overhead low
Is there really much overhead? Isn't it just checking a flag?
--
Greg
Stephan Houben wrote:
Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the
cesium atomic clocks which are currently used to *define* the second.
So we move to this new API, we should provide our own definition
of the second, since those rough SI seconds are just too imprecise
Stephan Houben wrote:
Do we realize that at this level of accuracy, relativistic time
dilatation due to continental drift starts to matter?
Probably also want an accurate GPS position for your computer
so that variations in the local gravitational field can be
taken into account.
--
Greg
Lucas Wiman wrote:
It is inconsistent that you can write hexadecimal integers but not
floating point numbers. Consistency in syntax is /fewer/ things to
learn, not more.
You still need to learn the details of the hex syntax for
floats, though. It's not obvious e.g. that you need to use
"p"
On 7/30/2017 2:57 PM, Markus Meskanen wrote:
>> How often do you get the keywords
in a random order?
The x, y, z example being used here is a bit deceptive,
because the fields have an obvious natural order. That
isn't always going to be the case.
--
Greg
Nick Coghlan wrote:
The same applies to the ntuple concept, expect there it's the fact
that it's a *tuple* that conveys the "order matters" expectation.
That assumes there's a requirement that it be a tuple in
the first place. I don't see that requirement in the use
cases suggested here so
Nick Coghlan wrote:
New builtin:
ntuple(x=1, y=0)
Do we really want this to be a tuple, with ordered fields?
If so, what determines the order? If it's the order of the
keyword arguments, this means that
ntuple(x=1, y=0)
and
ntuple(y=0, x=1)
would give objects with different
Jim J. Jewett wrote:
is there any reason not to simply define it as a view on a dict, or at
least as a limited proxy to one?
Some valuable characteristics of namedtuples as they are now:
* Instances are very lightweight
* Access by index is fast
* Can be used as a dict key
All of those would
Paul Moore wrote:
But no-one manually raises NameError, so Ken's example wouldn't work
with "real" NameErrors.
Part of his suggestion was that core and stdlib code would
move towards using attributes. The NameError example makes
sense in that context.
--
Greg
Terry Reedy wrote:
It occurs to me that if the exception object has no reference to any
python object, then all would be identical and only one cached instance
should be needed.
I don't think that's true now that exceptions get tracebacks
attached to them.
--
Greg
Terry Reedy wrote:
Attaching a *constant* string is very fast, to the
consternation of people who would like the index reported.
Seems to me that storing the index as an attribute would help
with this. It shouldn't be much slower than storing a constant
string, and formatting the message would
Paul Moore wrote:
As noted, I disagree that people are not passing components because
str(e) displays them the way it does. But we're both just guessing at
people's motivations, so there's little point in speculating.
I've no doubt that the current situation encourages people
to be lazy -- I
Steven D'Aprano wrote:
I think that we should assume that
def func(x:Spam()):
...
will always look up and call Spam when the function is defined.
Personally I think we should be moving towards not even
guaranteeing that. Then we would have a chance of some
day ending up with a static
Steven D'Aprano wrote:
isinstance([], List[int])
isinstance([], List[str])
How can a single value be an instance of two mutually incompatible
types?
I don't think there's any contradiction there, because the
compatibility rules are different for static and runtime types.
Statically,
Nathaniel Smith wrote:
A magic (implemented in C) decorator like @async_signals_masked I
think would be the simplest way to do this extension.
I don't have a good feeling about that approach. While implementing
the decorator in C might be good enough in CPython to ensure no
window of
Nathaniel Smith wrote:
So what should this async_signals_masked state do when we yield out
from under it? If it's a thread-local, then the masking state will
"leak" into other async function callstacks (or similar for regular
generators), which is pretty bad. But it can't be just frame-local
Erik Bray wrote:
My question would be to
make that a language-level requirement of the context manager
protocol, or just something CPython does...
I think it should be a language-level requirement, otherwise
it's not much use.
Note that it's different from some existing CPython-only
behaviour
Erik Bray wrote:
At this point a potentially
waiting SIGINT is handled, resulting in KeyboardInterrupt being raised
while inside the with statement's suite, and finally block, and hence
Lock.__exit__ are entered.
Seems to me this is the behaviour you *want* in this case,
otherwise the lock can
David Mertz wrote:
I just wish I could think of a good
character that doesn't have some very different meaning in other
well-known contexts (even among iterables).
(a;b)
Should be unambiguous as long as the parens are required.
--
Greg
___
Chris Angelico wrote:
And for completeness, "while not throw:".
And just to completely confuse everyone, "while not pass". :-)
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code
Steven D'Aprano wrote:
class X:
def __getitem__(self, n):
if n < 0:
n += len(self)
if not 0 <= n < len(self):
raise IndexError
...
class Y:
def __getitem__(self, n):
self._validate(n)
...
def _validate(self, n):
if n <
Cameron Simpson wrote:
try:
foo(bah[5])
except IndexError as e:
... infer that there is no bah[5] ...
One can easily want, instead, some kind of "shallow except", which would
catch exceptions only if they were directly raised from the surface
code;
The problem I see
In my experience, RLE isn't something you often find on its own.
Usually it's used as part of some compression scheme that also
has ways of encoding verbatim runs of data and maybe other
things.
So I'm skeptical that it can be usefully provided as a library
function. It seems more like a design
C Anthony Risinger wrote:
Incredibly useful and
intuitive, and for me again, way more generally applicable than iterable
unpacking. Maps are ubiquitous.
Maps with a known, fixed set of keys are relatively uncommon
in Python, though. Such an object is more likely to be an
object with named
One existing way to do this:
a, b, c = (mydict[k] for k in ('a', 'b', 'c'))
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Mikhail V wrote:
I find actually symbols ≤ ≥ (inclusive comparison) nice.
Yes, there are a few symbols it would be nice to have.
A proper ≠ symbol would have avoided the wars between
<> and !=. :-)
--
Greg
___
Python-ideas mailing list
Stephan Houben wrote:
What about just adding the -I (isolated mode) flag to the #! line of
installed scripts?
Not all unix systems support passing extra arguments on a #! line.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
Soni L. wrote:
How about `import self.thing` (where "self" implies same dir as the
current .py
That wouldn't provide quite the same functionality, since
currently a module alongside the main py file can be imported
from anywhere, including .py files inside a package.
Also I think it would be
Is this really much of a security issue? Seems to me that
for someone to exploit it, they would have to inject a
malicious .py file alongside one of my script files. If
they can do that, they can probably do all kinds of bad
things directly.
--
Greg
Steven D'Aprano wrote:
There's not much, if any, benefit to writing:
∫(expression, lower_limit, upper_limit, name)
More generally, there's a kind of culture clash between mathematical
notation and programming notation. Mathematical notation tends to
almost exclusively use single-character
Victor Stinner wrote:
You are right, it's the script directory that it added to
sys.path and I would like to know if it would be possible to change that?
Why do you want to change it?
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
Victor Stinner wrote:
How do you write π (pi) with a keyboard on Windows, Linux or macOS?
On a Mac, π is Option-p and ∑ is Option-w.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Victor Stinner wrote:
I prefer str.join() approach: write a single chunks() function which
takes a sequence, instead of modifying all sequence types around the
world ;-)
Even if a general sequence-chunking function is thought useful,
it might be worth providing a special-purpose one as a
Steven D'Aprano wrote:
I've also been thinking about generalisations such as grouping lines
into paragraphs, words into lines, etc.
You're probably going to want considerably more complicated
algorithms for that kind of thing, though. Let's keep it
simple.
--
Greg
For a name, I think "group" would be better than "chunk".
We talk about grouping the digits of a number, not chunking
them.
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of
Stephan Hoyer wrote:
In practice, CPython requires that the
right operand defines a different method before it defers to it.
I'm not sure exactly what the rationale for this behaviour is,
but it's probably something along the lines that the left
method should already know how to deal with that
Nick Coghlan wrote:
but at the cost of
changing the nature of the workload in a given thread, and hence
messing with the working set of objects it has active.
Does the working set of an individual thread matter to anything?
Or even an individual process? As far as the virtual memory
system is
Serhiy Storchaka wrote:
but should not
affect performance since locking is used only when you faced with a
generator running in other thread.
I don't think that's true, because the first thread to use a
generator has to lock it as well. And even if there is only
one thread in existence when
Paul Moore wrote:
Is this a well-defined idea? ... There's nothing describing how
multiple values would be stored in the same file/transmitted in the
same stream.
I think this is something that's outside the scope of the spec.
But since the grammar makes it clear when you've reached the end
Terry Reedy wrote:
PQL expressions should be quoted and passed to the dsl
processor, as done with SQL and other DSLs.
But embedding one language as quoted strings inside another
is a horrible way to program.
I really like the idea of a data manipulation language that
is seamlessly integrated
Chris Angelico wrote:
Which is why these proposals always seem to gravitate to "anything you
can assign to",
There might be some parsing difficulties with that, e.g.
def foo(x)[5](y, z):
...
That should be acceptable, because foo(x)[5] is something
assignable, but foo(x) looks like
Stephen J. Turnbull wrote:
Greg Ewing writes:
> FCLAP - Frequent Criticisms Levelled Against Python
It reads better if you don't insist that they be frequent. (This may
only play in America.)
Criticisms Frequently Levelled Against Python would be
another possibility...
--
G
Chris Barker wrote:
Frequently Asked Criticisms
Doesn't quite make sense -- one doesn't "ask" criticisms.
How about:
FCLAP - Frequent Criticisms Levelled Against Python
--
Greg
___
Python-ideas mailing list
Python-ideas@python.org
Ram Rachum wrote:
1. I'm making a program that lets people lease machines. They can issue
a command to lease 7 machines. ... If everything goes fine, I do pop_all on
the exit stack so it doesn't get exited and the machines stay leased,
Seems to me that would be done more easily and clearly
David Mertz wrote:
The most notable example of something that is "weird" and "a stupid
idea" is NumPy... and *everything* in the Scientific Python ecosystem
thereby.
Also the built-in list type. Guido clearly disagrees about
the stupidity level of this idea!
--
Greg
Another advantage of dunder method names is that you
can google them. Someone coming across a method called
"__foo__" can easily find documentation about it, but
it's not so easy to do that for special syntax.
--
Greg
___
Python-ideas mailing list
C Anthony Risinger wrote:
On Nov 6, 2016 7:32 PM, "Nathaniel Smith" > wrote:
>
> log.debug!(f"Message: {message_object!r}")
Would the log.debug implementation need to fetch the context to evaluate
the delayed expression
Not if it expands to
Eric V. Smith wrote:
I'd rather see the ability to have unevaluated expressions, that can
later be evaluated. I'll use backticks here to mean: "parse, but do not
execute the enclosed code". This produces an object that can later be
evaluated with a new builtin I'll call "evaluate_now".
So
Steven D'Aprano wrote:
Or even the subject line of this email thread???
Sorry, crossed over discussions.
But I think it's also true that the null-coalescing
idea is for cases where it's not an error for something
to be None.
--
Greg
___
Zero Piraeus writes:
If I write something like obj.attr, the failure mode I care about is
that
obj has no attribute attr, rather than that obj is specifically None (or
one of a defined group of somewhat Nonelike objects).
Clearly, in such a circumstance, obj is not what I
There was a discussion about this a while ago. From what
I remember, the conclusion reached was that there are too
many degrees of freedom to be able to express reduction
operations in a comprehension-like way that's any clearer
than just using reduce() or writing out the appropriate
loops.
--
C Anthony Risinger wrote:
Erlang/Elixir (sorry after 6 years python this is what I do now!)
does it the same way as python:
>>> [{X, Y} || X <- [1,2,3], Y <- [a,b]].
[{1,a},{1,b},{2,a},{2,b},{3,a},{3,b}]
Here X is the outer loop.
I think the confusion stems from doing it both ways at the
Alexander Heger wrote:
For me the current behaviour does not seem unreasonable as it resembles
the order in which you write out loops outside a comprehension
That's true, but the main reason for having comprehensions
syntax in the first place is so that it can be read
declaratively -- as a
Todd wrote:
||| is the delimiter for the third dimension, || is the delimiter for
the second dimension.
This seems a bit inconsistent. It appears the rule is
"n vertical bars is the delimiter for the nth dimension".
By that rule, the delimiter for the first dimension
should be a single
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
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*
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
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
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)
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
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
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
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
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
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"
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.
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
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
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
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
___
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
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
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,
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.
701 - 800 of 812 matches
Mail list logo