On Fri, Mar 15, 2019 at 12:25:22PM +0100, Antoine Pitrou wrote:
> Yeah, well I do think "+=" for lists was a mistake. I *still* have
> trouble remembering the exact difference between "list +=" and
> "list.extend" (yes, there is one: one accepts more types than the
> other... which one it
On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano
wrote:
> [snip]
>
> I still remember being told in no uncertain terms by the core devs that
> adding a clear() method to lists was a waste of time because there was
> already a perfectly good way to spell it with slicing. And then ABCs
> came
On Fri, Mar 15, 2019 at 11:54:51AM -0300, Andre Roberge wrote:
> On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano
> wrote:
>
> > [snip]
> >
> > I still remember being told in no uncertain terms by the core devs that
> > adding a clear() method to lists was a waste of time because there was
> >
On Fri, Mar 15, 2019 at 12:34:45PM +0100, Antoine Pitrou wrote:
> On Thu, 7 Mar 2019 10:58:02 +1100
> Chris Angelico wrote:
> >
> > Lots of words that basically say: Stuff wouldn't be perfectly pure.
>
> Chris, please learn to think twice before contributing what is
> essentially a
On Fri, Mar 15, 2019 at 11:15 AM Steven D'Aprano
wrote:
> On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote:
>
> > Watch the tone please.
>
> Brett, you might have missed my comment about wanting to avoid unhelpful
> arguments about tone, but if you are going to complain about
On 3/14/19 9:47 PM, Chris Angelico wrote:
> What happens when someone wants to support multiple Python versions?
> "Requires Python 3.5 or newer" is easy. Forcing people to install the
> correct one for each version isn't.
What are the reasons why people want to support multiple Python
Le 15 mars 2019 à 19:44:15, francismb
(franci...@email.de(mailto:franci...@email.de)) a écrit:
>
>
> On 3/14/19 9:47 PM, Chris Angelico wrote:
> > What happens when someone wants to support multiple Python versions?
> > "Requires Python 3.5 or newer" is easy. Forcing people to install the
> >
On 3/13/19 7:44 PM, David Teresi wrote:
> `->` would not be ambiguous in the proposed cases, but it does already
> mean something elsewhere in the language as of 3.5:
>
> def concat(a: str, b: str) -> str:
> return a + b
>
> This could potentially cause confusion (as with the % operator being
Thanks!
On 3/15/19 8:56 PM, Chris Angelico wrote:
> The same is true of books that discuss the language, blog posts giving
> tips and tricks, Stack Overflow answers, and everything else that
> incorporates code that people might want to copy and paste. What
> version of Python do you need? What's
On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote:
> Watch the tone please.
Brett, you might have missed my comment about wanting to avoid unhelpful
arguments about tone, but if you are going to complain about people's
tone, the considerate thing to do is to say what it is that
Raymond Hettinger wrote:
> Frequency of usage: Math provides ∑ and ∏ because they are common. It
> doesn't provide a special operator for sqrt(c**2 - b**2) because the latter
> is less fundamental and less common.
Here's some more information. Below is an example of an area, where
sqrt(c**2
On 3/15/2019 11:21 AM, Steven D'Aprano wrote:
On Fri, Mar 15, 2019 at 11:54:51AM -0300, Andre Roberge wrote:
On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano
wrote:
[snip]
I still remember being told in no uncertain terms by the core devs that
adding a clear() method to lists was a waste of
On Fri, Mar 15, 2019 at 4:36 AM Antoine Pitrou wrote:
> On Thu, 7 Mar 2019 10:58:02 +1100
> Chris Angelico wrote:
> >
> > Lots of words that basically say: Stuff wouldn't be perfectly pure.
>
> Chris, please learn to think twice before contributing what is
> essentially a trivialization of
There's been a lot of discussion about an operator to merge two dicts. I
participated in the beginning but quickly felt overwhelmed by the endless
repetition, so I muted most of the threads.
But I have been thinking about the reason (some) people like operators, and
a discussion I had with my
On Sat, Mar 16, 2019 at 5:43 AM francismb wrote:
>
> On 3/14/19 9:47 PM, Chris Angelico wrote:
> > What happens when someone wants to support multiple Python versions?
> > "Requires Python 3.5 or newer" is easy. Forcing people to install the
> > correct one for each version isn't.
> What are the
> On Mar 15, 2019, at 10:51 AM, Guido van Rossum wrote:
>
> The general idea here is that once you've learned this simple notation,
> equations written using them are easier to *manipulate* than equations
> written using functional notation -- it is as if our brains grasp the
> operators
Guido wrote:
> There's been a lot of discussion about an operator to merge two dicts. I
> participated in the beginning but quickly felt overwhelmed by the endless
> repetition, so I muted most of the threads.
> But I have been thinking about the reason (some) people like operators, and a
>
Hi Greg,
On 3/15/19 5:33 AM, Greg Ewing wrote:
> Not really. Having to translate all your source every time a
> minor version update occurs would be a huge hassle.
PythonUAAS: upload the sources (zipped or packaged) and get them updated
back ;-)
Regards,
--francis
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> Not really. For example, addition of syntax like "async" and "yield"
> fundamentally changes the meaning of "def", in ways that *could not*
> be fully emulated in earlier Pythons. The semantics simply were
> impossible to produce -- that's why
Le 15 mars 2019 à 18:52:51, Guido van Rossum
(gu...@python.org(mailto:gu...@python.org)) a écrit:
…
> The power of visual processing really becomes apparent when you combine
> multiple operators. For example, consider the distributive law:
>
> mul(n, add(x, y)) == add(mul(n, x), mul(n, y)) (5)
On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> The thing about "within 3" upgrades is that that kind of project-wide
> annoyance is going to be minimal, because the language is mostly
> growing in power, not changing the semantics of existing syntax. Such
> changes are very rare, and
On 3/15/19 2:34 PM, francismb wrote:
I understand that no one really wants to annoy the language users by
breaking the code and that's why those changes are considered carefully.
Is that may be because there is no easy way to write a translator? or
there is no translator to help transition?
On 15/03/2019 18:54, Raymond Hettinger wrote:
So, we have to ask whether we're stretching too far from "operators are good" to "we
need this operator". Here are some considerations:
Frequency of usage: Math provides ∑ and ∏ because they are common. It doesn't
provide a special operator for
Hello, Steven,
This wasn't a question asking for support. The answers I found when
searching were different from what I needed, that's why I'm using my own.
But I understand the point.
Regards,
Vlad
Le jeu. 14 mars 2019 à 23:43, Steven D'Aprano a
écrit :
> Hi Vlad, and welcome!
>
> On Thu,
On Fri, Mar 15, 2019 at 08:10:58PM +0100, francismb wrote:
> On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> > Not really. For example, addition of syntax like "async" and "yield"
> > fundamentally changes the meaning of "def", in ways that *could not*
> > be fully emulated in earlier Pythons.
> On Mar 15, 2019, at 12:28 PM, Rhodri James wrote:
>
> I suspect this is a bit personal; I had sufficiently evil lecturers in my
> university Algebra course that I still don't automatically take the
> commutativity of "+" over a particular group as a given :-) Nothing is
> obvious unless
On Sat, Mar 16, 2019 at 12:40 PM Raymond Hettinger
wrote:
> Also, it seems like the efficiency concerns were dismissed with hand-waving.
> But usually, coping and updating aren't the desired behavior. When teaching
> Python, I like to talk about how the design of the language nudges you
>
On Sat, Mar 16, 2019 at 12:28 PM Steven D'Aprano wrote:
>
> On Fri, Mar 15, 2019 at 08:10:58PM +0100, francismb wrote:
> > On 3/15/19 4:54 AM, Stephen J. Turnbull wrote:
> > > Not really. For example, addition of syntax like "async" and "yield"
> > > fundamentally changes the meaning of "def",
> On Mar 15, 2019, at 6:49 PM, Chris Angelico wrote:
>
> On Sat, Mar 16, 2019 at 12:40 PM Raymond Hettinger
> wrote:
>> Also, it seems like the efficiency concerns were dismissed with hand-waving.
>> But usually, coping and updating aren't the desired behavior. When teaching
>> Python, I
On Sat, Mar 16, 2019 at 1:27 PM Raymond Hettinger
wrote:
>
> > On Mar 15, 2019, at 6:49 PM, Chris Angelico wrote:
> >
> > On Sat, Mar 16, 2019 at 12:40 PM Raymond Hettinger
> > wrote:
> >> Also, it seems like the efficiency concerns were dismissed with
> >> hand-waving. But usually, coping and
On 2019-03-15 19:05, Jonathan Fine wrote:> Guido wrote:
>
>> There's been a lot of discussion about an operator to merge two
dicts. I participated in the beginning but quickly felt overwhelmed by
the endless repetition, so I muted most of the threads.
>
>> But I have been thinking about the
On Sat, Mar 16, 2019 at 7:35 AM francismb wrote:
>
> Thanks!
> On 3/15/19 8:56 PM, Chris Angelico wrote:
> > The same is true of books that discuss the language, blog posts giving
> > tips and tricks, Stack Overflow answers, and everything else that
> > incorporates code that people might want to
Despite my poor python skills, i don't think i'd ever use this one.
blocks = blocks + [block] # Not good for you.
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of
On Sat, Mar 16, 2019 at 2:51 AM Guido van Rossum wrote:
>
> But I think that the folks who point out "there is already a way to do this"
> are missing the point that it really is easier to grasp the meaning of this:
>
> d = d1 + d2
>
> compared to this:
>
> d = d1.copy()
> d =
On Fri, Mar 15, 2019 at 9:19 PM Inada Naoki wrote:
> On Sat, Mar 16, 2019 at 2:51 AM Guido van Rossum wrote:
> >
> > But I think that the folks who point out "there is already a way to do
> this" are missing the point that it really is easier to grasp the meaning
> of this:
> >
> > d = d1 +
On Wed, 6 Mar 2019 00:46:57 +
Josh Rosenberg
wrote:
>
> Overloading + lacks the clear descriptive aspect of update that describes
> the goal of the operation, and contradicts conventions (in Python and
> elsewhere) about how + works (addition or concatenation, and a lot of
> people don't
On Mon, 4 Mar 2019 16:02:06 +0100
Stefan Behnel wrote:
> INADA Naoki schrieb am 04.03.19 um 11:15:
> > Why statement is not enough?
>
> I'm not sure I understand why you're asking this, but a statement is "not
> enough" because it's a statement and not an expression.
This is an argument for
On Mon, 4 Mar 2019 15:57:38 -0800
Guido van Rossum wrote:
>
> > Those two points make me uncomfortable with "+=" strictly behaving
> > like ".update()".
>
> And yet that's how it works for lists. (Note that dict.update() still has
> capabilities beyond +=, since you can also invoke it with
On Thu, 7 Mar 2019 10:58:02 +1100
Chris Angelico wrote:
>
> Lots of words that basically say: Stuff wouldn't be perfectly pure.
Chris, please learn to think twice before contributing what is
essentially a trivialization of someone else's arguments. You're not
doing anything useful here, and
On Fri, Mar 15, 2019 at 12:20:21PM +0100, Antoine Pitrou wrote:
> Agreed with this. What is so useful exactly in this new dict operator
> that it hasn't been implemented, say, 20 years ago?
One could say the same thing about every new feature. Since Python 1.5
was so perfect, why add Unicode,
40 matches
Mail list logo
