On Saturday, July 1, 2017, Steven D'Aprano wrote:
> On Fri, Jun 30, 2017 at 01:09:51AM +0200, Jan Kaliszewski wrote:
>
> [...]
>
> But the more I think about it the more I agree with Nick. Let's start
> by moving itertools.chain into built-ins, with zip and map, and only
> consider giving it an o
On Fri, Jun 30, 2017 at 01:09:51AM +0200, Jan Kaliszewski wrote:
> But implementation of the OP's proposal does not need to be based on
> __add__ at all. It could be based on extending the current behaviour of
> the `+` operator itself.
>
> Now this behavior is (roughly): try left side's __add__
We HAVE spellings for these things:
c from:
>>yield from a
>>yield from b
>>
>
c = chain(a, b)
> c as list from:
>>yield from a
>>yield from b
>>
>
c = list(chain(a, b))
> c as sum from:
>>yield from a
>>yield from b
>>
>
c = sum(chain(a, b))
Those really are not "craz
On 26Jun2017 23:26, Koos Zevenhoven wrote:
I sometimes wish there was something like
c from:
yield from a
yield from b
Nice.
...or to get a list:
c as list from:
yield from a
yield from b
...or a sum:
c as sum from:
yield from a
yield from b
These would be great for a
On 28Jun2017 09:54, Paul Moore wrote:
On 28 June 2017 at 05:30, Terry Reedy wrote:
On 6/27/2017 10:47 PM, Nick Coghlan wrote:
While I haven't been following this thread closely, I'd like to note
that arguing for a "chain()" builtin has the virtue that would just be
arguing for the promotion
On 2017-06-30 07:17 PM, Victor Stinner wrote:
2017-06-30 17:09 GMT+02:00 Soni L. :
CPython should get a tracing JIT that turns slow bytecode into fast
bytecode.
A JIT doesn't have to produce machine code. bytecode-to-bytecode compilation
is still compilation. bytecode-to-bytecode compilation
2017-06-30 17:09 GMT+02:00 Soni L. :
> CPython should get a tracing JIT that turns slow bytecode into fast
> bytecode.
>
> A JIT doesn't have to produce machine code. bytecode-to-bytecode compilation
> is still compilation. bytecode-to-bytecode compilation works on iOS, and
> doesn't require deviat
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 30/06/2017 16:09, Soni L. wrote:
CPython should get a tracing JIT that turns slow bytecode into fast
bytecode.
A JIT doesn't have to produce machine code. bytecode-to-bytecode
compilation is still compilation. bytecode-to-bytecode compilation works
on iOS, and doesn't require deviating fro
On Jun 30, 2017 2:23 PM, "Erik Bray" wrote:
I actually really like this proposal, in additional to the original
proposal of using '+' to chain generators--I don't think it
necessarily needs to be extended to *all* iterables. But this
proposal goes one better. I just have to wonder what kind of
On Jun 30, 2017 5:16 PM, "Oleg Broytman" wrote:
On Fri, Jun 30, 2017 at 12:09:52PM -0300, "Soni L."
wrote:
> CPython should get a
You're welcome to create one. Go on, send your pull requests!
But if you are planning to do that, it is still a good idea to ask for
feedback here first. That w
PyPy does basically this. So does the tentative project Pyjion. Also Numba,
but on a pre-function basis. It's not a bad ideas, and one that currently
exists with varying degrees of refinement in several projects. I may have
forgotten a few others. I suppose Brython in a sense.
This is very unlikel
On Fri, Jun 30, 2017 at 12:09:52PM -0300, Soni L. wrote:
> CPython should get a tracing JIT that turns slow bytecode into fast
> bytecode.
Are you volunteering to do the work?
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://m
On Fri, Jun 30, 2017 at 12:09:52PM -0300, "Soni L."
wrote:
> CPython should get a
You're welcome to create one. Go on, send your pull requests!
Oleg.
--
Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETU
CPython should get a tracing JIT that turns slow bytecode into fast
bytecode.
A JIT doesn't have to produce machine code. bytecode-to-bytecode
compilation is still compilation. bytecode-to-bytecode compilation works
on iOS, and doesn't require deviating from C.
(This "internal bytecode" shou
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/p...@phdru.name
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
On Fri, Jun 30, 2017 at 1:09 AM, Jan Kaliszewski wrote:
> 2017-06-25 Serhiy Storchaka dixit:
>
>> 25.06.17 15:06, lucas via Python-ideas пише:
>
>> > I often use generators, and itertools.chain on them.
>> > What about providing something like the following:
>> >
>> > a = (n for n in range(2
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
25 matches
Mail list logo
