You probably wants also the python extension for gdb, to go faster to
the interesting code:
https://stackoverflow.com/q/41160447/1763602
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
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 frankly,
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 orde
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 supporting
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 i
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 keyw
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 th
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 alre
> 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
ab
> 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 sta
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 leas
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 argumen
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 == Struct[x=i
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, Str
> 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 co
> 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 M
> 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 th
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 fo
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 portion
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 n
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 s
27 matches
Mail list logo
