there were some internal language reasons
to want stable dicts, e.g. so that the class dict passed to __prepare__
preserves the order in which names are assigned in the class body. Are
there any such use cases for stable sets?
--
Greg
___
Python-Dev ma
all kernel written
in C, and write the rest using a tool similar to Cython that will
take care of all the tricky reference counting for you.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@
On 30/04/22 5:25 am, MRAB wrote:
I was going to suggest "metastable". Too late? :-)
What, the API is balanced on a knife edge and likely to collapse
into something else if you sneeze too hard?
--
Greg
___
Python-Dev mailing list --
On 27/04/22 1:26 pm, Chris Angelico wrote:
On Wed, 27 Apr 2022 at 11:18, Greg Ewing wrote:
The proposed feature is analogous to forward declaring a
struct in C. Would you call what C does monkeypatching?
No, because C doesn't have first-class types, much less mutable ones.
The purpose
ainst monkeypatching. Personally
I don't, but someone else seems to as they objected that they don't
want monkeypatching to be encouraged. I was just pointing out that
(1) I don't think it's the same thing as monkeypatching and (2)
you can't use it to modify an existing class in an ad-hoc man
On 27/04/22 2:01 am, Chris Angelico wrote:
That would be the case if monkeypatching were illegal. Since it's not,
wherein lies the difference?
The proposed feature is analogous to forward declaring a
struct in C. Would you call what C does monkeypatching?
--
Greg
On 27/04/22 1:04 am, Joao S. O. Bueno wrote:
MonkeyPatching in Python is not illegal in this sense.
I'm not suggesting it is. You're seizing on the wrong part
of the analogy. The point is that what you call something
doesn't change its nature.
--
Greg
.
If I lose my keys and have to break into my house, it's not
illegal. But if someone else breaks into my house without my
permission, that is illegal. It doesn't matter if the thief
*calls* it legal, there's still a difference.
--
Greg
___
Python-Dev ma
class and the module defining the extension methods.
Maybe here the client code should import the class from the module
containing the "continue class", and that module should import the
one containing the "forward class"? Would
continued, it doesn't
make monkeypatching any easier than it currently is.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org
.
[1] Actually it's a context-sensitive pseudo-keyword, which is
an unusual thing to find in Pascal; maybe Wirth added it as an
afterthought?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
of the class's public attributes in the "forward" part without
also supplying their definitions. If I remember rightly the
"forward" part was only going to include the class name and
base classes.
--
Greg
___
Python-Dev mailing list -- p
becomes discourse-only, I will no
longer be able to follow or participate in it. I don't have the
time or energy to chase around visiting a bunch of clunky web
interfaces every day.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
out this.
PEP 257 recommends that all docstrings be triple quoted, not that all
triple quoted strings be docstrings. There is a difference!
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
n any case, if numpy explicitly chooses speed over compatibility,
that's an issue between CPython and numpy, not CPython and Cython.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
htt
le by hand and
choosing whether to stick to the stable API or not. If they rely
on internals, they do so at their own risk.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.
that turns Python code into fast C code.
To address this there could be an option to choose between
"compatible code" and "fast code", with the former restricting
itself to the stable API.
--
Greg
___
Python-Dev mailing list -- p
.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev
better to organise their changes into
a number of small, independent commits rather than one large one. I
wouldn't be too quick to jump to conclusions about people's motives
here.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev
On 17/12/21 6:58 pm, Steven D'Aprano wrote:
Or a Doctor Who episode. Doctor Who and the Immortal Instances of Doom.
Hmmm... and Guido has a time machine... Is it possible he's
secretly a Time Lord?
--
Greg
___
Python-Dev mailing list -- python-dev
On 17/12/21 6:52 am, Eddie Elizondo via Python-Dev wrote:
I've just updated the original Immortal Instances PR
Is it just me, or does Immortal Instances sound like a
video game franchise?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
about
casts used as l-values.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https
. That wouldn't have happened
if typing were considered the only supported use.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org
<< i) & flags) != 0'.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.
uples and lists are compared lexicographically by comparing
corresponding elements. This means that to compare equal, every element
must compare equal and the two sequences must be of the same type and
have the same length."
--
Greg
___
Python-Dev ma
On 14/10/21 11:19 am, Greg Ewing wrote:
Not really -- __int__ is expected to return something of type
int, whereas __trunc__ is expected to return the same type as
its operand.
Scratch that, it seems __trunc__ also returns an int, at least
for floats. Not sure what the logic behind
On 14/10/21 6:10 am, Antoine Pitrou wrote:
It seems that
__int__ has now become a strict equivalent to __trunc__.
Not really -- __int__ is expected to return something of type
int, whereas __trunc__ is expected to return the same type as
its operand.
--
Greg
On 6/10/21 7:15 am, sascha.schlemmer--- via Python-Dev wrote:
except (*E1, *E2) as error: ...
Then we would have to decide whether to allow
except (E1, *E2) as error: ...
and if so, what it would mean.
--
Greg
___
Python-Dev mailing list
n't think it would be desirable in any case. The separation of
tokens into alphanumeric and non-alphanumeric is deeply embedded in
every Python programmer's brain by now, and we shouldn't mess with
it.
--
Greg
___
Python-Dev mailing list -- python-dev@p
?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev
is to make it possible
to attach a filename and line number directly to a traceback object,
without needing a frame or code object at all.
Creating a fake frame and code object just to do this is IMO an
ugly hack that should not be necessary.
--
Greg
On 19/08/21 7:23 pm, Antoine Pitrou wrote:
The whole thing is ridiculous enough to read like a Monty Python skit by
now, but the trout-slapping ending is still missing.
Just have the police come in and arrest everyone, that
usually works.
--
Greg
ventually learn that behaving
like spoilt 7-year-olds is no way to run a successful company.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lis
way, I don't think that's the intention.
I'm not sure it fits any of the usual grammatical categories. It
might be best understood as an abbreviated infinitive, i.e. there's
an implied "The purpose of this commit is to..." in front of it.
--
Greg
_
On 14/04/21 8:54 am, Guido van Rossum wrote:
On Tue, Apr 13, 2021 at 12:55 PM Serhiy Storchaka
>
>>> [0x1for x in (1,2)]
I would totally make that a SyntaxError, and backwards compatibility be
damned.
Indeed. Python is not Fotr
would be better? I think I've used
that term in PEPs before.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.o
ly be used only in rare
circumstances.
Can code that's aware of the possibility of getting an ExceptionGroup
not simply catch it as a normal exception and then pick it apart? Do
we really need a whole new piece of machinery for this?
--
Greg
___
Python-D
* clauses can be run,
whereas only one except clause will run (the first one that
matches something in the ExceptionGroup).
Is there any good reason not to do things that way?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe sen
a loop with pattern matching, so is except* really justified?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
On 14/02/21 8:48 am, Eric Traut wrote:
def is_str_list(val: Constrains[List[object]:List[str]) -> bool:
...
Maybe something like this?
def is_str_list(val: List[str] if True else List[object]) -> bool:
...
--
Greg
___
Python-Dev m
On 13/02/21 9:03 am, Paul Bryan wrote:
What if PSF were to undertake codifying a language specification?
We have the Language Reference and Library Reference. Do they
not count as specifications?
--
Greg
___
Python-Dev mailing list -- python-dev
it doesn't need __future__.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org
So I'm puzzled as to why you would want to do this.
Also, what definition do you have in mind for phi? It doesn't
seem to be something you can implement as a real function.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an
On 3/02/21 10:35 pm, Phil Thompson wrote:
On 02/02/2021 23:08, Greg Ewing wrote:
you have no idea what
kind of C struct it expects to get.
I had assumed that some other magic in typeobject.c (eg. conflicting
meta-classes) would have raised an exception before getting to this
stage
n is that if Mixin has a __new__
method written in Python, it won't get called. So if Mixin needs to
do any initialisation, it will have to be in __init__, *and* all the
__init__ methods in the chain will need to be designed for
cooperative calling.
--
Greg
where everything is much
more strict type-wise.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived
On 3/02/21 12:07 am, Phil Thompson wrote:
On 01/02/2021 23:50, Greg Ewing wrote:
At the C level, there is always a *single* inheritance hierarchy.
Why?
Because a C struct can only extend one other C struct.
I want my C-implemented class's __new__ to support cooperative
multi-inheritance
thing is for B's tp_new to directly call A's tp_new,
which calls object's tp_new.
Don't worry about Python-level multiple inheritance; the
interpreter won't let you create an inheritance structure
that would mess this up.
--
Greg
___
Python-Dev mailing
recognised by type checkers.
If you want to do run-time typing stuff, you would use
from typing import ...
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mail
of __co_annotations__.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python
:
class Inner:
def f(x: Outer.Inner): ...
However, I think cases like this should work:
class C:
t = List[int]
def f(x: t): ...
even though the closure placed in C.__co_annotations__ wouldn't
normally have access to t without qualification.
--
Greg
We haven't seen the definition of "zebra" yet, so we don't know what
approach to take.
I don't think that should be a problem. The compiler already knows
about all the assignments occurring in a scope before starting to
generate code for it.
--
Greg
_
as get_type_hints(), since it wouldn't make
any assumptions about what the annotations mean.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists
to *define* __bool__ as something the compiler
is allowed to optimise away. But that's a different thing from
"purity" (which is hard to pin down in an imperative language).
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubs
we decide that print() is pure,
then a __bool__ that calls print() is also pure, so there's
nothing wrong with optimising it away, right?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
call would still cause
a visible change in the program's behaviour.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.or
that.
All functions are pure in Haskell -- not sure if that counts
as "doing something like that". Retrofitting it into
Python would turn it into a very different language.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubs
do we know
which set of semantics we need to use?
This implies that __future__ is the wrong mechanism to use.
It's only appropriate when the changes it triggers are confined
to the module that uses it, which is not the case here.
--
Greg
___
Python-Dev
be significantly smaller than the corresponding
code object, though?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
lls belong to the enclosing scope, not the function that uses
them. I don't think they would interfere with sharing parts of code
objects between identical annotations.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
ry similar, but distinct.
Maybe "bare code object" would be a less confusing term?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev
;help", "copyright", "credits" or "license" for more information.
>>> class C:
... __slots__ = ['a', 'b']
...
>>> class D(C):
... __slots__ = ['c', 'd']
...
>>> class E(D):
... pass
...
>>> C.__slots__
[
object could be used for all
annotationless objects.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived
ems to me the code objects for those would be identical
wherever they're used, and so could be cached and re-used
the same way as interned strings.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyth
On 12/01/21 10:41 am, Larry Hastings wrote:
So: if you're using annotations for something besides "type hints",
Didn't Guido decree that using annotations for anything other than
type hints is no longer supported?
--
Greg
___
Python-D
kept alive by annotations.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/l
dict if the object doesn't have any
annotations.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https
premature optimisation. Function objects are
tiny compared to the code object, which is already a fairly
complicated thing composed of a number of sub-objects.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to pyt
On 9/01/21 9:12 am, Chris Barker wrote:
(though I notice that if you create __slots__ in pure Python, its names
show up in dict anyway -- so clearly I'm confused...)
Descriptors for the slots get added to the *class* dict.
But that's not the dict that vars() looks at.
--
Greg
Rather than a full-blown buffer-protocol-like thing, could we
get by with something simpler? How about just having a flag
in the unicode object indicating that it doesn't own the
memory that it points to?
--
Greg
___
Python-Dev mailing list -- python
a problem.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/
seem
to remove functionality that I like and rely on. I stuck with
10.6 for a very long time, because it did everything I wanted,
and there were some third party extensions I used that stopped
working in 10.7 and there were no good replacements available.
--
Greg
, but the Matcher doesn't know anything
about that namespace.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message a
doesn't permit introspection on types. It's unnecessary in
Python and better avoided.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python
hard to explain, it's probably
a bad idea." I think the proposed rules for match cases are
objectively harder to explain than those for other expressions,
because they're more complicated.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To u
case (x): # matches the value of x
case (x,): # matches any 1-tuple and binds x
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lis
of an =
Only in some of those contexts is it treated as a name to be
assigned. That's a fairly complex bit of mental parsing to do
when reading a case.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev
scribe algorithms they often
use subscripts to disinguish different values of a variable on
different iterations, effectively making them into different
variables. So they still don't need a symbol for assignment.
--
Greg
___
Python-Dev mailing list -- pyth
allowing the last-bound
value to be seen afterwards, but the idea didn't gain any traction.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python
as a good reason for that having to do with reference cycles.
Nobody liked it much, but we didn't really have a choice. There is
no such pressing need for special scope rules in match statements.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
, unfortunately.
I share this concern, and it's one of the reasons I would prefer
assignments to be explicitly marked. With
case Point(x=?a, y=?b):
then if you get it wrong and write
case Point(?a=x, ?b=y):
at least you'll get a syntax error.
--
Greg
ddle'.
I know the same rule applies whatever sigil is being used, but
to my way of thinking, '>' is too easily confused with a comparison
operator. Also it's tempting to interpret '=>' as a single token,
which accidentally happens to make sense h
On 13/11/20 9:19 am, MRAB wrote:
I'd still want to list "as" as another possibility, the advantage being
that it's already used for binding elsewhere.
Only where it makes English grammatical sense, though, which
it doesn't unless there's something on both sides
is that it would make
pattern matching substantially different from unpacking, but
it's been stated that making these compatible is a non-goal,
maybe even an anti-goal, and I'm fine with that.
--
Greg
___
Python-Dev mailing list -- python-dev@python.or
in the future. Can you elaborate
on what you don't like about it?
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
On 6/11/20 4:54 am, Steven D'Aprano wrote:
On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote:
If "_" is a non-binding wildcard, linters will have to allow
"case _, _" otherwise it might as well not be there. And then
if it is later changed to be binding,
Why
On 4/11/20 4:36 am, Paul Svensson wrote:
On Tue, 3 Nov 2020, Greg Ewing wrote:
once people start using "_" as a wildcard
in patterns, it will be too late to go back.
But will it, really ?
It seems to me, that if we leave the "_" magic out,
and leave "case x, x&quo
lse like "?". And we need to decide about
it now, because once people start using "_" as a wildcard
in patterns, it will be too late to go back.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an em
choosing a statement, not an expression?
Which is a *much* better way to say what I think you were trying to
say.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/m
d of weird that just looking at data on the
disk can change something about it. Sometimes it's an
advantage to *not* have quantum computing!
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python
o that it fails. You write a proper test, and it
fails initially because you haven't yet written the code that it tests.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
of its
strengths.
I worry that adding four layers of clever speedup tricks will
completely destroy this simplicity, leaving us with something
that can no longer be maintained or contributed to by
ordinary mortals.
--
Greg
___
Python-Dev mailing list -- python
structure -- it was all in the directory entry.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https
?
They seem to have a knack for making tricky stuff understandable.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
On 15/10/20 1:45 pm, Chris Angelico wrote:
So it'd
be heuristics in the core language that choose a good default for most
situations, and then a str method that returns a preprocessed needle.
Or maybe cache the results of the preprocessing?
--
Greg
, which also handled all the comparisons, so
tp_richcompare was likely seen as a generalisation of that.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org
- and you only pay for
the overhead of those if you need them.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archi
.
--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev
syntax so that users can keep it in their heads.
Maybe the PEP should propose an AST of its own, which would initially
be a third thing separate from either of the existing ones, with
the possibility of adopting it as the ast module representation
some time in the future.
--
Greg
1 - 100 of 2324 matches
Mail list logo
