Re: [Python-ideas] ImportError raised for a circular import

I've also been thinking about this lately. I can remember being confused the first time I saw "ImportError: cannot import name X". As there are multiple things that can cause this error, it took me a while to find a stackoverflow post that suggested that this might be due to circular imports. After

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

.getpreferredencoding(False) to retain the old behavior, suppressing the deprecation warning. And perhaps we could make a shortcut for that, like encoding="locale". ~Matt ___ Python-ideas mailing list -- [email protected] To unsubscribe

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

On Sat, Jan 23, 2021 at 10:51 PM Chris Angelico wrote: > On Sun, Jan 24, 2021 at 2:46 PM Matt Wozniski wrote: > > 2. At the same time as the deprecation is announced, introduce a new > __future__ import named "utf8_open" or something like that, to opt into the >

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

de what encoding to decode it as; that would be backwards incompatible, and it might block forever if the sender only sends one character before waiting for a response. ~Matt ___ Python-ideas mailing list -- [email protected] To unsubscribe send an e

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

On Mon, Jan 25, 2021, 4:25 AM Steven D'Aprano wrote: > On Sun, Jan 24, 2021 at 10:43:54PM -0500, Matt Wozniski wrote: > > And > > `f.read(1)` needs to pick one of those and return it immediately. It > can't > > wait for more information. The contract of

[Python-ideas] Re: Adding `open_text()` builtin function. (relating to PEP 597)

thout an explicit encoding when the system locale is not UTF-8, and that warning can say something like: Your system is currently configured to use shift_jis for text files. Beginning in Python 3.13, open() will always use utf-8 for text files instead. For compatibility with

[Python-ideas] Implicit line continuation for method chaining

.split(":")[0] .lower() i.e., not requiring an explicit line continuation character in the case where the next line starts with a period. I've had a search through the archives and I couldn't see this discussion before. Feel free to point me to it if I've miss

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

On Fri, Mar 12, 2021, 11:55 PM Eric V. Smith wrote: > I should mention another idea that showed up on python-ideas, at > > https://mail.python.org/archives/list/[email protected]/message/WBL4X46QG2HY5ZQWYVX4MXG5LK7QXBWB/ > . It would allow you to specify the flag via code like: > > @datacla

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

nal-only, since they don't become part of the class's public API, but in that case it seems it could just be a flag passed to `InitVar`. Outside of init-only variables, positional-only arguments seem like a misfeature to me. ~Matt > _

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

ional, > normal, keyword-only. > > Eric > > > Abdulla > > Sent from my iPhone > > On 13 Mar 2021, at 9:30 PM, Paul Bryan > wrote: > >  > +1 to Matt's points here. I get the desire for symmetry with / and * in > params, but I'm not convinced

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

sadvantage of allowing positional-only arguments. If positional-only fields show up just like keyword fields in an arbitrary position in the repr, the repr will cease to be a representation of a call to the dataclass's constructor suitable for passing to `eval`, as it

[Python-ideas] Re: Enum: determining if a value is valid

thods that each have fairly unsurprising semantics. ~Matt On Mon, Mar 15, 2021 at 3:55 PM Guido van Rossum wrote: > +1 > > On Mon, Mar 15, 2021 at 12:48 PM Ethan Furman wrote: > >> On 3/15/21 11:27 AM, Guido van Rossum wrote: >> > On Mon, Mar 15, 2021 at 10:53 AM Ethan F

[Python-ideas] Re: Enum: determining if a value is valid

16 Mar 2021 at 05:38, Matt Wozniski wrote: > > Color.from_value(1) # returns Color.RED > > What if I have an alias? > ___ > Python-ideas mailing list -- [email protected] > To unsubscribe send an email to python-ideas-le.

[Python-ideas] Re: Enhancing iterator objects with map, filter, reduce methods

In your comprehension example, I'm fairly certain the filtering should be on the post incremented remainder [ x+1 for x in [1,2,3] if (x+1) % 2 == 0] I think that is the downside of the comprehension, having to repeat that twice. Maybe you can get around it with := ?? I'm stuck on 3.7 so I don'

[Python-ideas] Re: List comprehension operators

Seems like a lot of work to just make list(range(1,100)) Insignificantly easier to write ___ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python

[Python-ideas] Global flag for whether a module is __main__

Currently, the simplest and most idiomatic way to check whether a module was run as a script rather than imported is: if __name__ == "__main__": People generally learn this by rote memorization, because users often want the ability to add testing code or command line interfaces to their modul

[Python-ideas] Re: Global flag for whether a module is __main__

> Also see PEP 299 for a slightly different approach. Indeed. This proposal is more limited in scope than PEP 299, and appears better from a backwards compatibility perspective. > there's going to be two ways to spell the exact same thing. Both are > still going to have to be memorized Sure - th

[Python-ideas] Re: pathlib enhancements

> 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 "FileNotFoundError" is raised. For Path.mkdir, exist_ok=True inhi

Re: [Python-ideas] Shuffled

t this behavior for "sorted"? That makes no sense at >>> all. >>> >> Of course it does. The only analogy to random.shuffle(big_list) >> returning None that makes a lick of sense here is that big_list.sort() >> also returns None. IF a `shuffled()` functi

Re: [Python-ideas] Python multi-dimensional array constructor

d supplement the existing approach， it > doesn't replace it. np.ndarray() would stay around just like list() stays > around for cases where it makes sense. > > > ___ > Python-ideas mailing list > [email protected] >

Re: [Python-ideas] Null coalescing operator

ve done otherwise. > > What needs to be decided is whether such use cases are frequent > enough to justify special syntax. > > -- > Greg > > ___ > Python-ideas mailing list > [email protected] > https://mail.python.org/mai

Re: [Python-ideas] Enhancing vars()

> It also refers to local and global variables, as vars() is effectively > an alias for locals() if you don't pass an argument, and locals() is > effectively an alias for globals() at module level: > > https://www.getpattern.com/meetpattern> to sign up! __

Re: [Python-ideas] incremental hashing in __hash__

behaves like a classmethod when called from the class, and like >> an instance method when called from an instance); >> >> * changing tuple.__hash__ from an ordinary method to one of the >> above special methods; >> >> * and likewise for frozenset.__

Re: [Python-ideas] incremental hashing in __hash__

gt; ___ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- [image: p

Re: [Python-ideas] Fwd: Define a method or function attributeoutsideof a class with the dot operator

_ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- [image: pattern-sig.png] Matt Gilson // SOFTWARE ENGINEER E: m..

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

t;>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> ___ >> Python-ideas mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of

Re: [Python-ideas] For/in/as syntax

so I couldn't > yet > think about the implications of such a new syntax to this (and what > about a > lazy keyword in here?) > - I suppose it's a huge work to create such a syntax. And I have no idea > how > complicated it could be to create methods (like break() and c

Re: [Python-ideas] get() method for list and tuples

On Fri, Mar 3, 2017 at 1:35 PM, Michel Desmoulin wrote: > > > Le 03/03/2017 à 22:21, Chris Barker a écrit : > > On Fri, Mar 3, 2017 at 12:21 PM, Sven R. Kunze > > wrote: > > > >> For my part, I think casting a list to a dict is often the RIGHT > >> way to address

Re: [Python-ideas] Augmented assignment syntax for objects.

ls really unexpected to all of a sudden give my tuple a temporary name and have the code behave in a dramatically different fashion. > > ___ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python

Re: [Python-ideas] dict(default=int)

gt;> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R(206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-63

Re: [Python-ideas] Dictionary destructing and unpacking.

7;, 'b', 100) > >>> a, b, c > (1, None, 'Foo') > > > E. > ___ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http:

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

I have been struggling to justify the need based on what I have read. I hope this isn't a dupe, I only saw caching mentioned in passing. Also please excuse some of the naive generalizations below for illustrative purposes. Is there a reason memoization doesn't work? If f is truly expensive, usin

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

t don't understand! On Wed, Feb 28, 2018 at 12:37 AM, Chris Angelico wrote: > On Wed, Feb 28, 2018 at 6:46 PM, Matt Arcidy wrote: >> I have been struggling to justify the need based on what I have read. I >> hope this isn't a dupe, I only saw caching mentioned in passi

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

-0 unless archived appropriately. List is the standard for decades. but I guess things change and I get old. On Wed, Feb 28, 2018, 13:49 Robert Vanden Eynde wrote: > We are currently like a dozen of people talking about multiple sections of > a single subject. > > Isn't it easier to talk on a

Re: [Python-ideas] Medium for discussion potential changes to python (was: PEP 572: Statement-Local Name Bindings)

if Linux kernel can handle it, there is no argument for it being factually superior or inferior. It is only preference. There is nothing stopping a forum link being created and posted to the list as an alternative right now. The result of that experiment would be the answer. On Wed, Feb 28, 201

Re: [Python-ideas] Descouraging the implicit string concatenation

ation can be extracted at the right time. I hope this helps in some way. I don't think it's impossible, but the above will introduce annoying bits into existing linters for this one issue. Of course, a working example would certainly make any case a lot easier. Given there is n

Re: [Python-ideas] Sublocal scoping at its simplest

On Sat, Apr 28, 2018, 20:16 Chris Angelico wrote: > There's been a lot of talk about sublocal scopes, within and without > the context of PEP 572. I'd like to propose what I believe is the > simplest form of sublocal scopes, and use it to simplify one specific > special case in Python. > > There

[Python-ideas] Objectively Quantifying Readability

ating factor of sending this email today. I think using python implicitly accepts readability being partially measurable, even if the resolution of current measure is too low to capture the changes currently being discussed. Perhaps using this criteria can incr

Re: [Python-ideas] Objectively Quantifying Readability

On Mon, Apr 30, 2018 at 5:42 PM, Steven D'Aprano wrote: > On Mon, Apr 30, 2018 at 11:28:17AM -0700, Matt Arcidy wrote: > >> A study has been done regarding readability in code which may serve as >> insight into this issue. Please see page 8, fig 9 for a nice chart of &

Re: [Python-ideas] Objectively Quantifying Readability

On Tue, May 1, 2018 at 1:29 AM, Nathaniel Smith wrote: > On Mon, Apr 30, 2018 at 8:46 PM, Matt Arcidy wrote: >> On Mon, Apr 30, 2018 at 5:42 PM, Steven D'Aprano wrote: >>> (If we know that, let's say, really_long_descriptive_identifier_names >>> hurt rea

Re: [Python-ideas] Objectively Quantifying Readability

:). I am really interested in these factors in general, however. Now I'm surprised no one asks which font each other are using when determining readability. "serif? are you mad? no wonder!" "+1 on PEP conditional on mandatory yellow (#FFEF00) k

Re: [Python-ideas] Inline assignments using "given" clauses

On Fri, May 4, 2018, 11:35 Guido van Rossum wrote: > On Fri, May 4, 2018 at 11:11 AM, Tim Peters wrote: > >> [Nick Coghlan ] >> > ... >> > Using a new keyword (rather than a symbol) would make the new construct >> > easier to identify and search for, but also comes with all the >> downsides of >

Re: [Python-ideas] A comprehension scope issue in PEP 572

> Personally, I'd still like to go back to := creating a statement-local > name, one that won't leak out of ANY statement. But the tide was > against that one, so I gave up on it. yes. I have some probably tangential to bad arguments but I'm going to make them anyways, because I think := makes th

Re: [Python-ideas] A comprehension scope issue in PEP 572

On Sun, May 6, 2018 at 7:37 PM, Matt Arcidy wrote: >> Personally, I'd still like to go back to := creating a statement-local >> name, one that won't leak out of ANY statement. But the tide was >> against that one, so I gave up on it. > > yes. > > I have s

Re: [Python-ideas] Inline assignments using "given" clauses

Apology for top post, but this is a general statement about Readability and not a response to an individual. it would be nice to list the objective parts separate from the "argument" (i.e. debate, not fight), perhaps list them then make a case for which metric is a more important, and which values

Re: [Python-ideas] Inline assignments using "given" clauses

On Fri, May 11, 2018, 17:04 Tim Peters wrote: > [Matt Arcidy] > >> Note Tim came up with a real metric: > >> 2 * count(":=")/len(statement). > >> It's objective. it's just unclear if a higher score is better or worse. > >> Howev

Re: [Python-ideas] Inline assignments using "given" clauses

On Sun, May 13, 2018, 11:28 Brendan Barnwell wrote: > On 2018-05-13 04:23, Steven D'Aprano wrote: > > In my experience mathematicians put the given *before* the statement: > > > > Given a, b, c three sides of a triangle, then > > > > Area = sqrt(s*(s-a)*(s-b)*(s-c)) > > > > where

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

On Sat, May 19, 2018, 11:07 Kirill Balunov wrote: > > > I think I have a very strong argument "why are not others valid" - Because > already three months have passed and among 1300+ messages there was not a > single real example where assignment expression would be convenient or > useful outside

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

Anyone can trivially construct a scope that limits applicable cases to support a specific point. This thread is pointless without full context. On Sun, May 20, 2018, 11:05 Mike Miller wrote: > For more background, this is the thread that inspired this one: > > https://mail.python.org/piper

Re: [Python-ideas] Modern language design survey for "assign and compare" statements

On Mon, May 21, 2018, 03:58 Rhodri James wrote: > On 20/05/18 06:19, Matt Arcidy wrote: > > On Sat, May 19, 2018, 11:07 Kirill Balunov > wrote: > > > >> > >> > >> I think I have a very strong argument "why are not others valid" - > Be

Re: [Python-ideas] Reuse "for" to express "given"

On Thu, May 24, 2018, 11:47 Alexander Belopolsky < [email protected]> wrote: > > But I do have a mathematics background, and I don't remember ever seeing > > "for x = value" used in the sense you mean. > > That's so because in mathematics, "for" is spelled ":" as in > > {2*a* : *a*∈*

Re: [Python-ideas] Reuse "for" to express "given"

On Thu, May 24, 2018, 14:48 Alexander Belopolsky < [email protected]> wrote: > > > On Thu, May 24, 2018 at 4:59 PM Matt Arcidy wrote: > >> >> >> On Thu, May 24, 2018, 11:47 Alexander Belopolsky < >> [email protected]

Re: [Python-ideas] Fwd: Trigonometry in degrees

Sorry for top posting, but these aren't really opinions for the debate, just information. I haven't seen them mentioned, and none grouped nicely under someone's reply. Number representation:: IEEE-754 doubles cannot represent pi correctly at any bit-depth (i mean, obviously, but more seriously).

Re: [Python-ideas] Link accepted PEPs to their whatsnew section?

On Wed, Jun 13, 2018, 06:51 Nick Coghlan wrote: > On 13 June 2018 at 11:06, Michael Selik wrote: > >> Google will probably fix this problem for you after dataclasses become >> popular. The docs will gain a bunch of inbound links and the issue will >> (probably) solve itself as time passes. >> >

Re: [Python-ideas] Fwd: Trigonometry in degrees

On Mon, Jun 18, 2018, 19:25 Chris Barker via Python-ideas < [email protected]> wrote: > On Sat, Jun 16, 2018 at 10:57 PM, Tim Peters wrote: > > Ya, decimal fp doesn't really solve anything except the shallow surprise >> that decimal fractions generally aren't exactly representable as binary

Re: [Python-ideas] Add a __cite__ method for scientific packages

On Fri, Jun 29, 2018, 17:14 Andrei Kucharavy wrote: > One more thing. There's precedent for this: when you start an interactive >> Python interpreter it tells you how to get help, but also how to get >> copyright, credits and license information: >> >> $ python3 >> Python 3.6.6 (v3.6.6:4cf1f54eb7

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

to finally happen for real. The import of *SomeClass* on line 3 *still* hasn't actually happened, and may never happen if *SomeClass* isn't imported (or lazy imported and then used) during the lifetime of this program. On Fri, Feb 5, 2021 at 12:34 PM Matt del Valle wrote: > I ha

[Python-ideas] Add lazy import statement to protect legitimate circular imports from failing

I have seen a lot of interest in this topic, and I think the sheer number of different lazy import implementations (generally using proxy objects for modules and then loading them when an attribute is accessed) should present pretty good evidence that this is a very desired feature, particularly fo

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

021 at 12:39 PM Matt del Valle wrote: > Whoops, sorry. I just realized that I mistyped the third paragraph from > the bottom, it should be: > > > from some_library import AnotherClass # this causes * AnotherClass * to > be imported from some_library/__init__.py which in turn causes

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

In response to Eric V. Smith, if something like what you're suggesting were to be implemented I would much rather it be done with context managers than special values, because otherwise you once again end up in a situation where it's impossible to easily subclass a dataclass (which was one of the

[Python-ideas] Re: Add lazy import statement to protect legitimate circular imports from failing

he normal 'import x' statement wouldn't be enough, and 'from x import y' would be needed. On Fri, Feb 5, 2021 at 2:13 PM Chris Angelico wrote: > On Sat, Feb 6, 2021 at 12:51 AM Matt del Valle > wrote: > > > > Unfortunately, [lazy importers are] fundame

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

Disclaimer: I posted this earlier today but I think due to some first-post moderation related issues (that I've hopefully now gotten sorted out!) it may not have gone through. I'm posting this again just in case. If it's gone through and you've already seen it then I'm super sorry, please just igno

[Python-ideas] Re: Dataclasses, keyword args, and inheritance

defined) > dataclass, and to capture the attributes that are being defined within. > > > On Thu, 2021-03-11 at 22:53 +, Matt del Valle wrote: > > Disclaimer: I posted this earlier today but I think due to some first-post > moderation related issues (that I've hopefu

[Python-ideas] Re: dataclasses: position-only and keyword-only fields

rs or with nested classes like Matt Woznisky suggested (because I think this makes it more explicit and and less surprising to someone seeing it for the first time). But that's not a hill I'd even remotely consider dying on. As long as we get: 1) positional-only and keyword-only arguments f

[Python-ideas] Re: Adding syntax for the empty set

Oh god, Stephane, you're giving me flashbacks to PEP 3117 ( https://www.python.org/dev/peps/pep-3117/). But not in a good way. Please pretty please let's keep unicode characters out of our code. With regards to the original proposal, for what it's worth, I like it well enough. I think sets are th

[Python-ideas] Re: Adding syntax for the empty set

represents an empty version of themselves, except for set. It's not really much of an argument, but I figured I'd mention it. On Fri, Apr 9, 2021 at 1:23 PM Serhiy Storchaka wrote: > 09.04.21 12:50, Matt del Valle пише: > > I think sets are the only type in the builtins m

[Python-ideas] Namespaces!

Hi all! So this is a proposal for a new soft language keyword: namespace I started writing this up a few hours ago and then realized as it was starting to get away from me that there was no way this was going to be even remotely readable in email format, so I created a repo for it instead and wi

[Python-ideas] Re: Namespaces!

l proposal first :) On Sun, May 2, 2021 at 1:25 AM David Mertz wrote: > So this is exactly the same as `types.SimpleNamespace`, but with special > syntax?! > > On Sat, May 1, 2021, 7:57 PM Matt del Valle wrote: > >> Hi all! >> >> So this is a proposal for a new soft language

[Python-ideas] Re: Namespaces!

ds the attribute lookup on to the Wrapped class (while prepending itself to the dict lookup). Does that make sense? On Sun, May 2, 2021 at 10:30 AM Stestagg wrote: > > > On Sun, 2 May 2021 at 00:57, Matt del Valle wrote: > >> Hi all! >> >> So this is a proposal for a ne

[Python-ideas] Re: Namespaces!

r the next lookup return wrap(value) On Sun, May 2, 2021 at 10:45 AM Matt del Valle wrote: > This shouldn't be a problem. > > For instance: > > class Wrapped: > namespace foo: > bar = True > > facade = proxy(Wrapped()) > facade.foo.bar # Tru

[Python-ideas] Re: Namespaces!

ps://github.com/matthewgdv/namespace On Mon, May 3, 2021 at 1:25 PM Calvin Spealman wrote: > OK, tell me what this does. > > namespace A: > namespace B: > foo = bar > > On Sat, May 1, 2021 at 7:55 PM Matt del Valle > wrote: > >> Hi all! >> >> So th

[Python-ideas] Re: Namespaces!

@Paul Bryan, I'll try to address your questions one-by-one 1. It seems that I could get close to what you're aiming for by just using > underscores in names, and grouping them together in the class definition. > Is there any advantage to declaring methods in a namespace beyond > indentation and th

[Python-ideas] Re: Namespaces!

> > I don't pretend to fully understand the proposal and how it would be > implemented, but IMO adding an overhead (not to mention more complicated > semantics) to *every* chained attribute lookup... It's a good thing that isn't the case then :p Sorry, couldn't resist that quip. But more serious

[Python-ideas] Re: Namespaces!

arent scope rather than 'owning' the attributes itself). It doesn't require any special-cased semantics. Can I just say that referencing `vars(sys.modules[__name__])` *really* > works against the clarity of your examples? > > Are there situations where that couldn't

[Python-ideas] Re: Namespaces!

#x27;Shop.spam'] exists! Sorry Steven! I totally misunderstood your example. It was a really good point. Thanks :) On Wed, May 5, 2021 at 12:06 PM Paul Moore wrote: > On Wed, 5 May 2021 at 11:33, Matt del Valle wrote: > > >> To give an example: > >> &g

[Python-ideas] Re: Bring back PEP 501

Yeah, huge +1 on this. A previous workplace of mine used C# and while I always sorely missed the ORMs available in Python (nothing in the C# ecosystem even *remotely* compares to sqlalchemy, not even LINQ to SQL), their FormattableString class always made me vaguely jealous when working with datab

[Python-ideas] Re: Fractions vs. floats - let's have the cake and eat it

Fully agreed on the sentiment that we shouldn't treat compile-time literals differently from runtime operations. It has no precedent in Python and adds a significant mental burden to keep track of. I can only imagine the deluge StackOverflow threads from surprised users if this were to be done. Th

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

I'm still digesting this proposal (though I think I like it quite a bit), but there's one thing in particular that just really doesn't gel with me. Is there any particular reason why you've proposed assignment decorators as being on the same line as the assignment statement rather than on the prec

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

> > What happens if the decorator factory has `__decoration_call__` and the > object it returns only has `__call__`? I presume you get this: > > func = decorator.__decoration_call__("spam this", > "func").__call__(func) > > And let's not forget the other two combinations: > > func = decorat

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

@decorator var: bool = True And even a bare type-hint version: @decorator var: bool seem to me to be far more self-evidently useful. On Thu, May 27, 2021 at 5:45 PM Ricky Teachey wrote: > On Thu, May 27, 2021 at 11:09 AM Matt del Valle > wrote: > >> >>> I'm not the OP

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

ill potential use-cases for it. I'll concede that there are also use-cases for decorating a completely naked name, but none of the ones I've seen so far seem to me compelling enough to break the rules like this. On Thu, May 27, 2021 at 8:43 PM Ricky Teachey wrote: > Whoops

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

> > I just thought it looked better, but would you and others here like it > better if the > NEWLINE requirement was kept for all decorators? There is nothing in the > original > proposal that requires a single line. > I also don't know what should happen for complicated assignments, and I > think

[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()

Interpolation templates were recently brought up here ( https://mail.python.org/archives/list/[email protected]/thread/5AW73ICBD4CVCRUNISRNAERPPF2KSOGZ/), and Guido mentioned that in his opinion the SC would be unlikely to reconsider PEP 501 in its current state. I trust that he has a much be

[Python-ideas] Reusing more builtins for type-hinting

In the spirit of 3.9 allowing builtin collections like `list`, `dict`, `tuple`, and `set` to be subscripted for type-hinting to remove the need for importing their equivalents from `typing`, I'd like to propose the same thing for a few other builtin objects, namely: `type` (for use instead of`typi

[Python-ideas] Re: Reusing more builtins for type-hinting

here are people far more qualified than me to discuss implementation details. If not then it's irrelevant anyway. On Fri, Oct 1, 2021 at 2:15 PM Ricky Teachey wrote: > On Fri, Oct 1, 2021 at 8:02 AM Matt del Valle > wrote: > >> In the spirit of 3.9 allowing builtin collections

[Python-ideas] Re: Real Positional Arguments or OO Currying

I think what's being discussed in this thread is variations on the fluent interface design pattern (https://en.wikipedia.org/wiki/Fluent_interface). Personally, I've found myself reaching for it several times in library code I've written where it makes sense. For example, I've written a set of gma

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

Agreed on the point about PEP 661, if this is accepted I don't think it will have much to offer. For what it's worth I'm a very strong +1 on PEP 671 as it stands. Thanks for showing me something I didn't even know I wanted Chris :) I'll confess though I'm not a fan of any of the alternate syntaxe

[Python-ideas] Adding pep8-casing-compliant aliases for the entire stdlib

So I was reading the docs for the `threading` module and I stumbled upon this little note: Note: In the Python 2.x series, this module contained camelCase names for some methods and functions. These are deprecated as of Python 3.10, but they are still supported for compatibility with Python 2.5 a

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

ight thank us :p I do concede that some awkward shadowing edge-cases are the strongest argument against this proposal. I personally don't think they're that strong of an argument compared to the eventual payoff, but that's just my subjective opinion. On Thu, Nov 11, 2021 at 2:11 P

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

osophical advantage, as you're suggesting. But at this stage I'm not so naive as to think this is a battle I can win, so could we refocus the discussion on the new scope which is: - Add pep8-compliant aliases for camelCased public-facing names in the stdlib (such as logging and unitt

[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib

) On Thu, Nov 11, 2021 at 7:53 PM Guido van Rossum wrote: > One thought: No. > > On Thu, Nov 11, 2021 at 05:41 Matt del Valle wrote: > >> So I was reading the docs for the `threading` module and I stumbled upon >> this little note: >> >> Note: >> >> I

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

> > 1) If this feature existed in Python 3.11 exactly as described, would > you use it? > Absolutely! > 2) Independently: Is the syntactic distinction between "=" and "=>" a > cognitive burden? > Nope, I don't think this is an undue cognitive burden. If anything I think the symmetry between the

[Python-ideas] Re: Applications user/system directories functions

There is appdirs which does precisely what you're looking for: https://pypi.org/project/appdirs/ That said, it does seem to be a core bit of functionality that would be nice to have in the os and pathlib modules without needing an external dependency. I'm not going to weigh in on the pros/cons of

[Python-ideas] Re: Native support for units [was: custom literals]

My personal preference for adding units to python would be to make instances of all numeric classes subscriptable, with the implementation being roughly equivalent to: def __getitem__(self, unit_cls: type[T]) -> T: return unit_cls(self) We could then discuss the possibility of adding some im

[Python-ideas] Variadic patterns

I couldn't find any information on whether this was considered and rejected during the pattern matching PEP, so apologies if this is already settled. I've just encountered this use-case repeatedly so I figured it was time to make a thread on this. Basically, I'd like to be able to designate a pat

[Python-ideas] Re: Variadic patterns

Great point Valentin. I do think it's worthwhile to allow capturing variadic sub-patterns while destructuring. For symmetry with variadic function arguments (*args) I would actually suggest accumulating all the values using a tuple and bind that tuple to the name, but I'm not precious about using

[Python-ideas] Re: Variadic patterns

ity to match on type isn't really relevant, because that is existing functionality. Cheers, Matt On Wed, Sep 14, 2022 at 3:43 PM Christopher Barker wrote: > On Tue, Sep 13, 2022 at 8:44 AM Matt del Valle > wrote:and bind them > >> match val: >> case [*str()]: >