On Thu, Aug 27, 2020 at 07:10:38PM +0200, Alex Hall wrote:
> 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
David Mertz writes:
> 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 don't think it can be a SyntaxError because you can't always know
that mylist i
Alex Hall writes:
> Do you not usually refactor duplicated code?
Taking "you" as generic: it depends.
> What *do* you refactor?
Code is expressive. In cases where the duplication results in
equivalent objects, I habitually refactor. When the process is
important to express and the duplicati
M.-A. Lemburg writes:
> On 27.08.2020 17:53, David Mertz wrote:
> > Suppose we didn't have dict.get(). I would then probably write:
> >
> > val = mydict[key] if key in mydict else None
> >
> > Likewise, since we don't have list.get(), I would write:
> >
> > val = mylist[N] if l
On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull
wrote:
>
> Paul Moore writes:
>
> > Furthermore, I'd be very, very strongly opposed to having x[i,
> > default=d] be a way of supplying a default result if i isn't present
> > in *any* subscriptable class, and particularly in dict as an
> > equ
This is a continuation of my previous post. I wrote:
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] = 'hello
On 28.08.2020 10:30, Stephen J. Turnbull wrote:
> M.-A. Lemburg writes:
> > On 27.08.2020 17:53, David Mertz wrote:
>
> > > Suppose we didn't have dict.get(). I would then probably write:
> > >
> > > val = mydict[key] if key in mydict else None
> > >
> > > Likewise, since we don't hav
On Fri, Aug 28, 2020 at 05:30:26PM +0900, Stephen J. Turnbull wrote:
> David Mertz writes:
>
> > 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).
>
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > tuple, or dict themselves. So `mylist[99, default=4]` would still
> > be a syntax error (or maybe a different exception).
>
> I don't think it can be a SyntaxError because you can't always know
On Thu, Aug 27, 2020, 19:30 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 default
On Fri, Aug 28, 2020 at 4:30 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> > > Suppose we didn't have dict.get(). I would then probably write:
> > > val = mydict[key] if key in mydict else None
> > >
> > > Likewise, since we don't have list.get(), I would write:
On 8/28/20 8:24 AM, David Mertz wrote:
>
> As a side note, I don't really get why everyone else thinks a
> try/except is the most natural approach while a ternary seems more
> obvious to me for this situation. But it kinda connects to me liking
> list.get() better, I think... since "not enough ite
On 8/28/20 6:56 AM, Steve Barnes wrote:
>
> 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
On Fri, 28 Aug 2020 at 13:26, David Mertz wrote:
> As a side note, I don't really get why everyone else thinks a try/except is
> the most natural approach while a ternary seems more obvious to me for this
> situation. But it kinda connects to me liking list.get() better, I think...
> since "n
On 2020-08-28 at 08:41:04 -0400,
Regarding "[Python-ideas] Re: What about having a .get(index, default) method
for arrays like we have for dicts?,"
Richard Damon wrote:
> On 8/28/20 8:24 AM, David Mertz wrote:
> >
> > As a side note, I don't really get why everyone else thinks a
> > try/except i
On 29/08/20 12:06 am, David Mertz wrote:
I only thought of it because `mydict[foo=bar]` now raises a
SyntaxError, so raising something different would technically be a
change in behavior.
It's going to be a change in behaviour whatever you raise,
because it's currently a compile time error.
-
On Fri, Aug 28, 2020 at 5:45 AM Shahriar Heidrich <
smheidr...@weltenfunktion.de> wrote:
> On 8/28/20 6:56 AM, Steve Barnes wrote:
>
> This is just about the first part of your mail: There are external
> libraries for reading and writing various formats while preserving comments
> (and even more,
On Fri, Aug 28, 2020 at 5:10 AM Todd wrote:
>
> But I don't see why this is a problem we have to deal with. The index
> argument can just not be passed at all, and it is up to the class developer
> to pick an appropriate sentinel if needed.
>
>>
>
That is a good point -- any existing ocde (Or ne
Thanks for the comments! Some food for thought. One comment:
Paul Moore writes:
> On Fri, 28 Aug 2020 at 09:30, Stephen J. Turnbull
> wrote:
> > True, but not really fair under my assumption that `x[i, default=d]`
> > becomes the accepted way of doing it generally. dict.get would be a
>
Em qui, 27 de ago de 2020 10:37, M.-A. Lemburg escreveu:
> 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 hardl
Oops, look like I took this off-list by accident -- bringing it back on.
On Fri, Aug 28, 2020 at 12:50 PM Guido van Rossum wrote:
> IMO the bar for attempting to solve this is pretty high, since I can think
> of no way to solve it without breaking old code that doesn't involve
> introducing new
On Thu, Aug 27, 2020 at 09:57:26AM -0400, Ricky Teachey wrote:
> Sorry, I need to stop coding in shorthand.
That might help.
What might help even more is if you spend less time showing imaginary,
and invariably buggy, examples and more time explaining in words the
intended semantics of this, a
On Fri, Aug 28, 2020 at 09:34:43AM -0700, Christopher Barker wrote:
> And on the Python side, there is no standard way to represent arbitrary
> text files as Python objects.
Um, sure there is: unstructured text, which is exactly what Python does.
And contrary to Steve Barnes' comments, Python d
On Fri, Aug 28, 2020 at 10:10 PM Steven D'Aprano
wrote:
> On Thu, Aug 27, 2020 at 09:57:26AM -0400, Ricky Teachey wrote:
>
> > Sorry, I need to stop coding in shorthand.
>
> That might help.
>
> What might help even more is if you spend less time showing imaginary,
> and invariably buggy, example
On 29/08/20 2:07 pm, Steven D'Aprano wrote:
Better would be to add a new future directive to change the parsing of
subscripts, and allow people to opt-in when they are ready on a
per-module basis.
from __future__ import subscript_arguments
I don't think that would help, at least not on it
On 29/08/20 4:50 pm, Ricky Teachey wrote:
(however [Greg Ewing was] talking about
3 dunders-- still hoping he and others might come around to the idea of
just one)
Whereas I'm hoping that you might come around to the idea of
three, :-)
Your version is simpler in the sense that it uses fewer n
Another idea:
Instead of new dunders, have a class attribute that flags the
existing ones as taking positional and keyword arguments.
class ILikeMyIndexesPositional:
__newstyleindexing__ = True
def __getitem__(self, i, j, spam = 42):
...
Advantages:
No new dun
27 matches
Mail list logo
