Re: [Python-ideas] Revisiting dedicated overloadable boolean operators
A small remark for Todd's proposal: I think you should treat the new not (bNOT in the original proposal) differently: it's not binary, so it should not have 2 dunders, the right one is not needed (or there is only the right one, in a way, but other unary ops use the classic dunder iirc...) Also, not having xor is made more painful by this proposal (or for any proposal for new Boolean operators using variants of and/or/not)... I have been bitten a few times writing xor in my code (not often, because xor is done less often), it already feel like it's missing from python. With additional duplicated operators, including bXOR, the missing xor is annoying like a missing teeth: even if you don't use it so much, you think of it all the time ;-) 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] Revisiting dedicated overloadable boolean operators
You should have a look at old PEP225 "Elementwise operators", that proposed ~ as a modifier for many existing operator, to indicate they do mostly what their "normal counterpart do, but act on the inner/ elements of an object instead of on the whole. This was only a memorisation technique, as all tilde operators were defined individually and has associated magic/dunder method (they had also the same precedence as the non-tilded version). It was mainly for ~* to be used as classic numpy multiply and * used as matrix multiply, but as an aside, ~and, ~or, ~not and ~xor were defined as elementwise logical operators, bitwise when applied on int-like objects. Also xor was proposed as a new short-circuiting Classic operator, for orthogonality (the value returned when doing true_a xor true_b was not fixed in the PEP, I can not decide between False and None ;-) Funny this come back after all this time___ 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] Change repr of collections.OrderedDict to be more dict-like
True, I was not aware of that... But the thread also predict OrderedDict will become very unfrequent, and that's also my impression: we are currently removing our OrderedDict. I expect OrderedDict will be used only in place where the sequential order is a primary characteristic, with key access the secondary use pattern. dict will be used in the opposite context, key are the preffered access and order is only a secondary charateristic (that's our use case, order is needed only to make iteration order deterministic). In this sense, the current repr is imho better: it emphasize the order aspect (through the list) while your proposal emphasize the dict aspect. ___ 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] Change repr of collections.OrderedDict to be more dict-like
I would wait a little bit. OrderedDict will probable become a pure synonym
for dict,
in a few releases, and the repr issue will solve itself, both giving the
even simpler/nicer {'a': '1', 'b': '2'}
Your proposal expose that dicts are ordered (which they are, but it's
hidden). Once exposed, OrderedDict are obsolete and should be in the
namespace only for backward compatibitlity.
On Thursday, July 26, 2018 at 10:13:12 AM UTC+2, Miro Hrončok wrote:
>
> Hi,
>
> now when dicts are sorted, can we change the repr of
> collections.OrderedDict to look like dict?
>
> I mean from:
>
> OrderedDict([('a', '1'), ('b', '2')])
>
> To:
>
> OrderedDict({'a': '1', 'b': '2'})
>
> I assume the current list-of-tuples repr is there so copy pasting the
> repr to the interpreter results in the same OrderedDict. When dicts
> preserve insertion order, this now works with dict.
>
> I consider the dict-based repr much easier to read.
>
> Thoughts?
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> Python-ideas mailing list
> python...@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] A better (simpler) approach to PEP 505
On Wednesday, July 25, 2018 at 10:33:37 AM UTC+2, Brice Parent wrote: > > I think the use case here is not really the simple 'is None' + 'is not > None'. > Sure, that's why I also proposed to manually check a non-too-small samples of the None-testing occurences found by Guido . You did it on your sample, and your findings findings are what I roughly expected. I didn't do it. Well, not true, I sort of did it ;-), but I was lazy so I did not look enough to be representative, it was only a quick look at a very few instances: I did not encounter deep hierarchy descent (I think the few we have use hasattr), but I found a couple where the proposed syntax would help but just a little: it's short and would use single ?? or ??= By far, the most common case was using None as a marker for "we need a default sensible in the context", most of the time for a default argument. ?? and ??= indeed makes things slightly shorter and usually slightly clearer, but the improvement is very small as things are short and clear already. That's also why I was interested in the default argument delegating: In quite a few cases, the None default was because the real default was in a subfunction, and a way to delegate would be much more useful there. if the case is just to replace one None value by something else, it's > not really an improvement as we just save one short line, and once the > new syntax is accepted and we're used to it, both solution are quite > explicit with what they do, so I'd prefer the status quo over a second > way of doing the same thing. > Yep, ditto. That's why I am -1 on ?? and ??= : They are useful, but not enough imho It gets interesting in json-like cases, when we traverse a deep tree in > which we might encounter None at multiple levels. > I hoped the PEP writers would submit such reallife examples, I think that's the motivation behind the PEP. But either I missed it, or they didn't show it yet. ___ 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] A better (simpler) approach to PEP 505
BTW, I did (very quickly, so it's rough, my regexps are not really catching everything) the same or our code base: "is None"+ "is not None": 5600 AttributeError: 160 3 args getattr: 60 hasattr: 1800 So very similar to your patternexcept for hasattr, which is much more common in my 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] A better (simpler) approach to PEP 505
Interesting, looking into, let's say, 100 of those is [not] None, randomly chosen, should give an very good idea of typical use for your code base. I am curious about why you don't like solutions involving exceptions? Performance? Catching too much, like typing errors? Less easy to distinguish between None and attr missing? Less easy to combine None-aware and classic attr lookup on the same expression? Something else?___ 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] PEP 505: None-aware operators
Both approaches should not be exposed as core language, but as facilitating tools to be used if, in your application, you have to traverse deep semi-regular attributes hierarchies. The operator approach, by definition, is part of the core, so -1 The wrapper does not need to be included in python, so the discussion is meaningless: people define the tools they want and use them as they please. Personally, I think it would be nice to have that in the standard distrib, especially wrapt or something as powerful. But I don't really care in fact, what good is that now I know about it so I can use it...___ 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] PEP 505: None-aware operators
On Tuesday, July 24, 2018 at 1:38:42 PM UTC+2, Rhodri James wrote: > > -snip- > I'm still of the opinion that both approaches are trying to solve a > problem that's too niche to merit them, BTW. That's also my impression. Hence the second approach: it does not require any change to python, it's just a tool for that niche, so imho it's the right approach. Such a wrapper can even be provided by the lib that produced such nested attributes in the first place. The operator are a tool which seems designed to the same niche issue, but is exposed as a core language feature. It may be interesting if it provides a lot of side benefits, so the tool is so braodly useful it outgrowned it's niche origin. At this point, I do not think it does. ___ 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] PEP 505: None-aware operators
On Tuesday, July 24, 2018 at 9:28:02 AM UTC+2, Brice Parent wrote: > > Le 24/07/2018 à 00:39, Chris Angelico a écrit : > > On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans > wrote: > ... > > What about: > > > > 5 < x < 10 > > > > Can you add parentheses to that to "make precedence and evaluation order > clear"? > Correct me if I'm wrong, but to my knowledge, this is just a shorthand > to `5 < x and x < 10`. I learned something here: >>> -5<-2<-1<=-1>-3 True I wonder how this works, especially as < and friends have magical __ methods... How is it expanded in tne AST? ___ 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] A better (simpler) approach to PEP 505
On Tuesday, July 24, 2018 at 2:39:19 AM UTC+2, Steven D'Aprano wrote: > PEP 505 has a section explaining why catching AttributeError > is undesirable. I find the reasons it gives are compelling. > > Can you explain why you reject the PEP's arguments against catching > AttributeError? > > Yes, and people have done it multiple time already. I will try to make it as explicit as possible, with a terminology that some may find useful... when u have a object hierarchy linked through attributes, which -seems- the use pattern of ?. , the hierarchy is either - 1) fully regular (each attribute contains the same type of objects (same type=with the same attributes), then normal . access is what you want - 2) regular-or-None (contain same type of objects, or None). That's what ?. is for, and ?. is only for that. - 3) its partially regular (does not contain the same type of objects, some objects have more attributes than other, e.g. partial objects). - 4) its irregular (objects may be of completely different type (int, str,... and do not specailly share attributes). ?. is intended for 2). 2) and 3) can be dealed with swallowing AttributeError 4) can also be traversed swallowing AttributeError, but it's probably a very bad idea in almost all cases. I've encountered all cases, from time to time, but none is really typical of most of my code. Which is more common? not sure, I would say 3). What is sure is that 2) do not stand as hugely more common than the others, so introducing a special syntax for 2) do not please me, so +0... Now as I find ?. unpleasant to parse (personal opinion), and having grown to share the general operaror / line noise allergy mainstream in the python community, i am a firm -1 on this: too small a niche, do not bring much compared to current approach, and visual line noise. firm -1 on ?? too, it's less polemic, less visually displeasing, but even less usefull I think: it does not gain that much compared to a more general ternary. As the pymaybe/this thread cover 2) and 3), and do it without any change to python, I find it better. No change > lib change > backward compatible object change - like dict becoming ordered, or None triggering NoneAttributeError(AttributeError) > syntax change (expecially a bunch of linenoisy operators). Now I will stop for a while here, arguments have become circular, proponents and opponents have exposed their view, but mostly proponents have provided very few additional information for a while, especially about real use cases, despite a few requests. We still do not know what motivated the proposal..We had to guess (JSON). Even the PEP do not say, it provide a set of real world example from the standard library, which is admirable but different. And personaly, while am very thankful for providing those concrete examples, I find them unconvicing: the code before is usually fine and improved little by the new operators. Sometimes it's worse: only slightly shorter and less clear. ___ 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] A better (simpler) approach to PEP 505
Short circuit is indeed the main difference. Makes me re-think about the None trigger subclasses of invalid operations exceptions. Like None.a trigger a NoneAttributeError(AttributeError), and so on... I think it solves many issues without much problems nor syntax changes, but probably I miss something... Sure, it's a big change, but maybe less so than 3 non-classic operators working only on None...___ 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] A better (simpler) approach to PEP 505
The proto here swallow and short circuit on attribute error. Changing to do it on Noneness is easy, and you can choose between the two behavior: it's a strength compared to the operator approach. It's working in current python, another strength. I think short-circuit behavior is similar: once stopping condition has been met, the gard object cascade till the end of the nested attribute lookup. Like None do for the operator. More complex stuff when None-coalescing attribute access is mixed with normal access is better done with operators. Maybe complex operations fine of the middle of the access chain would also be easier with the operators. How many times would you encounter that in real cases? I bet on very few. In those few case, would a one line ?. chain expression be better than a multiple line logic with temporaries? I think no. That's my feeling, but in the absence of concrete examples, feelings are ok.___ 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] A better (simpler) approach to PEP 505
Your wrapper class can also, I think: Swallow exceptions, especially AttributeError Specify the sentinel, if it is not None Work for getitem Mixing is indeed more difficult, and there is probably performance impact. Still, it's general and does not need to touch the implementation of the class you want to descend... I like it better than the operators Another idea, may be stupid, maybe not: what if None fails with a subinstance of AttributeError, and a subinstance of KeyError, or IndexError. Then a try/except catching only those exceptions would also work quite nicely...___ 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] PEP 505: None-aware operators
Paul Moore wrote: > > This is my impression, as well. It seems like something that's helpful > in dealing with unstructured object hierarchies with lots of optional > attributes - which is where JSON tends to be used. > > But given that, I'm really much more interested in seeing the new > operators compared against a well-written "JSON object hierarchy > traversal" library than against raw Python code. > Good point, I did not think about that when suggesting to give some context, but indeed if it's linked to a library in particular, there is always the possibility to choose another object than None as the "nothing here" marker. One that will absorb getitems and getattr accesses so that ?. and ?[] behavior is reproduced by plain . and []. Guard/NoValues should be chosen so that typical lib use is easier. Anyway, addressing partially-populated nodes would need lib support: None-coalescence will not help when you traverse a dict/attribute hierarchy where some nodes implement some attributes/keys but not others. It help only when a node is either regular, or a guard object without any attributes...So an irregular tree, but not too irregular ;-)... ___ 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] PEP 505: None-aware operators
Maybe it would help if you mention in which context you will benefit the most? If the python sub-community related to this context agree "?? and friends" is a good idea, then it will add weight to the proposal. Else, probably better to forget it. It seems related to JSON, but as I have never used it, it's a wild guess. Anyway, it's a special pattern with deep attribute hierarchies, whose traversal is shortcutted when one attribute happen to be None. This is common, with 2 exception: -it's rare it's really deep, or then it is arbitrarily deep and you need a procedural descent, not a fixed expression. -None break the descend, but then so does missing attributes. You address the first with special syntax. not the second, so I suspect in your case the second does not happen. Or rarely happen. Hope this will help finding why some finds the ? operators add little, while some others think they add enough to overcome python traditional operator-averse nature. On Monday, July 23, 2018 at 1:10:03 PM UTC+2, Steve Dower wrote: > > On 23Jul2018 1145, Antoine Pitrou wrote: > > > > Le 23/07/2018 à 12:38, Steve Dower a écrit : > >> > >> General comment to everyone (not just Antoine): these arguments have > >> zero value to me. Feel free to keep making them, but I am uninterested. > > > > So you're uninterested in learning from past mistakes? > > > > You sound like a child who thinks their demands should be satisfied > > because they are the center of the world. > > Sorry if it came across like that, it wasn't the intention. A bit of > context on why you think it's a mistake would have helped, but if it's a > purely subjective "I don't like the look of it" (as most similar > arguments have turned out) then it doesn't add anything to enhancing the > PEP. As a result, I do not see any reason to engage with this class of > argument. > > I hope you'll also notice that I've been making very few demands in this > thread, and have indicated a number of times that I'm very open to > adjusting the proposal in the face of honest and useful feedback. > > Cheers, > Steve > ___ > Python-ideas mailing list > python...@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] slice[] to get more complex slices
That would be even more directbut it require syntax support, usefull mainly for people doing multdim complex slicing (i.e numpy users). I may be wrong, but I do not see it gain much support outside numpy... slice[] is probably much more easy to swallow for standard python users, and almost as good imho. It reuse getitem, so it imply the produced slice will behaves exactly like it would if it was not stored/reused, and almost garantee it will be the case indeed (even if the slice syntax is extended) Getting this to work including a new module would be nice. Eventually, having it standard is positive too, it means slice manipulation will become more standardised. On Monday, July 23, 2018 at 12:32:04 PM UTC+2, Jeroen Demeyer wrote: > > On 2018-07-23 12:24, Jeroen Demeyer wrote: > > Another solution that nobody has mentioned (as far as I know) is to add > > additional syntax to the language for that. For example, one could say > > that (1:3) could be used to construct slice(1, 3) directly. The > > parentheses are required to avoid confusion with type hints. I'm not a > > Python language expert, but I don't think that type hints can occur > > inside parentheses like that. > > And this could be extended to tuples (1:3, 2:4) and lists [1:3, 2:4] of > slices too. > ___ > Python-ideas mailing list > python...@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] slice[] to get more complex slices
Oh yes , I see. Seems like almost everybody think using the [...] syntax to define reusable slices is a good idea, the discussion is where this could be implemented, knowing that numpy.s_ already exists. Discussion is not easy to follow, with the patch almost accepted then delayed then rejected, in a very short amount of time. In particular, it's not clear why direct indexing of slice type (not instance) was not chosen. It was the first proposal, and here again Todd's choice. it was silently skipped/changed to slice.literal then moved to operators, at least that's the impression I got reading https://bugs.python.org/issue24379 ... Not sure slice[1::3] can be done, but this has my preference too: it's the most direct exposure I can think of... ___ 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] slice[] to get more complex slices
+1 on this. Seems easy a limited in scope, and it reduce the need to remember the details of slice constructor, just reuse the same syntax for getitem slices. Seems that the initial proposal was skipped just for timing reasons, and have a large support among numpy users. More mixed outside numpy, but still I think it was put under the rug a little too quickly... ___ 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] PEP 505: None-aware operators
On Monday, July 23, 2018 at 8:24:45 AM UTC+2, Nicholas Cole wrote: And that leads to a simple question: how many times does this actually > occur in real-world by python code? -- i.e. how many times do I want > to check the value of an existing label, and, finding it is None (and > None specifically), then assign it a value? > The PEP present a few examples. I think the compactness and clarity is really gained when doing a descent into an "attribute tree", where any (or selected) members can be None, like getting back to the example by Steven (spell-corrected, and expanded): meal = obj?.spam?.eggs.tomato?.cheese ?? "Mozzarella" Where, to put the proposal in even better light, I have assumed that eggs instances always have a tomato attributes (i.e. are never None). This is indeed much more compact that the current version, and arguably more readable (it's easier to parse once you know the syntax...but you have to know the special syntax that will be used for this kind of stuff only). The more you deepen the attribute access, the more you gain, but of course deep attribute access is not so common. The new operators may make deep attribute hierarchies (or deeply nested dicts/lists) slightly more common, and there also I do not think it's a good thing. For me the issue is that you gain little, each operator is very limited in scope, but at the same it's a operator, and those are introduced very carefully in Python (the resistance to line noise is high, it's one of the defining aspect of Python since forever). Each of them do not do enough IMHO, it's too special case and do not unlock especially powerfull/elegant/generalization reuse of other part of Python syntax. If you add something, it should play nice with the existing feature and solve nagging issues that broaden its appeal, or be powerful/general enough to justify it's existence on its own, or be so self-evident for a python user that it feels it's solving a bug. It's not the case for ?? and friends imho, far from it. Also, what happen if you want to modify your deep nested tree, not only access it? obj?.spam?.eggs.tomato?.cheese = "Mozzarella" will not work, and the proposal will not really help there (Or will it? I am not the proposer, I am strongly against it, so I could easily miss capabilities). If it's not possible, you lose a kind of symmetry, and that I do not like (orthogonality and symmetries are really nice in in a computer language, it helps quickly remembering the syntax as you are not cluttered by special cases and exceptions) Steven wrote: The Python community has always been conservative and resistant to change, but the level of conservativeness is now pushing towards fear of change rather than justifiable caution about adding new features that cannot easily be reverted. That's probably because you like this proposal. Really, compared to the 2.0 days, it seems that Python has became much less resistant to change. You have resistance even when proposing changes in standard library, or even the C interpreter internal, unseen in the Python layer, and imho it's often justified (what can be discussed is how arbitrary the actual selection of change is, but a general resistance is not a bad thing) It is a little bit optimistic to expect ?? and friends will be a walk in the park, especially after := ... ___ 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] PEP 505: None-aware operators
Short circuit if the first argument is NOT None, I guess? ;-) Yes, so a short circuit is sometimes good. Not often imho, for a default triggered by None, but sometimes... In the case it is, do you want it to be hidden in an expression? Usually it would be better to draw attention, when the default is either costly to compute, or worse, it's evaluation have side effect. I would use an old fashioned if in those cases...___ 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] PEP 505: None-aware operators
The ?? operator is probably the less scary one regarding legibility, and in guessing (or remembering) what it exactly does... Well, at least I think I understand what it does exactly, but if I'm not wrong there, what it does is also quite simple and minimal. A function returning it's first non-None argument (or None, if all args are None) will provide the same functionality, with not much typing. You have parenthesis for the call, but you will probably need them anyway to group things, for correcting precedence, or helping the reader to parse your expression even if precedence was right. You have an extra call, so ?? may be more efficient...maybe. Is that a reason enough, together with a few letters saved typing, to introduce ?? ? Not for me...___ 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] PEP 505: None-aware operators
Except that the third possibility is not possible...if a is None, a[2] will throw an exception... For now at least ;-) ___ 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] PEP 505: None-aware operators
To get rid of the two other ( ?. And ?[] ), we could also define getitem and getattr for None to always return None...;-) I'm joking, although such an "absorbing" None may have been a good choice when None was introduced, and maybe a way to do an absorbing-None per-statement maybe nice...Nice enough to add more subtleties to python? I don't think so, but it would be readable...___ 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] if we were to ever shorten `A if A else B` (was: PEP 505: None-aware operators)
Coming from the @ side (I was strong +1 on this), I have troubles seeing the real benefits from ?? (And even more from associates): did we really have long and complex expressions where the compactness of an operator would help? Operators are inherently obscure (except for those that are learnt in elementary school), but they help when you combine multiple operators and benefit from their precedence rules. There you can benefit from them, even if explicit it's better than implicit... It was the case for @, and even with proofs of long formulas, and a history of matrix algebra from hundreds of years before computing science, the resistance was strong: a majority of non-numpy users resisted it, saying a function matmul(A,B) was good enough and A@B would bring nothing. It was eventually accepted, 7 or so years after the initial proposal, through another PEP, when relative weight of numpy community was probably larger. So i'd like to see examples of long expressions that would really benefit groin using an very specific operator. At this point, the explicitness of "a if a is not None else []" wins, by a long shot...___ 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] PEP 505: None-aware operators: operators ?= and ?? and OR
I like it much better than the operator version, if I understand correctly, it's like a watcher for special value, that monitor the stack. Danger is that it monitor the whole stack, so that final result is dependent on how much you decompose your algorithm into nested fiction calls: all return values will be monitored, and only return values... But if you refactor a big function into nested functions, and happen to return the special value in the new subfunctions, it will have side effects, that can not be known within the context: it expose internals that used to be hidden, deliberately so...___ 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] Idea: Deferred Default Arguments?
A crazy idea, didn't think much about it yet: def subfunc(c,a=0,b=1): Blabla def function(c,d=3, from args(subfunc) import a,b): Blabla return anotherfunc(a+b+c+d,subfunc(c,a,b)) ___ 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] Idea: Deferred Default Arguments?
Excellent point! I am not fully convinced by the syntax yet, but having proposed something is already very valuable and I do not have a better proposal. As I had to defer defaults countless times, and each times grumped about it, I hope something will come out of this... ___ 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] PEP 505: None-aware operators
On Friday, July 20, 2018 at 11:12:26 AM UTC+2, Chris Angelico wrote: > > On Fri, Jul 20, 2018 at 5:10 PM, Grégory Lielens > > wrote: > > Excuse me, that wasn't my words you quoted. Watch your citations please :) > > ChrisA > Yes, sorry, it was Brendan Barnwell. And I can not edit my previous post:-/ ___ 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] PEP 505: None-aware operators
On 2018-07-19 02:11, Chris Angelico wrote: > -snip- > As far as I can see, these null-coalescing operators would break > that > model. The PEP doesn't seem to provide for a "real" magic method > allowing users to override the actual behavior of the method. (You can > only override __has_value__ to hook into it, but not define by fiat what > A ?? B does, as you can with other operators.) And I think the reason > for this is that the operator itself is too specific, much more specific > in semantics than other operators. (I had similar doubts about adding > the matrix-multiplication operator @.) > > People keep saying that this null-coalescing behavior is so common > and > useful, etc., but that hasn't been my experience at all. In my > experience, the desire to shortcut this kind of logic is more often a > sign of corner-cutting and insufficiently specified data formats, and is > likely to cause bugs later on. Eventually it has to actually matter > whether something is None or not, and these operators just kick that can > down the road. In terms of their abstract meaning, they are not > remotely close to as common or useful as operators like & and |. > Fully agree with you on this, so -1 on those new operators. I like operators (I was behind one of the early proposals for matmul operator (even proposed a bunch of others, for orthogonality purpose: element-wise/object-as-a-whole is a dichotomy that can happen for other things that multiplication), but they need to benefit from operators specifics: precendence order, tradition meaning direct translation of formula/recipies already written with a similar notation, and be generic enough to allow productive use of overloading (instead of confusing use). Matmul have this (with possible exception for overloading, but they are quite a few other mathematical entities where you want to have more than 1 multiplication, beside matrices). Those new operators, not so much, the only benefit is more compact notation of something that is already quite compact (A if A is not None else B) and very explicit (it reads like pseudocode, which is a huge strengh of python). ?? and associates is much more cryptic, force you to think much harder about precedence, just to be slightly more compact. Granted, compact notation can be valuable, but usually if you want to couple multiple such things (like you often do with matmul), and precedence rules allows you to do it elegantly combine multiple operator with infix notation (again matmul is present in formulas that have scalar mul, + and -) . Do we do this with None-coalescence? I don't think so, not often anyway... Do we want to do this more with None-coalescence? Not me, certainly not: When I None coalesce, I want it to be as clear and atomic as possible because it's a corner case. so strong -1... ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
