On 6/1/23 11:06, David Mertz, Ph.D. wrote:
> I guess this is pretty general for the described need:
>
> >>> unicode_whitespace = [chr(c) for c in range(0x) if unicodedata.category(chr(c))
== "Zs"]
Using the module-level `__getattr__` that could be a lazy attribute.
--
~Ethan~
On 4/1/23 07:45, Richard Hajek wrote:
> # Feature or enhancement
>
> `len(Enum)` has no useful meaning and should therefore raise the appropriate
error
>
> # Pitch
>
> I cannot figure out any scenario, in which len(Enum) should not raise. Enum is a type and as any other types, such as
On 12/19/22 13:59, Chris Angelico wrote:
> The way things are, a StrEnum or an HTML string will behave *exactly
> as a string does*. The alternative is that, if any new operations are
> added to strings in the future, they have to be explicitly blocked by
> StrEnum or else they will randomly and
On 12/1/22 11:36, Ram Rachum wrote:
> Reviving this thread 2.5 years after I started it just to share this
satisfying moment...
Very cool! Always enjoyable to benefit from the fruits of one labors. :-)
--
~Ethan~
___
Python-ideas mailing list --
On 7/9/22 12:19, Steve Jorgensen wrote:
> [...] It works great to combine them by defining the dataclass as a mixin for
the Enum class. Why would
> it not be good to include that as an example in the official docs, assuming
(as I believe) that it is a
> particularly useful combination?
Do you
On 7/7/22 18:22, Steve Jorgensen wrote:
> After some playing around, I figured out a pattern that works without any
changes to the
> implementations of `dataclass` or `Enum`, and I like this because it keeps
the 2 kinds of
> concern separate. Maybe I'll try submitting an MR to add an example
On 7/8/22 19:50, Ethan Furman wrote:
> The repr from a combined dataclass/enum looks like a dataclass, giving no
clue that the
> object is an enum, and omitting any information about which enum member it is
and which
> enum it is from.
Fixed in 3.11: ``
On 7/7/22 09:01, Steve Jorgensen wrote:
> Actually, maybe these are fundamentally incompatible? `@dataclass` is a
decorator, so it
> acts on the class after it was already defined, but `Enum` acts before that
when `@dataclass`
> cannot have not generated the `__init__` yet. Right?
Correct.
On 7/6/22 17:01, Steve Jorgensen wrote:
> Perhaps, this has already been addressed in a newer release (?) but in Python
3.9, making
> `@dataclass` work with `Enum` is a bit awkward.
>
> Currently, it order to make it work, I have to:
> 1. Pass `init=False` to `@dataclass` and hand-write the
On 7/7/22 09:01, Steve Jorgensen wrote:
> Actually, maybe these are fundamentally incompatible?
Their intended use seems fundamentally incompatible:
- dataclass was designed for making many mutable records (hundreds, thousands,
or more)
- enum was designed to make a handful of named constants
On 5/8/22 05:08, Valentin Berlier wrote:
> This would make it really useful in if statements and list comprehensions.
Here are a couple motivating examples:
>
> # Buy every pizza on the menu
> cost_for_all_pizzas = sum(
> price for food in menu
> if ({"type":
On 5/7/22 06:24, Chris Angelico wrote:
> On Sat, 7 May 2022 at 23:15, Stephen J. Turnbull wrote:
>>
>> def foo(self, x, y):
>> x.y = y
>>
>> is not a pattern I can recall ever seeing
>
> I'd define it very simply. For positional args, these should be
> exactly equivalent:
>
> def
On 5/2/22 23:21, Christopher Barker wrote:
> But yes, there are many use cases not suited to dataclasses. The question is
how many of these would
> rap parge benefit from auto-assigning syntax?
How did you get to "rap parge" from "reap the" ?
On 5/2/22 20:32, Christopher Barker wrote:
>
On 5/1/22 00:21, Christopher Barker wrote:
> On Sat, Apr 30, 2022 at 2:17 PM Pablo Alcain wrote:
>> It shows that out of 20k analyzed classes in the selected libraries
(including black,
>> pandas, numpy, etc), ~17% of them could benefit from the usage of
auto-assign syntax.
>
> I only read
On 4/28/22 21:46, Christopher Barker wrote:
> One thing you can say about dataclasses is that they provide a way to handle
all parameters, mutable and immutable.
Really? I did not know that. Interesting.
Definitely an issue of dataclasses being special, though, and not attributable
to the
On 4/23/22 12:11, Christopher Barker wrote:
> NOTE: another key question for this proposal is how you would handle mutable
defaults -- anything
> special, or "don't do that"?
Why should they be handled at all? If the programmer writes
def __init__(a, @b, @c=[]):
pass
then all
On 4/21/22 15:12, Joao S. O. Bueno wrote:
> On Thu, Apr 21, 2022 at 5:17 PM Pablo Alcain wrote:
>> I think that discussion can probably belong to a specific thread with the
proposal with
>> your questions summary there so everyone can contribute to the
implementation that, clearly,
>> has some
On 4/21/22 10:29, Joao S. O. Bueno wrote:
> I take the freedom to interpret 'no news == good news' on this thread -
> nominally that there are no major disagreements that a decorator
> to auto-commit `__init__` atributes to the instance could be a nice addition
> to the stdlib.
I am strongly
On 4/12/22 00:57, Stephen J. Turnbull wrote:
Ethan Furman writes:
15mpg * 7l == how many miles?
Now it's my turn to not understand the point of this example.
My point is that when an object is instantiated it can normalize its arguments, and that that normalization should
happen
On 4/11/22 11:06, Chris Angelico wrote:
Steven is, as are a few who have agreed that namespaces are the One
True Way™ to do things.
That seems a grossly unfair characterization of those who don't agree with you.
I think everyone should take a break from this thread -- it is apparent that no
On 4/10/22 21:33, Stephen J. Turnbull wrote:
I guess you could call the associative law of multiplication "dumb
luck", but most mathematicians will consider that hate speech.
My apologies for not understanding your example. The counter example I had in my head, and should have written down,
On 4/10/22 14:09, Chris Angelico wrote:
On Mon, 11 Apr 2022 at 06:48, Ethan Furman wrote:
On 4/10/22 10:17, Chris Angelico wrote:
On Mon, 11 Apr 2022 at 02:59, Christopher Barker wrote:
But if I did that, then one lib registering my units with the global repository
might break some other
On 4/9/22 21:17, Stephen J. Turnbull wrote:
if 12*u.mm * 42*u.MFr == 502*u.foo:
print('Well done!')
That would work fine for me. But I can see why somebody who
frequently uses interactive Python as a scientific calculator would
prefer to write
if 12 m/s * 42 s == 502 m:
On 4/10/22 10:17, Chris Angelico wrote:
On Mon, 11 Apr 2022 at 02:59, Christopher Barker wrote:
But if I did that, then one lib registering my units with the global repository
might break some other lib's use of the global repository.
Then... libraries should not register units unless it's
On 4/6/22 08:50, Brian McCall wrote:
> Alright, now let's look at an example. Again, it's not my best, let's go with
it. This is just
> a calculation of the expected number of photons to reach a pixel through a
camera of a given
> f-number (F). I mentioned this has bitten me before. All that
On 4/4/22 13:31, David Mertz, Ph.D. wrote:
> You should probably change the thread subject to "All-and-only 7 SI units" if
that's what you mean.
While I'm sure SI would be very useful, I suspect that any system will have to be useful for a much broader audience to
be accepted; given the vast
On 4/3/22 22:39, Chris Angelico wrote:
> On Mon, 4 Apr 2022 at 14:22, Brian McCall wrote:
>> Related to these questions, there is the question of what to do about mixed
systems?
> Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should it evaluate to 1?
>
> I would say that 2.54in/1cm should be
On 4/4/22 08:54, Ken Kundert wrote:
> Now consider the issue of “unitless units”. In electrical circuit we often
talk
> about gain, which it the ratio between the signal level at the output of
> a circuit relative to the signal level at the input. But you need to be
> specific about how you
On 4/3/22 11:52, Brian McCall wrote:
> If you had asked me twenty years ago if I thought units should be a native
part of any
> programming language, I would have said absolutely - because in my youthful
ignorance
> I had no idea what it would take to make such a thing work. Five years later,
On 3/29/22 14:41, Christopher Barker wrote:
> Ethan Furman queried:
>> The `__dict__` is needed to store the field names -- did you add `__dict__`
to the
>> `__slots__`?
>
> Nope — though the error indicated that I couldn’t add anything to __slots__
when subclassing
On 3/29/22 09:57, Ricky Teachey wrote:
> On Tue, Mar 29, 2022 at 12:49 PM Ethan Furman wrote:
>> The `__dict__` is needed to store the field names -- did you add `__dict__`
to the
>> `__slots__`? (Of course, if you've added `__dict__` then you lose the
limited size
&
On 3/29/22 09:14, Christopher Barker wrote:
> [...] I tried to use __slots__ in TupleWithNames, but apparently you can't
use __slots__ in a
> tuple subclass ('cause tuple's already using it ??) -- but that could be done
in a builtin.
> then it wouldn't need a __dict__
The `__dict__` is needed
On 3/26/22 12:04, Ethan Furman wrote:
> On 3/26/22 09:57, malmiteria wrote:
>
>> The core of what i wanna discuss here is that i don't think mro and super
(mainly because it
>> relies on mro) are very pythonic. Mainly that some behaviors of the mro are
too implicit, and
>
On 3/26/22 09:57, malmiteria wrote:
> The core of what i wanna discuss here is that i don't think mro and super (mainly because it relies on mro) are very
pythonic. Mainly that some behaviors of the mro are too implicit, and are silencing what really should be errors.
When I first started
On 3/13/22 14:49, joao.p.f.batista...@gmail.com wrote:
> Currently:
> l = [] # new empty list
> t = () # new empty tuple
> s = set() # new empty set (no clean and consistent way of initializing regarding the
others) <<<
> d = {} # new empty dictionary
>
> Possible solution:
> s = {} # new empty
On 2/8/22 2:08 PM, Abdur-Rahmaan Janhangeer wrote:
> It might be true that the days of batteries included are over,
They are not. Batteries are still included in Python, and more advanced versions of built-in batteries are available
elsewhere.
--
~Ethan~
On 1/17/22 7:33 AM, John Sturdy wrote:
> One of the few things I don't like about Python is that variable scope
continues after
> the end of the suite the variable was created in --- probably because I think
of local
> variable declarations as equivalent to lambdas that are called immediately,
On 12/19/21 5:40 AM, Serhiy Storchaka wrote:
> classmethod supersedes staticmethod. It was not clearly known when they
> were introduced, but now we see that there is very few use cases for
> staticmethod which cannot be replaced by classmethod (actually only one
> specific case).
What is the
By way of correcting misconceptions:
On 12/18/21 8:39 AM, Chris Angelico wrote:
>
> I'm not sure that this is actually possible the way you're doing it.
> The descriptor protocol (which is what makes properties work) won't
> apply when you're looking up statically.
On 12/18/21 9:19 AM,
On 11/30/21 10:16 PM, Chris Angelico wrote:
> *PEP 671: Syntax for late-bound function argument defaults*
>
> Questions, for you all:
>
> 1) If this feature existed in Python 3.11 exactly as described, would
> you use it?
No.
> 2) Independently: Is the syntactic distinction between "=" and
On 11/11/21 9:35 PM, Christopher Barker wrote:
> Matt del Valle wrote:
>> So perhaps we could narrow the scope of this down to just adding snake_case
aliases to the logging and
>> unittest modules [...]
>
> The reason those are spelled that way is because they are ported from Java.
>
> And IMHO
On 11/11/21 11:53 AM, Matt del Valle wrote:
Okay, so from the replies so far it looks like this is very quickly going into
the 'never gonna happen'
dumpster, so in the interests of salvaging *something* out of it:
[...]
I just dislike having to settle for 'it's what we've got'. With these
I think what Paul is referring to is that according to PEP 8:
- functions: Function names should be lowercase, with words separated by
underscores as necessary
to improve readability.
- types: Class names should normally use the CapWords convention.
And, of course:
- Names that are visible
On 11/3/21 2:31 PM, Chris Angelico wrote:
> On Thu, Nov 4, 2021 at 5:54 AM Ethan Furman wrote:
>> On 11/3/21 12:13 AM, Chris Angelico wrote:
>>> Python has a strong policy of evaluating things immediately, or being
>>> very clear about when they will be evaluat
On 11/3/21 12:21 PM, Florian Wetschoreck wrote:
> In order to prevent confusion, I want to point out that the primary scenario
that I meant is not that the file imports
> itself but another file in the same directory with the name of a module that
is also installed in site-packages. Not
> sure
On 11/3/21 12:13 AM, Chris Angelico wrote:
> Python has a strong policy of evaluating things immediately, or being
> very clear about when they will be evaluated
Putting the marker in the middle of the name binding expression is not "very clear" -- particularly since the advice is
"ne spaces
On 11/3/21 10:35 AM, Steven D'Aprano wrote:
> I suppose that we could even add yet another overloaded meaning on the
> asterix:
>
> # with no default, * keeps the old meaning of collecting
> # extra positional values
>
> *parameter
>
> # with a default, * triggers
On 11/3/21 9:07 AM, Chris Angelico wrote:
> On Thu, Nov 4, 2021 at 2:29 AM Ethan Furman wrote:
>> One similarity that I don't think has been mentioned yet:
>>
>> - decorator syntax says, "run me later, after this function is built"
>>
>> - late-boun
One similarity that I don't think has been mentioned yet:
- decorator syntax says, "run me later, after this function is built"
- late-bound argument syntax says, "run me later, just before each function
call"
Because both mean "run me later" we can leverage the @ symbol to aid understanding;
On 10/23/21 5:13 PM, Chris Angelico wrote:
> PEP: 671
> Title: Syntax for late-bound function argument defaults
I have a major concern about the utility of this addition -- it was mentioned already (sorry, I don't remember who) and
I don't think it has yet been addressed.
Using the
On 10/26/21 12:08 PM, Ricky Teachey wrote:
> On Tue, Oct 26, 2021 at 2:40 PM Chris Angelico wrote:
>> Do you have any examples where this isn't the case?
>
> I don't. I only have a niggling feeling that maybe this is a bigger problem
than
> we're giving it credit for.
>
> At bottom I guess I'd
On 10/25/21 11:50 AM, Erik Demaine wrote:
> Here's another example where it matters whether the default expressions are
computed within their own scope:
>
> ```
> def f(x := (y := 5)):
> print(x) # 5
> print(y) # 5???
> f()
> ```
That should definitely be a SyntaxError.
--
~Ethan~
On 10/25/21 6:54 AM, Eric V. Smith wrote:
> On 10/25/2021 8:26 AM, Chris Angelico wrote:
>> If it's done with syntax, it can have special behaviour. If it looks
>> like a function call (or class constructor), it doesn't look like it
>> has special behaviour.
>
> This has been mentioned before,
On 10/24/21 11:22 PM, Steven D'Aprano wrote:
> On Sun, Oct 24, 2021 at 05:40:55PM +0100, Jonathan Fine wrote:
>> def puzzle(*, a=>b+1, b=>a+1):
>> return a, b
> We can consider that to be syntactic sugar for:
>
> def puzzle(*, a=None, b=None):
> if a is None:
>
On 10/23/21 8:04 PM, Bruce Leban wrote:
> I was talking about (2) but I should have been explicit. And yes, you
highlight a potential source of confusion.
>
> def f(x=>x + 1): ...
>
> means that x is 1 more than the value of x from the enclosing global scope
(at function call time) while
Uh,
On 10/23/21 2:23 PM, Chris Angelico wrote:
> It seems like there's broad interest in this, but a lot of details to
> nut out. I think it may be time for me to write up a full PEP. Guido,
> if I'm understanding recent SC decisions correctly, a PEP editor can
> self-sponsor, correct?
Of all
On 10/23/21 9:44 AM, Chris Angelico wrote:
> Feel free to propose an improvement to the syntax. Whatever spelling
> is ultimately used, this would still be of value.
def bisect(a, x, lo=0, hi?=len(a)):
--
~Ethan~
___
Python-ideas mailing list --
On 10/23/21 9:07 AM, Chris Angelico wrote:
> Proposal: Proper syntax and support for late-bound argument defaults.
I like the proposal.
> def spaminate(thing, count=:thing.getdefault()):
> ...
>
> def bisect(a, x, lo=0, hi=:len(a)):
> if lo < 0:
> raise ValueError('lo must
On 10/18/21 3:20 AM, Mathew Elman wrote:
> I don't know if this has been suggested before, or if this is outlandishly
impossible
> (though I would be surprised if it was), so apologies in advance if so.
>
> I have on occasion come across a situation where I use/write a signature like
this:
>
>
On 10/18/21 6:29 AM, Mathew Elman wrote:
>> What you are describing is very, very dissimilar to currying. It's simply
multi-argument
> functions with a different call syntax.
>
> It is almost identical to currying, the only differences are:
> 1. the intermediate return being an object with an
On 10/18/21 6:23 AM, Mathew Elman wrote:
> When learning python, and even sometimes now, I have had to look at the implementation of a function in order to
recall which order arguments should go.
Seems like the docs should cover that (or even `help()`) -- and if not, then
the parameter names
-Modified: $Date$
Author: Ethan Furman
Discussions-To: python-...@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post-History: 20-Jul-2021 10-Sep-2021
Resolution:
Abstract
Now that we have a few years experience with Enum
On 9/10/21 4:19 AM, matt...@matthewstocks.co.uk wrote:
> My proposal is that iterating through a member of a Flag enum will return all
the constituent members.
It's a good proposal, and is already in 3.11. If you want the functionality
now you can use the aenum [0] library.
--
~Ethan~
[0]
On 8/24/21 10:26 PM, Guido van Rossum wrote:
> On Tue, Aug 24, 2021 at 22:19 Christopher Barker wrote:
>> On Tue, Aug 24, 2021 at 9:58 PM David Mertz, Ph.D. wrote:
>>> Sorry, I should have been more explicit. The several kinds of queues can all
>>> "contain" items, but do not respond to len().
On 8/24/21 4:35 PM, Cameron Simpson wrote:
> If we're chasing rough edges, consider queue.Queue:
>
> >>> from queue import Queue
> >>> Q = Queue()
> >>> Q.empty()
> True
> >>> if Q: print("Q is true")
> ...
> Q is true
>
> I would often like to treat Queues as a
On 8/24/21 3:03 PM, Tim Hoffmann via Python-ideas wrote:
> **How do you check if a container is empty?**
>
> IMHO the answer should not depend on the container.
I think this is the fly in the ointment -- just about everything, from len() to bool(), to add, to iter() /all/ depend
on the
On 8/23/21 2:31 PM, Tim Hoffmann via Python-ideas wrote:
> Ethan Furman wrote:
>> It seems to me that the appropriate fix is for numpy to have an "is_empty()"
function
>> that knows how to deal with arrays and array-like structures, not force
every container
>>
On 8/23/21 2:06 PM, Tim Hoffmann via Python-ideas wrote:
> On a technical level, everything can be solved with the current language
capabilities. The
> main advantage is clearer semantics (explicit is better / readability counts)
Note the explicit and readability are often at odds with each
On 8/23/21 1:15 PM, Tim Hoffmann via Python-ideas wrote:
> If you want to write a function that accepts array-like `values`, you have to
change
> a check `if values` to `if len(values) == 0`. That works for both but is
against the
> PEP8 recommendation. This is a shortcoming of the language.
PEP: 663
Title: Improving and Standardizing Enum str(), repr(), and format() behaviors
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Discussions-To: python-...@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 23-Feb-2013
Python-Version: 3.11
Post
On 7/13/21 2:20 PM, Thomas Grainger wrote:
> On Tue, 13 Jul 2021, 21:31 Ethan Furman, wrote:
>> On 7/13/21 12:43 PM, Thomas Grainger wrote:
>>> I used the order I did because it's idiomatic to return the value the user
needs
>>> followed by the value the user want
On 7/13/21 12:43 PM, Thomas Grainger wrote:
> I used the order I did because it's idiomatic to return the value the user
needs
> followed by the value the user wants.
citation?
--
~Ethan~
___
Python-ideas mailing list -- python-ideas@python.org
To
On 6/26/21 1:55 PM, Marc-Andre Lemburg wrote:
> On 26.06.2021 21:32, Ethan Furman wrote:
>> In most cases I would agree with you, but in this case the object is security
>> sensitive, and security should be much more rigorous in ensuring correctness.
>
> Isn't this more a
[oops, hit Send too soon]
On 6/25/21 5:20 PM, Eric V. Smith wrote:
> It seems like many of the suggestions are SSLContext specific. I don't think
we should be adding
> __slots__ or otherwise redefining the interface to that object. Isn't this a general
"problem" in
> python...
In most cases
On 6/25/21 5:20 PM, Eric V. Smith wrote:
> It seems like many of the suggestions are SSLContext specific. I don't think
we should be adding
> __slots__ or otherwise redefining the interface to that object. Isn't this a general
"problem" in
> python...
Greetings!
The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements
into a decorator instead, and I'm having a hard time thinking up a name.
What is the behavior? Well, a name in a flag type can be either canonical (it represents
On 5/25/21 8:33 AM, Damian Shaw wrote:
> On Tue, May 25, 2021 at 11:02 AM Ethan Furman wrote:
>> On 5/25/21 5:23 AM, Chris Angelico wrote:
>>> On Tue, May 25, 2021 at 9:55 PM Shreyan Avigyan wrote:
>>>> The proposed syntax is as follows,
>>>>
>
On 5/25/21 5:23 AM, Chris Angelico wrote:
> On Tue, May 25, 2021 at 9:55 PM Shreyan Avigyan wrote:
>> The proposed syntax is as follows,
>>
>> constant x = 10
>> constant y = ["List"]
>> constant z: str = "Hi"
>
> https://docs.python.org/3/library/typing.html#typing.Final
>
> Already exists :)
On 5/24/21 6:36 PM, micro codery wrote:
> Variable decorators have been suggested here before, as have new statements
> that could also achieve the same level of access to the binding name. However
> I propose a much more restricted syntax that would make for less edge cases
> where what is
On 5/14/21 2:34 PM, Eric V. Smith wrote:
> My understanding of the proposal is that OP is only talking about
/ becomes a
> Fraction. So:
>
> x=1
> x/2 # unchanged, still yields a float.
>
> It's only literals like "1/2" that would become Fraction(1,2).
Ah -- which means we end up with
On 5/14/21 5:12 AM, Martin Teichmann wrote:
> In order to showcase how that would look like, let me give an example session:
>
> >>> 5/6-4/15
> 17/30
> >>> a=22/7
> >>> f"{a}"
> '22/7'
> >>> f"{a:f}"
> '3.142857'
> >>> from decimal import Decimal
>
On 5/14/21 1:07 PM, Paul Moore wrote:
> All I'm trying to say is "I think that having 1/2
> mean something different than 1 / 2 is unacceptable, because it's too
> easy for people to misunderstand".
Agreed. Significant white space for control flow is great; for specifying data
types it's
On 5/6/21 10:44 PM, Shreyan Avigyan wrote:
> Anyway this thread is closed.
As you may have noticed, this is a mailing list -- no thread is closed. I've
seen posts to three-year-old threads.
--
~Ethan~
___
Python-ideas mailing list --
On 5/6/21 6:26 AM, Shreyan Avigyan wrote:
> Chris wrote:
>> Please actually quote some text so we know who you're responding to,
>> what you're talking about, etc.
>
> I'm actually telling to read my comment here
On 4/9/21 11:33 AM, anthony.flury via Python-ideas wrote:
On 09/04/2021 19:02, Guido van Rossum wrote:
But if there are two proposals with conflicting semantics for the same syntax that kills both ideas, doesn’t it?
Because apparently it’s not clear what the syntax should mean.
Surely it
On 4/8/21 2:40 PM, Chris Angelico wrote:
At least in this form, it's clear that there's a sharp distinction
between the stuff around the outside of the 'with' block and the stuff
inside it.
The semantics, as suggested, give 'with' blocks two distinct
exception-management scopes, which mostly
On 4/8/21 1:21 PM, Chris Angelico wrote:
On Fri, Apr 9, 2021 at 6:16 AM Ethan Furman wrote:
On 4/8/21 11:25 AM, Chris Angelico wrote:
Similar question: What would be the semantics of this?
with contextlib.suppress(BaseException):
a = b / c
except BaseException as e:
print(e
On 4/8/21 11:25 AM, Chris Angelico wrote:
Similar question: What would be the semantics of this?
with contextlib.suppress(BaseException):
a = b / c
except BaseException as e:
print(e)
What types of exception could be caught and what types couldn't?
Well, if every exception is
On 3/16/21 1:19 PM, Brendan Barnwell wrote:
On 2021-03-16 06:20, Eric V. Smith wrote:
I'd like to avoid field() as much as possible. I think it's just too
easy to miss what it's doing, since it has many arguments. And I'd like
to make it easy to have a style that encourages all
On 3/16/21 11:43 AM, Matt Wozniski wrote:
On Tue, Mar 16, 2021, 2:39 PM Marco Sulla wrote:
On Tue, 16 Mar 2021 at 05:38, Matt Wozniski wrote:
Color.from_value(1) # returns Color.RED
What if I have an alias?
Aliases are different names for a single Enum member, so a by-value search is
On 3/15/21 11:27 AM, Guido van Rossum wrote:
On Mon, Mar 15, 2021 at 10:53 AM Ethan Furman wrote:
Part of the reason is that there are really two ways to identify an
enum -- by name, and by value -- which should `__contains__` work with?
The two sets don't overlap, so we could allow both
On 3/12/21 5:28 PM, Guido van Rossum wrote:
On Fri, Mar 12, 2021 at 1:52 PM Ethan Furman wrote:
A question that comes up quite a bit on Stackoverflow is how to test
to see if a value will result in an Enum member, preferably without
having to go through the whole try/except machinery
On 3/14/21 12:42 PM, Stestagg wrote:
The value of being able to (in specific cases) reach into third-party code, and
customize it to work for your specific situation should not be disregarded.
I completely agree with this. One of the hallmarks of Python is the ability to
query, introspect,
On 3/12/21 2:49 PM, Ricky Teachey wrote:
On Fri, Mar 12, 2021 at 4:52 PM Ethan Furman wrote:
A question that comes up quite a bit on Stackoverflow is how to test
to see if a value will result in an Enum member, preferably without
having to go through the whole try/except machinery.
Could
A question that comes up quite a bit on Stackoverflow is how to test to see if
a value will result in an Enum member, preferably without having to go through
the whole try/except machinery.
A couple versions ago one could use a containment check:
if 1 in Color:
but than was removed as
On 3/12/21 9:04 AM, Henk-Jaap Wagenaar wrote:
(
Q(user=user) |
Q(is_deleted=True) |
)
I am happy to flesh this out more, but as this discussion was ongoing, I
thought I would throw it out here and see what people think? Are there
potential problems with this e.g. with parsing it?
On 3/12/21 7:50 AM, Paul Bryan wrote:
My inclination would be to cede code formatting to a tool like Black and focus
on function:
https://black.readthedocs.io/en/stable/
We still have to read it after Black munges it.
Like Paul said, add parentheses -- it works for method chaining, string
On 3/11/21 10:50 AM, Paul Bryan wrote:
On Thu, 2021-03-11 at 10:45 -0800, Ethan Furman wrote:
On 3/10/21 9:47 PM, Eric V. Smith wrote:
I'm not sure of the best way to achieve this. Using flags to field()
doesn't sound awesome, but could be made to work. Or maybe special
field names or types
On 3/10/21 9:47 PM, Eric V. Smith wrote:
I'm not sure of the best way to achieve this. Using flags to field() doesn't
sound awesome, but could be made to work. Or maybe special field names or
types? I'm not crazy about that, but using special types would let you do
something like:
On 3/11/21 4:20 AM, Ricky Teachey wrote:
This might be a bit of an extreme step to take, but has new syntax for this
ever been discussed? Here I am using the same indicator for keyword arguments
as in a function signature, hanging on a line by itself:
@dataclasses.dataclass
class Comparator:
1 - 100 of 373 matches
Mail list logo
