Hi Mauricio,
I'd advise starting a discussion on typing-sig (
https://mail.python.org/archives/list/typing-...@python.org/) or creating
an issue on the python/typing repo (https://github.com/python/typing). The
folks interested in typing generally hang out in those places, so those are
usually
I'm a -1 on this proposal, as I don't see any way of doing it that wouldn't
cause a huge amount of disruption. Yes, the situation — especially with regard
to unittest and logging — is far from ideal. But, it's what we've got.However
I'm -100 on doing something like this while there already
-types-i-e-subclasses-of-number-not-numbers-themselv/69383462#69383462
Best,
Alex
> On 16 Oct 2021, at 13:54, Steven D'Aprano wrote:
>
> On Sat, Oct 16, 2021 at 09:54:13AM +0100, Alex Waygood wrote:
>>>> On 16 Oct 2021, at 06:13, Steven D'Aprano wrote:
>>> Be ca
> On 16 Oct 2021, at 06:13, Steven D'Aprano wrote:
> Be careful about believing what you are told.
Indeed, MyPy will correctly raise errors if you assign {None: []} to a variable
annotated with dict[str, Number]. However, you'll find that MyPy also raises an
error if you assign {'foo': 4} to a
I agree with Steven. I very much like Abdulla's proposed syntax for dicts,
TypedDicts and sets. But I'm not sure that the idea for `Annotated` is
workable, and the proposal for lists seems too prone to ambiguity, given how
extensively square brackets are already used in typing syntax.
One
>
> If one DID write a first() function, it maybe or maybe not should raise a
> different exception, but it should certainly provide a better error message
For reference, the more-itertools package on PyPI has `first()` and
`last()` functions:
t;> counting items but not gaps, and that’s O(n). Which explains why we don’t
>> have such an API. But please check the C code!
>>
>> —Guido
>>
>> On Sun, Oct 10, 2021 at 07:18 Alex Waygood
>> wrote:
>>
>>> Should `dict.items()` be index
> Should `dict.items()` be indexable now that dicts are ordered? I say yes. Why
> shouldn't it?
Would there be a way to ensure that this had the same time complexity as
indexing of sequences? If "yes", I would support this — I think it would be
useful in some situations, and it would be more
, and something I hadn't considered. Unless someone
can think of a good workaround that doesn't make the implementation hideously
complex, I retract my support for adding `first()` and `last()` to itertools.
> On 10 Oct 2021, at 05:09, Steven D'Aprano wrote:
>
> On Wed, Oct 06, 2021 at 03:
why I was saying that I liked
the itertools solution more.
> On 6 Oct 2021, at 15:01, Steven D'Aprano wrote:
>
> On Wed, Oct 06, 2021 at 11:11:09AM +0100, Alex Waygood wrote:
>>> The temptation to insist "see, YAGNI!" at this point I shall resist.
>>
>> *Yo
een used, but I don't see how that makes it an
invalid use of the data structure *now*. Why shouldn't users be expected to
exploit an advertised feature of the language?
> On 6 Oct 2021, at 10:29, Stephen J. Turnbull
> wrote:
>
> Alex Waygood writes:
>
>> Whereas o
I think there definitely should be a more obvious way to do this
(specifically the first and last keys/values/items of a dictionary — I'm
ambivalent about the others, since they won't always be fast, as discussed). An
anti-pattern you see quite often on Stack Overflow to get the first key of
I disagree that "it teaches a lot about how Python works" is a good reason to
keep things the way they are. If you applied this principle more broadly, it
would seem to be an argument in favour of complexity in most situations, that
would imply we should keep syntactic sugar to a bare minimum
I also really like this idea. Though I wonder if it might be a better fit for
`contextlib` rather than `os`? Can see arguments both ways (and it's a minor
detail, anyway).
Alex
> On 14 Sep 2021, at 20:55, Paul Moore wrote:
>
> On Tue, 14 Sept 2021 at 20:44, Marc-Andre Lemburg wrote:
>>
>>
14 matches
Mail list logo
