On Tue, Oct 18, 2022, 19:39 Paul Bryan wrote:
> For my edification, how is copy in pathlib proposed to be implemented?
> Just call out to the OS to do the copy? Do the copy by reading and writing?
>
Just a thin wrapper around shutil.copy2 and shutil.copytree. Most
non-parsing pathlib operations
On Tue, Oct 18, 2022 at 6:26 PM Chris Angelico wrote:
> On Wed, 19 Oct 2022 at 09:17, Todd wrote:
> >
> > On Tue, Oct 18, 2022 at 5:00 PM Chris Angelico wrote:
> >>
> >> On Wed, 19 Oct 2022 at 06:50, Todd wrote:
> >> >
> >> > Curr
On Tue, Oct 18, 2022 at 5:00 PM Chris Angelico wrote:
> On Wed, 19 Oct 2022 at 06:50, Todd wrote:
> >
> > Currently, pathlib supports pretty much all common filesystem
> operations. You can create, move, and delete both files and directories.
> One big omission is copying
Currently, pathlib supports pretty much all common filesystem operations.
You can create, move, and delete both files and directories. One big
omission is copying. You need shutil for that.
Whatever the original intent might have been behind pathlib, it is now
effectively the standard tool for fil
On Sun, Jun 12, 2022, 16:22 Bluenix wrote:
> I stumbled upon PEP 671 again today, and for what it's worth I fully agree
> with everything said here.
>
> For the same reasons as you listed, I am generally opposed to PEP 671.
> Wrapping functions in one way or another is extremely common and this P
Is there a reason we can't use "Object" and make "Any" just an alias for
"Object"?
On Fri, Oct 1, 2021, 10:47 Christopher Barker wrote:
>
>
> The fact that the built in “any” is not a type is not an implementation
> detail. any() and typing.Any are completely different things/concepts. They
> ju
On Wed, Sep 1, 2021, 03:18 Steven D'Aprano wrote:
> On Tue, Aug 31, 2021 at 06:18:15PM -0400, Todd wrote:
>
> > You insist that both approaches should be treated as equally valid. But
> > they simply aren't. In the real world, where people are trying to do
>
On Tue, Aug 31, 2021, 17:24 Nick Parlante wrote:
> Hi Chris - well maybe we're looking at different questions. Your examples
> show it is possible to construct a data type where == None does not work.
> Clearly that is possible.
>
> 1. One conclusion is that the possibility of such == means that
On Tue, Aug 31, 2021 at 2:18 PM Nick Parlante wrote:
> Hi Steven, I wish I could blame this on zealots, so let me talk a little
> bit about how PEP8 works in education, and I'll talk about moving forward
> in another message.
>
> As mentioned, PEP8 is formally for narrow cases, and includes discl
On Mon, Aug 30, 2021, 15:38 Nick Parlante wrote:
> Hi Chris - thanks for the response,
>
> so here you say:
>
> I disagree; experienced programmers should be using "is" where it's
>> correct.
>>
>
> I think PEP8 has forced people to use "is" so much, they've lost touch
> with the reality that in
The pytoolz/cytoolz project already has this:
https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.get_in
On Sun, May 23, 2021, 11:44 Chris Angelico wrote:
> On Mon, May 24, 2021 at 1:24 AM MRAB wrote:
> > Also, if the first lookup returns a list or a tuple, and an argument can
> > b
Numba already provides as-needed JIT compilation and type annotations. I am
not sure it supports multiple dispatch but if that was useful it could be
added with decorators. I am not sure integrating this into the language
will help much.
On Tue, Mar 16, 2021, 10:07 Marvin van Aalst
wrote:
> Hi
On Mon, Mar 15, 2021, 06:15 Roland Puntaier via Python-ideas <
python-ideas@python.org> wrote:
> On Fri 21Mar12 14:27, Paul Bryan wrote:
> >It seems your proposal is intended to address an aesthetic concern. Is
> >there a case where using a leading comma would make something
> >actually easier or
On Thu, Jan 7, 2021, 10:54 Sven R. Kunze wrote:
> I split my answers up to address different issues in different threads.
>
>
> On 31.12.20 15:32, Todd wrote:
>
> Hi Sven,
>
> Thanks for your support and feedback.
>
>
> On Thu, Dec 31, 2020, 07:23 Sven R. Kun
Hi Sven,
Thanks for your support and feedback.
On Thu, Dec 31, 2020, 07:23 Sven R. Kunze wrote:
> Hi Todd,
>
> my comments below. Also would offer my time for reviewing/testing if
> wanted.
>
>
> On 22.11.20 20:53, Todd wrote:
>
> I know enhancements to pathlib g
I would think this is something that should live in the type checker rather
than cpython. They could have an argument to run cpython after doing the
check.
On Sun, Dec 6, 2020, 05:23 wrote:
> It would be nice to have "Typed Python" mode that will look like this:
>
> ```bash
> #!/usr/bin/env bas
Does anyone have any further thoughts on these? Should I split these into
separate threads?
On Sun, Nov 22, 2020 at 10:05 PM Todd wrote:
> On Sun, Nov 22, 2020 at 9:49 PM Matt Wozniski wrote:
>
>> > I suggest adding an "exist_ok" argument to all of these, with
>
On Sun, Nov 22, 2020 at 9:49 PM Matt Wozniski wrote:
> > I suggest adding an "exist_ok" argument to all of these, with
> > the default being "True" for backwards-compatibility. This argument name
> > is already in use elsewhere in pathlib. If this is False and the file is
> > not present, a "Fi
On Sun, Nov 22, 2020 at 5:46 PM Chris Angelico wrote:
> On Mon, Nov 23, 2020 at 6:54 AM Todd wrote:
> >
> > I know enhancements to pathlib gets brought up occasionally, but it
> doesn't look like anyone has been willing to take the initiative and see
> things th
On Sun, Nov 22, 2020 at 3:27 PM Abdulla Al Kathiri <
alkathiri.abdu...@gmail.com> wrote:
> On Nov 22, 2020, at 11:53 PM, Todd wrote:
>
> I know enhancements to pathlib gets brought up occasionally, but it
> doesn't look like anyone has been willing to take the initiative a
I know enhancements to pathlib gets brought up occasionally, but it doesn't
look like anyone has been willing to take the initiative and see things
through to completion. I am willing to keep the ball rolling here and even
implement these myself. I have some suggestions and I would like to
discus
It is working for me now.
On Wed, Sep 23, 2020, 17:33 Ricky Teachey wrote:
> Hmmm, getting a 404 at:
>
> https://www.python.org/dev/peps/pep-0637
>
> Is this just a temporary condition or a bug?
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or
On Fri, Sep 4, 2020, 12:48 Cade Brown wrote:
> I am positing that Python should contain a constant (similar to True,
> False, None), called Infinity.
>
> It would be equivalent to `float('inf')`, i.e. a floating point value
> representing a non-fininte value. It would be the positive constant;
>
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 Thu, Aug 27, 2020, 00:56 Bruce Leban wrote:
> A bunch of the conversation here is how to handle both positional and
> keyword arguments with a single signature. Let me suggest an alternative.
> At compile time, we know if the call is made with keyword arguments or not.
>
> a[1] positio
On Wed, Aug 26, 2020 at 7:11 PM Stefano Borini
wrote:
> On Wed, 26 Aug 2020 at 23:56, Todd wrote:
> > Again, implicit on your argument here is the assumption that all keyword
> indices necessarily map into positional indices. This may be the case with
> the use-case you had in
On Wed, Aug 26, 2020, 18:04 Stefano Borini wrote:
> On Wed, 26 Aug 2020 at 17:50, David Mertz wrote:
> >
> > In my mind, *anything* other than the straightforward and obvious
> signature `__getitem__(self, index, **kws)` is a pointless distraction.
>
> It isn't.
> and the reason why it isn't is
On Tue, Aug 25, 2020 at 10:58 AM David Mertz wrote:
> On Tue, Aug 25, 2020 at 2:26 AM Christopher Barker
> wrote:
>
>> As for "why not" not being a motivator -- I agree, I posted it that easy
>> because this conversation has brought up a number of examples where slice
>> syntax is nice to use. A
On Tue, Aug 25, 2020 at 4:41 PM Stefano Borini
wrote:
> On Sat, 8 Aug 2020 at 02:34, Stephan Hoyer wrote:
>
> > I'm sorry, I did a poor job of editing this.
> >
> > To fill in my missing word: From my perspective, the *only* reasonable
> way to add keyword arguments to indexing would be in a com
message from Steven D'Aprano
> -
>
> Date: Mon, 24 Aug 2020 11:46:02 +1000
> From: Steven D'Aprano
> To: python-ideas@python.org
> Subject: Re: [Python-ideas] PEP 472 - slices in keyword indices, d[x=1:3]
>
> On Sun, Aug 23, 2020 at 09:40:53PM -0400, Todd wrote:
On Mon, Aug 24, 2020 at 12:23 PM Jonathan Fine wrote:
> Christopher wrote: Why not allow slice syntax as an expression everywhere?
>
> In reply, Todd wrote: That is a very different discussion, and not
> directly related to keyword indexes. Would it be possible to start a new
>
On Mon, Aug 24, 2020, 00:43 Christopher Barker wrote:
> But thus brings up a broader question:
>
> Why not allow slice syntax as an expression everywhere? Everywhere I’ve
> tried, it’s a syntax error now, but is there any technical reason that it
> couldn’t be used pretty much anywhere?
>
That i
I think it is worth directly discussing the availability of slices in PEP
472-style keyword indices, since we seem to have mostly converged on a
dunder method signature. This is an issue that has been alluded to
regarding keyword-based (labelled) indices but not directly addressed. The
basic synt
On Thu, Aug 20, 2020 at 2:28 PM Jonathan Fine wrote:
> Hi Todd
>
> You wrote:
>
> I think this is a bad idea, since it would mean classes could seem to
>> support keyword arguments but silently do the completely wrong thing,
>> especially if someone accidentally uses
On Thu, Aug 20, 2020 at 1:58 PM Christopher Barker
wrote:
> On Thu, Aug 20, 2020 at 12:55 PM Jonathan Fine
> wrote:
>
>> In addition, I would like
>>> >>> d = dict()
>>> >>> d[x=1, y=2] = 5
>>> to work. It works out-of-the-box for my scheme.
>>>
>>
> 1) it does? could you explain that, I
On Thu, Aug 20, 2020 at 2:13 PM Jonathan Fine wrote:
> Hi Todd
>
> I still don't see how testing it will help anything at this point.
>>
>
> Well, you and I have a difference of opinion here. I don't think it's
> worth discussing this further now. Perha
On Thu, Aug 20, 2020 at 1:43 PM Sebastian Kreft wrote:
>
>
> On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine
> wrote:
>
>> Todd wrote:
>>
>> It has the same capabilities, the question is whether it has any
>>> additional abilities that would justif
this, could we use:
>
> an_object[*args, **kwargs]
>
> and if *args was length-1, it would get extracted from the tuple? or would
> the seroth item of *args always get extracted from the tuple?
>
> So creating a new object to hold the arguments of an indexing operation is
>
On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine wrote:
> Todd wrote:
>
> It has the same capabilities, the question is whether it has any
>> additional abilities that would justify the added complexity.
>>
>
> The most obvious additional ability is that always
>
On Thu, Aug 20, 2020, 11:03 Jonathan Fine wrote:
> Todd wrote:
>
> Only Jonathan seems to want to do it differently. We are trying to find
>> out exactly why he prefers this approach. So far the only advantage I have
>> seen is that it is easier to experiment with.
>&g
uldn't work.
On Sat, Aug 15, 2020, 23:26 Guido van Rossum wrote:
> On Sat, Aug 15, 2020 at 8:02 PM Todd wrote:
>
>> On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
>> wrote:
>>
>>> > QUESTION
>>> > Suppose we have
>>> > >>
On Thu, Aug 20, 2020, 09:01 Random832 wrote:
> On Fri, Aug 14, 2020, at 06:03, Jonathan Fine wrote:
> > I'd like to sound out consensus regarding mapping access, where none of
> > the keys are positional. In particular, I suggest that PEP 472 allow
> > syntax and semantics such as
> > >>> d[x
On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
wrote:
> > QUESTION
> > Suppose we have
> > >>> d[x=1, y=2] = 42
> > >>> d[x=1, y=2]
> > 42
> > where d is an instance of a suitable class X that has no special
> knowledge of keywords.
>
> Initially, when I wrote the pep, the idea was th
On Wed, Aug 5, 2020, 10:38 <2qdxy4rzwzuui...@potatochowder.com> wrote:
> On 2020-08-04 at 10:58:51 -0400,
> Todd wrote:
>
> > My main issue with this is that, in my opinion, dunders are not
> > something a beginner should be messing with anyway. By the time
> >
On Wed, Aug 5, 2020, 09:47 Ricky Teachey wrote:
> Hi Todd thanks for your response.
>
> On Tue, Aug 4, 2020 at 11:01 AM Todd wrote:
>
>> On Tue, Aug 4, 2020 at 8:17 AM Ricky Teachey wrote:
>>
>>> ...
>>>
>>> There could be several reaso
On Mon, Aug 3, 2020 at 1:58 PM Jonathan Fine wrote:
> The decorator key_to_jfine comes from the kwkey.jfine submodule. It
> implements the API that I favour. This is my first contribution to the
> exploration of the API.
>
>
I guess the thing I don't understand is why you favor that API. Could y
On Tue, Aug 4, 2020 at 8:17 AM Ricky Teachey wrote:
> The following comment is from the thread about adding kwd arg support to
> the square bracket operator (eg, `Vec = Dict[i=float, j=float]`).
>
> On Tue, Aug 4, 2020, 2:57 AM Greg Ewing
> wrote:
>
> On 4/08/20 1:16 pm, Steven D'Aprano wrote:
>
a single variable rather than positional
arguments. There may also be performance implications, although I am not
certain about that.
On Mon, Aug 3, 2020 at 9:36 PM Steven D'Aprano wrote:
> On Mon, Aug 03, 2020 at 05:20:25PM -0400, Todd wrote:
> > Another approach could be too sim
On Mon, Aug 3, 2020, 17:13 Guido van Rossum wrote:
> On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker
> wrote:
>
>>
>> Yes, that would be correct. However, the function could instead be
>>> defined as:
>>>
>>> def __getitem__(self, index, /, **kwargs):
>>> ...
>>>
>>> and then there'd be no
Another approach could be too simply pass the labelled indices in a dict as
a third/fourth positional argument.
So for indexing
b = arr[1, 2, a=3, b=4]
Instead of
__getitem__(self, (1, 2), a=3, b=4)
Just do
__getitem__(self, (1, 2), {'a': 3, 'b': 4})
On Mon, Aug 3, 2020, 16:46 Christopher B
lating `x[1, 2, p=3, q=4]` into
> `x.__getitem__((1, 2), p=3, q=4)`. What the dict class's `__getitem__`
> would do with that is a different issue -- probably it would be an error.
>
> On Mon, Aug 3, 2020 at 10:32 AM Todd wrote:
>
>> On Mon, Aug 3, 2020, 13:11 Jonathan Fine w
or of Steven D'Aprano's idea of translating `x[1, 2, p=3, q=4]` into
> `x.__getitem__((1, 2), p=3, q=4)`. What the dict class's `__getitem__`
> would do with that is a different issue -- probably it would be an error.
>
> On Mon, Aug 3, 2020 at 10:32 AM Todd wrote:
>
>&
On Mon, Aug 3, 2020, 13:11 Jonathan Fine wrote:
> SUMMARY:
> Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.
>
> This package is about PEP 472 -- Support for indexing with keyword
> arguments
> See: https://www.python.org/dev/peps/pep-0472/
>
> As a result, I think we're now
What, exactly, is frozen? My understanding is that one problem with frozen
dicts in the past is deciding exactly what is mutable and what is
immutable. Can you change what object a key maps to so long as the set of
keys stay the same? Can you modify the contents of mutable object that is
a value
On Tue, Jul 21, 2020 at 2:05 PM David Mertz wrote:
> On Tue, Jul 21, 2020, 12:14 PM Sebastian Berg
>
>> First, using it for named dimensions, means you don't actually need to
>> mix it with normal tuple indexing, mixing both seems rather confusing?
>>
>> temperature.loc(method="nearest")[long
On Sat, Jul 18, 2020, 00:21 Ricky Teachey wrote:
>
> This raises a question that needs to be answered, then: what would be the
> utility of mixing together positional and kwd arguments in this way?
>
> Even the xarray examples given so far don't seem to make use of this
> mixture. From my knowled
On Fri, Jul 17, 2020 at 12:19 PM David Mertz wrote:
> Fwiw, I'm probably -0 on the feature itself. Someone suggested it could be
> useful for xarray, but I'm not sure now what that would look like. If
> someone had an example, I could easily be moved.
>
Here is what it currently looks like to as
On Fri, Jul 17, 2020, 12:10 David Mertz wrote:
> On Fri, Jul 17, 2020, 8:16 AM Jonathan Fine wrote:
>
>> Steve and I have different opinions, as to what the new behaviour of:
>> >>> d = dict()
>> >>> d[x=1, y=2] = 3
>> should be.
>>
>> He prefers that the assignment fail with
>> Type
On Fri, Jul 10, 2020, 12:44 Steven D'Aprano wrote:
> On Fri, Jul 10, 2020 at 02:48:31PM +0200, Alex Hall wrote:
>
> > I believe he was saying it would be weird if `d[1, 2]` called
> > `d.__getitem__((1, 2))` but `d[1, 2, x=3]` called `d.__getitem__(1, 2,
> > x=3)`. More generally, if `__getitem__
On Thu, Mar 5, 2020 at 4:27 AM Steve Barnes wrote:
> One of the lovely things about Python is that we have the capability to
> avoid issues such as the vagaries of the floating point type with libraries
> such as decimal and fractions. This is wonderous to me but comes with an
> issue that I susp
Currently with pickle you have to "open" the file separately from the
pickle operation, generally using a "with" clause, then provide the file
object to one of the pickle.dump or pickle.load. This adds quite a bit of
boilerplate for simply saving a file
I think it would be nice if pickle.dump and
On Tue, Jan 21, 2020 at 1:49 PM Johan Vergeer
wrote:
> I have worked with both C# and Python for a while now and there is one
> feature of C# I'm missing in the Python language.
>
> This feature is the "nameof" operator. (
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operat
The problem is that everyone has a different idea about what is a "basic
operation" is. If everything that anyone considered a "basic operation"
was included as a built-in then the builtins would be unusably large. That
is why we have the standard library, so people can easily do "basic
operation
The Python standard library module 'statistics' has a "mean" function.
On Thu, Dec 26, 2019, 08:54 Kemal Diri wrote:
> Hello,
>
> I think it would be nice to introduce an avg method for lists as a
> built-in function in python3.
> To get average of the list, I need to use some libs (eg numpy).
>
I am pretty sure this is a backwards incompatible change. It isn't likely
syntax, but I think it is possible.
I also don't like having to wait until the end of the expression to find
out it isn't a list. And also seems like it would be easy to miss in a
non-trivial case.
How would you be parsed
e copyright notice is in the Sphinx
> templates, maybe it's part of the python.org website? That has its own
> repo, follow the "Found a bug?" link on each page.
>
> --Guido
>
> On Tue, Oct 29, 2019 at 6:53 AM Todd wrote:
>
>> I am not really a lawyer, so I d
/license.html
[2]
https://docs.python.org/license.html#terms-and-conditions-for-accessing-or-otherwise-using-python
[3] https://licensebuttons.net/p/zero/1.0/88x31.png
[4] https://spdx.org/licenses/Python-2.0.html
On Thu, Oct 24, 2019 at 6:19 PM Guido van Rossum wrote:
> OK, let's see if w
Per Guido's suggestion, I am starting a new thread on this.
The itertools module documentation has a bunch of recipes that give various
ways to combine the existing functions for useful tasks. [1]
The issue is that these recipes are part of the documentation, and although
IANAL, as far as I can t
On Wed, Oct 23, 2019 at 11:44 AM Chris Angelico wrote:
> On Thu, Oct 24, 2019 at 2:39 AM Serhiy Storchaka
> wrote:
> >
> > 23.10.19 18:16, Steven D'Aprano пише:
> > > The average word length in English is five characters. That means that
> > > in a list of typical English words, more than a thir
On Wed, Oct 23, 2019 at 10:59 AM Steven D'Aprano
wrote:
> On Wed, Oct 23, 2019 at 10:09:41AM -0400, David Mertz wrote:
>
> > One big problem with the current obvious way would be shared by the
> > proposal. This hits me fairly often.
> >
> > colors1 = "red green blue".split() # happy
> >
> > Lat
On Sat, Apr 7, 2018 at 4:48 AM Paul Moore wrote:
> On 7 April 2018 at 08:44, Raymond Hettinger
> wrote:
> > Agreed that the "chain([x], it)" step is obscure. That's a bit of a
> bummer -- one of the goals for the itertools module was to be a generic
> toolkit for chopping-up, modifying, and spl
On Wed, Oct 23, 2019 at 5:30 AM Steven D'Aprano wrote:
> On Tue, Oct 22, 2019 at 08:53:53PM -0400, Todd wrote:
>
> [I wrote this]
> > > I would expect %w{ ... } to return a set, not a list:
> > >
> > > %w[ ... ] # list
> > > %w{ ... ]
On Tue, Oct 22, 2019 at 7:57 PM Steven D'Aprano wrote:
> On Tue, Oct 22, 2019 at 04:11:45PM -0400, Todd wrote:
> > On Tue, Oct 22, 2019 at 3:54 PM Steve Jorgensen
> wrote:
> >
> > > See
> > >
> https://en.wikibooks.org/wiki/Ruby_Programming/Syntax
On Tue, Oct 22, 2019 at 3:54 PM Steve Jorgensen wrote:
> See
> https://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Literals#The_%_Notation
> for what Ruby offers.
>
> For me, the arrays are the most useful aspect.
>
> %w{one two three}
> => ["one", "two", "three"]
>
> I did a search, an
On Tue, Oct 8, 2019 at 2:18 PM Anders Hovmöller wrote:
>
>
> On 8 Oct 2019, at 20:07, Todd wrote:
>
>
>
> On Tue, Oct 8, 2019 at 1:30 PM Anders Hovmöller
> wrote:
>
>>
>>
>> On 8 Oct 2019, at 19:19, Caleb Donovick wrote:
>>
>>
>
On Tue, Oct 8, 2019 at 2:03 PM Steven D'Aprano wrote:
> On Tue, Oct 08, 2019 at 12:55:40PM -0400, Todd wrote:
>
> > > da.isel(space=0, time=slice(None, 2))[...] = spam
> > >
> > > With this syntax this could be changed to:
> > >
> > > da
On Tue, Oct 8, 2019 at 1:30 PM Anders Hovmöller wrote:
>
>
> On 8 Oct 2019, at 19:19, Caleb Donovick wrote:
>
>
>
>> Because
>>
>> >>> dict(foo=:1)
>> File "", line 1
>> dict(foo=:1)
>> ^
>> SyntaxError: invalid syntax
>>
>
> I don't see how that's an argument, we are talkin
On Tue, Oct 8, 2019 at 1:05 PM Anders Hovmöller wrote:
>
>
> On 8 Oct 2019, at 18:59, Todd wrote:
>
>
>
>
> On Tue, Oct 8, 2019, 12:46 Anders Hovmöller wrote:
>
>>
>>
>> On 8 Oct 2019, at 18:35, Todd wrote:
>>
>> On Tue, Oct 8, 201
On Tue, Oct 8, 2019, 12:46 Anders Hovmöller wrote:
>
>
> On 8 Oct 2019, at 18:35, Todd wrote:
>
> On Tue, Oct 8, 2019 at 12:22 PM Andrew Barnert via Python-ideas <
> python-ideas@python.org> wrote:
>
>> On Oct 7, 2019, at 21:21, Caleb Donovick
>> wrote:
On Tue, Oct 8, 2019 at 12:22 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> On Oct 7, 2019, at 21:21, Caleb Donovick wrote:
> >
> > > But what if you wanted to take both positional AND keyword?
> >
> > I was suggesting that that wouldn't be allowed. So subscript either h
On Mon, Oct 7, 2019 at 11:19 AM Anders Hovmöller
wrote:
>
>
> On 7 Oct 2019, at 16:36, Batuhan Taskaya wrote:
>
>
> In fact, that would be a cool feature for ORMs. IMHO instead of ugly call
> chain with filters, slicing is a better option (on `__class_getattr__`). As
> said there are some disa
On Mon, Oct 7, 2019 at 8:37 PM Steven D'Aprano wrote:
> On Tue, Oct 08, 2019 at 09:19:07AM +1100, Cameron Simpson wrote:
> > On 07Oct2019 10:56, Joao S. O. Bueno wrote:
> > >So, in short, your idea is to allow "=" signs inside `[]` get notation
> to
> > >be translated
> > >to dicts on the call,
On Mon, Oct 7, 2019 at 8:34 PM Steven D'Aprano wrote:
> On Mon, Oct 07, 2019 at 02:22:22PM +0100, Rhodri James wrote:
> > On 04/10/2019 20:34, Caleb Donovick wrote:
>
> > >```
> > >where_x_1 = db[x=1]
> > >```
>
> which would be equivalent to the existing syntax
>
>where_x_1 = db[{'x': 1}]
>
On Fri, Oct 4, 2019 at 3:59 PM Caleb Donovick
wrote:
> While there is no restriction on passing dicts to getitem. Doing so tends
> to be a bit ugly. I have two main use cases in mind for this syntax.
>
> The first and perhaps the most obvious, is doing relational queries.
> ```
> where_x_1 = d
On Mon, Apr 1, 2019, 10:28 Antoine Pietri
wrote:
> While the switch to Python 3 did an excellent job in removing some of
> the old inconsistencies we had in the language, pretty much everyone
> agrees that some other backwards-incompatible changes could be made to
> remove some old warts and bri
What is the operator supposed to do?
On Sun, Mar 3, 2019, 09:52 francismb wrote:
> Hi,
> the idea here is just to add the __larrow__ and __rarrow__ operators for
> <- and ->.
>
>
> E.g. of use on dicts :
> >>> d1 = {'a':1, 'b':1 }
> >>> d2 = {'a':2 }
> >>> d3 = d1 -> d2
> >>> d3
> {'a':1, 'b':1
On Mon, Nov 26, 2018, 17:38 Steven D'Aprano On Mon, Nov 26, 2018 at 02:06:52PM -0800, Michael Selik wrote:
> > If you know the input is sizeable, why not check its length instead of
> the
> > map's?
>
> The consumer of map may not be the producer of map.
>
> You might know that alist supports len(
Sorry, nevermind. I think I misunderstood the idea.
On Thu, Sep 6, 2018 at 9:56 AM Todd wrote:
> I have encountered situations like this, and generally I just use **kwargs
> for non-critical and handle the parameter management in the body of the
> function.
>
> This also mak
I have encountered situations like this, and generally I just use **kwargs
for non-critical and handle the parameter management in the body of the
function.
This also makes it easier to pass the arguments to another function. You
can use a dict comprehension to copy over the keys you want, then
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:
> >>
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
> &g
On Fri, Aug 3, 2018 at 5:38 PM, Chris Barker wrote:
> On Fri, Aug 3, 2018 at 1:02 PM, Nicholas Chammas <
> nicholas.cham...@gmail.com> wrote:
>
>> The project overloaded the bitwise operators &, |, and ~ since they
>> could not
>>
> override the boolean operators and, or, and not.
>>
>> I actual
On Fri, Aug 3, 2018 at 6:05 PM, Benedikt Werner <1benediktwer...@gmail.com>
wrote:
> There was a proposal to allow overloading boolean operators in Pep-335
>> [2], but that PEP was rejected for a variety of very good reasons. I think
>> none of those reasons (besides the conversation fizzling out
On Fri, Aug 3, 2018 at 2:26 PM, Jonathan Fine wrote:
> Hi Todd
>
> Thank you for your contribution! I've got a couple of comments. The
> experts, I hope, will have more to say.
>
>
Thanks for your reply, Jonathan.
> You wrote:
>
> > As to why this is usef
On Thu, Aug 2, 2018 at 5:35 AM, Ken Hilton wrote:
> Hi, I don't know if someone has already suggested this before, but here
> goes:
>
> With expressions allow using the enter/exit semantics of the with
> statement inside an expression context. Examples:
>
> contents = f.read() with open('file
Coming back to the previous discussion about a new set of overloadable
boolean operators [1], I have an idea for overloadable boolean operators
that I think might work. The idea would be to define four new operators
that take two inputs and return a boolean result based on them. This
behavior can
On Mon, Jul 23, 2018 at 8:41 AM, Paul Moore wrote:
> On 23 July 2018 at 13:19, Todd wrote:
> > On Mon, Jul 23, 2018 at 7:24 AM, Paul Moore wrote:
> >>
> >> On 23 July 2018 at 11:31, Jeroen Demeyer wrote:
> >> > On 2018-07-23 12:24, Jeroen Demeyer wrote
On Mon, Jul 23, 2018 at 7:24 AM, Paul Moore wrote:
> On 23 July 2018 at 11:31, Jeroen Demeyer wrote:
> > On 2018-07-23 12:24, Jeroen Demeyer wrote:
> >>
> >> Another solution that nobody has mentioned (as far as I know) is to add
> >> additional syntax to the language for that. For example, one
On Mon, Jul 23, 2018 at 6:28 AM, Jonathan Fine wrote:
> Hi Grégory
>
> You wrote:
> > Oh yes , I see. Seems like almost everybody think using the [...] syntax
> to
> > define reusable slices is a good idea,
>
> > Not sure slice[1::3] can be done, but this has my preference too: it's
> the
> > mos
On Mon, Jul 23, 2018 at 6:24 AM, Jeroen Demeyer wrote:
> On 2018-07-23 11:58, Grégory Lielens wrote:
>
>> Not sure slice[1::3] can be done
>>
>
> It can be done. Since "slice" is a class, it would require a metaclass
> though.
>
> Another solution that nobody has mentioned (as far as I know) is t
1 - 100 of 155 matches
Mail list logo
