It occurs to me that there are many situations where files are human authored
and can include comments but by default when python reads/modifies/writes those
files by default the comments are lost.
Some examples include configfile, json and even python itself with the special
case that docstrin
On Thu, Aug 27, 2020 at 9:24 PM Joseph Martinot-Lagarde <
contreba...@gmail.com> wrote:
> That's only one of the possible uses, and I'm not even sure that it would
> be implemented directly. Adding keywords to indexation for custom classes
> is not the same as modifying the standard dict type for
That's only one of the possible uses, and I'm not even sure that it would be
implemented directly. Adding keywords to indexation for custom classes is not
the same as modifying the standard dict type for typing.
Anyway, my point was that it's still possible to do it later without breaking
anythi
On Thu, Aug 27, 2020, 7:31 PM Joseph Martinot-Lagarde
wrote:
> As for foo[a=1, b=2], I'd propose to keep it a SyntaxError for now, and
> always require an index. This way it can be changed later when people are
> more used to the keyword args and have more ideas of what would be good as
> a defau
Hi, other author here ! I'm still following the lists but not writing any more.
:)
Stefano if you want to change pep 472 there is no problem on my side (but I've
read that some people preferred a new one), I remember that you did all the
work anyway ! Since lots will change just remove my name,
On Thu, Aug 27, 2020 at 2:27 PM Ricky Teachey wrote:
>
> On Thu, Aug 27, 2020 at 2:14 PM Christopher Barker
> wrote:
>
>> On Thu, Aug 27, 2020 at 11:01 AM Ricky Teachey wrote:
>>
>>> What about something like this:
> class Name(NamedTuple):
> first: str
> last: str
On Thu, Aug 27, 2020 at 2:14 PM Christopher Barker
wrote:
> On Thu, Aug 27, 2020 at 11:01 AM Ricky Teachey wrote:
>
>> What about something like this:
>>>
>>>
class Name(NamedTuple):
first: str
last: str
d = NamedKeyDict(Named)
d[first='david', last='mertz']
On Thu, Aug 27, 2020 at 11:01 AM Ricky Teachey wrote:
> What about something like this:
>>
>>
>>> class Name(NamedTuple):
>>> first: str
>>> last: str
>>>
>>> d = NamedKeyDict(Named)
>>> d[first='david', last='mertz'] = 1_000_000 # dollars
>>>
>>
right -- that would be a new custom class
On Thu, Aug 27, 2020 at 10:24 AM David Mertz wrote:
> On Thu, Aug 27, 2020, 1:15 PM Christopher Barker
>
>> I agree -- this is very much a feature for third party packages -- or
>> *maybe* some future stdlib class, but the builtins are fine as they are.
>>
>> In fact, I don't think there's a sing
On Thu, Aug 27, 2020 at 1:45 PM David Mertz wrote:
> On Thu, Aug 27, 2020, 1:35 PM Ricky Teachey
>
>> Conceptually, an "immutable collection" serves a different purpose than
>>> "a collection of axes", even if they work then same under the hood.
>>>
>>
>> What about something like this:
>>
>> cla
(bringing this back on list)
On Thu, Aug 27, 2020 at 10:29 AM Chris Angelico wrote:
> On Fri, Aug 28, 2020 at 1:22 AM Christopher Barker
> wrote:
> > But no one is stopping anyone from writing anything they want. iI may
> not be a “PEP”, but it’s a good idea to write a document that makes it
>
On Thu, Aug 27, 2020, 1:35 PM Ricky Teachey
> Conceptually, an "immutable collection" serves a different purpose than "a
>> collection of axes", even if they work then same under the hood.
>>
>
> What about something like this:
>
> class Name(NamedTuple):
> first: str
> last: str
>
> d = N
On Thu, Aug 27, 2020 at 1:29 PM David Mertz wrote:
> On Thu, Aug 27, 2020, 1:15 PM Christopher Barker
>
>> I agree -- this is very much a feature for third party packages -- or
>> *maybe* some future stdlib class, but the builtins are fine as they are.
>>
>> In fact, I don't think there's a singl
On Thu, Aug 27, 2020, 1:15 PM Christopher Barker
> I agree -- this is very much a feature for third party packages -- or
> *maybe* some future stdlib class, but the builtins are fine as they are.
>
> In fact, I don't think there's a single use of a tuple of indexes (meaning
> something other than
On Thu, Aug 27, 2020 at 8:24 AM David Mertz wrote:
> I support named indices. But I strongly oppose using them in list,
tuple, or dict themselves. So `mylist[99, default=4]` would still be a
syntax error (or maybe a different exception).
I agree -- this is very much a feature for third party pa
On Thu, Aug 27, 2020 at 6:32 PM Steven D'Aprano wrote:
> Personally, I found your examples underwhelming because they're mostly
> repetitions of the same pattern.
>
That's surprising to me. When I see the same pattern over and over that's
when I most want to refactor into a common function/metho
On Thu, Aug 27, 2020 at 03:17:24PM +0200, Alex Hall wrote:
> I'm copying my earlier post because apparently linking to it repeatedly has
> no effect and people keep on claiming that this method wouldn't be useful
> while not saying a word about the evidence I presented that it would be.
Perhaps i
On 27.08.2020 17:53, David Mertz wrote:
> On Thu, Aug 27, 2020 at 11:37 AM M.-A. Lemburg wrote:
>
>> Asking a dict d of potentially any number of items for
>> existence of a particular item x is somewhat different than asking
>> a list l of a certain length i for the item at position i+1.
>>
>
>
On Thu, Aug 27, 2020 at 11:49:22PM +0900, Stephen J. Turnbull wrote:
> Alex Hall writes:
>
> > OK, I'll try again. Do people want collections to get a standard 'default'
> > for `__getitem__`?
>
> I don't know.
I'm pretty sure that Guido said that he doesn't want the builtin dict
and list typ
On Thu, Aug 27, 2020 at 11:37 AM M.-A. Lemburg wrote:
> Asking a dict d of potentially any number of items for
> existence of a particular item x is somewhat different than asking
> a list l of a certain length i for the item at position i+1.
>
Suppose we didn't have dict.get(). I would then pr
On Thu, 27 Aug 2020 at 16:21, David Mertz wrote:
>
> On Thu, Aug 27, 2020 at 10:51 AM Stephen J. Turnbull
> wrote:
>>
>> They're going to get one, is my reading of the "named indicies"
>> thread. That is, it looks to me very likely that index notation
>> (`x[i]`) is going to support keyword arg
On 27.08.2020 16:01, Alex Hall wrote:
> On Thu, Aug 27, 2020 at 3:37 PM M.-A. Lemburg wrote:
>
>> If I'm not mistaken, all those listed cases fall under the second case
>> I mentioned (branching on length).
>>
>> If your API allows for optional list entries, then it's better to
>> branch on lengt
On Thu, Aug 27, 2020 at 10:51 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> They're going to get one, is my reading of the "named indicies"
> thread. That is, it looks to me very likely that index notation
> (`x[i]`) is going to support keyword arguments (`x[i, k=v]`). I
Alex Hall writes:
> OK, I'll try again. Do people want collections to get a standard 'default'
> for `__getitem__`?
I don't know.
> I don't want mappings to grow a second way to do the same thing,
They're going to get one, is my reading of the "named indicies"
thread. That is, it looks to
Here are two examples, which I hope help us understand our options.
Here's an example of how the new dunder might work in practice.
class A:
__keyfn__ = None
def __setitem__(self, val, x=0, y=0, z=0):
print((val, x, y, z))
>>> a = A()
>>> a[1, z=2] = 'hell
On Thu, Aug 27, 2020 at 3:37 PM M.-A. Lemburg wrote:
> If I'm not mistaken, all those listed cases fall under the second case
> I mentioned (branching on length).
>
> If your API allows for optional list entries, then it's better to
> branch on length (e.g. as in the pytest case). If this happens
> And if I write set item code, it is like this:
>
> >>> q[1, 2, 3, x=4, y=5, z=6, foo='bar'] = "baz"
>
> cpython level call looks like:
>
> cpython_subscript_operator_function(q, 1,
> __item_dunder_name="__getitem__", __value="baz", x=4, y=5, z=6, foo='bar',
> b=2, c=3)
>
Sorry: forgot to change
On Thu, Aug 27, 2020, 8:34 AM Steven D'Aprano wrote:
>
> > 3. Removes the need to write calls to the same supporting function in the
>
> item dunders. They are called automatically.
>
> I don't understand that sentence.
>
>
> [...]
> > My current attempt is this:
> >
> > def __subscript__(self, *
On 27.08.2020 15:17, Alex Hall wrote:
> On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg wrote:
>
>> I disagree on the above assessment. I have had such a get() builtin
>> in mxTools for more than 20 years now and found that I hardly ever
>> used it:
>>
>> https://www.egenix.com/products/python/mxBa
where will I find these experiments and results? can you show me where to look
for? thanks in advance :D
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailma
Em qui, 27 de ago de 2020 10:09, M.-A. Lemburg escreveu:
> On 27.08.2020 14:40, Daniel. wrote:
> > It's simple:
> >
> > def get(self, i, default=None):
> > try:
> > return self[i]
> > except IndexError:
> > return default
> >
> > That was the idea, just a safe wrapper arro
thanks Eric :D I will surely look into this...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
http
On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg wrote:
> I disagree on the above assessment. I have had such a get() builtin
> in mxTools for more than 20 years now and found that I hardly ever
> used it:
>
> https://www.egenix.com/products/python/mxBase/mxTools/doc/#_Toc293606201
>
> The reason is
On Thu, Aug 27, 2020 at 11:13 PM M.-A. Lemburg wrote:
> For those cases, where a list can have a variable
> number of entries (e.g. optional arguments, file lists, etc.),
> code should clearly branch on list length and then determine the
> right strategy to fetch items.
Pattern matching seems pro
On 27.08.2020 14:40, Daniel. wrote:
> It's simple:
>
> def get(self, i, default=None):
> try:
> return self[i]
> except IndexError:
> return default
>
> That was the idea, just a safe wrapper arround IndexError. Because it's very
> common to need to catch this. I posted tw
An .get method wont hurt duck typing, it makes it better. Also most of the
time we're working with plain dicts and lists not abtract classes.
If you're typechecking for a Sequence you cant treat it as a list, and this
is already true because there are methods in list that dont exists Sequence
as A
On Thu, Aug 27, 2020 at 07:24:01AM -0400, Ricky Teachey wrote:
> It kills at least 3 birds with one stone:
>
> 1. Brings kwd arguments to item dunders (PEP 472 does this too, but a
> key/index translation dunder kills two other birds)
I would put it another way: your proposal to redesign subscri
> I'm not seeing what problem adding a new dunder and indirection of
>> __*item__ solves...
>>
> It kills at least 3 birds with one stone:
>
Actually there's a fourth bird.
4. Once you've decided on the signature of your key/index translation
dunder, you can ignore the signature in the rest of t
On Thu, Aug 27, 2020, 1:29 AM Alexandre Brault wrote:
> On 2020-08-27 12:33 a.m., Ricky Teachey wrote:
>
> On Wed, Aug 26, 2020 at 10:34 PM Steven D'Aprano
> wrote:
>
>> On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote:
>> > It creates a language supported way for the creator of the
On 27/08/20 3:56 pm, Steven D'Aprano wrote:
On Thu, Aug 27, 2020 at 03:28:07AM +1200, Greg Ewing wrote:
>
We're falling back to __getitem__ here, which doesn't currently allow
keywords,
Point of order: **the getitem dunder** already allows keywords, and
always has, and always will. It's just
On Thu, Aug 27, 2020 at 10:15 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Alex Hall writes:
> > On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull <
> > turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> >
> > > If the "keyword arguments in __getitem__" feature is added,
On Thu, Aug 27, 2020 at 08:25:45AM +0100, Stefano Borini wrote:
> I already sent a mail to D'Aprano and he said (please Steven correct
> me if I am wrong) that basically PEP-472 as is is not acceptable (and
> I agree) without modifications.
What I said was that *I* "cannot support any of the stra
Alex Hall writes:
> On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
> > If the "keyword arguments in __getitem__" feature is added, .get() is
> > purely redundant. (Of course this thread would then become "make
> > 'default' a standard k
Ok then it is my understanding that Steven D'Aprano is willing to
sponsor it. Steven please correct me if I am dead wrong, and apologies
if that's not the case.
On Thu, 27 Aug 2020 at 08:39, Chris Angelico wrote:
>
> On Thu, Aug 27, 2020 at 5:26 PM Stefano Borini
> wrote:
> > So the question is
On Thu, 27 Aug 2020 at 03:00, Steven D'Aprano wrote:
> > To me, most of the discussion is being derailed in deciding how this
> > should look like on the __getitem__ end and how to implement it, but
> > we haven't even decided what it should look like from the outside
>
> Is that even a question?
On Thu, Aug 27, 2020 at 5:26 PM Stefano Borini wrote:
> So the question is: is a core developer willing to sponsor the _idea_
> (not the PEP, as it doesn't exist yet)?
It comes to the same thing (it's really just a matter of terminology).
Before the PEP can be created, it needs a sponsor, which m
We surely can't deprecate them, but the naming of axes is done at the
dunder level, not at the client level. and if the idea were to add a
new dunder, then of course you can always name them post-facto, and
pass through to your older __getitem__ function. if you so wish.
I need to take a look at x
I already sent a mail to D'Aprano and he said (please Steven correct
me if I am wrong) that basically PEP-472 as is is not acceptable (and
I agree) without modifications.
But in my opinion the argument is circular. Who is willing to sponsor
a PEP that doesn't exist yet? it's like putting a signatur
48 matches
Mail list logo
