[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Steven D'Aprano wrote: > 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? I would not get rid of the `in` behavior, but the `in` behavior of a string is actually not like that of the `in` operator for a typical collection. Seen as simply a collection of single-character strings, "b" would be in "abcd", but "bc" would not. The `in` operator for strings is checking whether the left operand is a substring as opposed to an item. `(2, 3)` is not `in` `(1, 2, 3, 4)`. ___ 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/4H2IEA6MNOBH2JKENGLOYIE33O7BT4ST/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)
On Mon, 24 Feb 2020 at 17:47, Aaron Hall via Python-ideas
wrote:
>
> The context for this is statistics , so I'll quote Wolfram on tilde in the
> context of statistics: http://mathworld.wolfram.com/Tilde.html
>
> "In statistics, the tilde is frequently used to mean "has the distribution
> (of)," for instance, X∼N(0,1) means "the stochastic (random) variable X has
> the distribution N(0,1) (the standard normal distribution). If X and Y are
> stochastic variables then X∼Y means "X has the same distribution as Y."
>
> So X~Y is an assertion of a relationship between X and Y. Sympy has an entire
> module filled with these distributions. But maybe it's more useful to say `Z
> = Normal('Z', 0, 1)` instead of `Z = Z ~ Normal(0, 1)` or maybe `Z ~=
> Normal(0, 1)` (Z example from docs, latter tilde examples are mine).
Speaking as a SymPy contributor it isn't clear to me what you expect
tilde would be used for in SymPy (although I'm sure it would get used
for lots of things if it existed). The problem with the two examples
shown is that they require Z to exist already but if you need to
create Z you might as well just create it as Z=Normal(...).
Something that stands out to me in what you've said is that X~Y is a
"relationship between X and Y". In all mathematical contexts I know of
~ is a relation rather than an operation. In fact ~ is often used as
*the* generic symbol for talking about relations in the abstract e.g.:
https://en.wikipedia.org/wiki/Equivalence_relation#Definition
That would suggest ~ has the same precedence class as relational
operators like <, >, == etc rather than arithmetic operators like +,
-, *, so we should have X + Y ~ C being equivalent to (X + Y) ~ C.
Relating that back to SymPy I'd expect `Z ~ Normal(0, 1)` to be a
Boolean statement that could be used in some way. As a Boolean
statement (X ~ Y) + Z would be meaningless because + is meaningless
for Booleans so the other precedence would be more useful.
The other implication of being a relational operator in Python is
being usable in chaining like X < Y ~ Z.
--
Oscar
___
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/D7SRGKXIB232J4OAZADR7R6Y4TNA6C67/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
On 24/02/2020 21:07, Alex Hall wrote: This response honestly seems to ignore most of the paragraph that it's responding to. It being a sharp distinction doesn't matter because consistency isn't axiomatically valuable. Actually I think it is. Or more precisely, I think inconsistency is axiomatically has negative value. An inconsistency breaks your expectation of how a language works. Each inconsistency creates a special case that you simply have to learn in order to use the language. The more inconsistencies you have, the more of those exceptions you have to know, and the harder the language is to learn. Just consider how hard English is to learn as an adult, and notice just how much of the language is inconsistency after inconsistency. -- Rhodri James *-* Kynesim Ltd ___ 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/5ZIK4ESPNPX2YL4MNGGMNIFE56YIHCAP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)
I can imagine the hypothetical binary tilde being pretty for some kind of equivalence. This is definitely not enough to motivate me to actually want to add it. But I think this would read OK as equivalent: numpy.allclose(arr1, arr2) arr1 ~ arr2 However, the problem is that there are lots of other ways of being equivalent other than having elements that are all close. In the examples shown by Oscar and Aaron, we might ask whether two collections are drawn from the same distribution. That a useful question. But would this tilde mean the t-test? Unpaired or paired? Welch's t-test. Or maybe it should be a Kolmogorov-Smirnov test. Or a Shapiro-Wilk test? Or Wilcoxon's signed-rank test? Maybe Mann-Whitney's U test? The R approach with a "formula" is just a quotation of the thing we might test later, by whatever method. But as I've said, we already have quotes. So code like this seems fine to me: formula = "arr1 ~ arr2" ks_test(formula) welch_t(formula) However, once I've written that, it seem to have little point not simply to pass in the collections themselves to the various "equivalence" functions. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. ___ 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/ROMWHGGVNKBOT2TTUNEUCBDDMCX3ESWU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Helper to show code to hide warnings
This is inspired by the [discussion on iterable
strings](https://mail.python.org/archives/list/python-ideas@python.org/thread/WKEFHT4JYCL2PMZ5LB6HJRLVP3OGZI56/),
although I think it has applications elsewhere.
Sometimes programs emit warnings that need to be filtered out. Maybe they're
coming from dependencies that we don't control, or maybe it's our own code but
it's a problem that can't be fixed or isn't worth the trouble.
But filtering warnings correctly isn't very easy. You generally shouldn't
ignore all warnings, as this would hide important ones. Similarly, you probably
shouldn't even filter an entire category, which is what many end up doing. A
good compromise is to specify both the category and the module. In particular
this lets you ignore warnings from libraries while still being able to see
warnings from your own code. But there are obstacles on the way:
1. Remembering the syntax is hard. I've never been able to.
2. Looking it up is hard. If I Google "python ignore warnings" the top result
is a Stack Overflow question where neither the accepted answer nor the most
upvoted answer mention specifying a module. The second Google result is the
Python docs which are not easy to read through.
3. There's lots of similarly named methods and it's hard to find the right one.
Is it catch_warnings, simplefilter, or filterwarnings?
4. When warnings are displayed, they show the filename, but filters require a
module name, and converting between the two is tedious.
5. The more warnings there are, and thus the more serious the need to filter
them properly, the more work it is to write all the filters.
I propose we add a built in mechanism that is easy to use and remember which
displays Python code that can be copy pasted. For example, this could be a
configuration option which causes the line of code to be shown in stderr
immediately after the actual warning. Alternatively, here's a context manager /
decorator which prints the code after it exits:
import inspect
import warnings
from contextlib import contextmanager
import __main__
@contextmanager
def showfilters():
with warnings.catch_warnings(record=True) as warnings_list:
yield
for warning in warnings_list:
if warning.filename == getattr(__main__, "__file__", object()):
module = "__main__"
else:
module = inspect.getmodulename(warning.filename)
module = bool(module) * f", module={module!r}"
print(
f"warnings.filterwarnings('ignore', "
f"category={warning.category.__name__}"
f"{module})"
)
# Sample usage
# Prints the below, uncomment to confirm that output disappears
# warnings.filterwarnings('ignore', category=UserWarning, module='__main__')
# warnings.filterwarnings('ignore', category=SyntaxWarning)
@showfilters() # comment out to see original warnings
def main():
warnings.warn("DOOM")
exec("assert (1, 2)")
main()
This is of course a rough implementation, there are probably things it does
wrong and there's all sorts of details about the desired behaviour we could
debate about. The aim is that the code it prints is good enough for most cases
and can easily be edited, particularly by deleting lines. Does this seem like a
good general idea?
___
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/YGI6EJ6Q7HQ37YBIOMJEQ7SGW4WU4F22/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
> > Is there a reason mypy could not assume that all AtomicStr methods that > return strings actually return an AtomicStr, without impacting runtime > behavior...? Maybe it's not possible and I'm just not familiar enough with > the behavior of the type checkers. > I don't know but I could say that being problematic if parts of a project expects strings to be iterable and some expect them to atomic. If mypy assumes `isinstance(obj, Iterable)` returns false on `str` then its not really helping in the case where `obj: Union[str, Iterable[str]]` And while I don't really know much about mypy, I do know it understands stuff like `if isisnstance`, it seems like it would take tremendous hackery to get it to understand that when `isinstance(obj, Iterable)` returns True, you still can't pass that object to a function that consumes an iterable without also checking `not isinstance(obj, (str, bytes))`. assert """ > In practice this would be a very odd decision given that the definition of > Iterable is "has an __iter__". And there are plenty of times people will > find the resulting behavior surprising since str DOES have an __iter__ > method and there are plenty of times you might want to iterate on sequences > and strs in the same context. """ in set_of_draw_backs On Tue, Feb 25, 2020 at 4:28 AM Rhodri James wrote: > On 24/02/2020 21:07, Alex Hall wrote: > > This response honestly seems to ignore most of the paragraph that it's > > responding to. It being a sharp distinction doesn't matter because > > consistency isn't axiomatically valuable. > > Actually I think it is. Or more precisely, I think inconsistency is > axiomatically has negative value. An inconsistency breaks your > expectation of how a language works. Each inconsistency creates a > special case that you simply have to learn in order to use the language. > The more inconsistencies you have, the more of those exceptions you > have to know, and the harder the language is to learn. Just consider > how hard English is to learn as an adult, and notice just how much of > the language is inconsistency after inconsistency. > > -- > Rhodri James *-* Kynesim Ltd > ___ > 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/5ZIK4ESPNPX2YL4MNGGMNIFE56YIHCAP/ > 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/VQZWMIXFO4MJV6CH64YZXZH2JYVVRH5G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Helper to show code to hide warnings
> 2. Looking it up is hard. If I Google "python ignore warnings" the top
result is a Stack Overflow question where neither the accepted answer nor
the most upvoted answer mention specifying a module. The second Google
result is the Python docs which are not easy to read through.
Hmm, I think we may benefit from focusing the efforts on this point (at
least at first), particularly with regards to making the official
documentation for the warnings module [1] easier to understand with some
more examples, or perhaps writing a warnings HOWTO guide [2], which could
include the correct way to add filters for specific warning types by module
for a significant number of different filters.
>From my perspective, this seems to be more of an issue with a lack of
understanding and clear guides for using the existing tools, rather than a
direct indication that additional tools need to be added.
> 3. There's lots of similarly named methods and it's hard to find the
right one. Is it catch_warnings, simplefilter, or filterwarnings?
While I agree that the names might be a bit similar, I personally find that
the names accurately describe what each of them do, particularly
`filterwarnings()` and `catch_warnings()`. The purpose of `simplefilter()`
in relation to `filterwarnings()` might not be as obvious without reading
the documentation, but I don't think there's much that can reasonably be
done to address it. I also don't find it to be an especially significant
concern.
> 4. When warnings are displayed, they show the filename, but filters
require a module name, and converting between the two is tedious.
I could see it being useful to have a utility for filtering warnings by
filename rather than just module, if it's reasonably possible to implement.
> 5. The more warnings there are, and thus the more serious the need to
filter them properly, the more work it is to write all the filters.
This could be potentially addressed by adding an example in the warning
docs or a new warnings HOWTO that includes something along the lines of the
following:
```
modules_to_filter = {"foo": ResourceWarning, "bar": DeprecationWarning}
for mod, cat in modules_to_filter.items():
warnings.filterwarnings("ignore", category=cat, module=mod)
```
(I suspect the actual documented example would be much more fleshed out and
explained, the above was very quickly thrown together as a rough example)
Alternatively, we could consider adding a helper function to the warnings
module for adding a filter with the same action and warning category across
multiple modules at once; by accepting a collection of a strings instead of
a single string (like `filterwarnings()` does for it's *module* parameter).
I'm not certain if the implementation would be too trivial to justify a new
helper function for it, but the use case may be common enough for something
like that to be reasonable.
> I propose we add a built in mechanism that is easy to use and remember
which displays Python code that can be copy pasted.
I really don't like the idea of a builtin that specifically revolves around
the expectation of its output being copied and pasted as code elsewhere,
particularly from an API design perspective. Also, *if* we were to consider
something like this, it seems more appropriate to be included in the
warnings module rather than as a builtin.
> Does this seem like a good general idea?
-1 on the addition of the proposed builtin, but +1 on the general idea of
making the process of correctly adding a decent volume of warning filters
more clear.
---
[1] - https://docs.python.org/3/library/warnings.html
[2] - https://docs.python.org/3/howto/index.html
On Tue, Feb 25, 2020 at 4:04 PM Alex Hall wrote:
> This is inspired by the [discussion on iterable strings](
> https://mail.python.org/archives/list/python-ideas@python.org/thread/WKEFHT4JYCL2PMZ5LB6HJRLVP3OGZI56/),
> although I think it has applications elsewhere.
>
> Sometimes programs emit warnings that need to be filtered out. Maybe
> they're coming from dependencies that we don't control, or maybe it's our
> own code but it's a problem that can't be fixed or isn't worth the trouble.
>
> But filtering warnings correctly isn't very easy. You generally shouldn't
> ignore all warnings, as this would hide important ones. Similarly, you
> probably shouldn't even filter an entire category, which is what many end
> up doing. A good compromise is to specify both the category and the module.
> In particular this lets you ignore warnings from libraries while still
> being able to see warnings from your own code. But there are obstacles on
> the way:
>
> 1. Remembering the syntax is hard. I've never been able to.
> 2. Looking it up is hard. If I Google "python ignore warnings" the top
> result is a Stack Overflow question where neither the accepted answer nor
> the most upvoted answer mention specifying a module. The second Google
> result is the Python docs which are not easy to read through.
> 3. There's lots of sim
[Python-ideas] Add Standard String Literals and Prefixes for Mathematical Notation
I love regular expressions. I would love to see Bra-Ket notation and many of the popular mathematical forms commonly practiced in engineering and science supported by the Python language in an expressive and logical way. I feel the need for expressing mathematical concepts in a standardized and sightly way, beyond just being able to use Unicode equivalents of mathematical symbols, would be an enormous functional benefit. ___ 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/HDES3QWONVQSSK6JRKDHMB5RPU4MD42C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Standard String Literals and Prefixes for Mathematical Notation
Can you provide short, but non-trivial, clear examples of "before" (current Python) and "after" (what you propose it looks like) to demonstrate the advantage? Will it be ambiguous with existing syntax? On Tue, Feb 25, 2020 at 6:10 PM Nathan Edwards wrote: > I love regular expressions. I would love to see Bra-Ket notation and many > of the popular mathematical forms commonly practiced in engineering and > science supported by the Python language in an expressive and logical way. > I feel the need for expressing mathematical concepts in a standardized and > sightly way, beyond just being able to use Unicode equivalents of > mathematical symbols, would be an enormous functional benefit. > ___ > 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/HDES3QWONVQSSK6JRKDHMB5RPU4MD42C/ > 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/C7MOBMWHKOLQRSKBAYJXWVGTJPU6CKI4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str(obj) not calling obj.__str__?
On Sun, 23 Feb 2020 at 11:25, Michael Foord wrote: > 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. > The other little bit of trickery is that MagicMock gets all the magic methods by default and they're all MagicMock objects. To avoid instantiating MagicMock recursively creating MagicMocks forever the magic methods are descriptors that put a new MagicMock instance onto the subclass on first access via an instance. I could probably have saved a lot of effort by overriding __getattribute__ (which can intercept magic method lookups unlike __getatttr__) instead of the descriptor solution. At the time I didn't know that. There's still a bunch of jiggery-pokery to set valid default return values on a bunch of the methods (some are type checked on the return value and some aren't *sigh*), so maybe it's unavoidable. I had fun getting mock to work. Michael > > Michael > > On Sun, 23 Feb 2020 at 04:21, Jérôme Carretero > wrote: > >> Thanks Josh for your prompt reply. All clear. >> >> >> Regards, >> >> -- >> Jérôme >> >> PS: Somehow I had never encountered a situation exacerbating the >> subtleties of implicit invocations of special methods, and hadn't read >> or integrated that section of the documentation, then when encountering >> the “problem” I didn't make my way to the docs. >> And now I also see that right when opening § 3.3. Special method >> names ¶ 1 it's stated that “`x[i]` is roughly equivalent to >> `type(x).__getitem__(x, i)`”. I'll be more careful next time! >> >> >> On Sun, 23 Feb 2020 02:35:24 + >> Josh Rosenberg wrote: >> >> > This is explained in "Special Method Lookup": >> > >> https://docs.python.org/3/reference/datamodel.html#special-method-lookup >> > >> > Short version: For both correctness and performance, special methods >> (those >> > that begin and end with double underscores) are typically looked up on >> the >> > class, not the instance. If you want to override on a per-instance >> level, >> > have a non-special method that __str__ invokes, that can be overridden >> on a >> > per-instance basis. >> > >> > On Sun, Feb 23, 2020 at 2:30 AM Jérôme Carretero > > >> > wrote: >> > >> > > Hello, >> > > >> > > >> > > I just noticed that calling `str(x)` is actually doing (in CPython >> > > `PyObject_Str`) `type(x).__str__(x)` rather than `x.__str__()`. >> > > >> > > Context: I wanted to override __str__ for certain objects in order to >> > > “see them better”. >> > > >> > > I'm wondering why not do `x.__str__()` >> > > >> > > >> > > Best regards, >> > > >> > > -- >> > > Jérôme >> ___ >> 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/G3MW5GD534GNYLE4ARZGE42NHGSSNLGL/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > > Michael Foord > > Python Consultant, Contractor and Trainer > > https://agileabstractions.com/ > > -- Michael Foord Python Consultant, Contractor and Trainer https://agileabstractions.com/ ___ 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/3XVMOFY7UOBDCCRIC3RVF75YUAWVYAAV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Standard String Literals and Prefixes for Mathematical Notation
Hi Nathan, On Tue, Feb 25, 2020 at 11:58:58PM +, Nathan Edwards wrote: > I love regular expressions. Regexes' terse syntax are normally considered rather the opposite of Pythonic. > I would love to see Bra-Ket notation and many of the popular > mathematical forms commonly practiced in engineering and science > supported by the Python language in an expressive and logical way. I > feel the need for expressing mathematical concepts in a standardized > and sightly way, beyond just being able to use Unicode equivalents of > mathematical symbols, would be an enormous functional benefit. You might find more interest if you make some concrete proposals rather than a vague, generic request for more mathematical syntax. Also keep in mind that Python is not a specialised language for mathematics. Its a generic language for everyone, which means the standard is "will the average programmer be able to read this?" not "will mathematicians be familiar with this syntax?". For example, the function for calculating standard deviation is written `statistics.stdev` not `σ`. -- 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/6XA6DUK6L5HCLMTBGMWRHW5HFCVDZGDR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Standard String Literals and Prefixes for Mathematical Notation
> > For example, the function for calculating standard deviation is written > `statistics.stdev` not `σ`. > What do you mean? >>> from statistics import stdev as σ >>> σ([5, 6, 4, 6, 3, 7]) 1.4719601443879744 :-) -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th. ___ 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/E5JONY3IE6ZNTVQXT2NNECAPWC2KCBIG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Standard String Literals and Prefixes for Mathematical Notation
On Tue, Feb 25, 2020 at 10:08:57PM -0500, David Mertz wrote: > >>> from statistics import stdev as σ > >>> σ([5, 6, 4, 6, 3, 7]) > 1.4719601443879744 > > :-) You know what you've done now, don't you? Somebody is going to propose a whole series of aliased names for statistics and math modules: Σ = sum σ = statistics.stdev μ = statistics.mean Π = math.prod γ = math.gamma etc. -- 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/A4KGHRFDARKOV6ESS2E3GDPNC2XSO563/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Standard String Literals and Prefixes for Mathematical Notation
(Un)Happily we have the keyword "as" already. They can make their own aliases. On Tue, Feb 25, 2020, 11:46 PM Steven D'Aprano wrote: > On Tue, Feb 25, 2020 at 10:08:57PM -0500, David Mertz wrote: > > > >>> from statistics import stdev as σ > > >>> σ([5, 6, 4, 6, 3, 7]) > > 1.4719601443879744 > > > > :-) > > You know what you've done now, don't you? Somebody is going to propose a > whole series of aliased names for statistics and math modules: > > Σ = sum > σ = statistics.stdev > μ = statistics.mean > Π = math.prod > γ = math.gamma > > etc. > > > -- > 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/A4KGHRFDARKOV6ESS2E3GDPNC2XSO563/ > 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/IHFCNNOBW4QMNNA6LAWTAIY6P64HHXIW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add Standard String Literals and Prefixes for Mathematical Notation
On Wed, Feb 26, 2020 at 3:43 PM Steven D'Aprano wrote: > > On Tue, Feb 25, 2020 at 10:08:57PM -0500, David Mertz wrote: > > > >>> from statistics import stdev as σ > > >>> σ([5, 6, 4, 6, 3, 7]) > > 1.4719601443879744 > > > > :-) > > You know what you've done now, don't you? Somebody is going to propose a > whole series of aliased names for statistics and math modules: > > Σ = sum > σ = statistics.stdev > μ = statistics.mean > Π = math.prod > γ = math.gamma > > etc. Stick it up on PyPI. You "from blackboard import *" and then proceed to use all those symbols freely. Of course, things could get a little difficult when one symbol has multiple meanings, but version 2.0 of the module will have not just aliases, but magic objects that figure out from context what the meaning is supposed to be. ChrisA ___ 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/ML35AYL5VIFMICLD44WO5ZWQ45KFL3GH/ Code of Conduct: http://python.org/psf/codeofconduct/
