[Python-ideas] Re: Tracebacks for C code in Python

[Marco Sulla]

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
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IT7PX2W7XL2CSB55OOIQ7N6FTIQC6VTO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: basic matrix object

[Christopher Barker]

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, Python is simply not the right tool for the job of presenting
calculations that look iike math -- Ricky Teachey mentioned MathCAD --
which is indeed a tool for that job. Let's not try to squeeze Python into
that role.

So I don't think that trying to make Python look more like math is a reason
to add a Matrix library to Python.

I'm also very confused about why folks don't want to use numpy for this
stuff? numpy is the right tool for the job, is robust and well supported,
and virtually anyone can pip install it -- yes it took a couple decades to
get to that point, but we really are there now.

But: numpy has a Matrix object, which is pretty much deprecated, and there
is a good reason for that. In a nutshell, the reason is that the only thing
that Matrix gave you for "real work" was a nice operator for matrix
multiplication, and what it lost you was compatibility with the rest of
numpy -- it was really pretty painful to switch between Matrix and regular
numpy arrays. -- when we finally realized that matmult really was the only
important thing -- then adding the @ operator was an excellent solution --
and here we are.

However, that does NOT mean that a Matrix class isn't useful, just that
it's not useful for doing calculations within teh numpy ecosystem, and when
you are doing 'real work", the rest of the numpy ecosystem is very
important.

I highly encourage anyone interested in this topic to search the archives
of the numpy lists to find the many long discussions of this issue -- it
will be very informative. But I'll try to hit a couple highlights, from my
memory:

1) The primary motivator for a "proper" matrix object is pedagogical: being
able to write code that is more or less a direct translation of what one
sees in a linear algebra textbook. Why is that? Because in production code
there may be one or two lines that do a classic linear algebra calculation,
and hundreds of lines that do other things with arrays -- and a numpy-style
ndarray is better suited for those other hundred lines. And when you add @
-- now it's maybe one, rather than two out of hundreds :-).

(I saw a note earlier in this thread about how horrible broadcasting is:
I'm sorry, they are "just wrong" -- broadcasting is really, really, useful
-- far more useful than one or two "proper" linear algebra operations.)

2) The other reason the numpy.Matrix object didn't really work out is that
it didn't quite go far enough: I highly suggest that if one writes a linear
algebra package that seeks to model what we learn in textbooks, that you
have not just a Matrix, but also a Scalar (duh, but MATLAB, for instance
didn't really make that distinction), and a RowVector and ColumnVector
objects -- you could do what numpy Matrix and MATLAB did, and have all
"things" be 2D, and a 1xN matrix is a row vector, and an (Nx1) Matrix is a
column vector -- but I don't recommend it. This was a source of problems
for the numpy Matrix: numpy has a 1d array (i.e. vector) but no way to
distinguish Row vs Column -- it gets awkward. There may be other examples I
can't think of now, but in short: if you are going to do it, really go for
it, make it all about linear algebra, and not try to be a general purpose
array computation system -- we have numpy for that, and we know that mixing
and matching those two does not work out well.

Another suggestion: to leave the door open to better performance (with C or
Cython), I'd consider using an array.array for internal storage, and
support the buffer protocol for interchange with numpy, and image
processing libs, and  If you want to support "non-standard" numeric
types, like Decimal and Fraction, you could have a generic number type and
use a list to store those.

On the other hand, maybe performance simply isn't the point here.

So: does such a thing belong in the standard library? I don't think so. But
then again, I didn't think statistics did either. Though this really is
less useful that the statistics module -- as said above it's really about
teaching more than anything.

Yes, a generally useful array computation lib would be nice -- but if we
went that way, a "numpy-lite" would be the thing to do -- not a Matrix
object.

But in any case, it sure as heck could start out as a PyPi package to
hammer out the wrinkles.

BTW: There MUST be a Python Matrix lib out there already! Here's one that's
not too old.

https://pypi.org/project/matrix7/

I have no idea if it's any good but looking for prior art certainly makes
sense.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Steven D'Aprano]

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 order, since Python 3.6 at least), that should work, right? If
> not, can you clarify?


Just to clarify here, I assume you mean that if xarray cares about 
order-preserving keywords, they should write their methods this way:

def __getitem__(self, index=None, **kwargs):

rather than mandating that keyword args are *always* bundled into a 
single dict parameter.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DV5QYK2XC3RGZV2GDH4J4HJXRNS4PIZH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Steven D'Aprano]

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 `**kw` unpacking?

 
> On the other hand, we probably do need d[**kwargs] since there's no way to
> dynamically unpack keyword arguments (short of directly calling
> __getitem__).


Indeed. So there is an excellent reason to support keyword unpacking, 
and no good reason not to support it. (Assuming keyword args are 
supported at all.)


> And perhaps for symmetry this suggests d[*args] should be
> valid, too, defined as equivalent to d[tuple(args)].

Since positional arguments to `__getitem__` are automatically packed 
into a single argument, there is no need to call it with `*args`. That 
would be a waste of time: have the interpreter unpack the arguments, 
then pack them again. As you say, that makes it functionally equivalent 
to just passing `tuple(args)`.

"For symmetry" is at best a weak argument.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/G2DT2PLYHKJ7NI6EKLYJO2WINXPQYDEE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Stephan Hoyer]

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 instance of a suitable class X that has no special
>>> knowledge of keywords.
>>>
>>> Initially, when I wrote the pep, the idea was that there was no
>>> distinction of kwargs and normal args. Basically the idea was that
>>> currently the only "metainfo" associated to every argument is purely
>>> positional (e.g. the meaning of position 1 is implicit). But index 1
>>> can have a specific semantic meaning (e.g. it could be a day).
>>> So in practice they would be one and the same, just that you add
>>> non-positional semantic meaning to indexes, and you can refer to them
>>> either through the position, or this additional semantic meaning.
>>>
>>> In other words, if you claim that the first index is day, and the
>>> second index is detector, somehow, there is no difference between
>>> these
>>>
>>> d[3, 4]
>>> d[day=3, detector=4]
>>> d[detector=4, day=3]
>>>
>>> In fact, my initial feeling would be that you can use either one or
>>> the other. You should not be able to mix and match.
>>>
>>> the pep went through various revisions, and we came to a possible
>>> proposal, but it's not set in stone.
>>>
>>
>> This would definitely not be sufficient for xarray, which I see as being
>> one of the main users of this syntax.  The whole point is to be able to
>> specify an arbitrary subset labeled dimensions.
>>
>
> 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 order, since Python 3.6 at least), that should work, right? If
> not, can you clarify?
>

An extra **kwds would be quite sufficient for xarray. We don't need to
distinguish between `d[day=3, detector=4]` and `d[day=4, detector=3]`, at
least not any differently from normal Python keyword arguments.

What might not suffice is a required one-to-one mapping between positional
and keyword arguments. Xarray has a notion of a "Dataset" that contains
multiple arrays, some of which may have different dimensions or dimensions
in a different order. For this reason, on Dataset we allow keyword-based
indexing, but not positional-based indexing. This is basically the same as
the use-cases for keyword-only parameters.

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.

On the other hand, we probably do need d[**kwargs] since there's no way to
dynamically unpack keyword arguments (short of directly calling
__getitem__). And perhaps for symmetry this suggests d[*args] should be
valid, too, defined as equivalent to d[tuple(args)].


>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TGNFCU24YK36BOLKULDB36JRW73VTJGC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K3ASWL4AZU6RVE2NLT5QEWYW2PBPZRR2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Guido van Rossum]

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 keywords.
>>
>> Initially, when I wrote the pep, the idea was that there was no
>> distinction of kwargs and normal args. Basically the idea was that
>> currently the only "metainfo" associated to every argument is purely
>> positional (e.g. the meaning of position 1 is implicit). But index 1
>> can have a specific semantic meaning (e.g. it could be a day).
>> So in practice they would be one and the same, just that you add
>> non-positional semantic meaning to indexes, and you can refer to them
>> either through the position, or this additional semantic meaning.
>>
>> In other words, if you claim that the first index is day, and the
>> second index is detector, somehow, there is no difference between
>> these
>>
>> d[3, 4]
>> d[day=3, detector=4]
>> d[detector=4, day=3]
>>
>> In fact, my initial feeling would be that you can use either one or
>> the other. You should not be able to mix and match.
>>
>> the pep went through various revisions, and we came to a possible
>> proposal, but it's not set in stone.
>>
>
> This would definitely not be sufficient for xarray, which I see as being
> one of the main users of this syntax.  The whole point is to be able to
> specify an arbitrary subset labeled dimensions.
>

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 order, since Python 3.6 at least), that should work, right? If
not, can you clarify?

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TGNFCU24YK36BOLKULDB36JRW73VTJGC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Todd]

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 that there was no
> distinction of kwargs and normal args. Basically the idea was that
> currently the only "metainfo" associated to every argument is purely
> positional (e.g. the meaning of position 1 is implicit). But index 1
> can have a specific semantic meaning (e.g. it could be a day).
> So in practice they would be one and the same, just that you add
> non-positional semantic meaning to indexes, and you can refer to them
> either through the position, or this additional semantic meaning.
>
> In other words, if you claim that the first index is day, and the
> second index is detector, somehow, there is no difference between
> these
>
> d[3, 4]
> d[day=3, detector=4]
> d[detector=4, day=3]
>
> In fact, my initial feeling would be that you can use either one or
> the other. You should not be able to mix and match.
>
> the pep went through various revisions, and we came to a possible
> proposal, but it's not set in stone.
>

This would definitely not be sufficient for xarray, which I see as being
one of the main users of this syntax.  The whole point is to be able to
specify an arbitrary subset labeled dimensions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SJU4YXHOU27CIKPGDKIDJ6EB3H4XR253/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Guido van Rossum]

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 already do with a class definition and annotations). And
> without static checking this isn't going to be very popular.
>
> You underestimate my willingness to generate python files which could be
> consumed by static checkers via a preprocessing step.   Also, my real goal
> is to abuse type hints for the purposes of my DSL.  But DSL is a nuaghty
> term on the list so we won't mention that :)
>

Fine, so the use case you claimed was fiction. If you had just said "DSL"
instead of "anonymous protocols and dataclasses" you would have gotten
straight to the point and we would have been talking about whether extended
subscription would be useful for DSLs (I can see various use cases), rather
than arguing over whether Struct can be spelled with () instead of [] (a
total waste of time).

In fact, I don't know why you think "DSL" is a naughty term. (I find
"runtime use of annotations" much naughtier. :-)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KJB3BK7MBHOS4MGKQLPV7Y7ZGFXIULEO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Caleb Donovick]

> 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
about the square brackets other than notation but having a visual
distinction of type creation and instantiation is useful.

On Sat, Aug 15, 2020 at 3:44 PM David Mertz  wrote:

> 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, Struct[x=int, y=int])
>>
>
> Hmm... OK, that's an interesting desire.  How do square brackets get you
> any closer to that?
>
> If this proposal, in whatever variation, is adopted, `Struct[x=int,
> y=str]` is going to be some kind of call to .__getitem__().  There is some
> debate about exactly how the information gets passed into the method, but
> we can bracket that for this question.  One way or another, positional and
> named arguments are available to this future .__getitem__().
>
> So how do you make this true:
>
> assert isinstance(x, Struct.__getitem__(x=int, y=str))
> assert not isinstance(x, Struct.__getitem__(x=int, y=int))
>
> For demonstration, maybe it's easiest just to give a new name to the
> hypothetical method.  Say `Struct.bracket(...)`. It's not obvious to me how
> you'll get the behavior you want.
>
> ... and if you CAN get the behavior, why can't we name this method
> .__call__()?
>
> I'm not really sure what kind of thing Struct is meant to be, as well. Is
> it a class? An instance? A class factory? A metaclass?
>
>
> --
> The dead increasingly dominate and strangle both the living and the
> not-yet born.  Vampiric capital and undead corporate persons abuse
> the lives and control the thoughts of homo faber. Ideas, once born,
> become abortifacients against new conceptions.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NQXZKISQQ6DJM4IOZGURB62G32DBWMCM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Caleb Donovick]

>  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 static checking this isn't going to be very popular.

You underestimate my willingness to generate python files which could be
consumed by static checkers via a preprocessing step.   Also, my real goal
is to abuse type hints for the purposes of my DSL.  But DSL is a nuaghty
term on the list so we won't mention that :)





On Sat, Aug 15, 2020 at 4:05 PM Guido van Rossum  wrote:

> 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=int, y=str]
>> # similarly @dataclassclass S:
>>x: int
>>y: str
>> assert S == Struct[x=int, y=str]
>>
>> I often want to create such types “on the fly” without needing to put a
>> name on them.
>>
>> Now as I don’t need mixed keyword / positional arguments I can achieve
>> this with:
>>
>> # K = dict
>> Struct[K(x=int, y=str)]
>>
>> But that costs 3 more keystrokes and is certainly less beautiful.
>>
>> While I would not personally use this I think a real killer app would be
>> slicing named axis, as the slice syntax is exclusive to geitem and hence
>> can not leverage the dict trick.
>>
> 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 static
> checking this isn't going to be very popular.
>
> If and when we have `__getitem__` with keyword args we can start thinking
> about how to best leverage it in type annotations -- I would assume that
> describing axes of objects like numpy arrays would be the first use case.
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JVBCKBGBCZ2VMLMXXUCZTG3GLY3CHOHU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: basic matrix object

[Greg Ewing]

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 least have the ability to invert a square
matrix.

And once you have the machinery for that, it's only a small step
to use it for solving systems of equations, so we might as well
provide that too. It would cost very little extra, and might be
useful.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YW5P5C73RFGBREIGSWAAXR4YZK3JDGYU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Guido van Rossum]

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 whether the class
> >>> X = type(d)
> should be part of standard Python.
>

This way of phrasing it rubs me the wrong way. The way Python is defined,
notations like `x+y` or `a[i]` translate to dunder calls and we separately
specify which built-in types support which dunder methods. If you think
`dict` should support the extended subscript notation, just say so, don't
play guessing games with `X = type(d)`. (You've given the answer away by
naming the variable `d` anyway.)

Personally I think `dict` should *not* support the extended subscript
notation, but I think the extended `__getitem__` protocol should support
passing just keyword args.


> NO ARGUMENTS
> At present, item access requires an argument, as a matter of syntax.
> >>> d[]
> SyntaxError: invalid syntax
>
> Compare this to
> >>> fn()
> NameError: name 'fn' is not defined
>
> I'd like d[] to become valid syntax.
>

This looks like a syntax error that would trip over a lot of people. I
guess we could make it less dangerous if common types like `dict` rejected
this at runtime. But if you insist that `dict` should support keyword args,
I would personally insist on making this syntax illegal.


> 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 argument passed to
> __getitem__ and so forth. The other is to not pass an argument at all. I
> see this as a secondary question.
>

The signatures could be
```
def __getitem__(self, index=default, /, **kwargs): ...
def __setitem__(self, index=default, value, /, **kwargs): ...
```
A class that doesn't want to support `a[]` would indicate so by not
providing a default index, and then it would simply raise a TypeError, just
like calling a function with a missing required argument.


> NO POSITIONAL ARGUMENTS
> I'd like
> >>> d[x=1, y=2]
> to be valid syntax. It's not clear to me that all agree with this. Even if
> there are no objections, I'd like positive confirmation.
>

Both Greg Ewing and Steven D'Aprano agree with this, and it looks fine to
me as well, so I think you've got this.


> CONSEQUENCE
> Suppose
>>>> d[x=1, y=2]
> is valid syntax. If so, then there is I think consensus that
> >>> d[x=1, y=2] = 42
> >>> d[x=1, y=2]
> 42
> can be implemented, where d is an instance of a suitable class. Otherwise,
> what's the point?
>

Yes of course. A MutableMapping subclass that wanted to do this could be
defined like this:
```
class KeyKey(MutableMapping):

def __getitem__(self, key=None, /, **kwds):
return super().__getitem__(self.makekey(key, kwds))

def __setitem__(self, key=None, value, /, **kwds):
return super().__setitem__(self.makekey(key, kwds), value)

@classmethod
def makekey(self, key, kwds):
return (key, tuple(sorted(kwds)))  # Or something more sophisticated
```
(A few other methods would have to be added, like `__delitem__` and
`__contains__`; the caller of `__contains__` would need to know about the
makekey() method.)


> 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.
>

Why should X not be required to have knowledge of keywords?


> In other words, we also have for example
> >>> d[a='alpha', g='gamma', z=12] = 'cheese'
> >>> d[a='alpha', g='gamma', z=12]
> 'cheese'
>
> My question is this: Should such a class
>>>> X = type(d)
> be part of standard Python, as part of PEP 472? (My answer is: Yes, it
> should be in standard Python.)
>
> At this time, I'm interested in canvassing opinions. Discussion of
> different opinions perhaps can take place later, or elsewhere. My main
> concern is to know if there is at present a rough consensus regarding the
> above.
>

I don't think you have consensus at all -- in fact I haven't seen anyone
besides you agreeing that `d[x=1, y=2]` should construct a key of a special
type and pass that to `__getitem__` -- everyone else (including myself)
appears to think that it's better to pass the keyword args to `__getitem__`
and decide the edge cases based on that.

FWIW in my example I sorted the keywords, so that `d[x=1, y=2]` and `d[y=2,
x=1]` construct the same internal key. But for some use cases it might be
better if these constructed *different* internal keys. For example, Caleb's
Struct class, when used to construct a dataclass, would need to be able to
tell them apart, since the field order in a dataclass is part of the type
-- the argument order of the constructor depends on it.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pro

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Stefano Borini]

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 argument passed to __getitem__ and so 
> forth. The other is to not pass an argument at all. I see this as a secondary 
> question.

I understand it makes sense if you assume that you can have default
arguments. but still it's kind of weird. and it's not always obvious
how each structure is going to implement it.

> NO POSITIONAL ARGUMENTS
> I'd like
> >>> d[x=1, y=2]
> to be valid syntax. It's not clear to me that all agree with this. Even if 
> there are no objections, I'd like positive confirmation.

Yes, it should be.

> CONSEQUENCE
> Suppose
>>>> d[x=1, y=2]
> is valid syntax. If so, then there is I think consensus that
> >>> d[x=1, y=2] = 42
> >>> d[x=1, y=2]
> 42
> can be implemented, where d is an instance of a suitable class. Otherwise, 
> what's the point?

Yes. Agreed.


> 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 that there was no
distinction of kwargs and normal args. Basically the idea was that
currently the only "metainfo" associated to every argument is purely
positional (e.g. the meaning of position 1 is implicit). But index 1
can have a specific semantic meaning (e.g. it could be a day).
So in practice they would be one and the same, just that you add
non-positional semantic meaning to indexes, and you can refer to them
either through the position, or this additional semantic meaning.

In other words, if you claim that the first index is day, and the
second index is detector, somehow, there is no difference between
these

d[3, 4]
d[day=3, detector=4]
d[detector=4, day=3]

In fact, my initial feeling would be that you can use either one or
the other. You should not be able to mix and match.

the pep went through various revisions, and we came to a possible
proposal, but it's not set in stone.

> In other words, we also have for example
> >>> d[a='alpha', g='gamma', z=12] = 'cheese'
> >>> d[a='alpha', g='gamma', z=12]
> 'cheese'
>
> My question is this: Should such a class
>>>> X = type(d)
> be part of standard Python, as part of PEP 472? (My answer is: Yes, it should 
> be in standard Python.)

Yes and no. In my opinion, the current classes (e.g. dict) *may* be
extended to support this (optional) functionality. But the target
should probably be something like numpy or pandas, or any other class
that wants the flexibility for a named index approach.
I would not add X to python stdlib.

-- 
Kind regards,

Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BEVAR5LB5SN66RBR7DRAHSBWMHUUKLSJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: basic matrix object

[Stefano Borini]

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 about the topic went beyond 3x3 (it might not even have treated 
> non-square matrices).

Absolutely agree, dimensionality 2 is a must. For two reasons. First,
it's easy to understand and implement. Second it actively discourages
those who would like to use this matrix for real calculations. The
main point is basic and simple: teaching, geometry computation (e.g.
on point rotation/translation) etc. Things like that.
Anything else is beyond the scope of such a module and should be
implemented using numpy.

Calculations about determinant, element-wise operations, matrix
multiplication, inverse, etc are also basic operations that are likely
to come up during either a course or trivial computations for e.g.
geometry. I would not add things like QR or Cholesky factorization.


-- 
Kind regards,

Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UQDBXSVCLARFIGNIZPYGIJ5S4M7VPMCO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Guido van Rossum]

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=int, y=str]
> # similarly @dataclassclass S:
>x: int
>y: str
> assert S == Struct[x=int, y=str]
>
> I often want to create such types “on the fly” without needing to put a
> name on them.
>
> Now as I don’t need mixed keyword / positional arguments I can achieve
> this with:
>
> # K = dict
> Struct[K(x=int, y=str)]
>
> But that costs 3 more keystrokes and is certainly less beautiful.
>
> While I would not personally use this I think a real killer app would be
> slicing named axis, as the slice syntax is exclusive to geitem and hence
> can not leverage the dict trick.
>
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 static
checking this isn't going to be very popular.

If and when we have `__getitem__` with keyword args we can start thinking
about how to best leverage it in type annotations -- I would assume that
describing axes of objects like numpy arrays would be the first use case.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3DE7QVHYC4PV2CBAPETROWPJU2YV5HNN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[David Mertz]

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, Struct[x=int, y=int])
>

Hmm... OK, that's an interesting desire.  How do square brackets get you
any closer to that?

If this proposal, in whatever variation, is adopted, `Struct[x=int, y=str]`
is going to be some kind of call to .__getitem__().  There is some debate
about exactly how the information gets passed into the method, but we can
bracket that for this question.  One way or another, positional and named
arguments are available to this future .__getitem__().

So how do you make this true:

assert isinstance(x, Struct.__getitem__(x=int, y=str))
assert not isinstance(x, Struct.__getitem__(x=int, y=int))

For demonstration, maybe it's easiest just to give a new name to the
hypothetical method.  Say `Struct.bracket(...)`. It's not obvious to me how
you'll get the behavior you want.

... and if you CAN get the behavior, why can't we name this method
.__call__()?

I'm not really sure what kind of thing Struct is meant to be, as well. Is
it a class? An instance? A class factory? A metaclass?


-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S4SBAXTZD6KANWWYO3FY5H5WRVSZLBYN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Tracebacks for C code in Python

[Barry]

> 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 code now, and there's an exception because I'm 
> doing something wrong. I get a traceback, but some of the frames are in pyd 
> files (C code I guess?) so I don't see the code for them.
> 
> This is frustrating, because the exception message isn't that clear, so I 
> would at least like to know what the code was trying to do when it got the 
> exception. Maybe this will give me more hints about what's going wrong.
> 
> Would it be possible to have Python tracebacks include code for C code that's 
> called in Python?

On Linux gdb can show the python and c code stack at the same time.

Barry

> 
> I know very little about how the C-to-Python interaction works, and I assume 
> we'd need something complicated like packaging the source code with the 
> binaries in some way that lets Python get the right line of C code to put in 
> the traceback. This can get complicated.
> 
> Do you think it's possible?
> 
> 
> Thanks,
> Ram.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/2EAJ6IZ5QHW6GNPIQQBOOZ2MT4WLBCQT/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HUEXNTQJE5OXJ5KYZB25H6LVSS5AFLM4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Caleb Donovick]

> 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 Mertz  wrote:

>
> On Fri, Aug 14, 2020, 7:53 PM Caleb Donovick 
> wrote:
>
>> > I don't see what that can possible get you that `Struct(x=int, y=str)`
>> doesn't.
>>
>> Using `Struct(x=int, y=str)` requires a metaclass, where `Struct[x=int,
>> y=str]` does not.
>>
>
> Why would it require a metaclass? Rather than just:
>
> class Struct:
> def __init__(self, **kws): ...
>
> Yes, that won't get you the MRO for T, but neither can __getitem__() on an
> entirely different object Struct.
>
> A class factory is also an option, of course.
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S5II33XWAICKHHR47OCKVPKURKZRZGTU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Caleb Donovick]

>  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 the protocol and one for building the dataclass but thats
because of stupid engineering requirements).



On Fri, Aug 14, 2020 at 11:14 PM Steven D'Aprano 
wrote:

> 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 == Struct[x=int, y=str]
>
> I don't know how to interpret these examples. What's Protocol and where
> does it come from? What's Struct?
>
> As I recall, one of the motivations for re-visiting PEP 472 is to allow
> such keyword notation in type hints, so that we could write
>
> Struct[x=int, y=str]
>
> in a type hint and have it mean a struct with fields x (an int) and y (a
> str). I'm not sure whether that use in type hinting would allow the use
> of this Struct to create anonymous classes. I suppose it would, but I'm
> not expert enough on type hints to be sure.
>
> But assuming the two uses are compatible, I must say that having the
> same notation for type-hinting a struct and actually creating an
> anonymous struct class would be desirable:
>
> def func(widget:Struct[x=int, y=str]) -> gadget:
> pass
>
> # Later:
> MyWidget = Struct[x=int, y=str]
>
> func(MyWidget(19, 'hello'))
>
> I really like the look of that, and I think that having the Struct call
> use the same subscript notation as the Struct type hint is a plus.
>
>
> > While I would not personally use this I think a real killer app would be
> > slicing named axis, as the slice syntax is exclusive to geitem and hence
> > can not leverage the dict trick.
>
> This is one of the motivating use-cases of PEP 472.
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/HLXSO2KSOB62Z4RI7SA52DHWGCGECATC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TQHBPRCHNEPOFGBRKSB32VX4F5NY34G7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Tracebacks for C code in Python

[William Pickard]

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 for a Windows application, all 
you would see for the most part is memory addresses of the invoked function 
plus the offset from that address. If you had the debugging symbols, you would 
get the unmangled? name plus the offset.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S736B363SMZSLTTHHNYMNLB3UBIJV3BO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Tracebacks for C code in Python

[Ram Rachum]

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. I get a traceback, but some of the frames are in pyd
files (C code I guess?) so I don't see the code for them.

This is frustrating, because the exception message isn't that clear, so I
would at least like to know what the code was trying to do when it got the
exception. Maybe this will give me more hints about what's going wrong.

*Would it be possible to have Python tracebacks include code for C code
that's called in Python?*

I know very little about how the C-to-Python interaction works, and I
assume we'd need something complicated like packaging the source code with
the binaries in some way that lets Python get the right line of C code to
put in the traceback. This can get complicated.

Do you think it's possible?


Thanks,
Ram.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2EAJ6IZ5QHW6GNPIQQBOOZ2MT4WLBCQT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: basic matrix object

[Ricky Teachey]

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 of code that looks too much like programming (and not
>  > enough like equations) takes some time, but if I do not do this it will
>  > inevitably lead to a 40 minute phone call [...].
>
> Ah, I misinterpreted your statement that engineers don't much use
> linear algebra.  You *do* use it for *presentation*, but it's not very
> useful in the programming that gets your results.
>


Yes I'd say this is generally true most of the time. 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, and if I do
need to do it, I can always use Mathcad.

General comment: a lot of my "I wish" thoughts regarding python syntax have
to do with the idea that code could look more like handwritten mathematical
calculations. But I recognize that a balance has to be maintained.



> > Furthermore, the same NYDoT reviewer might come back and say:
>  >
>  > *"Rejected: calculation does not take into account change in friction
> angle
>  > with depth."*
>  >
>  > The official would be saying that friction (μ_s) is not a scalar, it
> should
>  > be another array variable, because the soils apply different friction
> along
>  > the shaft depth.
>
> I don't think Steven's proposed matrix class can substitute for numpy
> in general.  It will work for your case because '*' can be both scalar
> multiplication and matrix multiplication.  That is, the scalar μ_s
> (float, I presume?) doesn't know how to self.__mul__(q_s), but
> q_s.__rmul__(μ_s) works fine.  Then tmp.__mul__(C_shaft) (C_shaft a
> scalar or a vector of the same length) works.  But if you have *two*
> variables, and the reviewer claims they have different (scalar)
> coefficients, you're going to need numpy-style broadcasting.
>

I actually started trying to write a proof of concept for this last night.
I'm sure it will be far far less usable and correct then Steven's but if I
get it working I'll share it just for comparison of ideas.


 > >>>  γ_per_ft = matrix( [120, 122, 118, 117] )
>  > >>> print(f"{γ_per_ft=:.0f} pcf")
>  > (120, 122, 118, 117) pcf
>  >
>  > The idea here is that python knows the datatype of  γ_per_ft is float,
> so
>  > it can format all the members of the array *one at a time*.
>
> I think all you need to do is provide an appropriate __format__ method
> on matrix objects.  That method will have access to the format spec
> (ie, everything after the colon), and if there isn't a parser you can
> just import, I'm sure there are plenty you can copy.  At least for
> this case you can just apply it to the individual elements.
>
> It's not obvious to me that elementwise is the "right" way to
> implement matrix.__format__ (there may be "matrix-level" formatting
> that takes precedence, for example how to treat rows wider than the
> page width), but it's quite plausible.  Of course you can also derive
> a simple subclass with elementwise __format__.
>


I'm going to try to solve this with my toy implementation, too. If it get
it working I'll be sure to pass it along for comment.

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZWCHWUROLQOP3QRW5KWIHF5GNPGP2TIQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Jonathan Fine]

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 example
of where such a change would be required (see my conclusion below).

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

Your statement above helps me understand the motivation for your proposal,
for which I'm grateful. However, there might be a misunderstanding.

I'd like now to show you a consequence of my proposal.  First consider
>>> lst = []
>>> lst['a']
TypeError: list indices must be integers or slices, not str

A dict will accept any hashable object as the key, but every list raises a
type error if a string is passed as the index. No special action is
required, for the list to reject a string as the index.

Let's see what happens when we pass a keyword key to a list.
>>> from kwkey import o
>>> lst = []
>>> lst[o(a=1)]
TypeError: list indices must be integers or slices, not K

My proposal implies that the following be equivalent
>>> anything[o(1, 2, a=3, b=4)]
>>> anything[1, 2, a=3, b=4]
for a suitable definition of 'o'. And kwkey I believe will provide such an
'o' (once the bugs have been removed - see below).

CONCLUSION
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 don't see how this is a consequence of my proposal. To help me
understand, please provide an example such as
>>>  something[o(1, 2, a=3, b=4)] = 42
>>>  something[o(1, 2, a=3, b=4)]
whose behaviour is unexpected or unwelcome. (You might want to wait until
I've fixed the bug stated below.)

CONFESSION
There's a serious bug in kwkey. We don't have
>>> o(key) == key
True
but we should have that. Please accept my apologies.

I've reported the bug, and there'll be a new release next week.
https://github.com/jfine2358/python-kwkey/issues/2

-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CN5F3ATZ6ICMBRQMZ623NLXVFTDTGCKK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Jonathan Fine]

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
>
> Recall that your proposal implies
> >>> d = dict()
> >>> d[a=1, b=2] = 42
> TypeError: wrapper __setitem__ doesn't take keyword arguments
>
>
>>
>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7RNITRYNTORZ5VY547L5QPWXD5SKPB47/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar

[Jonathan Fine]

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


>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XR66NQ4LJ4CFK3JAQHQXJLDJGK5MAF6V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: basic matrix object

[Stephen J. Turnbull]

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 not do this it will
 > inevitably lead to a 40 minute phone call [...].

Ah, I misinterpreted your statement that engineers don't much use
linear algebra.  You *do* use it for *presentation*, but it's not very
useful in the programming that gets your results.

 > Furthermore, the same NYDoT reviewer might come back and say:
 > 
 > *"Rejected: calculation does not take into account change in friction angle
 > with depth."*
 > 
 > The official would be saying that friction (μ_s) is not a scalar, it should
 > be another array variable, because the soils apply different friction along
 > the shaft depth.

I don't think Steven's proposed matrix class can substitute for numpy
in general.  It will work for your case because '*' can be both scalar
multiplication and matrix multiplication.  That is, the scalar μ_s
(float, I presume?) doesn't know how to self.__mul__(q_s), but
q_s.__rmul__(μ_s) works fine.  Then tmp.__mul__(C_shaft) (C_shaft a
scalar or a vector of the same length) works.  But if you have *two*
variables, and the reviewer claims they have different (scalar)
coefficients, you're going to need numpy-style broadcasting.

Also, you're going to run into the issue that Steven is probably going
to use '@' for matrix multiplication for numpy compatibility as
requested by several people, while * will be elementwise
multiplication.

Finally you lose the convenience function like linspace.

Overall, it may still be worthwhile, and Steven may give you the
operator you want (whether it's '*' or '@' for matrix multiplication).

 > The answer is yes. It's a good question on the linspace() function -- I
 > don't think so.
[...]
 > However I would certainly hide this part of the code, and include the copy
 > and pasted result from this:
 > 
 > print(f"γ_per_ft = ({', '.join(f'{v:.0f}' for v in z)}) pcf")

Aaarggh!  What we do for money and to please reviewers 

 > Sidebar: it would be pretty fantastic if a native matrix library could
 > display values using f-strings like this:
 > 
 > >>>  x = 1.1
 > >>> print(f"{x=:.0f} pcf")
 > 1 pcf
 > >>>  γ_per_ft = matrix( [120, 122, 118, 117] )
 > >>> print(f"{γ_per_ft=:.0f} pcf")
 > (120, 122, 118, 117) pcf
 > 
 > The idea here is that python knows the datatype of  γ_per_ft is float, so
 > it can format all the members of the array *one at a time*.

I think all you need to do is provide an appropriate __format__ method
on matrix objects.  That method will have access to the format spec
(ie, everything after the colon), and if there isn't a parser you can
just import, I'm sure there are plenty you can copy.  At least for
this case you can just apply it to the individual elements.

It's not obvious to me that elementwise is the "right" way to
implement matrix.__format__ (there may be "matrix-level" formatting
that takes precedence, for example how to treat rows wider than the
page width), but it's quite plausible.  Of course you can also derive
a simple subclass with elementwise __format__.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5VDP2AG7VE637TRHTT2ZAG4W4MRNKLLM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Syntactic sugar for checking if a variable is an iterable but not a string?

[Marco Sulla]

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 saw many devs online that
implemented their solution or asked about it. Not sure if collections
module is appropriate, but IMO an helper function will be very useful.

@Steven: I continue the discussion with your objections in private.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EH4QKKZGVVVJJT2HETVCSLCXNJRJEEF2/
Code of Conduct: http://python.org/psf/codeofconduct/