On 6/30/2017 9:24 AM, Oleg Broytman wrote:
On Fri, Jun 30, 2017 at 03:10:08PM +0200, "Sven R. Kunze"
wrote:
'+' is the perfect concat operator. I love Python for this feature.
+1 from me
and me. I think extending it to chain iterators is an intriguing idea.
It would not be the first
On Sat, Jul 1, 2017 at 12:39 AM, Soni L. wrote:
> || is the mathematical notation for concatenation. Which, just so happens to
> be available in Python, even if it might be confused with short-circuiting
> `or`.
Also used in REXX. But the short-circuiting 'or' is not overridable.
You'd have to us
On 2017-06-30 09:43 AM, Steven D'Aprano wrote:
On Fri, Jun 30, 2017 at 12:51:26PM +0100, Jamie Willis wrote:
Just as an aside, if a concatenation operator *was* included, a suitable
operator would be "++",
As mentioned earlier in this thread, that is not possible in Python as
syntactically `
> On Jun 30, 2017, at 8:43 AM, Steven D'Aprano wrote:
>
>> On Fri, Jun 30, 2017 at 12:51:26PM +0100, Jamie Willis wrote:
>>
>> Alternatively
>> "<>" is an alternative, being the monoidal append operator in Haskell,
>> which retains a certain similarly.
>
> "<>" is familiar to many people as "n
On Fri, Jun 30, 2017 at 03:10:08PM +0200, "Sven R. Kunze"
wrote:
> '+' is the perfect concat operator. I love Python for this feature.
+1 from me
> Regards,
> Sven
Oleg.
--
Oleg Broytmanhttp://phdru.name/[email protected]
Programmers don't die, they j
On 30.06.2017 13:51, Jamie Willis wrote:
Just as an aside, if a concatenation operator *was* included, a
suitable operator would be "++", this is the concatenation operator in
languages like Haskell (for strings) and the majority of Scala cases.
Alternatively "<>" is an alternative, being the m
On Fri, Jun 30, 2017 at 12:51:26PM +0100, Jamie Willis wrote:
> Just as an aside, if a concatenation operator *was* included, a suitable
> operator would be "++",
As mentioned earlier in this thread, that is not possible in Python as
syntactically `x ++ y` would be parsed as `x + (+y)` (the plu
Just as an aside, if a concatenation operator *was* included, a suitable
operator would be "++", this is the concatenation operator in languages
like Haskell (for strings) and the majority of Scala cases. Alternatively
"<>" is an alternative, being the monoidal append operator in Haskell,
which ret
2017-06-30 1:33 GMT+02:00 Soni L. :
> Step 3. add decimal concatenation operator for numbers: 2 cat 3 == 23, 22
> cat 33 = 2233, etc. if you need bitwise concatenation, you're already in
> bitwise "hack" land so do it yourself. (no idea why bitwise is considered
> hacky as I use it all the time, bu
> On 30 Jun 2017, at 03:14, Soni L. wrote:
>
> This isn't a *major* backwards incompatibility. Unlike with unicode/strings,
> a dumb static analysis program can trivially replace + with the concatenation
> operator, whatever that may be. Technically, nothing forces us to remove +
> from strin
On Thu, Jun 29, 2017 at 11:14:46PM -0300, Soni L. wrote:
> astring cat alist is undefined for string (since strings are very
> specific about types), so it would return a list.
>
> alist cat atuple would return a list, because the list comes first.
This would be strongly unacceptable to me.
If
On 30 June 2017 at 09:33, Soni L. wrote:
> Step 4. make it into python 4, since it breaks backwards compatibility.
If a Python 4.0 ever happens, it will abide by the usual feature
release compatibility restrictions (i.e. anything that it drops will
have gone through programmatic deprecation in pr
-- Forwarded message --
From: Chris Angelico
Date: Fri, Jun 30, 2017 at 9:12 AM
Subject: Re: [Python-ideas] Python 4: Concatenation
To: electron
On Fri, Jun 30, 2017 at 2:38 PM, electron wrote:
> On Fri, Jun 30, 2017 at 8:30 AM, Chris Angelico wrote:
>>
>>
On Fri, Jun 30, 2017 at 12:14 PM, Soni L. wrote:
> This isn't a *major* backwards incompatibility. Unlike with unicode/strings,
> a dumb static analysis program can trivially replace + with the
> concatenation operator, whatever that may be. Technically, nothing forces us
> to remove + from string
On 2017-06-29 09:48 PM, Steven D'Aprano wrote:
On Thu, Jun 29, 2017 at 08:33:12PM -0300, Soni L. wrote:
Step 1. get rid of + for strings, lists, etc. (string/list concatenation
is not addition)
I agree that using + for concatenation is sub-optimal, & is a better
choice, but we're stuck with
I feel like this would literally break the world for almost no real
benefit...
--
Ryan (ライアン)
Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone
elsehttp://refi64.com
On Jun 29, 2017 at 6:33 PM, > wrote:
Step 1. get rid of + for strings, lists, etc. (string/list concatenation
i
On Thu, Jun 29, 2017 at 08:33:12PM -0300, Soni L. wrote:
> Step 1. get rid of + for strings, lists, etc. (string/list concatenation
> is not addition)
I agree that using + for concatenation is sub-optimal, & is a better
choice, but we're stuck with it. And honestly it's not *that* big a deal
t
On Fri, Jun 30, 2017 at 9:33 AM, Soni L. wrote:
> Step 1. get rid of + for strings, lists, etc. (string/list concatenation is
> not addition)
>
> Step 2. add concatenation operator for strings, lists, and basically
> anything that can be iterated. effectively an overloadable itertools.chain.
> (li
Step 1. get rid of + for strings, lists, etc. (string/list concatenation
is not addition)
Step 2. add concatenation operator for strings, lists, and basically
anything that can be iterated. effectively an overloadable
itertools.chain. (list cat list = new list, not iterator, but
effectively m
19 matches
Mail list logo
