Well, I was trained and an engineer, but now call myself an oceanographer,
but in any case, I don't need to submit my calculations for review to
anyone. Though I do need to present algorithms / calculations / methods in
written form that others can understand -- so a similar problem.
But
On Sat, Aug 15, 2020 at 08:26:10PM -0700, Guido van Rossum wrote:
> Are you saying that for xarray it is important to distinguish between
> `d[day=3, detector=4]` and `d[detector=4, day=3]`? If we just passed the
> keyword args to `__getitem__` as an extra `**kwds` argument (which
> preserves
On Sat, Aug 15, 2020 at 09:25:00PM -0700, Stephan Hoyer wrote:
> One question that comes up: should d[**kwargs] be valid syntax? d[*args]
> currently is not, but that's OK since d[tuple(args)] is identical.
If we're going to support keyword arguments, what reason would we have
for not
On Sat, Aug 15, 2020 at 8:27 PM Guido van Rossum wrote:
> On Sat, Aug 15, 2020 at 8:02 PM Todd wrote:
>
>> On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
>> wrote:
>>
>>> > QUESTION
>>> > Suppose we have
>>> > >>> d[x=1, y=2] = 42
>>> > >>> d[x=1, y=2]
>>> > 42
>>> > where d is an
On Sat, Aug 15, 2020 at 8:02 PM Todd wrote:
> On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
> wrote:
>
>> > QUESTION
>> > Suppose we have
>> > >>> d[x=1, y=2] = 42
>> > >>> d[x=1, y=2]
>> > 42
>> > where d is an instance of a suitable class X that has no special
>> knowledge of
On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
wrote:
> > QUESTION
> > Suppose we have
> > >>> d[x=1, y=2] = 42
> > >>> d[x=1, y=2]
> > 42
> > where d is an instance of a suitable class X that has no special
> knowledge of keywords.
>
> Initially, when I wrote the pep, the idea was
On Sat, Aug 15, 2020 at 7:14 PM Caleb Donovick
wrote:
> > To me, the main weakness here is that you couldn't move forward with
> this unless you also got the various static type checkers on board. But I
> don't think those care much about this use case (an inline notation for
> what you can
> Hmm... OK, that's an interesting desire. How do square brackets get you
any closer to that?
I use `__class_getitem__` as a memoized type factory that builds a new
subtype when it's called or returns the cached type.
You are correct I could name it as something else, there is nothing special
> To me, the main weakness here is that you couldn't move forward with
this unless you also got the various static type checkers on board. But I
don't think those care much about this use case (an inline notation for
what you can already do with a class definition and annotations). And
without
On 16/08/20 4:26 am, Ricky Teachey wrote:
There are certainly
instances where I've needed to used matrices to solve a system of
equations in an automated way. But most of time it's simply not needed,
If we're going to have a class that supports matrix multiplication,
I think we should at
On Fri, Aug 14, 2020 at 3:05 AM Jonathan Fine wrote:
> I'd like to sound out consensus regarding mapping access, where none of
> the keys are positional. In particular, I suggest that PEP 472 allow syntax
> and semantics such as
> >>> d[x=1, y=2] = 42
> >>> d[x=1, y=2]
> 42
> and ask
On Fri, 14 Aug 2020 at 11:07, Jonathan Fine wrote:
> NO ARGUMENTS
>
> I'd like d[] to become valid syntax.
This makes me a bit uncomfortable.
> SEMANTICS OF NO ARGUMENTS
> I can see two basic ways of allowing no arguments. One is for the interpreter
> to construct an object that is the
On Fri, 14 Aug 2020 at 05:37, Guido van Rossum wrote:
> My own strawman would be to limit a Matrix to 2-dimensionality -- I believe
> that even my college linear algebra introduction (for math majors!) didn't
> touch upon higher dimensionality, and I doubt that what I learned in high
> school
On Fri, Aug 14, 2020 at 4:38 PM Caleb Donovick
wrote:
> My own personal use for this would be for generating anonymous protocols
> and dataclasses:
>
> class T(Protocol):
> x: int
> y: str
> # with some abuse of notation obviously these would generate unique
> typesassert T ==
On Sat, Aug 15, 2020 at 4:38 PM Caleb Donovick
wrote:
> > Why would it require a metaclass? Rather than just: ...
>
> Because I want the following to be true:
> x = Struct[x=int, y=str](...)
> assert isinstance(x, Struct)
> assert isinstance(x, Struct[x=int, y=str])
> assert not isinstance(x,
> On 15 Aug 2020, at 20:15, Ram Rachum wrote:
>
>
> Here's something that's been bugging me for years. I'll suggest something,
> but since I'm a total newbie about this area, it's possible that everything
> I'm saying is impossible or doesn't make sense.
>
> I'm working with some Pandas
> Why would it require a metaclass? Rather than just: ...
Because I want the following to be true:
```
x = Struct[x=int, y=str](...)
assert isinstance(x, Struct)
assert isinstance(x, Struct[x=int, y=str])
assert not isinstance(x, Struct[x=int, y=int])
```
On Fri, Aug 14, 2020 at 5:27 PM David
> I don't know how to interpret these examples. What's Protocol and where
does it come from? What's Struct?
`Protocol` comes from `typing`
`Struct` is my own class which generates anonymous dataclasses and
protocols as you gathered (unfortunately I currently have two versions one
for building
At most, Python would only be able to tell you the Python name of the function
it invoked.
Traceback for native code is a different can of worms, especially since native
code can be distributed without debugging symbols, ESPECIALLY ON WINDOWS.
If you ever look at a processed native dump file
Here's something that's been bugging me for years. I'll suggest something,
but since I'm a total newbie about this area, it's possible that everything
I'm saying is impossible or doesn't make sense.
I'm working with some Pandas code now, and there's an exception because I'm
doing something wrong.
On Sat, Aug 15, 2020, 11:20 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Ricky Teachey writes:
>
> > Well keep in mind that generally an engineer submits calculations-- not
> > code-- to be reviewed. This leaves me with a few options:
>
> [...]
>
> > Hiding the
Hi Steven
You wrote:
why are we even considering a language change to force every single
> subscriptable object to accept arbitrary keyword-only arguments unless the
> maintainer changes their class to
> explicitly reject them?
I think there might be a misunderstanding here. I'd like to see an
Message below sent in error. Please ignore. I'll send a replacement in a
few minutes. Please accept my apologies.
On Sat, Aug 15, 2020 at 4:30 PM Jonathan Fine wrote:
> Hi Steven
>
>
> Recall that my proposal implies
> >>> d = dict()
> >>> d[a=1, b=2] = 42
> >>> d[a=1, b=2]
> 42
Hi Steven
Recall that my proposal implies
>>> d = dict()
>>> d[a=1, b=2] = 42
>>> d[a=1, b=2]
42
Recall that your proposal implies
>>> d = dict()
>>> d[a=1, b=2] = 42
TypeError: wrapper __setitem__ doesn't take keyword arguments
>
Ricky Teachey writes:
> Well keep in mind that generally an engineer submits calculations-- not
> code-- to be reviewed. This leaves me with a few options:
[...]
> Hiding the portion of code that looks too much like programming (and not
> enough like equations) takes some time, but if I do
On Fri, 14 Aug 2020 at 11:10, Chris Angelico wrote:
> IMO the collections module isn't really right for something like that,
> but if you really need a helper function for this one-liner, then I'd
> say having one in your own code is perfectly reasonable.
In my experience I used it a lot, and I
On Fri, Aug 14, 2020 at 08:58:36PM -0400, Ricky Teachey wrote:
> One problem is type hint creation has been extended to built-ins in python
> 3.9, so that you do not have to import Dict, List, et al anymore.
>
> Without kwd args inside [ ], you would not be able to do this:
>
> Vector =
On Fri, Aug 14, 2020 at 04:07:33PM -0700, Caleb Donovick wrote:
> My own personal use for this would be for generating anonymous protocols
> and dataclasses:
>
> class T(Protocol):
> x: int
> y: str
> # with some abuse of notation obviously these would generate unique
> typesassert T ==
28 matches
Mail list logo
