[Python-ideas] Re: Add "try: stmt except: stmt" syntax to Python

[Steele Farnsworth]

This was proposed in 2014 and was rejected:
https://www.python.org/dev/peps/pep-0463/

That being said, I would support such a thing being added to the language.
My preferred syntax would be `try expression except ExceptionType [as e]
with alternative`, or even `expression except ExceptionType [as e] with
alternative`.

Steele

On Tue, Jun 1, 2021 at 4:11 PM Shreyan Avigyan <
shreyan.avigya...@outlook.com> wrote:

> Python has support for conditional statement, list comprehensions, dict
> comprehensions, etc. So we can write these in mere one or two lines. But
> for try-except it's not possible to write it one or two lines. Many a
> times, we have one stmt that we want to check and if it raises error then
> do nothing or just execute one stmt. This idea proposes to add a way to
> write try-except for one stmt in one line.
>
> Thanking you,
>
> With Regards
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/T7UKDECCKNXPWIJ6VLCDGAVSXRJQVZ7W/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/DK45GOPP2BJEGQQWS63O6EKIQITEPDZM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Circular Indexing

[Steele Farnsworth]

I believe this would be simple to implement when it's needed by subclassing
`collections.UserList` and wrapping this functionality around
`__getitem__`, `__setitem__`, and `__delitem__`.

On Tue, Nov 24, 2020, 2:38 PM Mathew M. Noel via Python-ideas <
python-ideas@python.org> wrote:

> Python uses an index of -1 to index the last element in a list. Since -1
> occurs before 0 we might think of the elements of the linear list are being
> bent into a circle making the last element occur before the 0th element.
> Consider a list with n elements: it would be perfectly reasonable to
> address the element 0 of the list using an index of n since n occurs after
> n-1 (if we assume that the list is bent into a circle). This feature can
> prove to be extremely useful. Consider the following example:
>
>
> days_of_the_week = 
> ["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"]
>
> It would be nice if
>
> days_of_the_week[0]
>
> is the same as
>
> days_of_the_week[7]
>
> is the same as
>
> days_of_the_week[14] etc
>
> In other words use modular indexing.
> In other words if the index is outside the range 0 to n-1, we simply take the 
> remainder when the index is divided by n as the index.
> Because of the close relationship between finite length sequences and 
> periodic sequences this feature might simplify scientific computing(circular 
> convolution etc).
>
>
>
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZEH5W2XBYSHKU733WSLGQEIIPOFSVBIU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/3X5M357XO5P6E5JPFARIXDDTRM3PJYOD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Inline Try-Except Clause

[Steele Farnsworth]

`... except ... with ...` more closely mirrors the inline if-else syntax,
which I think is the idea, and it doesn't use a colon.

On Thu, Aug 6, 2020, 6:29 PM Rob Cliffe  wrote:

>
>
> On 06/08/2020 23:14, Steele Farnsworth wrote:
> > I have wanted this sort of syntax before but assumed it wasn't
> > feasible and never considered how I'd want it to look. One possibility
> > that wasn't mentioned in Chris's earlier PEP is this:
> >
> > `value = func() except Exception with default`
> Er, how is this different from
>  (value = func() except Exception: default)
> which is the PEP 463 syntax?
> >
> > Though you'd almost certainly want to use a more specific exception.
> True.
>
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/5D2272FRI6OEH5KS7GFBPPBO7SVIVUD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Inline Try-Except Clause

[Steele Farnsworth]

I have wanted this sort of syntax before but assumed it wasn't feasible and
never considered how I'd want it to look. One possibility that wasn't
mentioned in Chris's earlier PEP is this:

`value = func() except Exception with default`

Though you'd almost certainly want to use a more specific exception.


On Thu, Aug 6, 2020, 4:35 PM Chris Angelico  wrote:

> On Fri, Aug 7, 2020 at 6:28 AM  wrote:
> >
> > > Have a look at PEP 463, which looks into this in some detail.
> >
> > I wish this PEP had gained more traction.  Sooner or later, everyone
> wants an expression form of a try/except.
> >
> > When it comes to expressing "in the event of this exception, I want this
> default",  exception expressions read much more nicely than an equivalent
> try/except block.
> >
> > Also, new syntax would keep the rest of the language clean so that don't
> end up adding dozens of get() methods. Or r having us expand function
> signatures with default arguments, like min() and max() functions for
> example.
> >
> > It would be great if this PEP were to be resurrected.
> >
>
> I'd be happy to work on it again if anyone else has suggestions for
> better justifications - see the rejection notice at the top of the
> PEP.
>
> ChrisA
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/TN6MWJ3Y7VYHGPJUS7FKRDNXEYST2W5D/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/XH6A3A2K4LHC6IUFEKP5I74CFBSYO5QE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Else assert statement

[Steele Farnsworth]

To be more specific, if the last `elif` condition permits all remaining
permissible conditions (which I suppose would just be whatever is asserted
by the proposed syntax), then the else block can just be the raising of the
exception.

On Thu, Jul 2, 2020, 7:52 PM Steele Farnsworth 
wrote:

> Assertions aren't guaranteed to be executed and thus should never be used
> where raising an error is required.
>
> `else: raise SomeError('reason')` already has the desired effect, and it's
> plenty readable.
>
> On Thu, Jul 2, 2020, 7:46 PM Artemis  wrote:
>
>> Often, I know that a variable should have one of a set of values, and I
>> want to determine which one, with an if/elif/else clause. This looks
>> something like this:
>> ```
>> if foo == 1:
>> # do a
>> elif foo == 2:
>> # do b
>> elif foo == 3:
>> # do c
>> else:
>> raise ValueError('foo must be 1, 2 or 3')
>> ```
>> Sometimes, I just do
>> ```
>> if foo == 1:
>> # do a
>> elif foo == 2:
>> # do b
>> else:
>> # do c
>> ```
>> But this is less readable and allows errors to slip past. My proposal is
>> to allow the following syntax:
>> ```
>> if foo == 1:
>> # do a
>> elif foo == 2:
>> # do b
>> else foo == 3:
>> # do c
>> ```
>> Or perhaps the more readable version:
>> ```
>> if foo == 1:
>> # do a
>> elif foo == 2:
>> # do b
>> else assert foo == 3:
>> # do c
>> ```
>> Both of these options are backward compatible, since currently nothing is
>> allowed between the `else` and the `:`.
>> This would be roughly equivalent to
>> ```
>> if foo == 1:
>> # do a
>> elif foo == 2:
>> # do b
>> else:
>> assert foo == 3
>> # do c
>> ```
>> But shorter and more readable, since it puts the assertion at the same
>> levels as the others. Thoughts?
>> ___
>> 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
>> https://mail.python.org/archives/list/python-ideas@python.org/message/ZKAQK7YTOR2GVVFZFVO3U22WYJHVC3KE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/O44732WE7XIF5YRO2JFWDPXMOSSHII4A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Else assert statement

[Steele Farnsworth]

Assertions aren't guaranteed to be executed and thus should never be used
where raising an error is required.

`else: raise SomeError('reason')` already has the desired effect, and it's
plenty readable.

On Thu, Jul 2, 2020, 7:46 PM Artemis  wrote:

> Often, I know that a variable should have one of a set of values, and I
> want to determine which one, with an if/elif/else clause. This looks
> something like this:
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> elif foo == 3:
> # do c
> else:
> raise ValueError('foo must be 1, 2 or 3')
> ```
> Sometimes, I just do
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else:
> # do c
> ```
> But this is less readable and allows errors to slip past. My proposal is
> to allow the following syntax:
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else foo == 3:
> # do c
> ```
> Or perhaps the more readable version:
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else assert foo == 3:
> # do c
> ```
> Both of these options are backward compatible, since currently nothing is
> allowed between the `else` and the `:`.
> This would be roughly equivalent to
> ```
> if foo == 1:
> # do a
> elif foo == 2:
> # do b
> else:
> assert foo == 3
> # do c
> ```
> But shorter and more readable, since it puts the assertion at the same
> levels as the others. Thoughts?
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/ZKAQK7YTOR2GVVFZFVO3U22WYJHVC3KE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/MQYWGD6VUM2IFJ6HGIWKYRGPJOOCUB3G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Is possible some day add Uniform Function Call Syntax (UFCS) in Python like Dlang?

[Steele Farnsworth]

In theory it could be checked to see if a given function exists in the same
namespace as a given variable if it doesn't exist in it that variable's
object's method resolution order and try calling it using the syntax
described here, but I don't think it affords the language any added
elegance or communicative power.

It would have to be determined which takes precedence when a class has a
certain method that shares a name with one in the same namespace as an
instance. If a method with a given name is not part of a class, the
proposed syntax would cause what function calls are valid for a given
instance to sometimes be context dependent rather than dependent only on
the definition of the class. I'm concerned about what this would mean for
language learning and debugging.

The potential use case seems to be tied to nested function calls that take
one argument in the innermost call. If we were to change the syntax to
streamline these constructions, I'd want to see composite functions with @
revisited.

Steele

On Sun, Jun 28, 2020, 11:00 AM  wrote:

> Is possible some day add Uniform Function Call Syntax (UFCS) in Python
> like Dlang?
>
> Example:
> https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/UBGJ7K5YAYZSREN2QSTUEMLAS4JMYUCU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/X5XZYNJN5T4C2R2XZE6LTYKW3WSGSUDD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Steele Farnsworth]

It sounds like you're asking if the iteration order can be changed to be
something other than the original insertion order, or if you can cause a
new key-value pair to be added somewhere other than the end. I wonder if
you can achieve the desired outcome without a change to the language.

At any time, you can take the items in the dictionary, sort them however
you'd like, and then put them into a new dictionary.

sorted_items = sorted(my_dict.items(), key=lambda x: x[0].upper())
sorted_dict = dict(sorted_items)

There's probably a more elegant way to do the first line. But you could do
this before you perform the operation wherein you need the dict to be
ordered a certain way.

Steele

On Fri, Jun 26, 2020 at 1:30 PM Hans Ginzel  wrote:

> Date: Fri, 26 Jun 2020 18:47:44 +0200
> From: Hans Ginzel 
> To: Hans Ginzel 
> Subject: Access (ordered) dict by index; insert slice
>
> Hello,
>
> thank you for making dict ordered.
> Is it planned to access key,value pair(s) by index? See
> https://stackoverflow.com/a/44687752/2556118 for example. Both for
> reading and (re)writing?
> Is it planned to insert pair(s) on exact index? Or generally to slice? See
> splice() in Perl, https://perldoc.perl.org/functions/splice.html.
>
> Use case: Represent database table metadata (columns). It is useful as to
> access columns both by name and by index as to insert column on specific
> position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html,
> “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or
> table storage size optimisation by aligning).
>
> Thank you in advance,
> Hans
> PS1: Named tuples cannot be used, are immutable.
> PS2: See
> https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/2IXSBCDXKI3JIX5PNU7ELCVNBPIDWPPE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: giving set.add a return value

[Steele Farnsworth]

My point was only that, as far as I know, all the methods for built in
container types that serve only to change what is contained return None,
and that this was an intentional design choice, so changing it in one case
would have to evoke a larger discussion about what those sorts of methods
should return.

I wouldn't be opposed to that discussion happening and for any changes that
are made to happen within 3.x because I doubt that very much code that
currently exists depends on these methods returning None or even use what
they return at all.

On Thu, Jun 25, 2020, 10:28 AM Ben Avrahami  wrote:

> Hey all,
> Often I've found this kind of code:
>
> seen = set()
> for i in iterable:
>   if i in seen:
> ...  # do something in case of duplicates
>   else:
> seen.add(i)
> ... # do something in case of first visit
>
> This kind of code appears whenever one needs to check for duplicates in
> case of a user-submitted iterable, or when we loop over a recursive
> iteration that may involve cycles (graph search or the like). This code
> could be improved if one could ensure an item is in the set, and get
> whether it was there before in one operation. This may seem overly
> specific, but dicts do do this:
>
> seen = {}
> for i in iterable:
>   if seen.set_default(i, some_value) is not None:
> ...  # do something in case of duplicates
>   else:
> ... # do something in case of first visit
>
> I think the set type would benefit greatly from its add method having a
> return value. set.add would return True if the item was already in the set
> prior to insertion, and False otherwise.
>
> Looking at the Cpython code, the set_add_entry already detects existing
> entries, adding a return value would require no additional complexity.
>
> Any thoughts?
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/6WYNYNG5J5HBD3PA7PW75RP4PMLOMH4C/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/ILNANLAGZR3S6VBMK7FJXUZZUMKGKJOV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: giving set.add a return value

[Steele Farnsworth]

Personally, I'd want to see mutator methods return `self` so you can do
more than one mutation in a statement, but the convention is that all the
mutator methods return `None`.

On Thu, Jun 25, 2020, 10:28 AM Ben Avrahami  wrote:

> Hey all,
> Often I've found this kind of code:
>
> seen = set()
> for i in iterable:
>   if i in seen:
> ...  # do something in case of duplicates
>   else:
> seen.add(i)
> ... # do something in case of first visit
>
> This kind of code appears whenever one needs to check for duplicates in
> case of a user-submitted iterable, or when we loop over a recursive
> iteration that may involve cycles (graph search or the like). This code
> could be improved if one could ensure an item is in the set, and get
> whether it was there before in one operation. This may seem overly
> specific, but dicts do do this:
>
> seen = {}
> for i in iterable:
>   if seen.set_default(i, some_value) is not None:
> ...  # do something in case of duplicates
>   else:
> ... # do something in case of first visit
>
> I think the set type would benefit greatly from its add method having a
> return value. set.add would return True if the item was already in the set
> prior to insertion, and False otherwise.
>
> Looking at the Cpython code, the set_add_entry already detects existing
> entries, adding a return value would require no additional complexity.
>
> Any thoughts?
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/6WYNYNG5J5HBD3PA7PW75RP4PMLOMH4C/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/GQ3GYFCYMQSXRM2OPJ6ZRAKS4IYNETMG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extend the range functionality to allow infinite ranges

[Steele Farnsworth]

> I don't see the value myself, but in theory it would make sense to
have both bounded and infinite ranges be able to be processed the same
way.

My thinking is that if we wanted to represent an unbounded range as a
mathematical entity (rather than a tool for iteration), we should let that
exist in numpy or another mathematical package so that it can have whatever
functionality a mathematician would want it to have without being tied up
to the cpython release cycle or backwards compatibility constraints.

Steele

On Fri, Jun 19, 2020 at 12:47 PM Chris Angelico  wrote:

> On Sat, Jun 20, 2020 at 2:39 AM Steele Farnsworth
>  wrote:
> > If range were to support infinite ranges, range.__len__ would have to be
> changed to either raise an error or return float('inf') in these cases.
>
> That would be a problem that would have to be solved, as would related
> concepts like what slicing with negative indices would do - what's
> range(0, ...)[:-10] give? This doesn't mean the idea is dead in the
> water, but anyone who's proposing it will need to come up with answers
> to these questions.
>
> > I believe __contains__ would also need to have extra checks.
> >
>
> That'd be easy enough. The check "x in r" has to check three things:
> is x >= r.start, is r < x.stop, and is (x - r.start) % r.step == 0.
> Having an infinite end point would simply remove the need for the
> middle check (or have it always be true).
>
> Be aware that this idea is meaningful ONLY for the 'stop' parameter.
> An infinite start or step makes no sense.
>
> I don't see the value myself, but in theory it would make sense to
> have both bounded and infinite ranges be able to be processed the same
> way.
>
> ChrisA
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/KYDECOSQCTAE5QJN5HJICZBJVUNQ45CB/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/VD2BHQIGME3ABUSBEQXHYPIWOTBTNMZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extend the range functionality to allow infinite ranges

[Steele Farnsworth]

I suppose my previous message totally ignored that you acknowledged that
itertools.count exists.

If range were to support infinite ranges, range.__len__ would have to be
changed to either raise an error or return float('inf') in these cases. I
believe __contains__ would also need to have extra checks.

I don't really see the added benefit.

On Fri, Jun 19, 2020, 12:23 PM  wrote:

> Proposal:
> range(start, ..., step)
> should function like
> itertools.count(start, step)
>
> Reason:
> It's pretty common to see people do things where they increment a count
> within a while True loop, and it would be nice to have something easily
> available for people to use to replace this.
>
> Usefulness:
> There is definitely a use for this, as the type of code mentioned above is
> common, and itertools.count is commonly used as well.
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/6WEV73JM4EARGAYT6JIFH35Y5MRLK3MX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/U5HY2SAYRHLEKFLIEX5NKLXABQJXQNBR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Extend the range functionality to allow infinite ranges

[Steele Farnsworth]

You can get this behavior with itertools.count

On Fri, Jun 19, 2020, 12:23 PM  wrote:

> Proposal:
> range(start, ..., step)
> should function like
> itertools.count(start, step)
>
> Reason:
> It's pretty common to see people do things where they increment a count
> within a while True loop, and it would be nice to have something easily
> available for people to use to replace this.
>
> Usefulness:
> There is definitely a use for this, as the type of code mentioned above is
> common, and itertools.count is commonly used as well.
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/6WEV73JM4EARGAYT6JIFH35Y5MRLK3MX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/35KQGZFNWA2KFRAQA2EJCJZDCJBIV7T5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Postpone Python 4 for another 5 years

[Steele Farnsworth]

Is Python 4 being planned at the moment? What backwards incompatible
changes would it introduce?

Steele

On Sat, Jun 13, 2020, 9:22 AM João Bernardo  wrote:

> Now that double digits reached Python 3 and for the sake of
> maintaining compatibility for longer since Python 2.7 recently passed away
> and people is finally migrating after 12 years, I propose 5 new Python 3
> versions:
>
> So we can have Python 3.10, 3.11, 3.12, 3.13 and finally 3.14 a.k.a Pi-thon
>
>
> Regards
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/MH4LSSN2T7RCZUCGRUWHOQH6Q4D4CRSQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/AVXUTCMATG4HDP5W2HDAK5UWJWZTKYIL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Auto-assign attributes from __init__ arguments

[Steele Farnsworth]

I agree that dataclasses are for a slightly different use case.

It looks like this could be implemented as a decorator using the
functionality afforded by `inspect.signature`, though what I've come up
with so far is a bit clunky because you have to account for parameters that
could be positional or keyword and assigning default values for missing
arguments.

If this were added, I assume that static analysis tools would need to be
updated to account for the assumption that each instance has attributes
with the same names that appear in the `__init__` signature, and I have no
idea what that would entail. It would probably pose a similar issue for
automated refactoring.

On Mon, May 4, 2020 at 4:48 PM Lewis Ball  wrote:

> I did think about data classes and although I haven't really used them
> much they do seem to be for a different use case, for example they don't
> support keyword-only args or positional-only args. I'm not sure if there
> are any other differences. Maybe a data class which supported kW-only args
> and pos-only args would suit my use case.
>
> On Mon, 4 May 2020, 21:19 Henk-Jaap Wagenaar, 
> wrote:
>
>> You are not the first to have this idea. Unless I am mistaken you might
>> find what you are looking for in dataclasses which were added in Python 3.7:
>>
>> https://docs.python.org/3/library/dataclasses.html
>>
>> On Mon, 4 May 2020 at 19:06, Lewis Ball  wrote:
>>
>>> Hi All,
>>>
>>> First of all, if this is something which has been discussed in the past
>>> the please point me in the right direction.
>>>
>>> *Problem:*
>>>
>>> When creating classes in Python, I find myself writing the __init__
>>> method in a very similar way a lot of the time, that is:
>>> ```
>>> def __init__(self, argument_1, argument_2, argument_3=None):
>>> self.argument_1 = argument_1
>>> self.argument_2 = argument_2
>>> self.argument_3 = argument_3
>>> # then maybe some other attribute setting and logic follows
>>> ```
>>>
>>> Every argument of __init__ gets a corresponding attribute with the same
>>> name. This means that each `argument_i` has been typed 3 times, which seems
>>> overly-verbose as well as being easy to mistype. This pattern is easy to
>>> find in various popular python libraries, and in some it is actually
>>> enforced. For example, I do quite a bit of work with classifiers using the
>>> sklearn estimator API, and for various reasons sklearn enforce this pattern
>>> for an __init__ (see here
>>> 
>>> if interested).
>>>
>>> Here is an example of this pattern from the standard library (from
>>> textwrap.TextWrapper):
>>> ```
>>> def __init__(self,
>>>  width=70,
>>>  initial_indent="",
>>>  subsequent_indent="",
>>>  expand_tabs=True,
>>>  replace_whitespace=True,
>>>  fix_sentence_endings=False,
>>>  break_long_words=True,
>>>  drop_whitespace=True,
>>>  break_on_hyphens=True,
>>>  tabsize=8,
>>>  *,
>>>  max_lines=None,
>>>  placeholder=' [...]'):
>>> self.width = width
>>> self.initial_indent = initial_indent
>>> self.subsequent_indent = subsequent_indent
>>> self.expand_tabs = expand_tabs
>>> self.replace_whitespace = replace_whitespace
>>> self.fix_sentence_endings = fix_sentence_endings
>>> self.break_long_words = break_long_words
>>> self.drop_whitespace = drop_whitespace
>>> self.break_on_hyphens = break_on_hyphens
>>> self.tabsize = tabsize
>>> self.max_lines = max_lines
>>> self.placeholder = placeholder
>>> ```
>>>
>>> With a quick scan of the top 50 or so most used python packages, *1 in
>>> 4* __init__ methods that takes arguments has the line `self.argument_i
>>> = argument_i` for every single argument, with several of them having 10+
>>> arguments.
>>>
>>> *Suggestion:*
>>>
>>> A new built-in called something like `assign()` which would assign every
>>> single __init__ arg to a corresponding attribute. e.g. the snippet from
>>> above could be rewritten to:
>>> ```
>>> def __init__(self, argument_1, argument_2, argument_3=None):
>>> assign()
>>> # other init logic goes here
>>> ```
>>>
>>> This could alternatively be implemented as a decorator, like so
>>> ```
>>> @assign
>>> def __init__(self, argument_1, argument_2, argument_3=None):
>>> # other init logic goes here
>>> ```
>>> but then this requires a `pass` if no other logic is needed inside the
>>> __init__. There may also be some other syntax for this which would be even
>>> easier to use.
>>>
>>> Is this something that others would find useful?
>>>
>>> Thanks,
>>>
>>> Lewis
>>> ___
>>> 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
>>> 

[Python-ideas] Re: Equality between some of the indexed collections

[Steele Farnsworth]

You can get the desired behavior by casting a list to a tuple, or a tuple
to a list, in the equality statement. That way those that rely on the
existing implementation don't have to change their code.

my_tup = (1, 2, 3)
my_list = [1, 2, 3]
print(list(my_tup) == my_list)

On Sat, May 2, 2020, 9:04 AM Ahmed Amr  wrote:

> I'd like to take your opinion on modifying some of the indexed collections
> like tuples, lists, arrays to evaluate its equality to True when having the
> same items in the same indexes.
> Currently, when comparing a list of items to an array of the same items
> for equality (==)  it returns False, I'm thinking that it would make sense
> to return True in that context, as we're comparing item values and we have
> the same way of indexing both collections, so we can compare item values.
>
> So what do you think about applying such behavior on collections that can
> be indexed the same way such as tuples, lists, and arrays?
>
> Example: (Current)
>
> import array
> tuple_ = (1.1, 2.2, 3.3)
> list_ = [1.1, 2.2, 3.3]
> array_ = array.array('f', [1.1, 2.2, 3.3])
>
> # all of the following prints False.
> print(tuple_ == list_)
> print(tuple_ == array_)
> print(array_ == list_)
>
> Example: (Proposed):
> All prints above to show True as they are populated with the same data in
> the same indexes.
>
> A Side Note:
> An extra point to discuss, based on arrays implementation,
> array_.to_list() would actually get [1.10023841858, 2.20047683716,
> 3.29952316284] which is not exactly what we've passed as args and this
> is normal, but I'm thinking about leaving it to the array implementation to
> encapsulate that implementation and perform exact equality based on passed
> arguments.
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/UE5HGECRTS3ERK5OMG3GB77EKSAFJV7R/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/NPEIUL3A7JYPFTDLVLOOENT5UXFYJKUT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: is a

[Steele Farnsworth]

`yield from` is a case where two keywords are used together to do something
new, but they're both keywords independently of each other. If `a` can be
variable or a keyword, we'd have to decide when `x is a y` is using `a` as
a keyword and when it's using it as a variable. I don't think introducing
that possibility is worth the effort.

On Fri, May 1, 2020 at 2:13 PM Soni L.  wrote:

>
>
> On 2020-05-01 2:46 p.m., Steele Farnsworth wrote:
>
> So this would make `a` a new keyword. I don't think that could be added
> into python 4 at the earliest because it would immediately break all code
> for which `a` is a variable name.
>
>
> we could have keyphrases instead of keywords, tbh.
>
>
> I can appreciate wanting to make simple operations easy to read, though I
> think this relies too much on understanding English and wouldn't be
> intuitive for people who aren't English speaking. I am native English
> speaking so I wouldn't know for sure, but I think accepting that "or" is
> the same as "||" is an easier jump to make than "x is a y" being a
> construct for indicating that x belongs to the y class.
>
> If you need this English-style syntax, I believe `type(x) is y` is
> guaranteed to be True if x is exactly of the y type and not one of its
> super classes.
>
> On Fri, May 1, 2020, 1:27 PM gbs--- via Python-ideas <
> python-ideas@python.org> wrote:
>
>> In cases where it makes sense to do explicit type checking (with ABCs or
>> whatever), I really detest the look of the isinstance() function.
>>
>> if isinstance(thing, Fruit) and not isinstance(thing, Apple):
>>
>> Yucky.
>>
>> What I really want to write is:
>>
>> if thing is a Fruit and thing is not an Apple:
>>
>> and after thinking about it on and off for a while I wonder if it might
>> indeed be possible to teach the parser to handle that in a way that
>> eliminates almost all possible ambiguity with the regular "is", including
>> perhaps 100% of all existing standard library code and almost all user code?
>>
>> Maybe this has been considered at some point in the past? The "is [not]
>> a|an" proposal would at least be a strong contender for "hardest thing to
>> search for on the internet" lol.
>>
>> Thanks!
>>
>> Gavin
>> ___
>> 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
>> https://mail.python.org/archives/list/python-ideas@python.org/message/YKLNQXONLLZ7OXEMUHXF5HD4PCX4SNVT/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to 
> python-ideas-leave@python.orghttps://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/PQSJ6PSRS3JZZUV7CRRKRSGJAPVBYP6G/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/JFSNV7FAKLMTZWQDHJWPX3ZSMKVHA6V3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/ULZUOHUT4XY7ZB2XF6IAD6J7CDOVG4TU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: is a

[Steele Farnsworth]

So this would make `a` a new keyword. I don't think that could be added
into python 4 at the earliest because it would immediately break all code
for which `a` is a variable name.

I can appreciate wanting to make simple operations easy to read, though I
think this relies too much on understanding English and wouldn't be
intuitive for people who aren't English speaking. I am native English
speaking so I wouldn't know for sure, but I think accepting that "or" is
the same as "||" is an easier jump to make than "x is a y" being a
construct for indicating that x belongs to the y class.

If you need this English-style syntax, I believe `type(x) is y` is
guaranteed to be True if x is exactly of the y type and not one of its
super classes.

On Fri, May 1, 2020, 1:27 PM gbs--- via Python-ideas <
python-ideas@python.org> wrote:

> In cases where it makes sense to do explicit type checking (with ABCs or
> whatever), I really detest the look of the isinstance() function.
>
> if isinstance(thing, Fruit) and not isinstance(thing, Apple):
>
> Yucky.
>
> What I really want to write is:
>
> if thing is a Fruit and thing is not an Apple:
>
> and after thinking about it on and off for a while I wonder if it might
> indeed be possible to teach the parser to handle that in a way that
> eliminates almost all possible ambiguity with the regular "is", including
> perhaps 100% of all existing standard library code and almost all user code?
>
> Maybe this has been considered at some point in the past? The "is [not]
> a|an" proposal would at least be a strong contender for "hardest thing to
> search for on the internet" lol.
>
> Thanks!
>
> Gavin
> ___
> 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
> https://mail.python.org/archives/list/python-ideas@python.org/message/YKLNQXONLLZ7OXEMUHXF5HD4PCX4SNVT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/PQSJ6PSRS3JZZUV7CRRKRSGJAPVBYP6G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Proposed class for collections: dynamicdict

[Steele Farnsworth]

I've implemented the class as a stand-alone module here:
https://github.com/swfarnsworth/dynamicdict

It could in theory be made significantly more concise if `defdict_type`
were the base for this class instead of `PyDict_Type`.



On Tue, Apr 14, 2020 at 1:32 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:

> On Apr 13, 2020, at 18:44, Caleb Donovick 
> wrote:
>
> 
> I have built this data structure countless times. So I am in favor.
>
>
> Maybe you can give a concrete example of what you need it for, then? I
> think that would really help the proposal. Especially if your example needs
> a per-instance rather than per-class factory function.
>
> > Why can’t you just subclass dict and override that?
>
> Because TypeError: multiple bases have instance lay-out conflict is one
> of my least favorite errors.
>
>
> But defaultdict, being a subclass or dict, has the same problem in the
> same situations, and (although I haven’t checked) I assume the same is true
> for the OP’s dynamicdict.
>
> Perhaps `__missing__` could be a first class part of the getitem of
> protocol, instead of a `dict` specific feature.  So that
>
> ```
> r = x[key]
> ```
> means:
> ```
> try:
>   r = x.__getitem__(key)
> except KeyError as e: # should we also catch IndexError?
>   try:
> missing = x.__missing__
>   except AttributeError:
> raise e from None
>   r = missing(key)
> ```
>
> Obviously this would come at some performance cost for non dict mappings
> so I don't know if this would fly.
>
>
> Besides performance, I don’t think it fits with Guido’s conception of the
> protocols as being more minimal than the builtin types—e.g., set has not
> just a & operator, but also an intersection method that takes 0 or more
> arbitrary iterables; the set protocol has no such method, so
> collections.abc.Set neither specifies nor provides an intersection method).
> It’s a bit muddy of a conception at the edges, but I think this goes over
> the line, and maybe have been explicitly thought about and rejected for the
> same reason as Set.intersection.
>
> On the other hand, none of that is an argument or any kind against your
> method decorator:
>
> So instead maybe there could have standard decorator to get the same
> behavior?
> ```
> def usemissing(getitem):
>   @wraps(getitem)
>   def wrapped(self, key):
> try:
>   return getitem(self, key)
> except KeyError as e:
>   try:
> missing = self.__missing__
>   except AttributeError:
> raise e from None
> return missing(key)
>   return wrapped
> ```
>
>
> This seems like a great idea, although maybe it would be easier to use as
> a class decorator rather than a method decorator. Either this:
>
> def usemissing(cls):
> missing = cls.__missing__
> getitem = cls.__getitem__
> def __getitem__(self, key):
> try:
> return getitem(self, key)
> except KeyError:
>  return missing(self, key)
> cls.__getitem__ = __getitem__
> return cls
>
> Or this:
>
>def usemissing(cls):
> getitem = cls.__getitem__
> def __getitem__(self, key):
> try:
> return getitem(self, key)
> except KeyError:
>  return type(self).__missing__(self, key)
> cls.__getitem__ = __getitem__
> return cls
>
> This also preserves the usual class-based rather than instance-based
> lookup for most special methods (including __missing__ on dict subclasses).
>
> The first one has the advantage of failing at class decoration time rather
> than at first missing lookup time if you forget to include a __missing__,
> but it has the cost that (unlike a dict subclass) you can’t monkeypatch
> __missing__ after construction time. So I think I’d almost always prefer
> the first, but the second might be a better fit for the stdlib anyway?
>
> I think either the method decorator or the class decorator makes sense for
> the stdlib. The only question is where to put it. Either fits in nicely
> with things like cached_property and total_ordering in functools. I’m not
> sure people will think to look for it there, as opposed to in collections
> or something else in the Data Types chapter in the docs, but that’s true of
> most of functools, and at least once people discover it (from a Python-list
> or StackOverflow question or whatever) they’ll learn where it is and be
> able to use it easily, just like the rest of that module.
>
> It’s simple, but something many Python programmers couldn’t write for
> themselves, or would get wrong and have a hard time debugging, and it seems
> like the most flexible and least obtrusive way to do it. (It does still
> need actual motivating examples, though. Historically, the bar seems to be
> lower for new decorators in functools than new classes in collections, but
> it’s still not no bar…)
>
> Additionally—I’m a lot less sure if this one belongs in the stdlib like
> 

[Python-ideas] Proposed class for collections: dynamicdict

[Steele Farnsworth]

 I have implemented a class in the C code of the collections module which
has similar behavior to the defaultdict class. This class, dynamicdict,
supplies values for keys that have not yet been added using a default
factory callable, but unlike defaultdict, the missing key itself is passed
to the callable. This code can be seen here:
https://github.com/swfarnsworth/cpython/blob/3.8/Modules/_collectionsmodule.c#L2234

While this does introduce a lot of redundant code, I'm not sure how it
could be done without copying the implementation of the defaultdict class
and adjusting how the default factory is called. For example, I don't
believe that it's possible to support both behaviors within the defaultdict
class without breaking backwards compatibility or adding another parameter
to the constructor for the defaultdict class.

I don't know if a PEP is needed for this to be added to the standard
library, or if it's something that anyone other than myself wants to see
added, but I would be happy to further explain the concept, implementation,
potential use cases, or anything else that might work towards the adoption
of this feature.

Regards,
Steele
___
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 
https://mail.python.org/archives/list/python-ideas@python.org/message/XYSY3K4O6AYSIIGOJGIO5XKNBHOM6B5S/
Code of Conduct: http://python.org/psf/codeofconduct/