[Python-ideas] Re: Add an __exclude_all__ complement to __all__

On 3/5/21 12:41 PM, Caleb Donovick wrote: > __all__ = (Class.__name__, func.__name__, ...) > > So I have to put it at the end of the module. I do this because if I > change the class or function name and I forget to change it in > __all__, I get an exception. I certainly will not claim to

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

On 3/3/21 2:18 PM, George Harding wrote: __all__ does not stop anyone from importing anything in the module using `from foo import bar`. That is true, but that is also Python. If you import something not included in `__all__` then you do so at your own risk as it could change or vanish in

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

On 3/3/21 3:38 PM, George Harding wrote: If you are using __all__ to define your API, then you'll end up needing `from foo import *` if you want to combine modules, e.g.: https://github.com/python/cpython/blob/master/Lib/asyncio/__init__.py Absolutely! So the two need to coexist. *-import

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

On 3/3/21 2:17 PM, Brendan Barnwell wrote: [...] usually you want to define [__all__] at the beginning as a sort of documentation aid ("this is the public API"). That is its purpose. :-) I do think something like __exclude_all__ would be handy. It can be annoying to have to define

[Python-ideas] Re: Add an __exclude_all__ complement to __all__

On 3/3/21 12:55 PM, George Harding wrote: Python has an __all__ variable that can be defined in a module to restrict which members of the module should be included in a call `from foo import *`. The primary purpose these days for `__all__` is to codify a module's API. The *-import is just a

[Python-ideas] Re: Alternate lambda syntax

On 2/17/21 8:47 AM, Random832 wrote: On Tue, Feb 16, 2021, at 23:24, Stephen J. Turnbull wrote: except a couple of characters. So what currently looks like some_list.sort(key=lambda e: e[3].priority) would then be some_list.sort(key=(e)->e[3].priority) Let's not pretend the

[Python-ideas] Re: Using explicit parenthesization to convey aspects of semantic meaning?

On 12/17/20 11:09 AM, Chris Angelico wrote: > I said I wasn't going to respond, but this one is SUCH a common > misunderstanding that I don't want people led astray by it. > > "a+b" is NOT implemented as "a.__add__(b)", nor as "type(a).__add__(b)"! Okay, what is it implemented as? -- ~Ethan~

[Python-ideas] Re: @classproperty, @abc.abstractclasspropery, etc.

On 12/16/20 1:31 AM, Serhiy Storchaka wrote: Things like abstractclassmethod are legacy. It is more preferable to combine elemental decorators. I completely disagree, although I suppose the determining factor is one's point of view. I see it as "abstractclassmethod" being its own thing, and

[Python-ideas] Re: a new data type: NamedValue -- similar to Enum

On 12/12/20 7:25 PM, Steven D'Aprano wrote: > On Sat, Dec 12, 2020 at 06:00:17PM -0800, Ethan Furman wrote: >> Enum is great! Okay, okay, my opinion might be biased. ;) >> >> There is one area where Enum is not great -- for a bunch of unrelated >> values. > &

[Python-ideas] Re: a new data type: NamedValue -- similar to Enum

On 12/12/20 7:52 PM, Steven D'Aprano wrote: On Sat, Dec 12, 2020 at 07:01:55PM -0800, Ethan Furman wrote: That's invalid. Duplicates allowed means: ``` class K( NamedValue): A = 1 B = 1 ``` B is not an alias for A. Presumably one has the same number with different meaning

[Python-ideas] Re: a new data type: NamedValue -- similar to Enum

On 12/12/20 6:40 PM, Guido van Rossum wrote: unlike Enum, duplicates are allowed What does this even mean? ``` class K( NamedValue):     A = 1     A = 2 ``` That's invalid. Duplicates allowed means: > ``` > class K( NamedValue): > A = 1 > B = 1 > ``` B is not an alias for A.

[Python-ideas] a new data type: NamedValue -- similar to Enum

Enum is great! Okay, okay, my opinion might be biased. ;) There is one area where Enum is not great -- for a bunch of unrelated values. What would be nice is if we had something similar to Enum for the - repr() - constantness of the name/value relationship While I was looking in the

[Python-ideas] Re: Typed Python execution mode

On 12/10/20 2:08 PM, redrad...@gmail.com wrote: It is also about convenience It takes a stronger argument than convenience to get something added to the stdlib. -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe

[Python-ideas] Re: __init__ in module names

On 12/9/20 12:39 PM, Steven D'Aprano wrote: I am against changing this behaviour before anyone has identified *actual bugs* in code caused by it, and before anyone has addressed the use-case MAL gave for the current behaviour. +1 -- ~Ethan~ ___

[Python-ideas] Re: Adding PyInstaller to the standard library

On 11/20/20 8:41 PM, Brendan Barnwell wrote: On 2020-11-20 01:51, Steven D'Aprano wrote: If that's really what you want, you probably should look at making a way to run Python apps in the browser. Everyone has an OS, everyone has a browser, GUI browsers have similar looking look-and-feels,

[Python-ideas] Re: Enum and the Standard Library (and __str__ and __repr__)

On 11/3/20 3:58 PM, Steven D'Aprano wrote: On Tue, Nov 03, 2020 at 11:10:37AM -0800, Ethan Furman wrote: After discussions with Guido I made a (largely done) PR [3] which: for stdlib global constants (such as RE) - repr() -> uses `module.member_name` - str() -> uses `membe

[Python-ideas] Re: Enum and the Standard Library (and __str__ and __repr__)

On 11/3/20 11:26 AM, Chris Angelico wrote: On Wed, Nov 4, 2020 at 6:11 AM Ethan Furman wrote: TL;DR Changes may be coming to Enum str() and repr() -- your (informed) opinion requested. :-) Does this affect my own enums too, or just stdlib ones? I'm not entirely sure on that point

[Python-ideas] Enum and the Standard Library (and __str__ and __repr__)

TL;DR Changes may be coming to Enum str() and repr() -- your (informed) opinion requested. :-) Python-Dev thread [0], summary below: As you may have noticed, Enums are starting to pop up all over the stdlib [1]. To facilitate transforming existing module constants to IntEnums there is

[Python-ideas] Re: New feature

On 10/17/20 10:54 AM, Marco Sulla wrote: I think that in this case `clear` simply writes N enter chars, until the terminal is "cleared". IMHO this is the safest option. 'clear' should also leave the cursor in the upper-left position, which cannot be gotten by writing a bunch of line feeds.

[Python-ideas] Re: New feature

On 10/13/20 4:46 PM, Steven D'Aprano wrote: And I [clear my screen] frequently, in both Python and bash. Because I never remember the name of the bash command to do it (cls or clear?), and Python doesn't have one, I just hold down the Enter key for a couple of seconds until there's no clutter

[Python-ideas] Re: Curious : Why staticmethod if classmethods can do everything a static method can?

On 9/11/20 7:35 PM, Christopher Barker wrote: - > But the real question is why staticmethod at all? > > And the answer is that there is very little use for staticmethod in > Python [...] On 9/11/20 7:28 PM, Greg Ewing wrote:

[Python-ideas] Re: 'Infinity' constant in Python

On 9/5/20 1:18 AM, Jeffrey Kintscher wrote: My point was that importing "everything" into the global namespace The only global namespace in Python is builtins [1]. Everything else is module or local. and then finding that a new version of Python has a new global symbol that causes a

[Python-ideas] Re: still more use for pathlib.Path ....

On 8/20/20 6:06 PM, Christopher Barker wrote: But for a while is was painful to use, 'cause there was som much code that still used strings for paths. That was made a lot better when we introduced the __fspath__ protocol, and then updated the standard library to use it (everywhere?).

[Python-ideas] Re: Decorators for class non function properties

On 8/5/20 11:11 AM, Jonathan Goble wrote: That's literally useless, because after running that there is nothing stopping you from doing: >>> a = 10 or even: >>> a = "python has no constants" And now a has a value different from 5. There is nothing even remotely resembling const-ness to

[Python-ideas] Re: Decorators for class non function properties

On 8/5/20 10:54 AM, David Mertz wrote: I'm not advocating it, and I'm not the one that came up with it. But my impression is that it is intended to mean: a = const('a', 5) This doesn't seem completely pointless: class const(): ...     def __init__(self, name, val): ... self.name = name

[Python-ideas] Re: Idea: Extend "for ... else ..." to allow "for ... if break ..." else

On 7/28/20 10:30 PM, Rob Cliffe via Python-ideas wrote: A possible, unrelated, future language extension is to allow breaking out of more than one loop at a time. I would think that break would handle that situation. -- ~Ethan~ ___

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On 7/27/20 5:00 PM, Christopher Barker wrote: I guess this is the part I find confusing: when (and why) does __eq__ play a role? __eq__ is the final authority on whether two objects are equal. The default __eq__ punts and used identity. On Mon, Jul 27, 2020 at 12:01 PM Ethan Furman

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On 7/27/20 11:15 AM, Christopher Barker wrote: On Sun, Jul 26, 2020 at 8:25 PM Guido van Rossum wrote: In fact, defining `__hash__` as returning the constant `42` is better, because it is fine if two objects that *don't* compare equal still have the same hash value (but not the other way

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On 7/26/20 10:31 AM, Henry Lin wrote: You're right, declaring `__eq__` for the class we want to compare would solve this issue. However, we have the tradeoff that * All classes need to implement the `__eq__` method to compare two instances; I usually implement __eq__ sooner or later

[Python-ideas] Re: Deprecation of Enum members

On 7/23/20 12:24 PM, s.williamswynn.m...@gmail.com wrote: I have run into a situations when an enum member becomes obsolete. However, I'd like to avoid removing the member from the enum to give time for users to catch up to a libraries core types. This would be good. I've seen Java has a

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On 7/20/20 7:34 AM, Barry Scott wrote: To avoid the ambiguity of `if` after `for` why not follow `for` with `elif`? for x in ...: ... elif break: # break was called elif not break: # looped at least once and break not used elif pass: # same as else today # loop'ed no times (I always have to

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On 07/11/2020 09:16 PM, Rob Cliffe via Python-ideas wrote: My gut feeling (backed by no evidence) is that dealing with the case of zero iterations is not needed frequently enough to cater for it. My personal experience is that the case of no iterations is frequent enough, and a big enough

[Python-ideas] Re: Add builtin function for min(max())

Operator chaining -- gotcha. Thanks Dominik and Ronald! -- ~Ethan~ ___ 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/

[Python-ideas] Re: Add builtin function for min(max())

On 07/03/2020 05:03 PM, Steven D'Aprano wrote: def clamp(value, lower, upper): """Clamp value to the closed interval lower...upper. The limits lower and upper can be set to None to mean -∞ and +∞ respectively. """ if not (lower is None or upper

[Python-ideas] Re: Bringing the print statement back

On 06/11/2020 01:18 PM, Rob Cliffe via Python-ideas wrote: If the new super-duper all-singing-and-dancing-and-make-the-tea parser can cope with 'print' without parens, it can cope with print followed by nothing. Good addition to the proposal, actually. :-) (Repeated for clarity: I'm in favour

[Python-ideas] Re: Bringing the print statement back

On 06/09/2020 05:06 PM, Guido van Rossum wrote: One thing that the PEG parser makes possible in about 20 lines of code is something not entirely different from the old print statement. I have a prototype: >>> print 2+2 4 >>> print "hello world" hello world There are downsides too, though.

[Python-ideas] Re: Python __main__ function

On 05/28/2020 01:05 PM, tritium-l...@sdamon.com wrote: People write main entry points that are not exactly this? If __name__ == '__main__': sys.exit(main(sys.argv[1:])) I have never written an entry point that looks like that. -- ~Ethan~ ___

[Python-ideas] Re: How to propose a change with tests where the failing test case (current behaviour) is bad or dangerous

On 05/27/2020 05:53 PM, Rob Cliffe via Python-ideas wrote: No, I downloaded a 3rd-party package.  I'm not sure if that's "specialist sotware" by your definition. I won't name it here, but it was dead easy to install and use and works perfectly. Personally I'd recommend it. You'd recommend

[Python-ideas] Re: Enhance list.index with a comparison function

On 05/22/2020 05:11 PM, David Mertz wrote: On 05/22/2020 04:43 AM, Steven D'Aprano wrote: i = somelist.index(needle, pred=comparison) Why not just this (by object, not by its index, but that seems simpler): >>> do_something(next(filter(pred, somelist))) Something about 55 >>>

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On 05/20/2020 12:44 AM, Chris Angelico wrote: On Wed, May 20, 2020 at 4:36 PM Thierry Parmentelat wrote: I also reckon it is still cumbersome to simply enter Unicode characters from a keyboard sometimes; I guess if the big players were located in other countries that would maybe be

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/17/2020 12:02 PM, Rob Cliffe via Python-ideas wrote: On 17/05/2020 19:43, David Mertz wrote: The API matter is really orthogonal to this. My point here is that Nathan and some other discussants are operating under the assumption that: "Everyone really wants strict-zip but they just

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/17/2020 10:18 AM, Alex Hall wrote: But it's good that we have the assert statement, because it makes it easy to write safe code and so people are encouraged to do so. I could not disagree more strongly with this. Every time I have seen assert used it was in such a way that the

[Python-ideas] Re: [Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 05/16/2020 01:16 AM, Steven D'Aprano wrote: On Fri, May 15, 2020 at 05:46:43PM +0200, Antoine Pitrou wrote: For me: * zip(strict=True) +1 * zip(mode='strict') -0 * itertools.zip_strict() -0.5 * zip.strict() -1 (but really, I'd like to make this -1e10) I spent a

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

On 05/08/2020 09:36 AM, Alex Hall wrote: On Fri, May 8, 2020 at 5:51 PM Henk-Jaap Wagenaar wrote: FYI, it does show in my version on gmail and on the mailman version. Weird, did

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

On 05/08/2020 07:50 AM, Alex Hall wrote: On Fri, May 8, 2020 at 4:46 PM Henk-Jaap Wagenaar wrote: On Fri, 8 May 2020 at 14:16, Steven D'Aprano mailto:st...@pearwood.info>> wrote: If you have ever written something like any of these:     all(x==y for x,y in zip(a, b)) That looks like a zip

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

On 05/05/2020 03:05 AM, Alex Hall wrote: On Tue, May 5, 2020 at 7:36 AM Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote: >> Isn't a tuple essentially just a frozenlist? I know the intended >> semantics of tuples and lists tend to be different, but I'm not sure that's

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/04/2020 12:07 PM, Alex Hall wrote: No, I stand by my position for now that "just in case" is a genuine reason "just in case" is boiler-plate. One of the huge wins in Python is its low boiler-plate requirements. It's okay if programmers have to think about their code and what's

[Python-ideas] Re: zip(x, y, z, strict=True)

On 05/04/2020 12:35 PM, Alex Hall wrote: I imagine there are few people who are too lazy to copy code from SO right now, and would be too lazy to import from itertools when the feature becomes available, but if it's a builtin then they're willing to make changes Quite frankly, I have zero

[Python-ideas] Re: Introduce 100 more built-in exceptions

On 05/01/2020 02:19 AM, Steven D'Aprano wrote: Best practice is to put try...except around only a *single* operation which may raise what you want to catch. Of course that's easier said than done, especially since nearly anything can raise nearly anything. The follow-on to that is to only

[Python-ideas] Re: zip(x, y, z, strict=True)

On 04/30/2020 07:58 AM, Christopher Barker wrote: On 04/29/2020 10:51 PM, Stephen J. Turnbull wrote: I think that the issue of searchability and signature are pretty compelling reasons for such a simple feature to be part of the function name. I would absolutely agree with that if all three

[Python-ideas] Re: Adding a "once" function to functools

On 04/27/2020 11:34 AM, Antoine Pitrou wrote: On Mon, 27 Apr 2020 09:26:53 -0700 Ethan Furman wrote: That is what I was saying -- that `once`, all by itself, could mean multiple things. That's a good point. A more explicit spelling would be `@call_once`, what do you think? I think

[Python-ideas] Re: Adding a "once" function to functools

On 04/27/2020 08:26 AM, Barry wrote: On 27 Apr 2020, at 16:01, Ethan Furman wrote: I'm objecting to using "beginners" as the basis for name choices for advanced topics. Aside from that, `once` is a fine name. I'm sure it means that a function can only be defined once, and

[Python-ideas] Re: zip(x, y, z, strict=True)

On 04/26/2020 08:56 PM, Christopher Barker wrote: that seems not very "there's only one way to do it" to me. The quote is "one obvious way". It almost feels like the proponents of the new mode/function are hoping to avoid the processing that might need to be "rolled back" in some manner

[Python-ideas] Re: Adding a "once" function to functools

On 04/27/2020 05:09 AM, Steven D'Aprano wrote: On Sun, Apr 26, 2020 at 07:48:10PM -0700, Ethan Furman wrote: How many beginners know they want to call a function only once? More than the number who know about LRU caches. Ethan, are you objecting to a self-descriptive name because it is too

[Python-ideas] Re: Adding a "once" function to functools

On 04/26/2020 05:11 PM, Steven D'Aprano wrote: On Sun, Apr 26, 2020 at 06:43:06PM +0200, Alex Hall wrote: It's not clear to me why people prefer an extra function which would be exactly equivalent to lru_cache in the expected use case (i.e. decorating a function without arguments). It seems

[Python-ideas] Re: zip(x, y, z, strict=True)

On 04/22/2020 02:03 PM, Steven D'Aprano wrote: If they need to be *convinced* to use the new function, then they don't really need it and didn't want it. Sadly, it is not human nature to just accept that one needs something when they have been getting along "just fine" without it. --

[Python-ideas] Re: zip should return partial results in StopIteration

On 04/22/2020 07:08 AM, Soni L. wrote: I have, more than once, had a desire to use zip to partially consume an iterator from a set of iterators, and then pass the rest onto something else. it'd fit in with that. it's a small quality of life improvement that'd make zip even more useful than

[Python-ideas] Re: zip(x, y, z, strict=True)

On 04/21/2020 07:33 AM, Brandt Bucher wrote: I know that I, and everyone on my team, would use it frequently! Have you written your own version that does this check for input iterable equality? -- ~Ethan~ ___ Python-ideas mailing list --

[Python-ideas] Re: zip(x, y, z, strict=True)

On 04/21/2020 12:58 PM, David Mertz wrote: >>> it1 = iter([1,2,3]) >>> it2 = iter([4,5]) >>> it3 = iter([6,7,8, 9]) >>> list(zip(it1, it2, it3)) [(1, 4, 6), (2, 5, 7)] next(it3) 8 [...] worse is that most versions being discussed here seem to consume the 8 from it3 before raising the

[Python-ideas] Re: More appropriate behavior for the NotImplemented object

On 03/11/2020 11:16 AM, Andrew Barnert via Python-ideas wrote: On Mar 11, 2020, at 02:42, Steve Jorgensen wrote: Take the following example: ``` def __lt__(self, other): return not self.__ge__(other): def __le__(self, other): return not self.__gt__(other): def

[Python-ideas] Re: New explicit methods to trim strings

On 03/07/2020 05:31 AM, Alex Hall wrote: I've defined functions like this in my own utility library and I use them all the time, so I think they're very useful and would like to seem them built in. But I have two functions for each end: def strip_optional_suffix(string, suffix): ...

[Python-ideas] Re: New explicit methods to trim strings

On 03/06/2020 04:03 PM, Steven D'Aprano wrote: On Thu, Mar 05, 2020 at 12:45:28PM -0800, Andrew Barnert via Python-ideas wrote: Well, I like the idea if someone can come up with a good naming scheme—something that at least reminds me which function is the “set of chars” stripper and which the

[Python-ideas] Re: New explicit methods to trim strings

On 03/06/2020 04:07 PM, Steven D'Aprano wrote: On Fri, Mar 06, 2020 at 03:33:49PM -0800, Ethan Furman wrote: I think we should have a `stripstr()` as an alias for strip, and a new `stripchr()`. Shouldn't they be the other way around? `strip` removes chars from a set of chars; the proposed

[Python-ideas] Re: New explicit methods to trim strings

On 03/06/2020 02:59 PM, Guido van Rossum wrote: On Fri, Mar 6, 2020 at 2:19 PM Steven D'Aprano wrote: Can we just fix this? Obviously there will be a month of bike-shedding arguments about the names *wink* but can we at least agree that this is a genuine source of confusion and a useful

[Python-ideas] Re: Exception for parameter errors

On 03/04/2020 06:24 AM, Steven D'Aprano wrote: My earlier use-case still stands: feature detection where a function has changed its parameter list. More on this below. It seems like `inspect.signature` is the right way to do this kind of feature detection. On Wed, Mar 04, 2020 at

[Python-ideas] Communication on mailing lists [was: Add a __valid_getitem_requests__ protocol]

. Rhodri James wrote: -- Language, sunshine. Steven D'Aprano wrote: - What about it? Just for the record, I had no issues with Soni's language, but I do object to attempts to shame him for it. Ethan Furman wrote: -- Since when is simply

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

On 02/22/2020 04:37 PM, Chris Angelico wrote: Do any of the core devs agree with those two assertions? If posts to -Ideas required core dev agreement this would be an empty list indeed. -- ~Ethan~ ___ Python-ideas mailing list --

[Python-ideas] Re: Add a __valid_getitem_requests__ protocol

On 02/19/2020 08:55 AM, Soni L. wrote: On 2020-02-18 5:33 p.m., Soni L. wrote: Similar to len(). Just a [crappy] wrapper for __valid_getitem_requests__. Correction: Just a simple wrapper for __valid_getitem_requests__. Hopefully unsurprisingly, those words do not mean the same: simple:

[Python-ideas] Re: Add a __valid_getitem_requests__ protocol

On 02/18/2020 04:26 PM, Steven D'Aprano wrote: On Tue, Feb 18, 2020 at 08:44:07PM +, Rhodri James wrote: Language, sunshine. What about it? Just for the record, I had no issues with Soni's language, but I do object to attempts to shame him for it. Since when is simply drawing one's

[Python-ideas] Re: Add __keys__ or __items__ protocol

On 02/18/2020 12:24 AM, Serhiy Storchaka wrote: 1. What special method should be added, `__keys__` or `__items__`? The former returns keys, it needs to call `__getitem__` repeatedly to get values. The latter returns key-value pairs, it does not need to call `__getitem__`, but you should

[Python-ideas] Re: Traits

On 02/14/2020 02:24 PM, Soni L. wrote:   class Foo(Trait):     def x(self):   raise NotImplementedError   class Bar(Trait):     def x(self):   raise NotImplementedError   class Baz(TraitObject):  # "mirrors" class Baz(object):     @impl(Foo)     class Foo:   def x(self):

[Python-ideas] Re: Traits

On 02/14/2020 04:53 AM, Soni L. wrote: That's not traits. That's its own thing. That's not even mixins, it just seems to be type-checked attributes. Nobody has implemented actual traits in Python yet, only mixins with extra steps and there are 2 libraries providing these type-checked

[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?

On 02/12/2020 10:00 AM, Andrew Barnert wrote: On Feb 12, 2020, at 06:49, Ethan Furman wrote: On 02/11/2020 01:49 PM, Steven D'Aprano wrote: Oh, definitely for the best. This now allows us to write complex assertions much more easily and efficiently: assert log(flag

[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?

On 02/11/2020 01:49 PM, Steven D'Aprano wrote: Oh, definitely for the best. This now allows us to write complex assertions much more easily and efficiently: assert log(flag := complex_expression) or flag That doesn't seem very useful: for that assert to fail, `flag` would have to be

[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?

On 02/11/2020 11:49 AM, jdve...@gmail.com wrote: My point is: is it good to add a new way of causing side effects in assertions? Good or not, it's not changing now. It's probably safe to say that every new language feature adds one more way to break assertions. It is our responsibility to

[Python-ideas] Re: Traits

On 02/07/2020 01:40 PM, Greg Ewing wrote: On 8/02/20 5:59 am, Soni L. wrote: Traits are an alternative to Multiple Inheritance. They solve the problem of name conflicts by making them an ambiguity error and requiring you to disambiguate (at call site). This sounds like something that

[Python-ideas] Re: `raise as` to raise with current exception as cause

On 02/07/2020 09:06 AM, Anders Hovmöller wrote: On 7 Feb 2020, at 16:59, Ethan Furman wrote: On 02/07/2020 07:44 AM, Anders Hovmöller wrote: If the only difference is the text between the stack traces, why aren't you suggesting to change that text? Because the text is important

[Python-ideas] Re: `raise as` to raise with current exception as cause

On 02/07/2020 07:44 AM, Anders Hovmöller wrote: If the only difference is the text between the stack traces, why aren't you suggesting to change that text? Because the text is important in what it implies. See my other message for details. -- ~Ethan~ Aside: please trim the parts of your

[Python-ideas] Re: `raise as` to raise with current exception as cause

On 02/07/2020 07:33 AM, Serhiy Storchaka wrote: 07.02.20 16:28, Ram Rachum пише: The idea is to add `raise as` syntax, that raises an exception while setting the currently caught exception to be the cause. It'll look like this:      try:          1/0      except ZeroDivisionError:         

[Python-ideas] Re: addition of "nameof" operator

On 01/21/2020 02:08 PM, Chris Angelico wrote: Yes, that's exactly what I mean, and exactly why self.__class__ is used here. If you actually want "Person" even if it's actually a Martian, you can use __class__.__name__ rather than self.__class__.__name__ to get that. Gotcha, thanks. I'm still

[Python-ideas] Re: addition of "nameof" operator

On 01/21/2020 11:25 AM, Chris Angelico wrote: I'm not sure how this compares to what nameof(Person) should return, but the above idiom (or something like it) is very common in Python, as it allows repr to acknowledge a subclass. If you create "class Martian(Person): pass", then a Martian's repr

[Python-ideas] Re: Argumenting in favor of first()

On 12/05/2019 03:11 PM, Josh Rosenberg wrote: "Also, the for-loop version quits the moment it finds a Product type, while the `first` version has to first process the entire jsonld_items structure." The first version doesn't have to process the whole structure; it's written with a generator

[Python-ideas] Re: Allow user extensions to operators [related to: Moving PEP 584 forward (dict + and += operators)]

On 12/04/2019 08:39 AM, Random832 wrote: On Wed, Dec 4, 2019, at 08:26, Serhiy Storchaka wrote: 03.12.19 20:43, Brett Cannon пише: -1 from me. I can see someone not realizing an operator was changed, assuming it's standard semantics, and then having things break subtly. And debugging this

[Python-ideas] Re: Archiving Threads / Closing Threads

On 12/04/2019 04:44 AM, Abdur-Rahmaan Janhangeer wrote: An advantage. If the topic goes round several times, the mods closing the topic freezes the thread so that the thread does not gets filled with unnecessary details. By the time the topic has gone around several times, it is already

[Python-ideas] Re: Allow Path object instances in subprocess.Popen

On 11/03/2019 02:31 AM, Anders Hovmöller wrote: Side note! When switching subjects mid-thread, please re-title the subject. This side-note sub-thread is now nearly as long as the original thread. -- ~Ethan~ ___ Python-ideas mailing list --

[Python-ideas] Re: Suggestion for behaviour change import mechanics

On 10/29/2019 06:33 AM, mer...@gmx.net wrote: Anyways, just failing later would not hurt the Python language I think ;) It would, as Stephen D'Aprano explained. -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send

[Python-ideas] Re: add a .with_stem() method to pathlib objects

On 10/29/2019 10:41 AM, Paul Moore wrote: On Tue, 29 Oct 2019 at 17:38, Ethan Furman wrote: On 10/29/2019 10:17 AM, Brian Skinn wrote: I feel like the semantics of PurePath.suffix (https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.suffix) and PurePath.stem define this pretty

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/23/2019 01:08 PM, Steven D'Aprano wrote: On Wed, Oct 23, 2019 at 11:59:44AM -0400, Todd wrote: Compare that to: colors2 = "cyan,forest green,burnt umber".split(',') Sure, that's not going away. But consider that you're using this inside a tight loop: for something in

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/23/2019 01:36 PM, Steven D'Aprano wrote: Virtually overnight, the Python community got used to the opposite change, with f-strings . . . * citation needed -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/24/2019 04:03 AM, Steven D'Aprano wrote: The current "obvious" solution is tedious, annoying, verbose (about a third longer than it need be) and error-prone.^1 --> print("So should we have syntax for sentence literals" ... "so we don't forget spaces, too?") ^1 I'm gratified to

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

On 10/24/2019 07:07 AM, Steven D'Aprano wrote: On Thu, Oct 24, 2019 at 02:00:50PM +0100, Rhodri James wrote: The fact is, %w[...] doesn't look like anything else Python does It looks like a list display [...] with a prefix. It looks like gobbledygook. -- ~Ethan~

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

On 10/22/2019 03:13 PM, Steve Jorgensen wrote: Ethan Furman wrote: Experimenting is good! However, you'll want to either build your own metaclass and/or prepared dict, or do some work on your __new__/__init__ methods for building enum members. Currently, you are reassigning _value_

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

On 10/21/2019 10:33 PM, Steve Jorgensen wrote: class ChoiceEnum(Enum): def __init__(self, src=None, label=None): super().__init__() if isinstance(src, Label): value = None label = str(src) else:

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On 10/20/2019 10:08 PM, Andrew Barnert via Python-ideas wrote: On Oct 20, 2019, at 21:10, Stephen J. Turnbull wrote: I'm not against having an operator for updating dicts, but "+" is not it. "|" is fine, though. It seems like people who don’t really like this feature and don’t plan to use

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On 10/20/2019 03:06 PM, Guido van Rossum wrote: So the choice is really only three way. 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=) 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=) 3) Do nothing In the end I'm +0.5 on | and |=, +0 on + and +=, and -0 on doing

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

On 10/19/2019 11:25 PM, Andrew Barnert via Python-ideas wrote: On Oct 19, 2019, at 22:57, Steve Jorgensen wrote: The idea is to use a class as a singleton collection of choices where every choice appears both as an attribute of the class/singleton and as a value/label pair when treating it

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

On 10/19/2019 07:56 PM, Steve Jorgensen wrote: When using a custom classdict to implement a DSL or use in the body of a class definition, from what I can tell by experiment, the classdict takes priority, and the surrounding context is only referenced if trying to get an item from the

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On 10/18/2019 10:25 AM, Steven D'Aprano wrote: On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote: That result just doesn't match up with the '+' operator. Why not? Pretty sure I answered that question in my OP. Here it is again since you conveniently stripped it out

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

On 10/16/2019 10:35 PM, Brandt Bucher wrote: At long last, Steven D'Aprano and I have pushed a second draft of PEP 584 (dictionary addition): Please let us know what you think – we'd love to hear any *new* feedback that hasn't yet been addressed in the PEP or the related discussions it

[Python-ideas] Re: RFC: PEP xxx: Python Compatibility Version

On 10/17/2019 06:02 PM, Victor Stinner wrote: I propose the following PEP to add sys.set_python_compat_version(version) to introduce a partial compatibility with Python 3.8 in the next Python 3.9 version. -1 If possible, please try to read the whole PEP before replying. Done. TL;DR

<    1   2   3   4   >