[Python-ideas] Loosen 'as' assignment
Hi, I'm wondering if it's possible and consistent that loosen 'as' assignment, for example: >>> import psycopg2 as pg >>> import psycopg2.extensions as pg.ex You can't now assign to an attribute in as statement but are there some reasons? To be honest, I'll be satisfied if the statement above become valid, but also interested in general design decisions about 'as' functionality, I mean, it can be applicable to all expression that can be left side of '=' such as 'list[n]' one, and also other statement than 'import' such as 'with'. Thanks,___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python Decorator Improvement Idea
On Fri, Jun 15, 2018 at 11:54:42PM -0400, Brian Allen Vanderburg II via
Python-ideas wrote:
> An idea I had is that it could be possible for a decorator function to
> declare a parameter which, when the function is called as a decorator,
> the runtime can fill in various information in the parameters for the
> decorator to use.
We can already do this, by writing a decorator factory:
@decorator(any parameters you care to pass)
def spam():
...
"Explicit is better than implicit" -- it is better to explicitly pass
the parameters you want, than to hope that "the runtime" (do you mean
the interpreter?) will guess which parameters you need.
> Some of the information would be available in all
> contexts, while other information may only be available in certain
> contexts.The parameter's value cannot be explicitly specified, defaults
> to Null except when called as a decorator, and can only be specified
> once in the function's parameter list.
Do you mean None?
Why do you think it is a good idea to have the same function, the
decorator, behave differently when called using decorator syntax and
standard function call syntax? To me, that sounds like a terrible idea.
What advantage do you see?
[...]
> Rules:
>
> 1. It is not possible for the parameter's value to be directly
> specified. You can't call fn(info=...)
That sounds like a recipe for confusion to me. How would you explain
this to a beginner?
Aside from the confusion that something that looks like a parameter
isn't an actual parameter, but something magical, it is also very
limiting. It makes it more difficult to use the decorator, since now it
only works using @ syntax.
> 2. The parameters value is Null except in the cases where it is invoked
> (the callable called a a decorator). If used in a partial, the
> decorator parameter would be Null. etc.
You keep saying Null. What's Null?
> Information that could be contained in the parameters for all contexts:
>
> Variable name
> Module object declared in
> Module globals (useful for @export/@public style decorators)
> Etc
The variable name is just the name of the function or class, the first
parameter received by the decorator. You can get it with func.__name__.
The module globals is already available in globals(). You can either
pass it directly as an argument to the decorator, or the decorator can
call it itself. (Assuming the decorator is used in the same module it is
defined in.)
If the decorator is in the same module as the globals you want to
access, the decorator can just call globals(). Or use the global
keyword.
If the decorator is contained in another module, the caller can pass the
global namespace as an argument to the decorator:
@decorate(globals())
def func(): ...
Not the neatest solution in the world, but it works now.
> Using the decorator in a class context, pass the class object.
The decorator already receives the class object as the first parameter.
Why pass it again?
> While the class object hasn't been fully created yet,
What makes you say that?
> this could allow
> accessing attributes of the class (like a registry or such)
>
> def decorator(fn, @info):
> if hasattr(info, "class_obj"):
> registry = info.class_obj.__dict__.setdefault("_registry", [])
>
> registry.append(fn)
> return fn
Writing "hasattr(info, whatever)" is an anti-pattern.
By the way, the public interface for accessing objects' __dict__ is to
call the vars() function:
vars(info.class_obj).set_default(...)
> This could also make it possible to use decorators on assignments.
We already can:
result = decorator(obj)
is equivalent to:
@decorator
def obj(): ...
or
@decorator
class obj: ...
except that we can use the decorator on anything we like, not just a
function or class.
[...]
> # This will call the decorator passing in 200 as the object, as
> # well as info.name as the variable being assigned.
> @expose
> SCRIPT_CONSTANT = 200
That would require a change to syntax, and would have to be a separate
discussion.
If there were a way to get the left hand side of assignments as a
parameter, that feature would be *far* to useful to waste on just
decorators. For instance, we could finally do something about:
name = namedtuple("name", fields)
> The two potential benefits I see from this are:
>
> 1. The runtime can pass certain information to the decorator, some
> information in all contexts, and some information in specific contexts
> such as when decorating a class member, decorating a function defined
> within another function, etc
>
> 2. It would be possible to decorate values directly, as the runtime can
> pass relevant information such as the variables name
No, that would require a second, independent change.
We could, if desired, allow decorator syntax like this:
@decorate
value = 1
but it seems pretty pointless since that's the same as:
value = decorator(1)
The
Re: [Python-ideas] Operator for inserting an element into a list
On 16Jun2018 02:42, Mikhail V wrote: Now I have slightly different idea. How is about special-casing of this as a shortcut for append: L[] = item Namely just use the fact that empty slice is SyntaxError now. Now we're just making typing errors into working code. Also, that isn't an empty slice. That's a _missing_ slice. An empty slice has zero length. While genuinely new syntax needs to land in such a gap (because otherwise it will break working code), new syntax needs a much highly value than new meanings for existing operators. Some things _should_ be syntax errors. Particularly things which may be typing errors. Suppose I'd meant to type: L[0] = item Silent breakage, requiring runtime debugging. I understand this is totally different approach than operator overloading and maybe hard to implement, but I feel like it looks really appealing. And it is quite intuitive imo. For me the syntax reads like: "add new empty element and this element will be "item". The term "new empty element" is a nonsense term to me. If you mean "replace an empty slice at the end of the list with a new element", that can already be written: L[len(L):len(L)]=[9] Cumbersome, I accept. But I've got a .append method. Cheers, Cameron Simpson ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Fri, Jun 15, 2018, 6:18 PM Mikhail V wrote: > On Sat, Jun 16, 2018 at 3:47 AM, Michael Selik wrote: > > > One of those links was discussing extend, not append. > > Yes and so what? ... What is different with append? Luckily for extend, it's similar to the "obvious" semantics of ``a += b`` which is ``a = a + b``. Unfortunately for append, there's nothing quite like it among the operators. > The other wanted a > > repeated append, best solved by a list comprehension. > > I think yuo should reread that one more thoroughly - I'll even paste here > the text: > Though append works just fine, I feel it is less clear than: mylist[i] = 2*math.pi*radius*math.cos(phi[i]) > > So your claim this ^ is not relevant?! > I read that sentence. No, it was not relevant, because the best answer was to teach that person about list comprehensions, not to offer a new syntax. Seriously I am starting to get tired of that style of conversation. > To be honest, I'm getting a little tired myself. I am trying to politely suggest ways to strengthen your proposal even though I disagree with it. I provided you links - you are not pleased again. > Are you aware that modifying the language is difficult, time consuming, and the folks that do it aren't paid for their work? Further, any change is likely to increase the maintenance burden on these same volunteers. Even worse, tens of thousands of teachers will need to add more time to their lesson plans to explain new features. Book authors will need to issue errata and revised versions. If you add that all together, in a sense, changing the parser to expand the syntax would cost millions of dollars. Is that worth the change? > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
Mikhail V wrote: But I see from various posts in the web and SO - people just want to spell it compact, and keep the 'item' part clean of brackets. Where have you seen these posts? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Sat, Jun 16, 2018 at 3:47 AM, Michael Selik wrote: > One of those links was discussing extend, not append. Yes and so what? Does this makes it automatically not related to the wish to choose more compact spelling, despite it is not recommended way. What is different with append? Similar posts are in topics about append and anything else actually, e.g.: i = i +1 i +=1 You can find enough evidence that people prefer i += 1. > The other wanted a > repeated append, best solved by a list comprehension. I think yuo should reread that one more thoroughly - I'll even paste here the text: """ When appending longer statements to a list, I feel append becomes awkward to read [...] Though append works just fine, I feel it is less clear than: mylist[i] = 2*math.pi*radius*math.cos(phi[i]) So your claim this ^ is not relevant?! Seriously I am starting to get tired of that style of conversation. I provided you links - you are not pleased again. > > On Fri, Jun 15, 2018, 5:40 PM Mikhail V wrote: >> >> On Sat, Jun 16, 2018 at 3:26 AM, Michael Selik wrote: >> > >> > >> > On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote: >> >> >> >> there is just nothing against append() method. >> > >> > >> > Then why break the Zen: there should be only one obvious way? >> >> I think the question could be applied to 99% proposals >> >> >> But I see from various posts in the web and SO - people just want to >> >> spell >> >> it compact, and keep the 'item' part clean of brackets. >> > >> > >> > If you're going to cite things, please link to them. >> >> Want to force me to work? :) >> >> I made pair of links already in previous posts, not directly >> telling concrete wishes, but shows approximately the picture. >> >> >> Something more concrete maybe: >> >> https://stackoverflow.com/a/3653314/4157407 >> https://stackoverflow.com/q/13818992/4157407 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On 6/15/2018 8:42 PM, Greg Ewing wrote: Mikhail V wrote: It s just very uncommon to see standalone statements like: x.method() for me it came into habit to think that it lacks the left-hand part and =. You must be looking at a very limited and non-typical corpus of Python code. Mutating method calls are extremely common in most Python code I've seen. You seem to be trying to reason about Python as though it were intended to be used in a functional style, but it's not. Making guesses about it based on how something would be done in a functinal language will get you nowhere. > I am not sure about x.method() form - was it meant to hint to the user about anything? It seemed to me so when I started to learn Python, but its not. The fact that something is a method does not, and was never intended to, imply anytbing about whether it is mutating. However, there *is* a fairly easy way to tell, most of the time, when you're *reading* code. There's a convention that mutating methods don't return anything other than None, so mutating method calls reveal themselves by the fact that the result is not used. Conversely, a method call whose result *is* used is most likely non-mutating. (It's possible that it could both return a value and have a side effect, but that's frowned upon, Except for set/list.pop and dict.popitem. and you'll pretty much never see it in any builtin or stdlib API.) As for writing code, you just have to rely on memory and documentation, just like you do with most aspects of any language and its libraries. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ -- Terry Jan Reedy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
Michael Selik wrote: The += operator was meant as an alias for ``x = x + 1``. The fact that it mutates a list is somewhat of a surprise. That's very much a matter of opinion. For every person who thinks this is a surprise, you can find another that thinks it's obvious that += should mutate a list, and is surprised by the fact that it works on immutable types at all. Some other languages make no distinction between mutation and reassignment. Perhaps you're thinking of one of those other languages. Most languages, actually. I'm not aware of any other language with a += operator that has this dual interpretation of its meaning -- which is probably why almost everyone gets surprised by at least one of its meanings. :-) Maybe we should call it the "Spanish Inquisition operator". -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
Mikhail V wrote: It s just very uncommon to see standalone statements like: x.method() for me it came into habit to think that it lacks the left-hand part and =. You must be looking at a very limited and non-typical corpus of Python code. Mutating method calls are extremely common in most Python code I've seen. You seem to be trying to reason about Python as though it were intended to be used in a functional style, but it's not. Making guesses about it based on how something would be done in a functinal language will get you nowhere. > I am not sure about x.method() form - was it meant to hint to the user about anything? It seemed to me so when I started to learn Python, but its not. The fact that something is a method does not, and was never intended to, imply anytbing about whether it is mutating. However, there *is* a fairly easy way to tell, most of the time, when you're *reading* code. There's a convention that mutating methods don't return anything other than None, so mutating method calls reveal themselves by the fact that the result is not used. Conversely, a method call whose result *is* used is most likely non-mutating. (It's possible that it could both return a value and have a side effect, but that's frowned upon, and you'll pretty much never see it in any builtin or stdlib API.) As for writing code, you just have to rely on memory and documentation, just like you do with most aspects of any language and its libraries. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Sat, Jun 16, 2018 at 3:26 AM, Michael Selik wrote: > > > On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote: >> >> there is just nothing against append() method. > > > Then why break the Zen: there should be only one obvious way? I think the question could be applied to 99% proposals >> But I see from various posts in the web and SO - people just want to spell >> it compact, and keep the 'item' part clean of brackets. > > > If you're going to cite things, please link to them. Want to force me to work? :) I made pair of links already in previous posts, not directly telling concrete wishes, but shows approximately the picture. Something more concrete maybe: https://stackoverflow.com/a/3653314/4157407 https://stackoverflow.com/q/13818992/4157407 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Fri, Jun 15, 2018, 5:24 PM Mikhail V wrote: > there is just nothing against append() method. > Then why break the Zen: there should be only one obvious way? But I see from various posts in the web and SO - people just want to spell > it compact, and keep the 'item' part clean of brackets. If you're going to cite things, please link to them. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Approximately equal operator
On Fri, Jun 15, 2018 at 3:56 PM, Andre Roberge wrote: > * people doing heavy numerical work and wanting code as readable as possible IME serious numerical work doesn't use approximate equality tests at all, except in test assertions. > * teaching mostly beginners about finite precision for floating point > arithmetics Given that approximate equality tests are almost never the right solution, I would be worried that emphasizing them to beginners would send them down the wrong path. This is already a common source of confusion and trap for non-experts. > * people wishing to have trigonometric functions with arguments in degrees, > as in a current discussion on this forum. AFAICT approximate equality checks aren't really useful for that, no. (I also don't understand why people in that argument are so worried about exact precision for 90° and 30° when it's impossible for all the other angles.) Python is *very* stingy with adding new operators; IIRC only 3 have been added over the last ~30 years (**, //, @). I don't think ~= is going to make it. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Sat, Jun 16, 2018 at 3:02 AM, Chris Angelico wrote: > On Sat, Jun 16, 2018 at 9:42 AM, Mikhail V wrote: >> Now I have slightly different idea. How is about special-casing of this >> as a shortcut for append: >> >> L[] = item >> >> Namely just use the fact that empty slice is SyntaxError now. >> >> I understand this is totally different approach than operator >> overloading and maybe >> hard to implement, but I feel like it looks really appealing. >> And it is quite intuitive imo. For me the syntax reads like: >> "add new empty element and this element will be "item". >> >> No? > > Yes, if this were PHP. Is it like that in PHP? > I still haven't seen any compelling argument against the append > method. -1 on introducing a new way to spell append. By me - there is just nothing against append() method. But I see from various posts in the web and SO - people just want to spell it compact, and keep the 'item' part clean of brackets. And that kind of makes sense. > ChrisA > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Sat, Jun 16, 2018 at 9:42 AM, Mikhail V wrote: > Now I have slightly different idea. How is about special-casing of this > as a shortcut for append: > > L[] = item > > Namely just use the fact that empty slice is SyntaxError now. > > I understand this is totally different approach than operator > overloading and maybe > hard to implement, but I feel like it looks really appealing. > And it is quite intuitive imo. For me the syntax reads like: > "add new empty element and this element will be "item". > > No? Yes, if this were PHP. I still haven't seen any compelling argument against the append method. -1 on introducing a new way to spell append. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
Now I have slightly different idea. How is about special-casing of this as a shortcut for append: L[] = item Namely just use the fact that empty slice is SyntaxError now. I understand this is totally different approach than operator overloading and maybe hard to implement, but I feel like it looks really appealing. And it is quite intuitive imo. For me the syntax reads like: "add new empty element and this element will be "item". No? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Approximately equal operator
On 6/15/18 1:38 PM, Andre Roberge wrote: > I have a suggestion to make inspired by the current discussion about > trigonometric functions in degrees, and the desire to have them show > "exact" values in some special cases. > > I suggest that it would be useful to have operators for performing > **approximate** comparisons. I believe that such operators would be > useful both for students learning using Python as well as experts > doing numerical computations. > > For discussion purpose, I will use ~= as representing an operator > testing for approximate equality. (I will show some sample usage below). > > When teaching students, the availability of both == and ~= would give > the opportunity to discuss the fact that numerical computations using > floats are approximate, while having the possibility to write code > that is readable using the approximate equality operator instead of > the strict equality operator when needed. > > Before I started writing this email, I had noticed that numpy includes > at least two functions (isclose and allclose) whose purpose is to > perform such approximate comparisons. [1] I had completely missed the > fact that Python added the function isclose() in the math module in > version 3.5, as described in PEP 485 [0]. I would suggest that the > possibility of using operators instead of explicit function calls > could make programs easier to write and read, both for beginners and > experts alike. I note that PEP 485 makes no mention of introducing > operators as a possibility. > > In addition to an approximate equality operator, it would be natural > to include two additional operators, greater than or approximately > equal, and lesser than or approximately equal. These could be written > respectively as >~= and <~=. I did consider using some relevant utf-8 > symbol instead of combination of ascii characters, but I think that it > would be easier to write programs if one does not require characters > nor found on any normal keyboard. > > Some time ago, I created a toy module [2] to enable easy experiments > with some syntactic additions to Python. Using this module, I created > a very poor and limited implementation that shows what using these > proposed o[erators might look like [3] ... My current implementation > is slightly different from either Numpy or Python's math.isclose() > function [This may no longer be the case soon as I plan to change it > to use Python's version instead.] . As is the case for isclose(), > there are two paramaters to be set to determine if the values are > close enough to be considered approximately equal: an absolute > tolerance and a relative one. Given that one cannot pass parameters > to an operator, my implementation includes a function which can change > the values of these parameters for a given session. If these new > operators were to be added to Python, such a function would either > have to be added as a builtin or as a special function in the math module. > > Here's a sample session for demonstration purpose... > > $ python -m experimental > experimental console version 0.9.5. [Python version: 3.6.1] > > ~~> 0.1 + 0.2 > 0.30004 > ~~> 0.1 + 0.2 == 0.3 > False > ~~> from __experimental__ import approx > ~~> 0.1 + 0.2 ~= 0.3 # use approximately equal operator > True > ~~> 0.1 + 0.2 <~= 0.3 > True > ~~> 0.1 + 0.2 >~= 0.3 > True > ~~> 2 ** 0.5 > 1.4142135623730951 > ~~> 2**0.5 ~= 1.414 > False > ~~> set_tols(0.001, 0.001) > ~~> 2**0.5 ~= 1.414 > True > > > André Roberge > > [0] https://www.python.org/dev/peps/pep-0485/ > > [1] See for > example > https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.isclose.html > > [2] https://github.com/aroberge/experimental > > [3] > https://github.com/aroberge/experimental/blob/master/experimental/transformers/readme.md#approxpy > The big issue with 'approximately equals' is that the definition of it is hard to come up with. This is especially true for small values. In particular how small does a number need to be to be ~= 0. You also get inconsistencies, you can have a ~= b, and b ~= c but not a ~= c. You can have a + b ~= c but not a ~= c - b should 0.001 ~= 0.0011 To properly handle this sort of thing you need that tolerance parameter, but the values you give should be carefully though about for THAT comparison, having a 'global' value is apt to lead to laziness and wrong answers. -- Richard Damon ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On 6/15/18 1:25 PM, Mikhail V wrote: > On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico wrote: >> On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote: >>> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote: >>> If you would like to prove the need for this operator, one piece of evidence you can provide is a count of the number of times someone writes "list.append" for an iterable vs "+=" and encloses a str or other type in a throw-away list to effectively append. >>> That's strange idea - there is no doubt that one would use >>> list.append() and most probably >>> it is the case statistically. >>> So the question would be "what is wrong with list.append()?" >>> And as said many times, there is nothing wrong, but a lot of people >>> seem to want an in-place >>> operator for this purpose. And I can understand this, because: >>> >>> 1. append() is _ubiquitous_ >>> 2. in-place assignment form makes some emphasis on mutating, in >>> contrast to method call. >> How so? You can write "x += 1" with integers, and that doesn't mutate; >> but if you write "x.some_method()", doing nothing with the return >> value, it's fairly obvious that it's going to have side effects, most >> likely to mutate the object. Augmented assignment is no better than a >> method at that. >> > How it would be obvious unless you test it or already have learned by heart > that x.some_method() is in-place? For a list variable you might expect > it probably, > and if you already aware of mutability, etc. > > It s just very uncommon to see standalone statements like: > x.method() > > for me it came into habit to think that it lacks the left-hand part and =. > Of course augmented assignment is not a panacea because it is limited only > to one operation, and the appeal of the operator itself is under question. > > As for x+=1 it is implementation detail - historical idea of such operators > was > mutating, so at least visually its not like a returning expression. > and I am not sure about x.method() form - was it meant to hint to the user > about anything? It seemed to me so when I started to learn Python, but its > not. For me if I see foo.bar() my assumption is that likely bar() is going to mutate foo, especially if it doesn't produce a return value, and this is the natural way to define something that mutates something. If it returns something, it might be just an accessor, or it might be a bit of both, easily a mutation that returns a status about the success/failure of the mutation. foo = bar would seem to be never a 'mutation', but always a rebinding of foo, even if 'bar' is an expression using foo. foo += bar, conceptually reads as foo = foo + bar, so the first impression is that it isn't going to mutate, but rebind, but it is possible that it does an inplace rebind so to me THAT is the case where I need to dig into the rules to see what it really does. This means that at quick glance given: list1 = list list1 += value it is unclear if list would have been changed by the +=, while a statement like list1.append(value) is more clearly an in place mutation so other names bound to the same object are expected to see the changes. -- Richard Damon ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Approximately equal operator
On Fri, 15 Jun 2018 14:38:22 -0300 Andre Roberge wrote: > > Here's a sample session for demonstration purpose... > > $ python -m experimental > experimental console version 0.9.5. [Python version: 3.6.1] > > ~~> 0.1 + 0.2 > 0.30004 > ~~> 0.1 + 0.2 == 0.3 > False > ~~> from __experimental__ import approx > ~~> 0.1 + 0.2 ~= 0.3# use approximately equal operator > True > ~~> 0.1 + 0.2 <~= 0.3 > True > ~~> 0.1 + 0.2 >~= 0.3 > True > ~~> 2 ** 0.5 > 1.4142135623730951 > ~~> 2**0.5 ~= 1.414 > False > ~~> set_tols(0.001, 0.001) > ~~> 2**0.5 ~= 1.414 > True On the one hand, this matches the corresponding math notation quite pleasantly. On the other hand, it doesn't seem so useful that it deserves to be a builtin operator. I'm also not sure we want to encourage its use for anything other than experimenting at the prompt and writing unit tests. Being able to set a global tolerance setting is an anti-pattern IMHO, regardless of the operator proposal. Regards Antoine. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Fri, Jun 15, 2018 at 10:25 AM Mikhail V wrote: > very uncommon to see standalone statements like: x.method() > Python has many such mutation methods. It sounds like you're judging the frequency of code patterns across all languages instead of just Python. Even then, I don't think that's true. All OO languages that come to mind have that pattern frequently. As for x+=1 it is implementation detail - historical idea of such operators > was > mutating, so at least visually its not like a returning expression. > Incorrect. The += operator was meant as an alias for ``x = x + 1``. The fact that it mutates a list is somewhat of a surprise. Some other languages make no distinction between mutation and reassignment. Perhaps you're thinking of one of those other languages. > and I am not sure about x.method() form - was it meant to hint to the user > about anything? It seemed to me so when I started to learn Python, but its > not. > Yes, it returns None to emphasize that it's a mutation. This is different from the so-called "fluent" design pattern where all mutation methods also return the original object, causing confusion about whether the return value is a copy or not. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Approximately equal operator
I have a suggestion to make inspired by the current discussion about trigonometric functions in degrees, and the desire to have them show "exact" values in some special cases. I suggest that it would be useful to have operators for performing **approximate** comparisons. I believe that such operators would be useful both for students learning using Python as well as experts doing numerical computations. For discussion purpose, I will use ~= as representing an operator testing for approximate equality. (I will show some sample usage below). When teaching students, the availability of both == and ~= would give the opportunity to discuss the fact that numerical computations using floats are approximate, while having the possibility to write code that is readable using the approximate equality operator instead of the strict equality operator when needed. Before I started writing this email, I had noticed that numpy includes at least two functions (isclose and allclose) whose purpose is to perform such approximate comparisons. [1] I had completely missed the fact that Python added the function isclose() in the math module in version 3.5, as described in PEP 485 [0]. I would suggest that the possibility of using operators instead of explicit function calls could make programs easier to write and read, both for beginners and experts alike. I note that PEP 485 makes no mention of introducing operators as a possibility. In addition to an approximate equality operator, it would be natural to include two additional operators, greater than or approximately equal, and lesser than or approximately equal. These could be written respectively as >~= and <~=. I did consider using some relevant utf-8 symbol instead of combination of ascii characters, but I think that it would be easier to write programs if one does not require characters nor found on any normal keyboard. Some time ago, I created a toy module [2] to enable easy experiments with some syntactic additions to Python. Using this module, I created a very poor and limited implementation that shows what using these proposed o[erators might look like [3] ... My current implementation is slightly different from either Numpy or Python's math.isclose() function [This may no longer be the case soon as I plan to change it to use Python's version instead.] . As is the case for isclose(), there are two paramaters to be set to determine if the values are close enough to be considered approximately equal: an absolute tolerance and a relative one. Given that one cannot pass parameters to an operator, my implementation includes a function which can change the values of these parameters for a given session. If these new operators were to be added to Python, such a function would either have to be added as a builtin or as a special function in the math module. Here's a sample session for demonstration purpose... $ python -m experimental experimental console version 0.9.5. [Python version: 3.6.1] ~~> 0.1 + 0.2 0.30004 ~~> 0.1 + 0.2 == 0.3 False ~~> from __experimental__ import approx ~~> 0.1 + 0.2 ~= 0.3# use approximately equal operator True ~~> 0.1 + 0.2 <~= 0.3 True ~~> 0.1 + 0.2 >~= 0.3 True ~~> 2 ** 0.5 1.4142135623730951 ~~> 2**0.5 ~= 1.414 False ~~> set_tols(0.001, 0.001) ~~> 2**0.5 ~= 1.414 True André Roberge [0] https://www.python.org/dev/peps/pep-0485/ [1] See for example https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.isclose.html [2] https://github.com/aroberge/experimental [3] https://github.com/aroberge/experimental/blob/master/experimental/transformers/readme.md#approxpy ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico wrote: > On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote: >> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote: >> >>> If you would like to prove the need for this operator, one piece of evidence >>> you can provide is a count of the number of times someone writes >>> "list.append" for an iterable vs "+=" and encloses a str or other type in a >>> throw-away list to effectively append. >> >> That's strange idea - there is no doubt that one would use >> list.append() and most probably >> it is the case statistically. >> So the question would be "what is wrong with list.append()?" >> And as said many times, there is nothing wrong, but a lot of people >> seem to want an in-place >> operator for this purpose. And I can understand this, because: >> >> 1. append() is _ubiquitous_ >> 2. in-place assignment form makes some emphasis on mutating, in >> contrast to method call. > > How so? You can write "x += 1" with integers, and that doesn't mutate; > but if you write "x.some_method()", doing nothing with the return > value, it's fairly obvious that it's going to have side effects, most > likely to mutate the object. Augmented assignment is no better than a > method at that. > How it would be obvious unless you test it or already have learned by heart that x.some_method() is in-place? For a list variable you might expect it probably, and if you already aware of mutability, etc. It s just very uncommon to see standalone statements like: x.method() for me it came into habit to think that it lacks the left-hand part and =. Of course augmented assignment is not a panacea because it is limited only to one operation, and the appeal of the operator itself is under question. As for x+=1 it is implementation detail - historical idea of such operators was mutating, so at least visually its not like a returning expression. and I am not sure about x.method() form - was it meant to hint to the user about anything? It seemed to me so when I started to learn Python, but its not. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V wrote: > On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote: > >> If you would like to prove the need for this operator, one piece of evidence >> you can provide is a count of the number of times someone writes >> "list.append" for an iterable vs "+=" and encloses a str or other type in a >> throw-away list to effectively append. > > That's strange idea - there is no doubt that one would use > list.append() and most probably > it is the case statistically. > So the question would be "what is wrong with list.append()?" > And as said many times, there is nothing wrong, but a lot of people > seem to want an in-place > operator for this purpose. And I can understand this, because: > > 1. append() is _ubiquitous_ > 2. in-place assignment form makes some emphasis on mutating, in > contrast to method call. How so? You can write "x += 1" with integers, and that doesn't mutate; but if you write "x.some_method()", doing nothing with the return value, it's fairly obvious that it's going to have side effects, most likely to mutate the object. Augmented assignment is no better than a method at that. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Operator for inserting an element into a list
On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik wrote:
> If you would like to prove the need for this operator, one piece of evidence
> you can provide is a count of the number of times someone writes
> "list.append" for an iterable vs "+=" and encloses a str or other type in a
> throw-away list to effectively append.
That's strange idea - there is no doubt that one would use
list.append() and most probably
it is the case statistically.
So the question would be "what is wrong with list.append()?"
And as said many times, there is nothing wrong, but a lot of people
seem to want an in-place
operator for this purpose. And I can understand this, because:
1. append() is _ubiquitous_
2. in-place assignment form makes some emphasis on mutating, in
contrast to method call.
That's it. So instead of a method call one gets a clean element on the
right-hand
and (hopefully) emphasis on the in-place nature of operation.
A quick google search shows some tendency:
https://stackoverflow.com/a/2022044/4157407
https://stackoverflow.com/a/28119966/4157407
So you shoudn't explain it to _me_ - I don't see other significant
convincing points,
and unless this gets support here - I am not interested in continuing.
>
> I see no benefit to this, because += already is an elegant way to extend a
> list, which is more flexible than append. Yes, if the right-hand is an
> iterable and should be appended as a single element, you'll need to enclose
> it in a single-element container. This is true for strings, lists, sets,
> whatever. It's natural and is not a "trick".
>
encouraging to mimic append() via += operator is bad practice.
In the above links to SO, people try to tell the same, but that is not something
that can be easily explained on paper. Now add here the constant wish for
using in-place operator - and there will be on-going confusion.
Regardless of how natural or general it is, it's something
that should be avoided.
Only in this discussion thread I had 3 different advices to use:
L += ["aa"]
L += ("aa",)
L += "aa",
But you should not give it to _me_ - i use the correct form only:
L.append("aa")
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Fwd: Trigonometry in degrees
On 6/13/18 7:21 AM, Stephan Houben wrote: > > > Op wo 13 jun. 2018 13:12 schreef Richard Damon > mailto:rich...@damon-family.org>>: > > My first comment is that special casing values like this can lead to > some very undesirable properties when you use the function for > numerical > analysis. Suddenly your sind is no longer continuous (sind(x) is no > longer the limit of sind(x+d) as d goes to 0). > > > > The deviations introduced by the special casing are on the order of > one ulp. > > At that level of detail the sin wasn't continuous to begin with. I would say the change isn't one ulp, changing a non-zero number to zero is not one ulp (unless maybe you are on the verge of underflow). It may be one ulp of 'full scale', but we aren't near the full scale point. It might be the right answer for a less than one ulp change in the INPUT, but if we thought that way we wouldn't have minded the non-zero result in the first place. The fundamental motivation is that for 'nice angles' we want the 'nice result' when possible, but the issue is that most of the 'nice angles' in radians are not representable exactly, so it isn't surprising that we don't get the nice results out. One property that we like to preserve in functional calculation is that the following pseudo code dp = x + delta derivative = ( f(xp) - f(x) ) / (xp - x) (or variations where you subtract delta or work at x+delta and x-delta) should approximate well the derivative of the function, (which for sin in radians should be cos), and that this improves as delta gets very small until we hit the rounding error in the computation of f(x). (Note, I don't divide by delta, but xp-x to remove the round off error in computing xp which isn't the fault of the function f). Changing a point because it is the closest to the nice number will cause this calculation to spike due to the single point perturbation). Yes, this calculation may start to 'blow up' f(xp) - f(x) is very small compared to f(x) and we start to measure the round off error in the computation of the function, near a zero of the function, (which if we are root finding is common) we can do quite well. > > As I stated in my initial comment on this, if you are going to > create a > sind function with the idea that you want 'nice' angles to return > 'exact' results, then what you need to do is have the degree based > trig > routines do the angle reduction in degrees, and only when you have a > small enough angle, either use the radians version on the small > angle or > directly include an expansion in degrees. > > > > Yes that is what my code does. > It reduces degrees to [0,90]. > > > Angle reduction would be based on the identity that sin(x+y) = > sin(x) * > cos(y) + cos(x) * sin(y) and cos(x+y) = cos(x)*cos(y) - sin(x) * > sin(y). > > If you want to find sin(z) for an arbitrary value z, you can reduce it > to and x+y where x is some multiple of say 15 degrees, and y is in the > range -7.5 to 7.5 degrees. You can have stored exact values of sin/cos > of the 15 degree increments (and only really need them between 0 > and 90) > and then compute the sin and cos of the y value. > > > This is not how sine functions are calculated. They are calculated by > reducing angle to some interval, then evaluating a polynomial which > approximates the true sine within that interval. > > Stephan > And that is what my method did (as others have said). Virtual all methods of computing sin and cos use the angle addition formula (and even quadrant reduction is using it for the special case of using one of the angles where sin/cos are valued in-1, 0, 1). The methods that least use it that I know of reduces the angle to a quadrant (or octant) and then selects one a number of expansions good for a limited range, or table interpolation (but even that sort of uses it with the approximation of sin(x) ~ x and cos(x) ~ 1 for very small x) -- Richard Damon ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow filtered dir built in
On Fri, Jun 15, 2018 at 10:10:19AM +0200, Michel Desmoulin wrote: > Fantastic idea. Would this make sense on var() too ? It's not exactly > the same usage context. No. The point of vars() is to return the actual namespace dict used by an object. It's not primarily an introspection tool, it is the public interface for accessing __dict__ without using the dunder directly. vars() and dir() have completely different purposes, and they do very different things. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Allow filtered dir built in
Le 14/06/2018 à 11:27, Steve Barnes a écrit : > Currently when working with interactive sessions using the dir() or > dir(module) built in is incredibly useful for exploring what > functionality is available in a module. (Especially the regrettable > libraries or modules that add really valuable functionality but have no > or limited docstrings). > > However I often find that when a module adds a lot of functions I need > to filter those entries to be able to find the one that I need, e.g.: > > >>> import mpmath > >>> dir(mpmath) # This produces 390+ lines of output but > >>> for name in dir(mpmath): > ...if 'sin' in name: > ...print(name) # gives me a mere 13 to consider as candidates > > What I would really like to do is: > >>> dir(mpmath.*sin*) > > However, I know that the interpreter will hit problems with one or more > operators being embedded in the module name. > > What I would like to suggest is extending the dir built-in to allow an > optional filter parameter that takes fnmatch type wild card as an > optional filter. Then I could use: > > >>> dir(mpmath, "*sin*") > > To narrow down the candidates. > > Ideally, this could have a recursive variant that would also include > listing, (and filtering), any sub-packages. > Fantastic idea. Would this make sense on var() too ? It's not exactly the same usage context. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Give regex operations more sugar
Le 14/06/2018 à 07:29, Steven D'Aprano a écrit : > On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote: > >>> Attaching an entire module to a type is probably worse than >>> adding a slew of extra methods to the type. >>> >> >> Not my point. >> >> str.re would not be the re module, just a namespace where to group all >> regex related string methods. > > That's what a module is :-) > > How would this work? If I say: > > "My string".re.match(...) > > if str.re is "just a namespace" how will the match function know the > string it is to operate on? There are a lot of ways to do that. One possible way: import re class re_proxy: def __init__(self, string): self.string = string def match(self, pattern, flags): return re.match(pattern, self.string, flags) ... @property def re(self): return re_proxy(self) ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Give regex operations more sugar
from a lurker's perspective, why not just implement str.compile() as
new method, and methods where it's relevant support it's result as
argument ? That's a small change in additions, and the other methods
in the normal case just do the same as now. It's also pretty clear
what things like "whatever".replace("regex".compile(), "otherstring")
should do in that case.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Give regex operations more sugar
On Thu, Jun 14, 2018, 11:22 PM Franklin? Lee wrote: > P.S.: Is there any way of guessing what proportion of Python programs > use `re`, either explicitly or implicitly? How many programs will, at > some point in their runtime, load the `re` module? > GitHub posts it's data to Google BigQuery. It's a biased sample, but it's the largest open repository of code I'm aware of. Hmm. Better search now before it gets moved to Azure :-/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Give regex operations more sugar
On Thu, Jun 14, 2018 at 2:12 AM, Brendan Barnwell wrote:
> On 2018-06-13 22:29, Steven D'Aprano wrote:
>>
>> On Wed, Jun 13, 2018 at 10:59:34PM +0200, Michel Desmoulin wrote:
>>
>>> > Attaching an entire module to a type is probably worse than
>>> > adding a slew of extra methods to the type.
>>> >
>>>
>>> Not my point.
>>>
>>> str.re would not be the re module, just a namespace where to group all
>>> regex related string methods.
>>
>>
>> That's what a module is :-)
>>
>> How would this work? If I say:
>>
>> "My string".re.match(...)
>>
>> if str.re is "just a namespace" how will the match function know the
>> string it is to operate on?
>
>
> str.re can be a descriptor object which "knows" which string
> instance it is bound to. This kind of thing is common in many libraries.
> Pandas for example has all kinds of things like df.loc[1:3],
> df.column.str.startswith('blah'), etc. The "loc" and "str" attributes give
> objects which are bound (in the sense that bound methods are bound) to the
> objects on which they are accessed, so when you use these attributes to do
> things, the effect takes account of on the "root" object on which you
> accessed the attribute.
>
> Personally I think this is a great way to reduce namespace clutter
> and group related functionality without having to worry about using up all
> the short or "good" names at the top level. I'm not sure I agree with the
> specific proposal here for allowing regex operations on strings, but if we
> do do it, this would be a good way to do it.
It's a clever idea, but it's a completely new (at least to standard
Python) way to call a function that acts on a given argument. That
means more to learn.
We already have foo.bar(...) and bar(foo):
"Hello!".count("o")
len("Hello!")
Nesting is hiding. Hiding can be good or bad. Adding `foo.b.ar()` will
make it harder to discover. It's also magical: To understand what
`foo.b.ar()` does, you can't think of `foo.b` as a (semantic) property
of the object, or a method of the object, but as a descriptor trick
which holds more methods of that object.
I mainly use Python on a REPL. When I'm on IPython, I can ask what
properties and methods an object has. When I'm on the basic Python
REPL, I use `dir`, or a function which filters and prints `dir` in a
nicer way. Nested method namespaces will be harder to navigate
through. I would not be able to programmatically tell whether a
property is just a property. I'd need to manually inspect each
oddly-named property, to make sure it's not hiding more methods of the
object (and that would only work if the docstrings are maintained and
clear enough for me).
I don't see any advantage of using `foo.b.ar()` over `foo.b_ar()`. In
either case, you'd need to spell out the whole name each time (unlike
with import statements), unless you save the bound method, which you
can do in both cases.
P.S.: Is there any way of guessing what proportion of Python programs
use `re`, either explicitly or implicitly? How many programs will, at
some point in their runtime, load the `re` module?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
