On Sat, Aug 04, 2018 at 12:40:13AM +0200, Benedikt Werner wrote:
> Overall I like the idea of the with-expression as it allows you to make
> some common use cases like the open/read example more readable.
For some definition of "readable".
> It's
> clear at first sight that what is actually d
On Fri, Aug 03, 2018 at 06:57:40PM -0500, Abe Dillon wrote:
> tmp = None
> with suppress(AttributeError):
> tmp = person.name[0]
> initial = tmp
>
> Then it would solve many of the common use cases for the None-aware
> operators proposed in PEP 505
No it would not. The None-aware operators a
On 2018-08-04 09:43, Steven D'Aprano wrote:
If you want to
propose a general exception suppressing mechanism (aside from the
existing try...except statement) then propose it as an independent PEP.
This was already tried in PEP 463 (which IMHO is a pity that it wasn't
accepted because it seems
> I know what functional programming is. What I don't understand is what
> you mean when you say that the F.P. community "seems to be more
> interested in python". Surely they are more interested in functional
> languages than a multi-paradigm language like Python which does not
> privilege functio
>
>
>
>
> A with-statement is great for when you care about the
> implementation details. Somebody has to care about the process of
> opening a file, reading from it and closing it. But when you *don't*
> care about those implementation details, a simple interface like a
> read() function is superi
On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote:
> Boolean operators like the sort I am discussing have been a standard part
> of programming languages since forever. In fact, they are the basic
> operations on which modern microprocessors are built.
>
> The fact that Python, strictly speak
On Sat, 04 Aug 2018 23:13:34 +1000, Steven D'Aprano wrote:
> There are certainly advantages to using binary operators over named
> functions, and a shortage of good, ASCII punctuation suitable for new
> operators.
Hold that thoght.
Then again, why is it 2018 (or 5778?) and we're still stuck with
I think that before adding more ad hoc binary operators, we ought to
consider the possibility of custom operators.
That actually sounds like the most sensible solution so far, altough the
scope of such a change is also much larger. But custom operators really
would be a cool addition to Python.
Hello, I would like to propose a new method to create a partial function.
At the moment we have to load the *partial* function from the *functool*
library, and apply it to an existing function, e.g.
from functools import partial
def add(x: int, y: int) -> int:
return x + y
add_2 = par
On Sat, Aug 04, 2018 at 04:56:56PM +0200, Benedikt Werner wrote:
> >I think that before adding more ad hoc binary operators, we ought to
> >consider the possibility of custom operators.
>
> That actually sounds like the most sensible solution so far
Thanks :-)
Unfortunately there's a flaw, in tha
The funcoperators lib on pypi does exactly that:
from funcoperators import partially
@partially
def add(x: int, y: int) -> int:
return x + y
add_2 = add[2]
@partiallymulti
def stuff(x,y,z):
return x - y + 2*z
sort = partially(sorted)
sort_by_x = sort.key(key=lambda element: element.x)
> @partiallymulti
> def stuff(x,y,z):
> return x - y + 2*z
>
f = stuff[1,2]
f(4)
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On Sun, Aug 5, 2018 at 2:37 AM, Steven D'Aprano wrote:
> All this supposes that there is sufficient benefit to allowing custom
> infix operators, including overridable or/and/xor, which is not yet
> shown.
Part of the justification for that is that the bitwise operators have
different precedence
On Sat, Aug 04, 2018 at 02:04:01PM +, Dan Sommers wrote:
> On Sat, 04 Aug 2018 23:13:34 +1000, Steven D'Aprano wrote:
>
> > There are certainly advantages to using binary operators over named
> > functions, and a shortage of good, ASCII punctuation suitable for new
> > operators.
>
> Hold tha
Here's my opinion, in a nutshell.
A diet with a small amount of sugar is healthy. But too much sugar is not.
https://www.nhs.uk/live-well/eat-well/how-does-sugar-in-our-diet-affect-our-health/
I have a similar attitude to syntactic sugar. Sometimes helpful.
https://news.ycombinator.com/item?id=16
On Sat, Aug 04, 2018 at 09:03:50AM -0700, Fabrizio Messina wrote:
> At the moment we have to load the *partial* function from the *functool*
> library, and apply it to an existing function
[...]
> While partial expose the mechanism excellently its instantiation method is,
> at times, not very f
On Sat, Aug 4, 2018, 1:24 PM Steven D'Aprano wrote:
> If you think the uproar over PEP 572 was vicious, imagine what would
> happen if we introduced new operators like ∉ ∥ ∢ ∽ ⊎ etc instead.
>
> - keyboard support for entering the bulk of Unicode characters is
> non-existent or poor;
>
> - with
I use these Vim abbreviations,
which are derived from LaTeX
https://gist.github.com/stephanh42/fc466e62bfb022a890ff2c4643eaf3a5
Stephan
Op za 4 aug. 2018 20:03 schreef David Mertz :
> On Sat, Aug 4, 2018, 1:24 PM Steven D'Aprano wrote:
>
>> If you think the uproar over PEP 572 was vicious, ima
That's very nice Stephan. I think I'll add those to my machines.
But not everyone uses vim. And although I use vim a lot, I also use other
text editors, by choice or compulsion (e.g. editing code in web interface).
And even when I have vim, I don't necessarily have the ability to install
and test
On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano wrote:
> On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote:
>
> > Boolean operators like the sort I am discussing have been a standard part
> > of programming languages since forever. In fact, they are the basic
> > operations on which modern mi
On Sun, Aug 5, 2018 at 4:40 AM, Todd wrote:
>
>
> On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano wrote:
>>
>> On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote:
>>
>> > Boolean operators like the sort I am discussing have been a standard
>> > part
>> > of programming languages since forever.
That's an awesome library! Congratulation for doing this and thanks for
sharing!
Em sáb, 4 de ago de 2018 às 13:42, Robert Vanden Eynde
escreveu:
> The funcoperators lib on pypi does exactly that:
>
> from funcoperators import partially
>
> @partially
> def add(x: int, y: int) -> int:
> retu
You can read the other functionalities on the project page :
https://pypi.org/project/funcoperators/
And if you want to solve the "can't partial from right that allows to use
the Ellipsis '...' :
# the built-in "pow" doesn't take keyword arguments, so partial can't be
used.
from funcoperators im
On Sat, Aug 4, 2018 at 2:48 PM, Chris Angelico wrote:
> On Sun, Aug 5, 2018 at 4:40 AM, Todd wrote:
> >
> >
> > On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano
> wrote:
> >>
> >> On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote:
> >>
> >> > Boolean operators like the sort I am discussing ha
On Sat, Aug 04, 2018 at 02:40:54PM -0400, Todd wrote:
> On Sat, Aug 4, 2018 at 9:13 AM, Steven D'Aprano wrote:
>
> > On Fri, Aug 03, 2018 at 03:17:42PM -0400, Todd wrote:
> >
> > > Boolean operators like the sort I am discussing have been a standard part
> > > of programming languages since forev
On Sat, Aug 04, 2018 at 09:16:35PM -0400, Todd wrote:
[Chris said:]
> > You say that Python doesn't have them. What aspect of boolean
> > operators doesn't Python have?
> >
>
> Python's "and" and "or" don't return "True" or "False" per se, they return
> one of the inputs based on their respective
You should have a look at old PEP225 "Elementwise operators", that proposed ~
as a modifier for many existing operator, to indicate they do mostly what their
"normal counterpart do, but act on the inner/ elements of an object instead of
on the whole.
This was only a memorisation technique, as al
Obviously I'm +1 on this, but a little bit less so than at the time of
proposal, let's say +0.8...at PEP 225 time, @ matmul operator did not exist (it
was the competing PEP 211, also to address matrix multiply, that proposed
@...both were rejected at the time lol).
But now that @ exists, there w
28 matches
Mail list logo
