On 2020-02-23 19:35, Aaron Hall via Python-ideas wrote:
My main goal here is to increase the flexibility of Python for
various domains where I have used `object0 ~ object1` - and can't yet
do so in Python.
You've said something like this a couple times in this thread, but
personally I don't
Thanks for the feedback, David. Sources that demonstrate that "sim" is the
wrong semantic would be very much appreciated.
I chose "sim" because it's the same name and usual top usual result for an
infixed tilde in LaTeX.
And note that there is an implied relationship between the two sides in
I am not yet a contributor to either, I have an invitation to contribute to
Sympy, and I have contributed to CPython, and I would like to be a contributor
on all of these libraries
(You might know me from my answers on Stack Overflow, and I gave the slots talk
at PyCon 2017 where we met - now
Jim, thanks for your feedback. I didn't intend for this to address the
interaction term syntax.
As you can see the R language has several ways of representing the same
information:
https://stat.ethz.ch/R-manual/R-devel/library/stats/html/formula.html
I would prefer to write, e.g.: `y ~
On 2020-02-24 02:22, Chris Angelico wrote:
On Mon, Feb 24, 2020 at 1:00 PM C. Titus Brown wrote:
WHATS WRONG WITH TOP POSTING IN ALL CAPS AND NO PUNCTUATION!?!?!?!
:)
Oh, it's alright, you just put all the punctuation at the end :)
Not all of it; it's still missing an apostrophe. :-)
On Mon, Feb 24, 2020 at 1:00 PM C. Titus Brown wrote:
>
> WHATS WRONG WITH TOP POSTING IN ALL CAPS AND NO PUNCTUATION!?!?!?!
>
> :)
Oh, it's alright, you just put all the punctuation at the end :)
ChrisA
___
Python-ideas mailing list --
Aside from all the other problems, 'sim' (~) in LaTeX and mathematics means
something completely different than 'depends on' (~) in R. Trying to
overload those meaning makes everything harder.
I would recommend doing what NumPy did for many years for matrix multiply.
Use an existing operator. Yes
WHATS WRONG WITH TOP POSTING IN ALL CAPS AND NO PUNCTUATION!?!?!?!
:)
No one has complained to the moderators that CoC is being violated. and if they
did, there’s a whole bunch of safeguards to ensure that it’s not being misused.
I do occasionally (once or twice a year?) place specific
On Mon, Feb 24, 2020 at 10:04 AM Steven D'Aprano wrote:
> > At any rate, we should be able to control what we say and how we say it,
> > adult or not.
>
> Indeed we should. And if that means we want to call a shitty piece of
> software a shitty piece of software, especially when it's our own
>
Are you a contributor or core dev on one of those packages? That would be
useful context to have.
Also, did you see Jim Baker's module? How do you propose to translate
Patsy's ':' operator?
On Sun, Feb 23, 2020 at 5:22 PM Aaron Hall via Python-ideas <
python-ideas@python.org> wrote:
> > Is
> Is there an existing function in one of the libraries you mention
> that has the desired behavior (in the context of that library)? That would
> help.
Yes, and we are currently parsing and evaluating strings to convey the meaning.
Patsy is currently used by statsmodels to parse strings in the
On 2020-02-23 15:58, Aaron Hall via Python-ideas wrote:
(Apologies for the html email, it was poorly formatted, making my example very
difficult to follow. So let me try to give better examples.)
With sympy we would be able to create meaningful behavior for:
```
from sympy import symbols
y,
Aaron,
It's too soon to start drafting a PEP. However you need to get at least one
core dev to understand your proposal well enough that they will act as a
*sponsor* for your proposal. Once you have a willing sponsor you can then
put it forward in PEP form. See PEP 1 for PEP sponsorship when the
Supporting ~ as a binary operator is an interesting idea, especially given
the relatively limited usage of unary ~. However, the big hole in this
proposal for formulas is that there is a de facto standard "minilanguage"
for writing such formulas in Python, namely what Patsy supports:
On 2020-02-23 16:32, Guido van Rossum wrote:
> Assuming that the reader is familiar with the example `Lottery ~
> Literacy + Wealth + Region` is *not* going to work. I have literally no
> idea from what field that is taken or what the purpose of the example
> is. Please don't expect that I can
Guido, thank you so much for your kind review.
I think I would prefer
```
(A ~ B) + C
```
as it would first create a coalescing object to which it knows C is added, and
this is the usual way it is used.
I believe Sympy could handle it easily either way, but dataframes/arrays less
well so
Aaron Hall wrote:
> Currently, Python only has ~ (tilde) in the context of a unary operation (like
> -, with __neg__(self), and +, __pos__(self)).
> ~ currently calls __invert__(self) in the unary context.
> I think it would be awesome to have in the language, as it would allow
> modelling along
I still can't follow this explanation.
Operators in Python have a priority, which determines order of evaluation.
In the example
A ~ B + C
is this equivalent to
A ~ (B + C)
or to
(A ~ B) + C
???
It's not unheard of to add an operator to Python that's primarily important
for a
I have no behavior for integers in mind. I would expect high-level libraries to
want to implement behavior for it.
- sympy
- pandas, numpy, sklearn, statsmodels
- other mathematically minded libraries (monadic bind or compose?)
To do this we need a name. I like `__sim__`. Then we'll need
On 2/23/20 5:01 PM, Sebastian Berg wrote:
The main issue is generic code. Sequence like lists and tuples are
often iterated over: You work with the elements inside.
However, in the same code, often strings are actually not desired to be
handled as sequences.
I.e. some code uses strings as
On 2020-02-23 16:00, João Matos wrote:
Hello,
Can't you use eval()?
This
return eval(expr)
instead of
return expr.evaluate()
You can use eval if expr is a string, but then you have the same
problems that were mentioned in a recent thread about "SQL strings":
it's not syntax-highlighted,
Hello,
Can't you use eval()?
This
return eval(expr)
instead of
return expr.evaluate()
Best regards,
João Matos
On 23/02/2020 23:04, Brendan Barnwell wrote:
On 2020-02-23 14:38, Steven D'Aprano wrote:
Hi Aaron, and welcome!
Your proposal would be a lot more interesting to me if I knew
(Apologies for the html email, it was poorly formatted, making my example very
difficult to follow. So let me try to give better examples.)
With sympy we would be able to create meaningful behavior for:
```
from sympy import symbols
y, x1, x2 = symbols('y x1 x2')
model = y ~ x1 + x2
Greg Ewing wrote:
> On 24/02/20 9:32 am, jdve...@gmail.com wrote:
> > It is a common "pattern" in any languages to walk
> > along strings,
> > letter by letter.
> > Maybe in some other languages, but I very rarely find myself doing
> that in Python. There is almost always some higher level way of
Alex Hall wrote:
> > Strings already have an exception in this area. Usually x in y means
> any(x == elem for elem in y). It makes the two meanings of in
> match
Actually, `in` means the same in strings, in sequences, in lists, etc. But, in
Python's view, a string is composed of sub-strings,
On 2020-02-23 14:38, Steven D'Aprano wrote:
Hi Aaron, and welcome!
Your proposal would be a lot more interesting to me if I knew what this
binary ~ would actually do, without having to go learn R or LaTeX.
You say:
I think it would be awesome to have in the language, as it would allow
I've been sitting on this email for the best part of a week. It hasn't
been an easy decision to decide to send it, because I expect it will
ruffle some feathers, including someone who, last time I ruffled his
feathers, banned me from one of the other mailing lists.
But I am part of this
On 24/02/20 9:32 am, jdve...@gmail.com wrote:
It is a common "pattern" in any languages to walk along strings,
letter by letter.
Maybe in some other languages, but I very rarely find myself doing
that in Python. There is almost always some higher level way of
doing what I want.
if strings
Sebastian Berg wrote:
> However, in the same code, often strings are actually not desired to be
> handled as sequences.
> I.e. some code uses strings as sequences of characters, but most code
> probably uses the meaning that a string is a word, or sentence: the
> individual character has no
Hi Aaron, and welcome!
Your proposal would be a lot more interesting to me if I knew what this
binary ~ would actually do, without having to go learn R or LaTeX.
You say:
> I think it would be awesome to have in the language, as it would allow
> modelling along the lines of R that we
23.02.20 23:51, Aaron Hall via Python-ideas пише:
This is not a fully baked idea, perhaps there's a good reason we haven't
added a binary `~`. It seems like I've seen discussion in the past. But
I couldn't find such discussion. And as I'm currently taking some
statistics courses, I'm getting
On Sun, Feb 23, 2020 at 11:25:12PM +0200, Alex Hall wrote:
> "Strings are not iterable - you cannot loop over them or treat them as a
> collection.
Are you implying that we should deprecate the `in` operator for strings
too?
Strings *are* collections:
py> import collections.abc
py>
Alex Hall wrote:
> I've also had to special case strings when dealing with iterables
> generically, and it's annoying, but it's not a big deal. The real problem
> is when you meant to pass an iterable of strings and you just passed a
> single string and it produces confusing behaviour - something
Steven D'Aprano wrote:
> On Sun, Feb 23, 2020 at 08:51:55PM -, Steve Jorgensen wrote:
> Python has not just the "iterator protocol" using __iter__ and
> __next__, but also has an older sequence protocol used in Python 1.x
> which still exists to this day. This sequence protocol falls back on
On Sun, 2020-02-23 at 20:32 +, jdve...@gmail.com wrote:
> Kyle Stanley wrote:
> > In order for this proposal to be seriously considered, I think it's
> > necessary to cite many realistic examples where the current
> > behavior is
> > existing solutions, I strongly suspect that this is going
On Feb 23, 2020, at 12:52, Steve Jorgensen wrote:
>
> The only change I am proposing is that the iterability for characters in a
> string be moved from the string object itself to a view that is returned from
> a `chars()` method of the string. Eventually, direct iteratability would be
>
Currently, Python only has ~ (tilde) in the context of a unary operation (like
`-`, with __neg__(self), and `+`, __pos__(self)).
`~` currently calls `__invert__(self)` in the unary context.
I think it would be awesome to have in the language, as it would allow
modelling along the lines of R
Steve Jorgensen wrote:
> > The only change I am proposing is that the iterability for characters in a
> string be moved from the string object itself to a view that is returned from
> a
> chars() method of the string. Eventually, direct iteratability would be
> deprecated and then removed.
That
On Sun, Feb 23, 2020 at 5:17 PM Andrew Barnert wrote:
> On Feb 23, 2020, at 05:44, André Roberge wrote:
>
>
> In an attempt to make it easier to create import hooks to "play" with
> non-standard syntax, I have created a library that is simply called "ideas"
> [2].
> It includes quite a few toy
On Sun, Feb 23, 2020 at 08:51:55PM -, Steve Jorgensen wrote:
> The only change I am proposing is that the iterability for characters
> in a string be moved from the string object itself to a view that is
> returned from a `chars()` method of the string. Eventually, direct
> iteratability
I've also had to special case strings when dealing with iterables
generically, and it's annoying, but it's not a big deal. The real problem
is when you meant to pass an iterable of strings and you just passed a
single string and it produces confusing behaviour - something more subtle
than each
On Feb 23, 2020, at 05:44, André Roberge wrote:
>
>
> In an attempt to make it easier to create import hooks to "play" with
> non-standard syntax, I have created a library that is simply called "ideas"
> [2].
> It includes quite a few toy examples meant to illustrate what can be done. It
>
I have fairly frequently written some kind of recursive descent into
collections. Like many people, I've had to special case strings, which are
pseudo-scalar, and I don't want to descend into.
But one thing I don't think I've ever tripped over is descending into
single characters, but then
jdveiga＠gmail.com wrote:
> Kyle Stanley wrote:
> > In order for this proposal to be seriously
> > considered, I think it's
> > necessary to cite many realistic examples where the current behavior is
> > problematic enough to justify changing the current behavior, and that
> > adding a str.chars()
Kyle Stanley wrote:
> In order for this proposal to be seriously considered, I think it's
> necessary to cite many realistic examples where the current behavior is
> problematic enough to justify changing the current behavior, and that
> adding a str.chars() and eventually removing the ability to
On 2/23/20 1:49 AM, Christopher Barker wrote:
I think that the "strings are an iterable of strings", i.e. an
iterable of iterables onto infinity... is the last remaining common
dynamic type issue with Python.
However, I'd like to see the "solution" be a character type, rather
than making
Christopher Barker wrote:
> I think that the "strings are an iterable of strings", i.e. an iterable of
> iterables onto infinity... is the last remaining common dynamic type issue
> with Python.
> However, I'd like to see the "solution" be a character type, rather than
> making strings not
Christopher Barker wrote:
> Better yet:
> Provide type codes for the “new” C exact width integer types:
> https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
> (and any number of tother references)
> I've always thought is was unfortunate that Python inherited C's
>
On Sun, Feb 23, 2020 at 1:01 PM Eric Fahlgren
wrote:
> I had just started to play with Andrew's code on Friday, but got
> distracted by real work and had to drop it. This gets me further into the
> parts I wanted to play with, so big thanks!
>
If you come up with something that you find useful
I had just started to play with Andrew's code on Friday, but got distracted
by real work and had to drop it. This gets me further into the parts I
wanted to play with, so big thanks!
On Sun, Feb 23, 2020 at 5:45 AM André Roberge
wrote:
> (Apologies if this appears twice: I attempted to create
> > raise TypeError(f"iterable cannot be a str")
>
> Why is that a f-string? It's a static message. That's kind of like
> writing `x += eval('1')`.
>
Well I had cut it down from another copy/pasted version with a variable in
it just for this conversation.
> yield from iter(iterable)
(Apologies if this appears twice: I attempted to create a new thread using
the Web interface but do not see any sign of it having been created.)
When people suggest changes to Python's syntax on this list, it is often
suggested that they might want to try doing so using an import hook.
In fact,
In unittest.mock.MagicMock I solve this problem by having __new__ create a
new subclass for every instantiation. Setting any magic method on the
instance is promoted to the type via __setattr__. That way every instance
can have unique magic methods without affecting other instances.
Michael
On
53 matches
Mail list logo
