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
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
`... 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 as
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
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
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
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
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
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()
>
, 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
>
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
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
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
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
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
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 immediat
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
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 <
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
20 matches
Mail list logo
