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
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
On Mon, Mar 15, 2021, 06:15 Roland Puntaier via Python-ideas <
[email protected]> 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
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
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
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
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 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 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
>
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
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 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
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 Fri, Aug 3, 2018 at 6:05 PM, Benedikt Werner <[email protected]>
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 5:38 PM, Chris Barker wrote:
> On Fri, Aug 3, 2018 at 1:02 PM, Nicholas Chammas <
> [email protected]> wrote:
>
>> The project overloaded the bitwise operators &, |, and ~ since they
>> could not
>>
> override the boolean operators and, or, and not.
>>
>> I actual
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 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:
> >>
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
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
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(
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, 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
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, 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 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 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 Tue, Oct 8, 2019 at 12:22 PM Andrew Barnert via Python-ideas <
[email protected]> 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 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 <
> [email protected]> wrote:
>
>> On Oct 7, 2019, at 21:21, Caleb Donovick
>> wrote:
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 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 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 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 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 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 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 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 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 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
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
/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
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
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
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).
>
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
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
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 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
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 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 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 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 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
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 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
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:
>
>&
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
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
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
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 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:
>
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 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 Wed, Aug 5, 2020, 10:38 <[email protected]> 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 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 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
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, 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
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
>
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 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
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: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: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
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 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
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
>
message from Steven D'Aprano
> -
>
> Date: Mon, 24 Aug 2020 11:46:02 +1000
> From: Steven D'Aprano
> To: [email protected]
> 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 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
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 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 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 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 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, 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;
>
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
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
On Sun, Nov 22, 2020 at 3:27 PM Abdulla Al Kathiri <
[email protected]> 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
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 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
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
>
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
On Thu, Oct 13, 2016 at 1:46 AM, Mikhail V wrote:
> Practically all this notation does, it reduces the time
> before you as a programmer
> become visual and brain impairments.
>
>
Even if you were right that your approach is somehow inherently easier, it
is flat-out wrong that other approaches le
On Sun, Oct 16, 2016 at 3:26 PM, Mikhail V wrote:
> One my supposition is that during the reading there is
> very intensive two-directional signalling between eye and
> brain. So generally you are correct, the eye is technically
> a camera attached to the brain and simply sends pictures
> at some
On Wed, Oct 19, 2016 at 3:38 AM, Neil Girdhar wrote:
> This is a very interesting proposal. I just wanted to share something I
> found in my quick search:
>
> http://stackoverflow.com/questions/14797930/python-
> custom-iterator-close-a-file-on-stopiteration
>
> Could you explain why the accepte
I have been thinking about how to go about having a multidimensional array
constructor in python. I know that Python doesn't have a built-in
multidimensional array class and won't for the foreseeable future.
However, some projects have come up with their own ways of making it
simpler to create suc
On Wed, Oct 19, 2016 at 2:38 PM, Paul Moore wrote:
> On 19 October 2016 at 19:13, Chris Angelico wrote:
> > Now it *won't* correctly call the end-of-iteration function, because
> > there's no 'for' loop. This is going to either (a) require that EVERY
> > consumer of an iterator follow this new p
On Wed, Oct 19, 2016 at 3:24 PM, Thomas Nyberg wrote:
> Personally I like the way that numpy does it now better (even for
> multidimensional arrays). Being able to index into the different sub
> dimension using just [] iteratively matches naturally with the data
> structure itself in my mind. Thi
On Wed, Oct 19, 2016 at 3:55 PM, Joseph Jevnik wrote:
> You could add or prototype this with quasiquotes (http://quasiquotes.
> readthedocs.io/en/latest/). You just need to be able to parse the body of
> your expression as a string into an array. Here is a quick example with a
> parser that only
On Wed, Oct 19, 2016 at 4:47 PM, Matt Gilson wrote:
> FWIW, you probably _don't_ want to use `ndarray` directly. Normally, you
> want to use the `np.array` factory function...
>
> >>> import numpy as np
> >>> a = np.ndarray([0, 1, 2])
> >>> a
> array([], shape=(0, 1, 2), dtype=float64)
>
> Aside
On Wed, Oct 19, 2016 at 7:48 PM, Chris Barker wrote:
> a few thoughts:
>
> On Wed, Oct 19, 2016 at 12:08 PM, Todd wrote:
>
>> I have been thinking about how to go about having a multidimensional
>> array constructor in python. I know that Python doesn't have a
1 - 100 of 155 matches
Mail list logo
