I ran into an issue today with `str()` not behaving as I thought it should.
Given the following test script, what should happen?
-- 8< --
class Blah(object):
def __str__(self):
return 'blah'
class Huh(int, Blah):
pass
class Hah(Blah, int):
pass
On Tue, Nov 30, 2021 at 3:31 PM Guido van Rossum wrote:
>
>> There is some discussion of the numeric tower in PEP 484 but the PEP says
> you should just use 'int', 'float' and be happy.
>
Thanks -- I didn't think to look there. And this: "when an argument is
annotated as having type float, an ar
On 12/1/2021 12:47 AM, Oscar Benjamin wrote:
On Tue, 30 Nov 2021 at 23:37, Guido van Rossum wrote:
We should definitely push back on zealous new converts to typing who insist
that everything should be annotated. But we should also recognize that even in
their current, far from perfect state,
On Tue, Nov 30, 2021 at 4:48 PM Oscar Benjamin
wrote:
> On Tue, 30 Nov 2021 at 23:37, Guido van Rossum wrote:
> >
> > We should definitely push back on zealous new converts to typing who
> insist that everything should be annotated. But we should also recognize
> that even in their current, far
On Tue, 30 Nov 2021 at 23:37, Guido van Rossum wrote:
>
> We should definitely push back on zealous new converts to typing who insist
> that everything should be annotated. But we should also recognize that even
> in their current, far from perfect state, type annotations can provide a lot
> of
Heh. We could update PEP 8 to ban type annotations, then watch as the
people who over-zealously apply PEP 8 to everything AND
over-zealously
insist on adding type annotations to everything have their heads
explode.
--
Steve
I love it!
"Surtout, pas trop de zèle"
On Tue, Nov 30, 2021 at 2:52 PM Christopher Barker
wrote:
> Another concern I have is the over specification of types.
>
> I have seen many examples of, e.g.
>
> func(x: int, y: float, stuff: List(int]):
>
> but very few of:
>
> func(x: SupportsInt, y: SupportsFloat, stuff: Sequence[SupportsInt])
The code in the pull request is not updated and cannot be updated (though I
seem to have fixed the bugs in the test in my modified CPython build). It won't
merge, and I definitely believe it won't pass.
___
Python-Dev mailing list -- python-dev@python.o
Another concern I have is the over specification of types.
I have seen many examples of, e.g.
func(x: int, y: float, stuff: List(int]):
but very few of:
func(x: SupportsInt, y: SupportsFloat, stuff: Sequence[SupportsInt]):
(or even Iterable[int])
Is that even the right thing to do to get gene
On Tue, 30 Nov 2021 at 19:07, Brett Cannon wrote:
>
> On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano wrote:
>>
>> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
>>
>> > And to be clear, it's often very non-obvious how to annotate something
>> > - in https://github.com/pfmoore/editab
On Tue, Nov 30, 2021 at 9:09 AM Steven D'Aprano wrote:
> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
>
> > And to be clear, it's often very non-obvious how to annotate something
> > - in https://github.com/pfmoore/editables I basically gave up because
> > I couldn't work out how t
On Tue, Nov 30, 2021 at 7:34 PM Guido van Rossum wrote:
> How about *not* asking for an exception and just following the PEP 387
> process? Is that really too burdensome?
The Backward Compatibility section gives an explanation:
"This change does not follow the PEP 387 deprecation process. There
On 11/26/21 1:13 AM, Paul Moore wrote:
> On Fri, 26 Nov 2021 at 05:14, Guido van Rossum wrote:
>>
>> My memory is also hazy, but I'm quite sure that *in my mind* annotations were
>> intended as a compromise between conflicting proposals for *typing*. We
didn't
>> have agreement on the syntax or s
How about *not* asking for an exception and just following the PEP 387
process? Is that really too burdensome?
On Tue, Nov 30, 2021 at 10:30 AM Victor Stinner wrote:
> Hi,
>
> I propose to disallow using macros as l-value. Read and comment the
> plain text below, or read the PEP 674 online,
> h
Hi,
I propose to disallow using macros as l-value. Read and comment the
plain text below, or read the PEP 674 online,
https://python.github.io/peps/pep-0674/
While I'm not sure that the proposed changes are really controversial,
I decided to write a formal PEP since the incompatible changes are
This is great Patrick, thanks.
My use case is similar to Patrick's, except it builds on dataclasses
directly:
It's part of a larger system, but I've just pulled it out into its own
poorly documented and poorly tested package:
https://github.com/PythonCHB/flexi
(I think it's generally useful, so
On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
> And to be clear, it's often very non-obvious how to annotate something
> - in https://github.com/pfmoore/editables I basically gave up because
> I couldn't work out how to write a maintainable annotation for an
> argument that is "a Pat
On Fri, 26 Nov 2021 at 09:14, Paul Moore wrote:
> I'd therefore interpret Barry's plea as being for *anyone* with a use
> for annotations to provide their feedback (at least, anyone who
> accepts that annotations are types), with particular emphasis on
> people who want to use the types declared
On Tue, 30 Nov 2021 at 12:39, Oscar Benjamin wrote:
> There are other open "issues" like this for SymPy where the
> presumption is that not having type hints is now to be considered a
> deficiency of the library regardless of whether the hints have any
> benefit for internal use. I don't object t
On 29 Nov 2021, at 23:56, Barry Warsaw wrote:
[...]
(not that you're not allowed to use for anything else, of course you
are, but that other uses won;t be taken into account when designing
the new interface)
But I have never seen that clearly stated anywhere. The closest is
from PEP 563, wh
On Tue, Nov 30, 2021 at 09:17:13AM +, Paul Moore wrote:
> Also, related to the question Terry raised, IMO it would be useful to
> have a clear statement on code that *does* use type annotations, but
> violates them at runtime. To be specific, is the following considered
> as an error?
>
> >>>
On Tue, 30 Nov 2021 at 09:23, Paul Moore wrote:
>
> On Tue, 30 Nov 2021 at 02:52, Steve Dower wrote:
> >
> > THAT'S the kind of thing that also has been happening with typing, and
> > why some of us feel the need to publicly re-state things that are all
> > agreed upon within this group, but are
On Tue, 30 Nov 2021 at 09:37, Chris Angelico wrote:
>
> On Tue, Nov 30, 2021 at 8:19 PM Paul Moore wrote:
> > Also, related to the question Terry raised, IMO it would be useful to
> > have a clear statement on code that *does* use type annotations, but
> > violates them at runtime. To be specific
On Tue, Nov 30, 2021 at 8:19 PM Paul Moore wrote:
> Also, related to the question Terry raised, IMO it would be useful to
> have a clear statement on code that *does* use type annotations, but
> violates them at runtime. To be specific, is the following considered
> as an error?
>
> >>> def muladd
On Tue, 30 Nov 2021 at 02:52, Steve Dower wrote:
>
> THAT'S the kind of thing that also has been happening with typing, and
> why some of us feel the need to publicly re-state things that are all
> agreed upon within this group, but are struggling to be heard over the
> public discourse on the top
If someone wants to experiment such optimization, there is no need to
modify the Python internal optimizer, it can be done externally:
https://faster-cpython.readthedocs.io/ast_optimizer.html
For example, I implemented many optimizations like constant
propagation and loop unrolling in my old AST f
26 matches
Mail list logo
