Technical possibilities for a syntax [was: Reverse assignment operators ...]
On 15 November 2016 at 10:46, Paul Moore <p.f.moore@gmail.com> wrote:
I thank you all again for informing me about assignment operator and its further consequences. I read accurately and try to absorb the information, still however I feel like I need just a little bit of more understanding in this particular case. So I can do better if we imagine, just imagine, such a scenario: 1. += and friends are now not allowed for integers, but all _add()_, _iadd()_ are still of course there, it does not concern me. 2. Somebody says: now I want to write something like: halfofanextremelylongvariable = halfofanextremelylongvariable + 1 3. I come up, scratch my head and say: Ok, now we can write that as: halfofanextremelylongvariable = self + 1 So, considering previous comments, there was an impression that I wanted to shake the fundament of all Python world or something. But is it necesserily so? So I don't know how the Python parser works exactly, but why cannot the above roughly speaking "translated", e.g.: x = self + 1 would mean exactly the same that was before x += 1 and call __iadd()__ in turn. Isn't it a very simple thing technically seen? Since augmented assignment is always applied to exactly one argument I believe (correct me if I am wrong), would not it be simple and non-ambigios operation at parsing stage? So in other words sequence " = self + " is same as sequence " += " was. Another example, lets take a Numpy array for example. So it was also stated that += is vital for doing in-place sum. Now I say, we write it in such way, having "A+=1" in mind: exec A + 1 since again, += can be only applied only on one operand, cannot I just say that a sequence "exec {1} + {2}" is what sequence "{1}+={2}" was? What semantics it will fundamentally break or so hard to implement? I was actually trying to give similar ideas in previous comments, but I was not precise in my ideas, so it came to misunderstanding, or it can be that I'm still missing something very important here. Mikhail
On 16 November 2016 at 08:51, Mikhail V <mikhailwas@gmail.com> wrote:
What semantics it will fundamentally break or so hard to implement?
I'm afraid I don't have time at the moment to fully review your email, but my first impression is that you are proposing that the name "self" be treated specially. It's going to be very difficult to convince people that this is a good idea. In the first instance, if you're talking about "self" being a keyword, that would break the current usage of "self" as a normal variable name, which is used by convention in all class methods to represent the current object. If you're not aware, in class A: def method(self): ... the use of self as the variable name is *convention*. You could use any other name just as well. If self were a keyword, it couldn't be used here. So making "self" a keyword would be a major change. In addition, consider code like this: class A(int): def method(self): myvar = 1 myvar = self + 1 return myvar foo = A(5) foo.method() This is legitimate code at the moment. It sets "myvar" to 6 (self is an integer subclass with value 5, which the code adds 1 to) and returns that. Your proposal would change that to return 2. The problem here is that when considering language changes, you can't just consider code that you consider "correct". You have to take account of the fact that other people may be writing code that is to your eyes bizarre and unmaintainable - but if it does what they want it to, and it works according to the language specification, they have a right to expect that the behaviour won't get changed (at least not without due consideration of the backward compatibility process). So proposals that change the behaviour of currently working code have to be *very* careful to consider all edge cases. This is probably the biggest hurdle for people proposing changes to Python to get over. Backward compatibility isn't pleasant to deal with - it's frustrating and demotivating to have a good idea blocked because code that seems senseless "might break". But that's part of the price we have to pay for Python being a hugely popular language. Hope this is useful. Paul
On 16 November 2016 at 10:27, Paul Moore <p.f.moore@gmail.com> wrote:
Oh Paul, come on, pleeeeease. I am making an **example**. Write a "poo" instead or a poo pile character, whatever. You think I am an idiot and don't know that there is "self" in OOP. When I was writing that I just thought, should I make a special note that I am making it only for example, but then thought, oh that would be too pedantic. You say you have no time and write a whole page about it, so don't blame me that I take too much time from you. Mikhail
On Nov 16 2016, Mikhail V <mikhailwas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
...and all of Paul's points still apply.
You think I am an idiot and don't know that there is "self" in OOP.
No, that wouldn't be the reason. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On 16 November 2016 at 16:48, Mikhail V <mikhailwas@gmail.com> wrote:
No I don't think you're an idiot. I thought you were offering a proposal.
Well, if it's "only an example", there's nothing to comment on. You need to offer a proper proposal with the details filled in - otherwise it's not worth replying.
You say you have no time and write a whole page about it, so don't blame me that I take too much time from you.
I'm sorry. I thought I was trying to help by explaining how your proposal could be improved. My mistake - I'll keep quiet next time. Paul
On 16 November 2016 at 18:28, Paul Moore <p.f.moore@gmail.com> wrote:
Paul, ok, I apologize for the latter. But can you see, I spent also quite a bit of time trying to think out use cases, I spent over an hour and looked for similar ideas here. Then I accurately made the subject for the question "Technical possibilities" which already implies that it is about my previous misunderstanding of typed vs. non-typed execution and its possible consequences and it is hard to do without exact knowledge how it all works. Therefore I start small and wanted actually that next time I don't ask stupid questions and other new users can also raise their knowledge for making better quality post. My only fault is that I choose wrong name for the keyword and naively supposed that it will not cause big misunderstanding. Ok? So lets say I made a typo and lets take other keyword, it is not so important in this case, which one. Mikhail
On Wed, Nov 16, 2016 at 11:24:01PM +0100, Mikhail V wrote: [...]
It doesn't matter what keyword you come up with, you still have the problem that this idea introduces a new keyword. New keywords always break backwards compatibility, which means there has to be a good reason to do it. We could make up a random keyword, XusBeooSwqxy3nf7TRx say, and expect that probably nobody in the world has ever used that in their code before. But it would be hard for people to remember and spell correctly, and that goes against the idea that keywords should be meaningful. Any meaningful name you pick as a keyword will probably clash with somebody's code, which means you will break their working program by introducing a new keyword. We take our responsibility seriously: we try very hard to not break people's code when they upgrade, so there has to be a really, really good reason before new keywords are introduced. If this was, say, Python 2.2 or so, and you proposed a new keyword: really_long_variable_name = KEYWORD + 1 then it might be treated a bit more seriously. But the first question we'd ask is, what do other languages do? Python rarely invents new programming ideas itself, but it does copy good ideas from other languages. And of course, the most obvious answer is: Most C-based languages have a += augmented assignment symbol, which avoids the need for a new keyword: really_long_variable_name += 1 Now that we have symbols for augmented assignment, there's *zero* chance that we will remove them, and very little chance that we'll introduce a parallel syntax for doing the same thing by keyword. To get an idea of the standard we require before adding major new syntax or keywords, you should read the historical PEPs: https://www.python.org/dev/peps/ You don't have to write up a full PEP before proposing an idea here, but if the idea involves a large change (especially a new keyword) it almost certainly will require a PEP. But either way, reading the PEPs will give you an idea of what proposals are likely to be accepted, which are likely to be rejected, and which are still open for discussion, as well as the sorts of objections you are likely to receive. -- Steve
On Wed, Nov 16, 2016 at 10:48 AM, Mikhail V <mikhailwas@gmail.com> wrote:
Maybe I should just point out a sec that saying this is a great way to get people to not listen to you. As for your actual question: I'm not sure if I understand correctly, but I think you got things a little mixed up, or I'm not reading this the right way (also likely). Let's not use self anymore as an example, since that ended in fire and brimstone. Let's use something like this: A = source_var + 1 where `source_var` is a magic thing that refers to the target variable. Does that get the same idea across? Yes? Okay. The main reason that this would be difficult to translate isn't difficulty, but just readability. It's weird that using source_var would use __iadd__, but anything else would use __add__. Now, what I think everyone was telling you about as for "difficulty translating" is this: A = A + 1 ==> A += 1 Similar problem: semantics change. If someone decided to be weird and have __add__ and __iadd__ do two different things, this would completely break that. Granted, that's a stupid idea to begin with, but it's still poor justification for the code breakage.
-- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://kirbyfan64.github.io/
On Nov 16 2016, Ryan Gonzalez <rymg19-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Aeh, that's used e.g. in numpy and most certaintly not weird. x = np.range(5) y = x**2 y_int = interpolate(x, y, copy=False) y = y+1 print(y_int(3)) If you replace 'y = y + 1' with 'y += 1', then instead of creating a new array and assigning it to y, you modify the existing array in place, which will change the result of y_int(3). That is a feature. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
The most notable example of something that is "weird" and "a stupid idea" is NumPy... and *everything* in the Scientific Python ecosystem thereby. -- 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.
I think the best way to remove compound operators would be to go back in time and hit Dennis Ritchie with a bat at the exact moment when the notion of them crosses his mind. In all seriousness, compound operators are in practically every modern language and aren't going away. While you don't need to be a savant polyglot and build a database-analysis-webapp in every language known to man, everyone should break out of their own "language bubble" once they have the basics of programming down. Do a tutorial and make a weekend project with a couple other *disparate* languages with different paradigms (not just close relatives like Python and Ruby, or Java and C and C++). There's always something good in other perspectives and worth learning from. Except Perl. On Wed, Nov 16, 2016 at 3:08 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Nick Timkovich writes:
True enough as a concept, but Python didn't have to implement them for immutables. It might have been interesting to allow in-place operations only for mutables. Dunno if Guido thought of that at the time, and I suspect that a lot of the voices that convinced him to go against his instincts wanted them specifically for integers (a lot of people wanted "++" and "--", too). So even if he did think of it, it might not have satisfied the proponents that their needs were being addressed.
Except Perl.
Please don't. Perl has its weaknesses, but it has its strengths too. I suspect that Python regexps were strongly influenced by PCRE, and that the Cheeseshop has borrowed a feature or two from CPAN.
On Thu, Nov 17, 2016 at 12:07:34PM +0900, Stephen J. Turnbull wrote:
By definition, you can only perform in-place operations on mutables. But I guess you are talking about the syntax. Should += raise an exception if the assignment target is immutable? Problem is, how is the Python interpreter supposed to determine whether or not the target is immutable or mutable? There's no isinstance(obj, Immutable) and I doubt there ever will be. More importantly, banning immutables would immediately prohibit the number one most common use of augmented assignment, and probably the largest motivation for the feature: x += 1
Indeed. Supporting `alist += [x]` but not `x += 1` would have been deeply unsatisfactory. I think the status quo is actually very clever: augmented assignment is broadly equivalent to the expanded assignment: obj += foo => obj = obj + foo except that the target obj has the opportunity to optimize it to an in-place operation, even if that makes the semantics slightly different from the ordinary & operator.
Except Perl.
Please don't.
I don't think there is any need for that. No harm is done by a little light-hearted banter relating to the rivalry between programming language communities. In the big picture, a bit of friendly rivalry probably does both communities good. Regardless of what virtues Perl may or may not have, in some ways the philosophy behind Perl is dramatically opposed to that of Python. Many of us like Python code because it goes against Perl's ideals. We discourage many of the things that Perl and its culture encourages: terse, long one-liners, heavy use of regexes, heavy use of sigils and symbols, "clever" code, and More Than One Way To Do It. There's a natural rivalry between Perl and Python. We should be permitted to criticise other languages, and even dismiss them as useless. Programming languages do not have the assumption of dignity owed to human beings. Nick's dismissal of Perl was obviously intended as light-hearted and not entirely serious. This is an informal forum, a mailing list, and throw-away comments intended as humour shouldn't be held to the same standard as serious statements intended as part of a logical argument. Had Nick said "Python should not do X, because Perl does it and nothing Perl does is of any value at all" then we'd be justified in asking him to defend his claim, or to simply dismiss it as obviously ridiculous. But he didn't. I doubt Nick meant that Perl was literally lacking in any redeeming features: exaggeration and hyperbole are time-honoured forms of humour. His comments weren't disruptive and they most certainly were not attacking anyone. It would require the most extraordinarily thin skin to take that as an attack against people who use Perl, and even if somebody did, well, this is not a support group for people so lacking in self-esteem that their self-image is equated to their choice of programming language. (I believe we've already had to ban, or at least warn, one regular to this list under the terms of the CoC, because he couldn't distinguish ill-founded criticism of Python the language from criticism of the people designing and using the language, and he responded with personal attacks.) I'm sorry that I've written more words defending Nick's throw-away two word comment than you expended in lightly chastising him. But I didn't want to just say that I disagreed with you -- I wanted to give the reasons why I support our right to light-heartedly disrespect other languages. (And of course you're right, Python has borrowed regular expression syntax and the Cheeseshop from Perl, and possibly more.) -- Steve
Steven D'Aprano writes:
I don't disagree with that principle, just with the evaluation of the tone, and even that is the difference between rgb.txt's grey49 and grey51. Calling old-style Perl one-liners "line noise" I would count as "light-hearted banter". "All languages have something to teach us -- but let's be really careful about which parts of Perl we study" I would count as lighthearted *and* making the point that we have our own style, which is pretty close to diametrically opposed to the one-liners that Perl is so useful for. "We have nothing to learn from Perl" in context (IIRC, Perl had not been mentioned in this thread to that point, and definitely the emphasis was on C/C++ and Java) was gratuitous and extreme, pure trash talking. Which has its place.[1] I don't think it's unreasonable to request tone-down when it's gratuitous. And I did mean "request" -- I wouldn't follow up to the OP if he chose to disagree with me, even in public. Here I'm discussing a principle that is not absolute, just one I'd like to advocate, and your post gives me a chance.
Regardless of what virtues Perl may or may not have, in some ways the philosophy behind Perl is dramatically opposed to that of Python.
So make that point. Just do it better than I did above! :-)
We should be permitted to criticise other languages,
Sure.
and even dismiss them as useless.
That's another matter, slightly different, but it's an important difference. There was an excellent blog post a couple years ago on "Contempt Culture"[2]. I deny that Nick's comment was made out of contempt, but I have to suspect that past contemptuous utterances provided context for it. The point of the term "culture" is that the contempt becomes natural in context, and indetectable to the speaker, and many of the listeners.
Programming languages do not have the assumption of dignity owed to human beings.
No, but their users are quite capable of *taking* offense where none was offered to them. And nasty people are quite capable of quoting out of context, just to see you and him fight. After a lifetime of using those facts as an excuse for my own borderline insults[3], I've decided I like the much more friendly style of the Python dev lists. It's not that there's no conflict here, but generally the arguments are delivered in such a way that people stay calm throughout.
Of course not. But are you aware that many women are of the opinion that the Python dev community is an uncomfortable place to hang out? I don't know why yet, but the women who have told me they feel that way are quite capable of holding their own in a battle of words and wits when they want to, so they could handle python-dev if they wanted to. With as few reviewers as we have, I would rather risk convincing a few participants I'm some sort of "PC fanatic" than risk chasing away the brain power of half the human race. No, I don't *know* that humorous dismissals of whole programming environments contribute to that alleged atmosphere. I don't even have full understanding of what the issue is, just that I respect the women who have mentioned it to me enough to consider their statements to be evidence (not "proof"). I don't claim to have anything more than personal preference, and a very vague hope for increased participation from a group I think is currently underrepresented here, behind my request this time.
I'm sorry that I've written more words defending Nick's throw-away two word comment than you expended in lightly chastising him.
I'm not. These are very difficult and subtle issues, and you've expressed an important point of view eloquently. And I am very aware that current subscribers of the list have the right to express themselves with such humor, at least as I understand the current list policy.[4] I just wish such expression would be avoided, and I like to think my wish is partly motivated by a certain amount of public-spirited-ness, and that said motivation is in response to a real issue. Steve Footnotes: [1] Cf. http://www.jwz.org/gruntle/rbarip.html, though nothing could be like that any more. ;-) [2] http://blog.aurynn.com/contempt-culture. I suspect it's not the origin of the term, but don't feel like digging further. [3] My out-and-out insults were generally committed with malice aforethought, in the expectation of getting as good as I gave.[1] [4] I suspect that if asked, Brett would sympathize with my preference, and if not asked directly, he would say nothing precisely because anything he says might be construed to be policy, and this isn't. But you'd have to ask him. :-)
On 16 November 2016 at 17:50, Ryan Gonzalez <rymg19@gmail.com> wrote:
If you think of a = a + 1 as "assigning the value of the expression a + 1 to a" and a += 1 as "incrementing a by 1" it's neither weird nor stupid. There are some well-known invariants (for example, that the value of a after the operation should be one more than the value before) that would be confusing to violate, but there are plenty of other aspects of the behaviour that are not so fundamental, and which can safely and sensibly differ between the two operations. Paul PS Note for anyone who wants to take this off on a wild tangent - my above comment is *in the context of Python as it has been defined for 20+ years*. If you want to write a new language, you can make your own judgement about any or all of this, and the success of your language will be the measure of how reasonable your ideas are...
On Wed, Nov 16, 2016 at 07:36:04PM +0000, Paul Moore wrote:
Indeed. Suppose Python had both mutable and immutable ints (as we have mutable lists and immutable tuples, which are kinda-lists). Then given assignment of immutable ints the two forms will be the same. (This is the status quo.) a = b = 99 a = a + 1 assert a == 100 and b == 99 and likewise for a += 1. But for *mutable* ints, they may not be. We might expect: a = b = mutable(99) a = a + 1 assert a == 100 and b == 99 no different from the status quo, but: a = b = mutable(99) a += 1 # modify a in-place assert a == b == 100 as is the status quo for lists. Of course, if we're designing mutable ints, we're free to pick whatever behaviour we want for both __add__ and __iadd__. But we needn't feel that they are *necessarily* identical. -- Steve
Paul Moore writes:
Not quite. Augmented assignment operators were added in Python 2.0 according to What's New, and they were quite controversial (== Guido didn't like them) at the time. In that respect, Mikhail is in good company (perhaps for different reasons). But Guido did accept them, and they are immoveable at this point in time. Steve
On 17 November 2016 at 03:07, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Fair point. My "20+ years" was a rough guess, and wasn't so much intended to relate specifically to augmented assignment as to the principles involved. Python tends to pick up ideas from other C-like languages, and doesn't arbitrarily deviate from common syntax (the conditional expression being the most obvious example where we did use a different syntax than everyone else). Paul PS Whatever the merit of Mikhail's specific proposals, he is prompting discussion on the principles behind our rejection of his ideas, and that's valuable. So thanks to him for that, at least.
On 17 November 2016 at 10:22, Paul Moore <p.f.moore@gmail.com> wrote:
Citation from http://legacy.python.org/dev/peps/pep-0203/ """ Expressions of the form <x> = <x> <operator> <y> are common enough in those languages to make the extra syntax worthwhile, and Python does not have significantly fewer of those expressions. Quite the opposite, in fact, since in Python you can also concatenate lists with a binary operator, something that is done quite frequently. Writing the above expression as <x> <operator>= <y> -> __is both more readable__ and less error prone, because it is instantly obvious to the reader that it is <x> that is being changed, and not <x> that is being replaced by something almost, but not quite, entirely unlike <x>. """ Aha, sure, if "readable" == "suits C programmers". And it's surely not, which in some sence also means that it *more* error prone, since I cannot notice possible error so easy. (I am not trying to start flame again though, that is *not* my intention) Mikhail
On 17.11.2016 11:16, Mikhail V wrote:
The above follows the general principle in Python that "explicit is better than implicit": 1. "a = a + 1" means (in Python): add 1 to a (via the .__add__() method) and bind the new value to "a". 2. "a += 1" means (in Python): let the object a add 1 to itself (via the .__iadd__() method) and bind the new value to "a". In the first variant, a may well result in a new object being created, even changing the object type. In the second variant, it is immediately clear that the intent is for a to do something to itself. It is much less likely to result in a new object type (even though it may still result in a new object being created). More common is to have a manipulate itself without even changing the object. Examples: ---------
Here, a new list object was created.
Here, the object itself was manipulated without creating a copy; and that's what you'd typically expect from an in-place operation on mutable objects. The situation is different with immutable objects:
In both cases, you get new objects (but the object type remains the same). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 17 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 11/16/2016 08:48 AM, Mikhail V wrote:
On 16 November 2016 at 10:27, Paul Moore wrote:
On 16 November 2016 at 08:51, Mikhail V wrote:
Next time, include the "just an example" disclaimer. We don't know what you do and don't know.
You say you have no time and write a whole page about it, so don't blame me that I take too much time from you.
Hopefully you were joking, but it's really hard to tell. -- ~Ethan~
Hi all, Please be mindful when replying, even if some of the lurker know who some of you are and can figure out that some of the reply to this thread below this message are sarcastic, not all readers can. Your messages can also be cited out of context. Thus many messages in this thread can be misinterpreted, and can be/are hurtful (regardless of previous misinterpretation). Please try to give the example. Some of the recent exchanges are typically the kind of things that are driving contributors away, or even just repel users from following what's happening on Python-*. Honestly I like to hear about ideas here, but if it's to have to read these kind of exchanges, I'm starting to lean toward unsubscribing. I'll remind you that Brett Cannon wrote an email to this list only 9 days ago to remind people to be civil. Also when you are subscribed to the mailing list a link to the code of conduct is appended to every mails: Code of Conduct: http://python.org/psf/codeofconduct/ Regards, -- Matthias On Wed, Nov 16, 2016 at 1:27 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Matthias Bussoni writes:
Mikhail has long since gone past the point where further posts from him deserve such consideration. Replying to Paul Moore when deprecating "sarcastic" replies is just bad manners; Paul is never intentionally sarcastic that I can remember. Mikhail V writes:
So I can do better if we imagine, just imagine, such a scenario:
I can imagine it, and immediately reject it for reasons already given for precisely that scenario. Evidently you have not understood the answers that have been given already. Please just stop. You are trying to enforce your preferences on the Python world, and that is just not going to happen because the Python world has already demonstrated strong preference in the opposite direction, starting at
Both I and David Mertz, among others, have addressed this point directly. It is not going to happen. Of course I am not authoritative; if 6 or 7 different posters does not convince you, feel free to ask Guido directly. But it is useless to continue here. Your questions have all already been answered in full. Your preference has not been denied; it's simply impossible to satisfy it and the preference of the great majority (David estimated 80%, sort of humorously I think; I'm stodgy, I'll just say significantly more than 50%) at the same time. Your persistence given those responses is rude, because you're simply ignoring the effort that others have taken to address your posts. Please stop both the repeat posting and the failure to acknowledge the effort others have made -- words are not enough, you must try harder to understand to show proper respect.
What semantics it will fundamentally break or so hard to implement?
This has been explained, in detail, in several ways, from at least two points of view. It is rude of you to continue asking. Please stop, reread the posts explaining this point, and ask about specific statements you don't understand rather than whining that nobody seems interested in doing things your way. This is my last post on this matter, and my last reply to you until your behavior indicates an interest in cooperating to solve problems, rather than self-centered demands. Sincerely yours, Stephen Turnbull -- Associate Professor Department of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
On Wed, Nov 16, 2016 at 6:50 PM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Apologies, if my message looked like targetting Paul, and was a reply to Paul. Paul answers were always well written and I never meant to target his message or him, but other messages in the thread. I didn't wanted to look like my comment was about anyone especially any may miss-used my mail client when replying. Sorry about how it could have been perceived, and for doing that. -- M
On 17 November 2016 at 03:50, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Steven, are you sure that Matthias adressed that only to me? There were indeed pair of quite strange comments regarding Numpy and lists that I personally also did not understand. So let us probably wait and Matthias will clear that.
I must say you re getting it wrong, from my side there are only clear *non* self-centered, humanistic intentions. This is probaly not seen, but that is due to differences between people, their culture, background, etc. Everyone is unique and stylistics of words does not reflect it, but the intentions what is important. Mikhail
On 17 November 2016 at 02:50, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
For the record, I didn't take Matthias' comment personally. I presumed that the main focus of his comment was the sub-thread that was hinting towards "NumPy is weird" - some of the comments in there lacked enough context. But regardless, his point was entirely fair - even something as simple as a trimmed quote in email can make a comment mean something quite different from the original intent, so it pays everyone to think carefully about what they say. Oh, and by the way, if you think I'm never sarcastic, you've never met me face to face ;-) I take way more care with my tone in emails than I do in real life! Paul
On 16 November 2016 at 08:51, Mikhail V <mikhailwas@gmail.com> wrote:
What semantics it will fundamentally break or so hard to implement?
I'm afraid I don't have time at the moment to fully review your email, but my first impression is that you are proposing that the name "self" be treated specially. It's going to be very difficult to convince people that this is a good idea. In the first instance, if you're talking about "self" being a keyword, that would break the current usage of "self" as a normal variable name, which is used by convention in all class methods to represent the current object. If you're not aware, in class A: def method(self): ... the use of self as the variable name is *convention*. You could use any other name just as well. If self were a keyword, it couldn't be used here. So making "self" a keyword would be a major change. In addition, consider code like this: class A(int): def method(self): myvar = 1 myvar = self + 1 return myvar foo = A(5) foo.method() This is legitimate code at the moment. It sets "myvar" to 6 (self is an integer subclass with value 5, which the code adds 1 to) and returns that. Your proposal would change that to return 2. The problem here is that when considering language changes, you can't just consider code that you consider "correct". You have to take account of the fact that other people may be writing code that is to your eyes bizarre and unmaintainable - but if it does what they want it to, and it works according to the language specification, they have a right to expect that the behaviour won't get changed (at least not without due consideration of the backward compatibility process). So proposals that change the behaviour of currently working code have to be *very* careful to consider all edge cases. This is probably the biggest hurdle for people proposing changes to Python to get over. Backward compatibility isn't pleasant to deal with - it's frustrating and demotivating to have a good idea blocked because code that seems senseless "might break". But that's part of the price we have to pay for Python being a hugely popular language. Hope this is useful. Paul
On 16 November 2016 at 10:27, Paul Moore <p.f.moore@gmail.com> wrote:
Oh Paul, come on, pleeeeease. I am making an **example**. Write a "poo" instead or a poo pile character, whatever. You think I am an idiot and don't know that there is "self" in OOP. When I was writing that I just thought, should I make a special note that I am making it only for example, but then thought, oh that would be too pedantic. You say you have no time and write a whole page about it, so don't blame me that I take too much time from you. Mikhail
On Nov 16 2016, Mikhail V <mikhailwas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
...and all of Paul's points still apply.
You think I am an idiot and don't know that there is "self" in OOP.
No, that wouldn't be the reason. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
On 16 November 2016 at 16:48, Mikhail V <mikhailwas@gmail.com> wrote:
No I don't think you're an idiot. I thought you were offering a proposal.
Well, if it's "only an example", there's nothing to comment on. You need to offer a proper proposal with the details filled in - otherwise it's not worth replying.
You say you have no time and write a whole page about it, so don't blame me that I take too much time from you.
I'm sorry. I thought I was trying to help by explaining how your proposal could be improved. My mistake - I'll keep quiet next time. Paul
On 16 November 2016 at 18:28, Paul Moore <p.f.moore@gmail.com> wrote:
Paul, ok, I apologize for the latter. But can you see, I spent also quite a bit of time trying to think out use cases, I spent over an hour and looked for similar ideas here. Then I accurately made the subject for the question "Technical possibilities" which already implies that it is about my previous misunderstanding of typed vs. non-typed execution and its possible consequences and it is hard to do without exact knowledge how it all works. Therefore I start small and wanted actually that next time I don't ask stupid questions and other new users can also raise their knowledge for making better quality post. My only fault is that I choose wrong name for the keyword and naively supposed that it will not cause big misunderstanding. Ok? So lets say I made a typo and lets take other keyword, it is not so important in this case, which one. Mikhail
On Wed, Nov 16, 2016 at 11:24:01PM +0100, Mikhail V wrote: [...]
It doesn't matter what keyword you come up with, you still have the problem that this idea introduces a new keyword. New keywords always break backwards compatibility, which means there has to be a good reason to do it. We could make up a random keyword, XusBeooSwqxy3nf7TRx say, and expect that probably nobody in the world has ever used that in their code before. But it would be hard for people to remember and spell correctly, and that goes against the idea that keywords should be meaningful. Any meaningful name you pick as a keyword will probably clash with somebody's code, which means you will break their working program by introducing a new keyword. We take our responsibility seriously: we try very hard to not break people's code when they upgrade, so there has to be a really, really good reason before new keywords are introduced. If this was, say, Python 2.2 or so, and you proposed a new keyword: really_long_variable_name = KEYWORD + 1 then it might be treated a bit more seriously. But the first question we'd ask is, what do other languages do? Python rarely invents new programming ideas itself, but it does copy good ideas from other languages. And of course, the most obvious answer is: Most C-based languages have a += augmented assignment symbol, which avoids the need for a new keyword: really_long_variable_name += 1 Now that we have symbols for augmented assignment, there's *zero* chance that we will remove them, and very little chance that we'll introduce a parallel syntax for doing the same thing by keyword. To get an idea of the standard we require before adding major new syntax or keywords, you should read the historical PEPs: https://www.python.org/dev/peps/ You don't have to write up a full PEP before proposing an idea here, but if the idea involves a large change (especially a new keyword) it almost certainly will require a PEP. But either way, reading the PEPs will give you an idea of what proposals are likely to be accepted, which are likely to be rejected, and which are still open for discussion, as well as the sorts of objections you are likely to receive. -- Steve
On Wed, Nov 16, 2016 at 10:48 AM, Mikhail V <mikhailwas@gmail.com> wrote:
Maybe I should just point out a sec that saying this is a great way to get people to not listen to you. As for your actual question: I'm not sure if I understand correctly, but I think you got things a little mixed up, or I'm not reading this the right way (also likely). Let's not use self anymore as an example, since that ended in fire and brimstone. Let's use something like this: A = source_var + 1 where `source_var` is a magic thing that refers to the target variable. Does that get the same idea across? Yes? Okay. The main reason that this would be difficult to translate isn't difficulty, but just readability. It's weird that using source_var would use __iadd__, but anything else would use __add__. Now, what I think everyone was telling you about as for "difficulty translating" is this: A = A + 1 ==> A += 1 Similar problem: semantics change. If someone decided to be weird and have __add__ and __iadd__ do two different things, this would completely break that. Granted, that's a stupid idea to begin with, but it's still poor justification for the code breakage.
-- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://kirbyfan64.github.io/
On Nov 16 2016, Ryan Gonzalez <rymg19-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Aeh, that's used e.g. in numpy and most certaintly not weird. x = np.range(5) y = x**2 y_int = interpolate(x, y, copy=False) y = y+1 print(y_int(3)) If you replace 'y = y + 1' with 'y += 1', then instead of creating a new array and assigning it to y, you modify the existing array in place, which will change the result of y_int(3). That is a feature. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
The most notable example of something that is "weird" and "a stupid idea" is NumPy... and *everything* in the Scientific Python ecosystem thereby. -- 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.
I think the best way to remove compound operators would be to go back in time and hit Dennis Ritchie with a bat at the exact moment when the notion of them crosses his mind. In all seriousness, compound operators are in practically every modern language and aren't going away. While you don't need to be a savant polyglot and build a database-analysis-webapp in every language known to man, everyone should break out of their own "language bubble" once they have the basics of programming down. Do a tutorial and make a weekend project with a couple other *disparate* languages with different paradigms (not just close relatives like Python and Ruby, or Java and C and C++). There's always something good in other perspectives and worth learning from. Except Perl. On Wed, Nov 16, 2016 at 3:08 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Nick Timkovich writes:
True enough as a concept, but Python didn't have to implement them for immutables. It might have been interesting to allow in-place operations only for mutables. Dunno if Guido thought of that at the time, and I suspect that a lot of the voices that convinced him to go against his instincts wanted them specifically for integers (a lot of people wanted "++" and "--", too). So even if he did think of it, it might not have satisfied the proponents that their needs were being addressed.
Except Perl.
Please don't. Perl has its weaknesses, but it has its strengths too. I suspect that Python regexps were strongly influenced by PCRE, and that the Cheeseshop has borrowed a feature or two from CPAN.
On Thu, Nov 17, 2016 at 12:07:34PM +0900, Stephen J. Turnbull wrote:
By definition, you can only perform in-place operations on mutables. But I guess you are talking about the syntax. Should += raise an exception if the assignment target is immutable? Problem is, how is the Python interpreter supposed to determine whether or not the target is immutable or mutable? There's no isinstance(obj, Immutable) and I doubt there ever will be. More importantly, banning immutables would immediately prohibit the number one most common use of augmented assignment, and probably the largest motivation for the feature: x += 1
Indeed. Supporting `alist += [x]` but not `x += 1` would have been deeply unsatisfactory. I think the status quo is actually very clever: augmented assignment is broadly equivalent to the expanded assignment: obj += foo => obj = obj + foo except that the target obj has the opportunity to optimize it to an in-place operation, even if that makes the semantics slightly different from the ordinary & operator.
Except Perl.
Please don't.
I don't think there is any need for that. No harm is done by a little light-hearted banter relating to the rivalry between programming language communities. In the big picture, a bit of friendly rivalry probably does both communities good. Regardless of what virtues Perl may or may not have, in some ways the philosophy behind Perl is dramatically opposed to that of Python. Many of us like Python code because it goes against Perl's ideals. We discourage many of the things that Perl and its culture encourages: terse, long one-liners, heavy use of regexes, heavy use of sigils and symbols, "clever" code, and More Than One Way To Do It. There's a natural rivalry between Perl and Python. We should be permitted to criticise other languages, and even dismiss them as useless. Programming languages do not have the assumption of dignity owed to human beings. Nick's dismissal of Perl was obviously intended as light-hearted and not entirely serious. This is an informal forum, a mailing list, and throw-away comments intended as humour shouldn't be held to the same standard as serious statements intended as part of a logical argument. Had Nick said "Python should not do X, because Perl does it and nothing Perl does is of any value at all" then we'd be justified in asking him to defend his claim, or to simply dismiss it as obviously ridiculous. But he didn't. I doubt Nick meant that Perl was literally lacking in any redeeming features: exaggeration and hyperbole are time-honoured forms of humour. His comments weren't disruptive and they most certainly were not attacking anyone. It would require the most extraordinarily thin skin to take that as an attack against people who use Perl, and even if somebody did, well, this is not a support group for people so lacking in self-esteem that their self-image is equated to their choice of programming language. (I believe we've already had to ban, or at least warn, one regular to this list under the terms of the CoC, because he couldn't distinguish ill-founded criticism of Python the language from criticism of the people designing and using the language, and he responded with personal attacks.) I'm sorry that I've written more words defending Nick's throw-away two word comment than you expended in lightly chastising him. But I didn't want to just say that I disagreed with you -- I wanted to give the reasons why I support our right to light-heartedly disrespect other languages. (And of course you're right, Python has borrowed regular expression syntax and the Cheeseshop from Perl, and possibly more.) -- Steve
Steven D'Aprano writes:
I don't disagree with that principle, just with the evaluation of the tone, and even that is the difference between rgb.txt's grey49 and grey51. Calling old-style Perl one-liners "line noise" I would count as "light-hearted banter". "All languages have something to teach us -- but let's be really careful about which parts of Perl we study" I would count as lighthearted *and* making the point that we have our own style, which is pretty close to diametrically opposed to the one-liners that Perl is so useful for. "We have nothing to learn from Perl" in context (IIRC, Perl had not been mentioned in this thread to that point, and definitely the emphasis was on C/C++ and Java) was gratuitous and extreme, pure trash talking. Which has its place.[1] I don't think it's unreasonable to request tone-down when it's gratuitous. And I did mean "request" -- I wouldn't follow up to the OP if he chose to disagree with me, even in public. Here I'm discussing a principle that is not absolute, just one I'd like to advocate, and your post gives me a chance.
Regardless of what virtues Perl may or may not have, in some ways the philosophy behind Perl is dramatically opposed to that of Python.
So make that point. Just do it better than I did above! :-)
We should be permitted to criticise other languages,
Sure.
and even dismiss them as useless.
That's another matter, slightly different, but it's an important difference. There was an excellent blog post a couple years ago on "Contempt Culture"[2]. I deny that Nick's comment was made out of contempt, but I have to suspect that past contemptuous utterances provided context for it. The point of the term "culture" is that the contempt becomes natural in context, and indetectable to the speaker, and many of the listeners.
Programming languages do not have the assumption of dignity owed to human beings.
No, but their users are quite capable of *taking* offense where none was offered to them. And nasty people are quite capable of quoting out of context, just to see you and him fight. After a lifetime of using those facts as an excuse for my own borderline insults[3], I've decided I like the much more friendly style of the Python dev lists. It's not that there's no conflict here, but generally the arguments are delivered in such a way that people stay calm throughout.
Of course not. But are you aware that many women are of the opinion that the Python dev community is an uncomfortable place to hang out? I don't know why yet, but the women who have told me they feel that way are quite capable of holding their own in a battle of words and wits when they want to, so they could handle python-dev if they wanted to. With as few reviewers as we have, I would rather risk convincing a few participants I'm some sort of "PC fanatic" than risk chasing away the brain power of half the human race. No, I don't *know* that humorous dismissals of whole programming environments contribute to that alleged atmosphere. I don't even have full understanding of what the issue is, just that I respect the women who have mentioned it to me enough to consider their statements to be evidence (not "proof"). I don't claim to have anything more than personal preference, and a very vague hope for increased participation from a group I think is currently underrepresented here, behind my request this time.
I'm sorry that I've written more words defending Nick's throw-away two word comment than you expended in lightly chastising him.
I'm not. These are very difficult and subtle issues, and you've expressed an important point of view eloquently. And I am very aware that current subscribers of the list have the right to express themselves with such humor, at least as I understand the current list policy.[4] I just wish such expression would be avoided, and I like to think my wish is partly motivated by a certain amount of public-spirited-ness, and that said motivation is in response to a real issue. Steve Footnotes: [1] Cf. http://www.jwz.org/gruntle/rbarip.html, though nothing could be like that any more. ;-) [2] http://blog.aurynn.com/contempt-culture. I suspect it's not the origin of the term, but don't feel like digging further. [3] My out-and-out insults were generally committed with malice aforethought, in the expectation of getting as good as I gave.[1] [4] I suspect that if asked, Brett would sympathize with my preference, and if not asked directly, he would say nothing precisely because anything he says might be construed to be policy, and this isn't. But you'd have to ask him. :-)
On 16 November 2016 at 17:50, Ryan Gonzalez <rymg19@gmail.com> wrote:
If you think of a = a + 1 as "assigning the value of the expression a + 1 to a" and a += 1 as "incrementing a by 1" it's neither weird nor stupid. There are some well-known invariants (for example, that the value of a after the operation should be one more than the value before) that would be confusing to violate, but there are plenty of other aspects of the behaviour that are not so fundamental, and which can safely and sensibly differ between the two operations. Paul PS Note for anyone who wants to take this off on a wild tangent - my above comment is *in the context of Python as it has been defined for 20+ years*. If you want to write a new language, you can make your own judgement about any or all of this, and the success of your language will be the measure of how reasonable your ideas are...
On Wed, Nov 16, 2016 at 07:36:04PM +0000, Paul Moore wrote:
Indeed. Suppose Python had both mutable and immutable ints (as we have mutable lists and immutable tuples, which are kinda-lists). Then given assignment of immutable ints the two forms will be the same. (This is the status quo.) a = b = 99 a = a + 1 assert a == 100 and b == 99 and likewise for a += 1. But for *mutable* ints, they may not be. We might expect: a = b = mutable(99) a = a + 1 assert a == 100 and b == 99 no different from the status quo, but: a = b = mutable(99) a += 1 # modify a in-place assert a == b == 100 as is the status quo for lists. Of course, if we're designing mutable ints, we're free to pick whatever behaviour we want for both __add__ and __iadd__. But we needn't feel that they are *necessarily* identical. -- Steve
Paul Moore writes:
Not quite. Augmented assignment operators were added in Python 2.0 according to What's New, and they were quite controversial (== Guido didn't like them) at the time. In that respect, Mikhail is in good company (perhaps for different reasons). But Guido did accept them, and they are immoveable at this point in time. Steve
On 17 November 2016 at 03:07, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Fair point. My "20+ years" was a rough guess, and wasn't so much intended to relate specifically to augmented assignment as to the principles involved. Python tends to pick up ideas from other C-like languages, and doesn't arbitrarily deviate from common syntax (the conditional expression being the most obvious example where we did use a different syntax than everyone else). Paul PS Whatever the merit of Mikhail's specific proposals, he is prompting discussion on the principles behind our rejection of his ideas, and that's valuable. So thanks to him for that, at least.
On 17 November 2016 at 10:22, Paul Moore <p.f.moore@gmail.com> wrote:
Citation from http://legacy.python.org/dev/peps/pep-0203/ """ Expressions of the form <x> = <x> <operator> <y> are common enough in those languages to make the extra syntax worthwhile, and Python does not have significantly fewer of those expressions. Quite the opposite, in fact, since in Python you can also concatenate lists with a binary operator, something that is done quite frequently. Writing the above expression as <x> <operator>= <y> -> __is both more readable__ and less error prone, because it is instantly obvious to the reader that it is <x> that is being changed, and not <x> that is being replaced by something almost, but not quite, entirely unlike <x>. """ Aha, sure, if "readable" == "suits C programmers". And it's surely not, which in some sence also means that it *more* error prone, since I cannot notice possible error so easy. (I am not trying to start flame again though, that is *not* my intention) Mikhail
On 17.11.2016 11:16, Mikhail V wrote:
The above follows the general principle in Python that "explicit is better than implicit": 1. "a = a + 1" means (in Python): add 1 to a (via the .__add__() method) and bind the new value to "a". 2. "a += 1" means (in Python): let the object a add 1 to itself (via the .__iadd__() method) and bind the new value to "a". In the first variant, a may well result in a new object being created, even changing the object type. In the second variant, it is immediately clear that the intent is for a to do something to itself. It is much less likely to result in a new object type (even though it may still result in a new object being created). More common is to have a manipulate itself without even changing the object. Examples: ---------
Here, a new list object was created.
Here, the object itself was manipulated without creating a copy; and that's what you'd typically expect from an in-place operation on mutable objects. The situation is different with immutable objects:
In both cases, you get new objects (but the object type remains the same). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 17 2016)
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 11/16/2016 08:48 AM, Mikhail V wrote:
On 16 November 2016 at 10:27, Paul Moore wrote:
On 16 November 2016 at 08:51, Mikhail V wrote:
Next time, include the "just an example" disclaimer. We don't know what you do and don't know.
You say you have no time and write a whole page about it, so don't blame me that I take too much time from you.
Hopefully you were joking, but it's really hard to tell. -- ~Ethan~
Hi all, Please be mindful when replying, even if some of the lurker know who some of you are and can figure out that some of the reply to this thread below this message are sarcastic, not all readers can. Your messages can also be cited out of context. Thus many messages in this thread can be misinterpreted, and can be/are hurtful (regardless of previous misinterpretation). Please try to give the example. Some of the recent exchanges are typically the kind of things that are driving contributors away, or even just repel users from following what's happening on Python-*. Honestly I like to hear about ideas here, but if it's to have to read these kind of exchanges, I'm starting to lean toward unsubscribing. I'll remind you that Brett Cannon wrote an email to this list only 9 days ago to remind people to be civil. Also when you are subscribed to the mailing list a link to the code of conduct is appended to every mails: Code of Conduct: http://python.org/psf/codeofconduct/ Regards, -- Matthias On Wed, Nov 16, 2016 at 1:27 AM, Paul Moore <p.f.moore@gmail.com> wrote:
Matthias Bussoni writes:
Mikhail has long since gone past the point where further posts from him deserve such consideration. Replying to Paul Moore when deprecating "sarcastic" replies is just bad manners; Paul is never intentionally sarcastic that I can remember. Mikhail V writes:
So I can do better if we imagine, just imagine, such a scenario:
I can imagine it, and immediately reject it for reasons already given for precisely that scenario. Evidently you have not understood the answers that have been given already. Please just stop. You are trying to enforce your preferences on the Python world, and that is just not going to happen because the Python world has already demonstrated strong preference in the opposite direction, starting at
Both I and David Mertz, among others, have addressed this point directly. It is not going to happen. Of course I am not authoritative; if 6 or 7 different posters does not convince you, feel free to ask Guido directly. But it is useless to continue here. Your questions have all already been answered in full. Your preference has not been denied; it's simply impossible to satisfy it and the preference of the great majority (David estimated 80%, sort of humorously I think; I'm stodgy, I'll just say significantly more than 50%) at the same time. Your persistence given those responses is rude, because you're simply ignoring the effort that others have taken to address your posts. Please stop both the repeat posting and the failure to acknowledge the effort others have made -- words are not enough, you must try harder to understand to show proper respect.
What semantics it will fundamentally break or so hard to implement?
This has been explained, in detail, in several ways, from at least two points of view. It is rude of you to continue asking. Please stop, reread the posts explaining this point, and ask about specific statements you don't understand rather than whining that nobody seems interested in doing things your way. This is my last post on this matter, and my last reply to you until your behavior indicates an interest in cooperating to solve problems, rather than self-centered demands. Sincerely yours, Stephen Turnbull -- Associate Professor Department of Policy and Planning Science http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information Email: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
On Wed, Nov 16, 2016 at 6:50 PM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Apologies, if my message looked like targetting Paul, and was a reply to Paul. Paul answers were always well written and I never meant to target his message or him, but other messages in the thread. I didn't wanted to look like my comment was about anyone especially any may miss-used my mail client when replying. Sorry about how it could have been perceived, and for doing that. -- M
On 17 November 2016 at 03:50, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Steven, are you sure that Matthias adressed that only to me? There were indeed pair of quite strange comments regarding Numpy and lists that I personally also did not understand. So let us probably wait and Matthias will clear that.
I must say you re getting it wrong, from my side there are only clear *non* self-centered, humanistic intentions. This is probaly not seen, but that is due to differences between people, their culture, background, etc. Everyone is unique and stylistics of words does not reflect it, but the intentions what is important. Mikhail
On 17 November 2016 at 02:50, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
For the record, I didn't take Matthias' comment personally. I presumed that the main focus of his comment was the sub-thread that was hinting towards "NumPy is weird" - some of the comments in there lacked enough context. But regardless, his point was entirely fair - even something as simple as a trimmed quote in email can make a comment mean something quite different from the original intent, so it pays everyone to think carefully about what they say. Oh, and by the way, if you think I'm never sarcastic, you've never met me face to face ;-) I take way more care with my tone in emails than I do in real life! Paul
participants (12)
-
David Mertz -
Ethan Furman -
Greg Ewing -
M.-A. Lemburg -
Matthias Bussonnier -
Mikhail V -
Nick Timkovich -
Nikolaus Rath -
Paul Moore -
Ryan Gonzalez -
Stephen J. Turnbull -
Steven D'Aprano