On 2019-02-20 10:10, Steven D'Aprano wrote:
> Or if you're worried about the line length:
> result = function(mystr.strip()
>.expandtabs()
>.lower()
>.replace('ham', 'spam')
> I think
It seems
On Thu, 21 Feb 2019, 16:44 Rhodri James, wrote:
> On 21/02/2019 15:31, Robert Vanden Eynde wrote:
> > In funcoperators, because the dot operator is just syntaxic sugar for
> > functions getattr and setattr with a string,
> [snip hideousness]
>
> I have to say, that's a pretty strong argument for
On 21/02/2019 15:47, Robert Vanden Eynde wrote:
On Thu, 21 Feb 2019, 16:44 Rhodri James, wrote:
On 21/02/2019 15:31, Robert Vanden Eynde wrote:
In funcoperators, because the dot operator is just syntaxic sugar for
functions getattr and setattr with a string,
[snip hideousness]
I have to say
On 21/02/2019 15:31, Robert Vanden Eynde wrote:
In funcoperators, because the dot operator is just syntaxic sugar for
functions getattr and setattr with a string,
[snip hideousness]
I have to say, that's a pretty strong argument for not touching
funcoperators with a ten foot bargepool.
--
Rh
In funcoperators, because the dot operator is just syntaxic sugar for
functions getattr and setattr with a string,
a.hello.world
# can be implemented using infix
a -o- 'hello' -o- 'world'
# or using postfix
a |dot('hello') |dot('world')
# using
from funcoperators import postfix, infix
o = infix(g
Correcting myself twice now, that's not a good sign... :-)
On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote:
> But there's a deeper problem with this entire concept, regardless of
> syntax, one which to my knowledge nobody has mentioned yet: it simply
> isn't compatible with the
On 2/20/19 7:46 PM, Christopher Barker wrote:
> mutating operations vs copying operations
>
> functions vs methods.
>
> This has a lot of impact on the design, and it's very important that
> any final syntax makes these distinctions clear.
Absolutely.
> On Wed, Feb 20, 2019 at 8:33 AM Dan Somme
On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote:
> On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote:
>
> > Here's a syntax that solves this using the new operators _:= and ,_
>
> Be careful about making such dogmatic statements.
Ah, I have just spotted your later expla
On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote:
> Here's a syntax that solves this using the new operators _:= and ,_
Be careful about making such dogmatic statements.
Language design is not a matter of picking random syntax and claiming
that it solves the problem -- especially whe
TL;DR:
When talking about all this, there are two distictions that should be
considered:
mutating operations vs copying operations
functions vs methods.
This has a lot of impact on the design, and it's very important that any
final syntax makes these distinctions clear.
On Wed, Feb 20, 2019 at
On Wed, Feb 20, 2019 at 11:03 AM Rhodri James wrote:
> On 20/02/2019 18:24, Bruce Leban wrote:
> > a = [1,2,3]
> > (_:=a,_.append(4),_.sort())
>
> I'm not sure what problem you are solving here, but if that's the
> solution I'd rather have the problem. There is absolu
On 20/02/2019 18:24, Bruce Leban wrote:
Here's a syntax that solves this using the new operators _:= and ,_
a = [1,2,3]
(_:=a,_.append(4),_.sort())
I'm not sure what problem you are solving here, but if that's the
solution I'd rather have the problem. There is ab
I think this
>>> a = [1,2,3]
>>> _ = a
>>> ( _ .append(4), _ .sort())
(None, None)
is clearer than
a = [1,2,3]
(_:=a,_.append(4),_.sort())
And it works in every version of Python3 (and Python2 I expect).
--
Jonathan
_
On Wed, Feb 20, 2019 at 10:34 AM Jonathan Fine wrote:
> There's a problem with introducing ,_ as a new operator.
>
I should have put "new" in scare quotes to be more clear as it's not really
new. As you've observed this is already implemented. For it to work as in
my example you also need to use
There's a problem with introducing ,_ as a new operator.
$ python3.6
Python 3.6.2 (default, Jul 29 2017, 00:00:00)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 2 + 2
4
>>> 4 ,_ + 6
(4, 10)
Hint:
>>> _
(4, 10)
>>> 3 ,_
(3, (4, 10))
--
Jonathan
_
Here's a syntax that solves this using the new operators _:= and ,_
a = [1,2,3]
(_:=a,_.append(4),_.sort())
Personally, I find this a bit harder to read on one line and would break it
up like this:
(_:=a
,_ .append(4)
,_ ..sort()
)
--- Bruce
_
On 2/20/19 9:10 AM, Steven D'Aprano wrote:
> That's possibly a matter of familiarity. I'd be very surprised if you
> preferred this:
>
> mystr = mystr.strip()
> mystr = mystr.expandtabs()
> mystr = mystr.lower()
> mystr = mystr.replace('ham', 'spam')
> result = function(m
On Tue, Feb 19, 2019 at 01:52:34PM -0800, Brett Cannon wrote:
> On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote:
[...]
> > I would be happy to have
> >
> > >>> [1,2,3].append(4)::sort()::max() +1
> >
> > It makes things very easy to read: first create list, then append 4,
> > then sort, then
On 2/20/19 1:58 AM, Jimmy Girardet wrote:
You're right on it. The str class is a straightforward swiss army knife
with methods you can chain. list or dict do not fit this idea.
Python strings are immutable. Python lists and dicts are
not. Both classes are straightforward.
__
Hi,
thank for the replies.
I searched on python-idea as Chris proposed me with "chain" and I've
found 2 relevant discussions :
* A proposal from Cris Angelico ;-)
https://mail.python.org/pipermail/python-ideas/2014-February/026079.html
"""Right. That's the main point behind this: it gives the
Brett Cannon writes:
> On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote:
> > I would be happy to have
> >
> > >>> [1,2,3].append(4)::sort()::max() +1
> >
> > It makes things very easy to read: first create list, then append 4,
> > then sort, then get the max.
(Responding to the OP)
I
Heyy, it's funcoperators idea !
>>> [1,2,3].append(4)::sort()::max() +1
[1, 2, 3] |append(4) |to(sorted) |to(max) |to(plus1)
You just have to :
pip install funcoperators
from funcoperators import postfix as to
plus1 = postfix(lambda x: x+1)
from funcoperators import postfix
def append(x):
On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote:
> Hi,
>
> There was the discussion about vector, etc...
>
> I think I have a frustration about chaining things easily in python in
> the stdlib where many libs like orm do it great.
>
> Here an example :
>
> The code is useless, just to show
On Wed, Feb 20, 2019 at 1:22 AM Jimmy Girardet wrote:
> >>> a = [1,2,3]
> >>> a.append(4)
> >>> a.sort()
> >>> c = max(a) + 1
>
> I would be happy to have
> >>> [1,2,3].append(4)::sort()::max() +1
>
> It makes things very easy to read: first create list, then append 4,
> then sort, then get the ma
I would suggest a small improvement: allow a trailing :: which is useful for
when the last function does not return anything. So for example this
[1,2,3].append(4)::sort()
will evaluate to None, but
[1,2,3].append(4)::sort()::
would evaluate to the list.
> On 19 Feb 2019, at 15:13, Jimmy Gi
Hi,
There was the discussion about vector, etc...
I think I have a frustration about chaining things easily in python in
the stdlib where many libs like orm do it great.
Here an example :
The code is useless, just to show the idea
>>> a = [1,2,3]
>>> a.append(4)
>>> a.sort()
>>> c = max(a)
26 matches
Mail list logo
