On Tue, Oct 19, 2021 at 11:30 AM Jeremiah Paige wrote:
>
> This could probably be toggled via a __future__ import which would make its
> usage more apparent to readers of the file. But this would imply that the
> keyword would eventually be turned on by default; I don't think there are any
> examp
On Sat, Oct 16, 2021 at 6:22 AM Erik Demaine wrote:
>
> It's not especially short, and it's not backward-compatible,
> but at least there's a history of adding double-underscore things.
> Perhaps, for backward compatibility, the feature could be disabled in any
> scope (or file?) where __lhs__ is
On Sat, Oct 16, 2021 at 8:46 AM Steven D'Aprano wrote:
> On Sat, Oct 16, 2021 at 09:19:26AM -0400, Erik Demaine wrote:
>
> > To me (a mathematician), the existence of this magic in def, class,
> import,
> > etc. is a sign that this is indeed useful functionality. As a fan of
> > first-class lang
On Tue, Oct 19, 2021 at 9:00 AM Cameron Simpson wrote:
> The problem with a "download()" method is that it is almost never what
> you need. There are too many ways to want to do it, and one almost
> _never_ wants to suck the download itself into memory as you do above
> with read() because downloa
On 18Oct2021 21:25, Tom P wrote:
>In the context of building Docker images, it is often required to download
>stuff. If curl/wget is available, great, but often slim images don't
>include that. The urllib could provide a very simple download functionality
>(like http offers a simple server):
>
>fr
In the context of building Docker images, it is often required to download
stuff. If curl/wget is available, great, but often slim images don't
include that. The urllib could provide a very simple download functionality
(like http offers a simple server):
from urllib.request import urlopen
dat
On Mon, Oct 18, 2021 at 6:15 PM Matt del Valle wrote:
> I think what's being discussed in this thread is variations on the fluent
> interface design pattern (https://en.wikipedia.org/wiki/Fluent_interface).
>
> with Schedule(...) as schedule:
>
> schedule.every(3).months.and_(7).days.and_(12
On Mon, Oct 18, 2021 at 2:13 PM Matt del Valle wrote:
>
> Ricky's curry helper decorator is cool, but for me the drawback that makes
> it a dealbreaker is that it is too dynamic for IDE's to understand. I write
> a lot of library code and find myself routinely foregoing metaprogramming
> and run
I think what's being discussed in this thread is variations on the fluent
interface design pattern (https://en.wikipedia.org/wiki/Fluent_interface).
Personally, I've found myself reaching for it several times in library code
I've written where it makes sense. For example, I've written a set of gma
On 10/18/21 3:20 AM, Mathew Elman wrote:
> I don't know if this has been suggested before, or if this is outlandishly
impossible
> (though I would be surprised if it was), so apologies in advance if so.
>
> I have on occasion come across a situation where I use/write a signature like
this:
>
>
On 10/18/21 6:29 AM, Mathew Elman wrote:
>> What you are describing is very, very dissimilar to currying. It's simply
multi-argument
> functions with a different call syntax.
>
> It is almost identical to currying, the only differences are:
> 1. the intermediate return being an object with an at
On 10/18/21 6:23 AM, Mathew Elman wrote:
> When learning python, and even sometimes now, I have had to look at the implementation of a function in order to
recall which order arguments should go.
Seems like the docs should cover that (or even `help()`) -- and if not, then
the parameter names
> Reminds me of some testing/assertion frameworks. I'm not a fan, but
> some people like it.
>
> expect(thing).to.be.numeric()
That rings a bell with test a javascript test framework, something like enzyme?
___
Python-ideas mailing list -- python-ideas@
On Tue, Oct 19, 2021 at 3:34 AM Ricky Teachey wrote:
> insert(x).into.seq(s).at(i)
> insert(k, v).into.mapping(m)
>
> I would never use any of this in a serious application, but it's still fun.
Reminds me of some testing/assertion frameworks. I'm not a fan, but
some people like it.
expect(thing)
> I think that a programming language needs to be different enough from a
> natural language to remind you that it's a programming language and that
> the computer isn't that smart. The computer will do as you say, not as
> you mean.
I agree entirely, that's why I am not suggesting putting spac
Yeah if you change the API to be a bit more powerful, you could build all
kinds of ideas on top of the basic kernel of idea...
Here's some others I was shooting around with a python-eque buddy of mine
this morning:
@curry_helper
def is_(x):
... # elsewhere
@is_.add_predicate
def a_number(x)
This is interesting, it's not as nice as native syntax support could have been
but a decorator like this is also pretty nice.
I think I would bikeshed this so the decorator was the full dot separated
signature, e.g.
@curry_helper('insert.into')
def insert(x: Any, y: list):
def y.append(x)
Not really, I'm not trying to suggest a fully English like language be incepted
into python, my main point here was that there are cases where the order of
arguments is important and being able to have actually positional arguments
would go a long way to improving knowing intuitively that order.
On 2021-10-18 15:58, Steven D'Aprano wrote:
On Mon, Oct 18, 2021 at 10:20:17AM -, Mathew Elman wrote:
despite a driving idea of python syntax being readability in
english, the function signature is distinctly not english.
Python's syntax was not really modelled on English, as far as I can
On 2021-10-18 11:20, Mathew Elman wrote:
I don't know if this has been suggested before, or if this is outlandishly
impossible (though I would be surprised if it was), so apologies in advance if
so.
I have on occasion come across a situation where I use/write a signature like
this:
def
+1 from me too.
I just had the case yesterday of having to chain a bunch of lists and I
naturally wrote it as [*lst for lst in lst_of_lsts] only to see my IDE complain
:) I've known about itertools.chain() for a while, too. Yet, every time I have
to chain iterables like this, for some reason, ma
On Mon, Oct 18, 2021 at 10:20:17AM -, Mathew Elman wrote:
> despite a driving idea of python syntax being readability in
> english, the function signature is distinctly not english.
Python's syntax was not really modelled on English, as far as I can
tell. It was (I think) modelled more on P
I kind of like this idea. I wrote this curry helper module as a proof of
concept of how to implement it in Python, today, without having to add
features:
https://gist.github.com/Ricyteach/b290849da903135a1ed5cce9b161b8c9
Using that, you can write code like this:
from typing import Any
@curry_he
> What you are describing is very, very dissimilar to currying. It's simply
> multi-argument functions with a different call syntax.
It is almost identical to currying, the only differences are:
1. the intermediate return being an object with an attribute (rather than a new
function) that you ca
Paul Moore wrote:
> On Mon, 18 Oct 2021 at 12:49, Mathew Elman mathew.el...@ocado.com wrote:
> > The point is that at the moment to set this sort of api up requires a lot
> > of work, defeating 50% of the value i.e. to define a new function with the
> > attribute access behaviour requires definin
On Mon, 18 Oct 2021 at 12:49, Mathew Elman wrote:
>
> The point is that at the moment to set this sort of api up requires a lot of
> work, defeating 50% of the value i.e. to define a new function with the
> attribute access behaviour requires defining each individual function to
> return a midd
What you are describing is very, very dissimilar to currying. It's simply
multi-argument functions with a different call syntax.
Moreover, this hypothetical syntax would make no sense at all for 99% of
the functions I write or call. There are a very small number of functions
where a conceivable be
> Still, I don't want Python to try to be Cobol.
I agree, I don't want Python to try and be Cobol, but that doesn't mean there
aren't things to learn from Cobol regarding this, if this indeed something
found there - I can't comment on that.
> I think the intellectual argument for "English synt
What you want was popular in Cobol. That language has generally lost favor
for current development, but lots of it is still around.
Still, I don't want Python to try to be Cobol. I think the intellectual
argument for "English syntax" failed, notwithstanding installed base.
On Mon, Oct 18, 2021, 3
The point is that at the moment to set this sort of api up requires a lot of
work, defeating 50% of the value i.e. to define a new function with the
attribute access behaviour requires defining each individual function to return
a middle step object that has the attribute of the next function, s
That is interesting but is missing the point of what I am really getting at, in
order to build a function of multiple args this way would require a lot of
these "operators" that would need to be interchangeable, so I don't think what
I am looking for is an operator.
The key point being having
On Mon, 18 Oct 2021 at 11:20, Mathew Elman wrote:
>
> I don't know if this has been suggested before, or if this is outlandishly
> impossible (though I would be surprised if it was), so apologies in advance
> if so.
>
> I have on occasion come across a situation where I use/write a signature lik
On Mon, Oct 18, 2021 at 9:22 PM Mathew Elman wrote:
>
> I don't know if this has been suggested before, or if this is outlandishly
> impossible (though I would be surprised if it was), so apologies in advance
> if so.
As stated, it basically is but the cool thing about crazy ideas
is, there
I don't know if this has been suggested before, or if this is outlandishly
impossible (though I would be surprised if it was), so apologies in advance if
so.
I have on occasion come across a situation where I use/write a signature like
this:
def insert_x_into_y(x, y):
...
or worse
34 matches
Mail list logo
