[Python-ideas] Re: pathlib enhancements

Hi Todd, my comments below. Also would offer my time for reviewing/testing if wanted. On 22.11.20 20:53, Todd wrote: I know enhancements to pathlib gets brought up occasionally, but it doesn't look like anyone has been willing to take the initiative and see things through to completion.  I am

[Python-ideas] Re: pathlib enhancements

I split my answers up to address different issues in different threads. On 31.12.20 15:32, Todd wrote: Hi Sven, Thanks for your support and feedback. On Thu, Dec 31, 2020, 07:23 Sven R. Kunze <mailto:srku...@mail.de>> wrote: Hi Todd, my comments below. Also would offe

[Python-ideas] Re: pathlib enhancements

Last but not least, I tend more towards the "rmtree" method just to make it crystal clear to everyone. Maybe docs could cross-refer both methods. Tree manipulations are inherently complicated and a lot can go wrong. Symmetry is not 100% given as you might delete more than wh

[Python-ideas] Re: pathlib enhancements

On 31.12.20 15:32, Todd wrote: 5. Stem with no suffixes The stem property only takes off the last suffix, but even in the example given ('my/library.tar.gz') it isn't really useful because the suffix has two parts ('.tar' and '.gz').  I suggest another property, probably c

[Python-ideas] Re: Arrow functions polyfill

On 15.02.21 22:42, Greg Ewing wrote: On 16/02/21 6:29 am, Guido van Rossum wrote: I can sympathize with trying to get a replacement for lambda, because many other languages have jumped on the arrow bandwagon, and few Python first-time programmers have enough of a CS background to recognize the

[Python-ideas] Re: Arrow functions polyfill

On 16.02.21 17:26, Steven D'Aprano wrote: >>> from types import SimpleNamespace >>> obj = SimpleNamespace() >>> obj.spam = 1 >>> obj namespace(spam=1) Gives you a nice repr so when you are debugging you can actually see what the object is. I see that's Python 3 (vs.

[Python-ideas] SimpleNamespace vs object

Starting this as a new thread for the interested reader: On 17.02.21 11:18, Chris Angelico wrote: On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote: Still think that "object()" should be writable since this seems like an arbitrary restriction (+SimpleNamespace is no builtin and

[Python-ideas] Re: SimpleNamespace vs object

On 18.02.21 05:43, Chris Angelico wrote: On Thu, Feb 18, 2021 at 1:59 PM Ben Rudiak-Gould wrote: It seems to me that all you'd have to do is add a line or two to the add_dict logic in type_new so that instances of object get a dict. Then instances of object would get a dict, and nothing else

[Python-ideas] Re: Deferred evaluation (was: PEP 671: Syntax for late-bound function argument defaults)

Actually, the "defer:"-syntax is really readable and searchable compared to the cryptic comparison operator used in the proposal. Just thinking towards "googleability". Furthermore, the concept is even more general than parameter definition of functions and methods. I guess a lot of people hav

[Python-ideas] Re: Deferred evaluation (was: PEP 671: Syntax for late-bound function argument defaults)

On 31.10.21 12:34, Chris Angelico wrote: Google's smarter than that. I've searched for symbols before and found plenty of good results. For instance, I can search for information about the @ sign before a function, or independently, for a @ b, and get information about decorators or matrix multip

Re: [Python-ideas] Revisiting Immutable Mappings

On 12.10.18 01:30, Chris Barker via Python-ideas wrote: If Python had a way to check ABCs without issubclass, then I wouldn't care about subclasses at all. I'd actually kind of like to have: hasinterface(an_object, (ABC1, ABC2, ABC3)) I actually like your idea and could imagine using "hasint

Re: [Python-ideas] Revisiting Immutable Mappings

On 18.10.18 18:49, Anders Hovmöller wrote: If it's AND, shouldn't it be "hasinterfaces" (notice the s!)? Yeah, could be. To be sure, we are on the same page here: "interface" refers to a set of attributes of the object in question, does it? E.g. like the __iter__ iterface. I usually don't c

Re: [Python-ideas] real numbers with SI scale factors

On 30.08.2016 04:34, David Mertz wrote: On Mon, Aug 29, 2016 at 1:55 PM, Sven R. Kunze <mailto:srku...@mail.de>> wrote: There was no reasonable real-world code examples taken from important projects, that would be significantly improved by underscores in numbers. I reca

Re: [Python-ideas] real numbers with SI scale factors: next steps

Thanks a lot for this comprehensive summary. :) Find my comments below. On 30.08.2016 22:34, Ken Kundert wrote: Okay, let's try to wrap this up. In summary I proposed three things: 1. A change to the Python lexer to accept SI literal as an alternative, but not replacement to, E-notation. A

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

Hi Yury, just for my understanding: On 04.09.2016 01:31, Yury Selivanov wrote: We propose to allow the use of ``await`` expressions in both asynchronous and synchronous comprehensions:: result = [await fun() for fun in funcs] result = {await fun() for fun in funcs} result = {fun: a

Re: [Python-ideas] Shuffled

If so, then I would suggest than each list provides a .shuffle method as well (just as sorted/sort does). On 06.09.2016 06:34, Mahmoud Hashemi wrote: I tend to agree with Arek. I've been bitten multiple times, including once yesterday, because shuffle works in place, when I really expect a so

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

On 06.09.2016 03:16, Yury Selivanov wrote: Whereas the following will produce some sort of async lists, sets, and dicts? result = [await fun() async for fun in funcs] result = {await fun() async for fun in funcs} result = {fun: await fun() async for fun in funcs} If so, how do

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

On 06.09.2016 19:38, Yury Selivanov wrote: On 2016-09-06 9:40 AM, C Anthony Risinger wrote: On Tue, Sep 6, 2016 at 10:20 AM, Sven R. Kunze <mailto:srku...@mail.de>> wrote: So, what's the "async" good for then? Maybe I'm off base here, but my un

Re: [Python-ideas] Shuffled

Hi Steven, On 06.09.2016 18:32, Steven D'Aprano wrote: On Tue, Sep 06, 2016 at 05:29:18PM +0200, Arek Bulski wrote: [I think Arek is quoting me here] One moderately stong piece of evidence would be if this function is widely available in third-party libraries and other languages. Wrong. Pytho

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

Hi Srinivas, On 06.09.2016 05:46, srinivas devaki wrote: On Tue, Sep 6, 2016 at 6:46 AM, Yury Selivanov wrote: Hi Sven, I doubt that anybody ever would write something like that; this is just examples of what the PEP will enable. using the same object as iterator and async generator, may be

Re: [Python-ideas] Shuffled

Are you serious? The reason for "we don't need standardization" == "there is a solution, long, and with a lot of special characters". Holy c***. I remember Python being the least verbose language on the planet. I suspect this argument didn't lead to status quo. It's like saying, we don't need v

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

On 06.09.2016 20:37, Nick Coghlan wrote: On 7 September 2016 at 04:24, Sven R. Kunze wrote: Python async community wants you to write everything twice: for the sync and async case. And don't dare to mentioned code sharing here. They will rip you apart. ;) Just kidding. Of course would

Re: [Python-ideas] Shuffled

On 06.09.2016 20:46, Tim Peters wrote: [Sven R. Kunze ] ... He already convinced some people. Just not some venerable Python devs, which doesn't necessarily mean something at all. Their response: "Oh, I don't need it, let's close it." Arek: "But I need it."

Re: [Python-ideas] Shuffled

On 06.09.2016 20:46, Bernardo Sulzbach wrote: On 09/06/2016 03:37 PM, Sven R. Kunze wrote: Besides being a silly argument, it's an interesting solution. Does it really work? I remember Microsoft utilizing a similar approach for their browser selection tool which led to a skewed probab

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

On 06.09.2016 20:45, Koos Zevenhoven wrote: On Tue, Sep 6, 2016 at 9:24 PM, Sven R. Kunze wrote: [...] No really, I have absolutely no idea why you need to put that "async" in all places where Python can detect automatically if it needs to perform an async iteration or not. Maybe

Re: [Python-ideas] PEP 530: Asynchronous Comprehensions

On 06.09.2016 21:45, Terry Reedy wrote: On 9/6/2016 2:54 PM, Sven R. Kunze wrote: PS: Nick, I noted that while replying, my mail client made me responding to you and the list as cc. For Thunderbird, this is normal behavior. I suspect you would find the same if your tried 'replay al

Re: [Python-ideas] Shuffled

On 06.09.2016 21:29, Tim Peters wrote: In the absence of anything approaching [use-cases], it's a matter of taste, and then - yes - decades of Python development experience do - and should - outweigh a newcomer's wish list. Especially when, as appears to be the case here, those with truly exte

Re: [Python-ideas] Shuffled

On 07.09.2016 02:49, Chris Kaynor wrote: I'll weigh in and say that I've had a few cases where I've wanted a shuffled function, but not many. The vast majority are interactive uses, where I want to get a sampling of data, and in those cases I'm normally just printing the output (often, by letti

Re: [Python-ideas] Shuffled

rry" and then ascertain "why the heck is there no alternative returning the shuffled result instead of overwriting my list? I would expect this from Python as it already provides both alternatives for sorting". Sven On 08.09.2016 00:02, Tim Peters wrote: [Sven R. Kunze ] I am not

Re: [Python-ideas] Typecheckers: there can be only one

On 08.09.2016 00:00, Paul Moore wrote: On 7 September 2016 at 22:31, Hugh Fisher wrote: The average programmer such as myself will expect that if I write code specifying the type of a variable or whatever it should *do something*. It's code, I wrote it, it should be interpreted. Reading the do

Re: [Python-ideas] Shuffled

/tutorial/appendix.html#the-interactive-startup-file> that you can modify so that this function will always be available to /you/ whenever you start up an interactive session (and you can put whatever else in there that you like as well :-). I hope that helps. On Wed, Sep 7, 2016 at 3

Re: [Python-ideas] Inconsistencies (was: Shuffled)

On 08.09.2016 04:00, Steven D'Aprano wrote: On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote: >BUT experienced devs also need to recognize and respect the fact that >younger/unexperienced developers are just better in detecting >inconsistencies and bloody work-aro

Re: [Python-ideas] Null coalescing operator

On 10.09.2016 19:14, Random832 wrote: As I remember the discussion, I thought he'd more or less conceded on the use of ? but there was disagreement on how to implement it that never got resolved. Concerns like, you can't have a?.b return None because then a?.b() isn't callable, unless you want to

Re: [Python-ideas] if-statement in for-loop

On 11.09.2016 22:15, C Anthony Risinger wrote: On Sep 11, 2016 7:11 AM, "Chris Angelico" > wrote: > > That said, though, filtered iteration isn't common enough to demand > its own syntax IMO. I do it fairly often, I do it often enough to want this. Same here. Most

Re: [Python-ideas] from __pip__ import

I can definitely understand your point. The only issue with it (besides that it doesn't seem to be a good way for dependency management) is how do you manage the syntax involved here? Pip provides distributions. Each distribution contains a set of packages and modules. The latter can be impor

Re: [Python-ideas] from __pip__ import

Which is still not allowed syntax IIRC? ;) On 19.09.2016 19:20, אלעזר wrote: Obviously from __pip__ import "run-lambda>=0.1.0" Which is ugly but not my fault :) On Mon, Sep 19, 2016 at 8:16 PM Sven R. Kunze <mailto:srku...@mail.de>> wrote: I can definitely

Re: [Python-ideas] if-statement in for-loop

On 04.10.2016 15:20, Random832 wrote: The *real* question is what "break" should do. I think it should likewise break from the outermost for-loop (but "continue" should still continue the innermost one), but this does mean that it's not mechanically identical to the "equivalent" nested loops [it

Re: [Python-ideas] async objects

On 04.10.2016 13:30, Nick Coghlan wrote: What it *doesn't* do, and what you need greenlet for, is making that common interface look like you're using plain old synchronous C threads. If folks really want to do that, that's fine - they just need to add gevent/greenlet as a dependency, just as the

Re: [Python-ideas] async objects

On 04.10.2016 09:50, Stephen J. Turnbull wrote: As I understand the main point, Sven and Rene don't believe that [the kind of] async code [they want to write] should need any keywords; just start the event loop and invoke functions, and that somehow automatically DTRTs. [reading my name second t

Re: [Python-ideas] if-statement in for-loop

On 05.10.2016 11:20, Stephen J. Turnbull wrote: Eg, there's no question in my mind that for i in range(m): for j in range (n): for k in range (p): m_out(i, k) += m_in1(i, j) * m_in2(j, k) is easier to read[1] than for i in range(m) for j in rang

Re: [Python-ideas] async objects

On 05.10.2016 08:49, Rene Nejsum wrote: As a result of past discussions, I wrote the module "xfork" which basically does this "golang goroutine" stuff. It's just a thin wrapper around "futures" but it allows to avoid that what René and Anthony objects about. I had a look at xfork, and really

Re: [Python-ideas] async objects

On 05.10.2016 20:23, Michel Desmoulin wrote: On the other hand, await / async is a fantastic interface to unify all concurrent paradigms and asyncio already provide a bridge with threads and subprocess. So it kinda make sense. Almost if it would not require duplicate pieces of code. But maybe

Re: [Python-ideas] xfork [was Re: async objects]

On 05.10.2016 06:11, Ethan Furman wrote: On 10/04/2016 09:40 AM, Sven R. Kunze wrote: As a result of past discussions, I wrote the module "xfork" which basically does this "golang goroutine" stuff. It's just a thin wrapper around "futures" but it allows t

Re: [Python-ideas] async objects

On 05.10.2016 18:06, Nick Coghlan wrote: [runtime matters] I think I understand your point. I also hope that others and me could provide you with our perspective. We see Python not as a C-like runtime but as an abstract modelling language. I know that it's different from the point of view of

Re: [Python-ideas] [Python-Dev] Optimizing list.sort() by checking type in advance

On 11.10.2016 05:02, Tim Peters wrote: Let's not get hung up on meta-discussion here - I always thought "massive clusterf**k" was a precise technical term anyway ;-) I thought so as well. ;) http://www.urbandictionary.com/define.php?term=clusterfuck Cheers, Sven __

[Python-ideas] warn/error when using a method as boolean in ifs/whiles

Hey python-ideas, on django-developers, an intriguing idea appeared: https://groups.google.com/d/msg/django-developers/4bntzg1HwwY/HHHjbDnLBQAJ """ It seems to me that the default `method.__bool__` is undesirable in Jinja2 templates. I do not know Jinja2 well enough, but maybe they could ben

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

Hi Martti, On 11.10.2016 14:42, Martti Kühne wrote: Hello list I love the "new" unpacking generalisations as of pep448. And I found myself using them rather regularly, both with lists and dict. Today I somehow expected that [*foo for foo in bar] was equivalent to itertools.chain(*[foo for foo i

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

On 12.10.2016 17:41, Nick Coghlan wrote: This particular proposal fails on the first question (as too many people would expect it to mean the same thing as either "[*expr, for expr in iterable]" or "[*(expr for expr in iterable)]") So, my reasoning would tell me: where have I seen * so far? *ar

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

On 12.10.2016 21:38, אלעזר wrote: What is the intuition behind [1, *x, 5]? The starred expression is replaced with a comma-separated sequence of its elements. The trailing comma Nick referred to is there, with the rule that [1,, 5] is the same as [1, 5]. I have to admit that I have my pr

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

On 13.10.2016 01:29, Steven D'Aprano wrote: On Wed, Oct 12, 2016 at 06:32:12PM +0200, Sven R. Kunze wrote: So, my reasoning would tell me: where have I seen * so far? *args and **kwargs! And multiplication. Multiplication with only a single argument? Come on. And sequence unpacking.

Re: [Python-ideas] Fwd: unpacking generalisations for list comprehension

On 13.10.2016 16:10, Steven D'Aprano wrote: On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote: Multiplication with only a single argument? Come on. You didn't say anything about a single argument. Your exact words are shown above: "where have I seen * so far?&qu

Re: [Python-ideas] Null coalescing operator

On 15.10.2016 08:10, Nick Coghlan wrote: However, it's also the case that where we *do* have a well understood and nicely constrained problem, it's still better to complain loudly when data is unexpectedly missing, rather than subjecting ourselves to the pain of having to deal with detecting prob

Re: [Python-ideas] Heap data type, the revival

On 15.10.2016 20:15, Nick Timkovich wrote: I once again had a use for heaps, and after rewrapping the heapq.heap* methods for the umpteenth time, figured I'd try my hand at freezing off that wart. We re-discussed this in the beginning of 2016 and xheap https://pypi.python.org/pypi/xheap was on

Re: [Python-ideas] Heap data type, the revival

On 15.10.2016 23:19, Nick Timkovich wrote: Features and speed are good, but I'm interested in getting something with the basic features into the Standard Library so it's just there. Not having done that before and bit clueless, I'm wanting to learn that slightly less-technical procedure. What are

Re: [Python-ideas] Fwd: Fwd: unpacking generalisations for list comprehension

On 15.10.2016 16:47, Martti Kühne wrote: [var for expression in iterable for var in expression] you are right, though. List comprehensions are already stackable. TIL. Good catch, Paul. Comprehensions appear to be a special case when it comes to unpacking as they provide an alternative path. So

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 16.10.2016 07:08, David Mertz wrote: In case it wasn't entirely clear, I strongly and vehemently opposed this unnecessary new syntax. It is confusing, bug prone, and would be difficult to teach. As this discussion won't come to an end, I decided to consult my girlfriend. I started with

Re: [Python-ideas] Heap data type, the revival

On 16.10.2016 19:02, Nick Timkovich wrote: Functions are great; I'm a big fan of functions. That said, the group of heapq.heap* functions are literally OOP without using that "class" word. As far as flexibility, what is the use of the those functions on non-heap structures? IIRC the statement w

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 20:38, David Mertz wrote: Under my proposed "more flexible recursion levels" idea, it could even be: [f(x) for x in flatten(it, levels=3)] There would simply be NO WAY to get that out of the * comprehension syntax at all. But a decent flatten() function gets all the flexibili

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 16.10.2016 09:35, Alireza Rafiei wrote: Awesome! Thanks for the thorough explanation. Indeed. I also didn't know about that detail of reversing. :) Amazing. (Also welcome to the list, Alireza.) def multisort(xs, specs): for key, reverse in reversed(specs):

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 22:12, Paul Moore wrote: 4. Whether you choose to believe me or not, I've sincerely tried to understand the proposal [...] I think you did and I would like others to follow your example. 2. Can someone summarise the *other* arguments for the proposal? I for one think it's just res

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 17.10.2016 22:26, Paul Moore wrote: Certainly having to add an import statement is extra typing. But terseness was *never* a feature of Python. In many ways, a resistance to overly terse (I could say "Perl-like") constructs is one of the defining features of the language - and certainly, it's

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17.10.2016 22:31, Paul Moore wrote: On 17 October 2016 at 21:06, Sven R. Kunze wrote: Do you think that simple solution could have a chance to be added to stdlib somehow (with the possibility of speeding it up in the future)? You could submit a doc patch to add an explanation of this

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18.10.2016 10:01, Daniel Moisset wrote: So, for me, this feature is something that could be covered with a (new) function with no new syntax required. All you have to learn is that instead of [*...] you use flatten(...) The main motivation is not "hey we need yet another way for xyz" but "

Re: [Python-ideas] Order of loops in list comprehension

On 19.10.2016 00:08, Rob Cliffe wrote: But it's far too late to change it now, sadly. Indeed. :-( But if I were ruler of the world and could have my own wish-list for Python 4, this (as per the first example) would be on it. I don't see no reason why we can't make it. Personally, I also di

Re: [Python-ideas] Fwd: Fwd: Fwd: unpacking generalisations for list comprehension

On 18.10.2016 08:23, Greg Ewing wrote: If it were a namedtuple, for example, you could write [*t for t in fulltext_tuples if t.language == 'english'] or [x for t in fulltext_tuples if t.language == 'english' for x in t] The latter is a bit unsatisfying, because we are having to make up an

Re: [Python-ideas] Order of loops in list comprehension

On 21.10.2016 01:43, Greg Ewing wrote: Alexander Heger wrote: For me the current behaviour does not seem unreasonable as it resembles the order in which you write out loops outside a comprehension That's true, but the main reason for having comprehensions syntax in the first place is so that i

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

On 19.10.2016 21:08, Todd wrote: a= [ 48, 11, 141, 13, -60, -37, 58, -52, -29, 134 || -6, 96, -66, 137, -59, -147, -118, -104, -123, -7 ||| -103, 50, -89, -12, 28, -12, 119, -131, -73, 21 || -58, 105, 25, -138, -106, -118, -29, -49, -63, -56 -43, -34, 101, -115

Re: [Python-ideas] Multiple level sorting in python where the order of some levels may or may not be reversed

On 17.10.2016 23:53, Paul Moore wrote: On 17 October 2016 at 22:28, Mark Lawrence via Python-ideas wrote: How about changing https://wiki.python.org/moin/HowTo/Sorting ? Good point. Better still, https://docs.python.org/3.6/howto/sorting.html Don't know what the real difference between those

Re: [Python-ideas] Conditional Assignment in If Statement

On 18.10.2016 00:11, Michael duPont wrote: What does everyone think about: if foo = get_foo(): bar(foo) as a means to replace: foo = get_foo() if not foo: bar(foo) del foo Might there be some better syntax or a different keyword? I constantly run into this sort of use case. Befor

Re: [Python-ideas] Order of loops in list comprehension

On 22.10.2016 09:50, Alexander Heger wrote: Well, an argument that was often brought up on this forum is that Python should do things consistently, and not in one way in one place and in another way in another place, for the same thing. Like * in list displays? ;-) Here it is about the order

Re: [Python-ideas] Smart/Curly Quote Marks and cPython

+1 from me for the idea of a more useful error message (if possible). On 22.10.2016 09:36, Ryan Birmingham wrote: Per the comments in this thread, I believe that a better error message for this case would be a reasonable way to fix the use case around this issue. It can be difficult to notice t

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

On 28.10.2016 22:06, MRAB wrote: On 2016-08-26 13:47, Steven D'Aprano wrote: Ken has made what I consider a very reasonable suggestion, to introduce SI prefixes to Python syntax for numbers. For example, typing 1K will be equivalent to 1000. Just for the record, this is what you can now do in

Re: [Python-ideas] PEP 531: Existence checking operators

Hi Nick, thanks for writing all of this down and composing a PEP. On 28.10.2016 10:30, Nick Coghlan wrote: 1. Do we collectively agree that "existence checking" is a useful general concept that exists in software development and is distinct from the concept of "truth checking"? Right to your

Re: [Python-ideas] Marking keyword arguments (was: f-string, for dictionaries)

Hi Michel, hi Paul, sorry for hijacking this thread somewhat. I would like to extend this proposal a bit in order make it useful for a broader audience and to provide a real-word use-case. So, this post is just to gather general acceptance and utility of it. Michel, you specifically mention

Re: [Python-ideas] Showing qualified names when a function call fails

Great idea! Another issue I encounter regularly are things like: >>> func(mylist[i], mylist2[j]) IndexError: list index out of range So, which are the list and index that cause the error? On 25.10.2016 00:07, Ryan Gonzalez wrote: I personally find it kind of annoying when you have code li

Re: [Python-ideas] Null coalescing operator

On 02.11.2016 17:17, Nick Coghlan wrote: The gist is that rather than writing the bare: target = expr1 ?? expr2 ?? expr3 You'd instead write None-coalescing as: target = exists(expr1) ?? exists(expr2) ?? expr3 and None-propagating as: target = missing(expr1) ?? missing(expr2) ??

Re: [Python-ideas] Null coalescing operator

On 03.11.2016 02:06, MRAB wrote: On 2016-11-02 21:57, Greg Ewing wrote: MRAB wrote: target = expr1 || expr2 || expr3 target = expr1 && expr2 && expr3 except that only None would be considered falsey? Or would that be confusing? Yes, I think that borrowing an operator from C but givi

Re: [Python-ideas] PEP 532: A circuit breaking operator and protocol

Thanks, Nick. This PEP is far easier to read than the previous one. On 05.11.2016 10:50, Nick Coghlan wrote: This PEP has been designed specifically to address the risks and concerns raised when discussing PEPs 335, 505 and 531. * it defines a new operator and adjusts the definition of chained

Re: [Python-ideas] Built-in function to run coroutines

What about making "run" an instance method of coroutines? On 14.11.2016 19:30, Yury Selivanov wrote: Hi Guido, On 2016-11-12 4:24 PM, Guido van Rossum wrote: I think there's a plan to add a run() function to asyncio, which would be something akin to def run(coro): return get_event_loo

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 06.11.2016 09:07, Steven D'Aprano wrote: I'm having a lot of difficulty in understanding your use-case here, and so maybe I've completely misunderstood something. Although, this thread is dead for a week or so, I am still curious to hear the real-world use-case. I am equally puzzled by the

Re: [Python-ideas] Things that won't change (proposed PEP)

Good evening to everybody, On 12.01.2017 03:37, Steven D'Aprano wrote: I have a proposal for an Informational PEP that lists things which will not change in Python. If accepted, it could be linked to from the signup page for the mailing list, and be the one obvious place to point newcomers to

Re: [Python-ideas] How to respond to trolling (Guido van Rossum)

Moreover, when I read "explicit self" is a wart, then I think, "you have absolutely no idea how fantastic 'explicit self' is". Thus, inferring from a single data-point these seems to be personal "dislike lists". In this regard, I tend to prefer Guido's one before any others if there is even

Re: [Python-ideas] Fused multiply-add (FMA)

On 16.01.2017 20:28, Gregory P. Smith wrote: Is there a good reason not to detect single expression multiply adds and just emit a new FMA bytecode? Same question here. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/m

Re: [Python-ideas] Is it Python 3 yet?

A Big Yes! On 26.01.2017 17:11, Victor Stinner wrote: Hi, The download button of https://www.python.org/ currently gives the choice between Python 2.7 and 3.6. I read more and more articles saying that we reached a point where Python 3 became more popular than Python 2, Python 3 has now enough

Re: [Python-ideas] A decorator to call super()

Hi Roberto, On 31.01.2017 08:13, Roberto Martínez wrote: class MyOverridedClass(MyBaseClass): def mymethod(self, foo, **kwargs): # Do something return super().mymethod(**kwargs) What about creating a decorator to call super() after/before the overrided method? Something lik

Re: [Python-ideas] A more readable way to nest functions

On 31.01.2017 00:54, Mikhail V wrote: Great idea :) But actually that was my idea initially, so just breaking it into two lines solves the readability issue perfectly with long expressions. Although if one is chasing some kind of optimisations... I don't know, I see very often people want to s

Re: [Python-ideas] Is it Python 3 yet?

Agree with all of this. That's state of the art for many projects. On 07.02.2017 07:35, Mike Miller wrote: Hmm, agreed. BTW, I think the current download page is *way* too complicated for new comers. There should be a giant button for the latest 3.x/64 (platform sniffed), and below it a more

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

Another point of view: Some call it monkeypatching. Others call it configuration. There's room for both views and I don't see anything wrong with configuration using this kind of feature. Sven On 10.02.2017 17:17, Markus Meskanen wrote: Well yes, but I think you're a bit too fast on labeli

Re: [Python-ideas] Efficient debug logging

On 15.02.2017 12:55, Barry Scott wrote: The lazy eval sound like a generator. Exactly my thought. Sven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/ps

Re: [Python-ideas] More classical for-loop

On 17.02.2017 04:59, Chris Angelico wrote: On Fri, Feb 17, 2017 at 2:13 PM, Mikhail V wrote: Common use case: L = [1,3,5,7] for i over len(L): e = L[i] or: length = len(L) for i over length: e = L[i] Better use case: for i, e in enumerate(L): I totally agree with Chris here. Fo

Re: [Python-ideas] Delayed Execution via Keyword

I would like to add another view of this feature might be very useful for cleaning up existing code bases: Just have a look at https://pypi.org/project/xfork/ and specifically I would like to point you to the following lines https://github.com/srkunze/fork/blob/afecde0/fork.py#L216 till #419.

Re: [Python-ideas] if in for-loop statement

Hi Henk-Jaap, thanks for your "if in for" proposal. Paul's comments are all "motherhood statements" against a generic proposal. It's nothing that would prevent your specific proposal from being accepted or not. And there's no rejected PEP for this feature as far as I can see. Skimming throu

Re: [Python-ideas] if in for-loop statement

Hey Steven, On 23.02.2017 19:25, Steven D'Aprano wrote: Indeed not. The Pythonic solution is exactly the one you used: DON'T combine the for-loop and if-statement. for x in range(100): if is_prime(x): ... If the use of two lines and two indents is truly a problem, to the point th

Re: [Python-ideas] if in for-loop statement

On 24.02.2017 05:45, Chris Angelico wrote: Don't forget that you can rewrite a "for-if" using two additional lines and no indents, rather than one line and one indent: for ...: if not (...): continue ... ... That's exactly what I meant by "for+if+continue". At work we e

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

On 28.02.2017 18:18, David Mertz wrote: Yes, and easily written as above. What significant advantage would it have to spell the above as: x = alist.get(pos, default_val) It's a couple characters shorter in the proposed version. I guess I'll concede that needing the odd indexing at the

Re: [Python-ideas] Positional-only parameters

Isn't https://www.python.org/dev/peps/pep-0457/ the PEP you are looking for? On 02.03.2017 19:16, Brett Cannon wrote: It seems all the core devs who have commented on this are in the positive (Victor, Yury, Ethan, Yury, Guido, Terry, and Steven; MAL didn't explicitly vote). So to me that sugge

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

On 02.03.2017 04:41, Chris Barker wrote: Maybe someone else will chime in with more "I'd really have a use for this" examples. It also makes refactoring easier. Regards, Sven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.

Re: [Python-ideas] for/except/else

On 03.03.2017 09:47, Wolfgang Maier wrote: However, the fact that else exists generates a regrettable asymmetry in that there is direct language support for detecting one outcome, but not the other. Stressing the analogy to try/except/else one more time, it's as if "else" wasn't available for

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

On 01.03.2017 06:34, Ethan Furman wrote: On the bright side, if enough use-cases of this type come up (pesky try/except for a simple situation), we may be able to get Guido to reconsider PEP 463. I certainly think PEP 463 makes a lot more sense that adding list.get(). It then would make sens

Re: [Python-ideas] Optional parameters without default value

On 03.03.2017 14:06, Victor Stinner wrote: 2017-03-03 6:13 GMT+01:00 Mike Miller : Agreed, I've rarely found a need for a "second None" or sentinel either, but once every few years I do. So, this use case doesn't seem to be common enough to devote special syntax or a keyword to from my perspect

  1   2   >