Re: [Python-ideas] PEP 525: Asynchronous Generators

2016-08-10 Thread Sven R. Kunze
On 09.08.2016 05:23, Nick Coghlan wrote: On 9 August 2016 at 08:37, Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: From what I've heard in the wild, that most if not all pieces of async are mirroring existing Python features. So, building async basi

Re: [Python-ideas] From mailing list to GitHub issues

2016-08-14 Thread Sven R. Kunze
On 14.08.2016 13:19, Paul Moore wrote: In my opinions, forums tend to encourage a much more focused style of discussion. In one way, that's a good thing (and I'm sure many people would prefer python-ideas to have more focus). But it *also* tends to deter people from contributing - I can't quite

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

2017-01-31 Thread Sven R. Kunze
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

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

2017-01-31 Thread Sven R. Kunze
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

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

2017-02-07 Thread Sven R. Kunze
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

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

2017-02-23 Thread Sven R. Kunze
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

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

2017-02-24 Thread Sven R. Kunze
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

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

2017-02-23 Thread Sven R. Kunze
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

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

2017-02-10 Thread Sven R. Kunze
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

Re: [Python-ideas] Efficient debug logging

2017-02-15 Thread Sven R. Kunze
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:

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

2017-02-17 Thread Sven R. Kunze
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

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

2017-01-16 Thread Sven R. Kunze
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

Re: [Python-ideas] discontinue iterable strings

2016-08-21 Thread Sven R. Kunze
On 21.08.2016 04:52, Steven D'Aprano wrote: Saying that these so-called "fixes" (we haven't established yet that Python's string behaviour is a bug that need fixing) will be easier and more obvious than the change to Unicode is not that bold a claim. Agreed. Especially those "we need to

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

2017-02-28 Thread Sven R. Kunze
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

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

2016-09-05 Thread Sven R. Kunze
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:

Re: [Python-ideas] Shuffled

2016-09-06 Thread Sven R. Kunze
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.

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

2016-09-06 Thread Sven R. Kunze
On 06.09.2016 20:37, Nick Coghlan wrote: On 7 September 2016 at 04:24, Sven R. Kunze <srku...@mail.de> 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 k

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

2016-09-06 Thread Sven R. Kunze
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

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

2016-09-06 Thread Sven R. Kunze
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 <srku...@mail.de <mailto:srku...@mail.de>> wrote: So, what's the "async" good for then? Maybe I'm off base here

Re: [Python-ideas] Shuffled

2016-09-06 Thread Sven R. Kunze
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

Re: [Python-ideas] Shuffled

2016-09-06 Thread Sven R. Kunze
On 06.09.2016 20:46, Tim Peters wrote: [Sven R. Kunze <srku...@mail.de>] ... 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

Re: [Python-ideas] Shuffled

2016-09-06 Thread Sven R. Kunze
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 probability

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

2016-09-06 Thread Sven R. Kunze
On 06.09.2016 20:45, Koos Zevenhoven wrote: On Tue, Sep 6, 2016 at 9:24 PM, Sven R. Kunze <srku...@mail.de> 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

Re: [Python-ideas] a multiProcess scheduler

2016-08-29 Thread Sven R. Kunze
On 29.08.2016 05:32, Nick Coghlan wrote: (Alternatively, if the answer the interviewer is looking for is "I wouldn't, I would use...", then it may be an unfair "Gotcha!" question, and those aren't cool either, since they expect the interviewee to be able to read the interviewer's mind, rather

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

2016-08-29 Thread Sven R. Kunze
On 29.08.2016 11:37, Chris Angelico wrote: That's why I keep asking you for code examples. Real-world code, taken from important projects, that would be significantly improved by this proposal. There was no reasonable real-world code examples taken from important projects, that would be

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

2016-08-29 Thread Sven R. Kunze
I didn't follow the previous discussion so far, so excuse me if I repeat something somebody already mentioned. But these are intriguing points you made here. On 29.08.2016 09:31, Ken Kundert wrote: The reason why hexadecimal and octal are in general purpose languages and real numbers with SI

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

2016-08-29 Thread Sven R. Kunze
On 29.08.2016 05:40, Brendan Barnwell wrote: On 2016-08-28 20:29, Ken Kundert wrote: What is wrong with have two ways of doing things? We have many ways of specifying the value of the integer 16: 0b1, 0o20, 16, 0x10, 16L, Zen of Python: "There should be one-- and preferably only

Re: [Python-ideas] Shuffled

2016-09-07 Thread Sven R. Kunze
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 <srku...@mail.de>] I am not q

Re: [Python-ideas] Shuffled

2016-09-07 Thread Sven R. Kunze
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

Re: [Python-ideas] Shuffled

2016-09-07 Thread Sven R. Kunze
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:22 PM, Sven R. Kunze <srku...@mail.de &l

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

2016-09-07 Thread Sven R. Kunze
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

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

2016-08-30 Thread Sven R. Kunze
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.

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

2016-09-11 Thread Sven R. Kunze
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.

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

2016-09-10 Thread Sven R. Kunze
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 wor

Re: [Python-ideas] Null coalescing operator

2016-09-10 Thread Sven R. Kunze
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

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

2016-10-05 Thread Sven R. Kunze
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

Re: [Python-ideas] async objects

2016-10-04 Thread Sven R. Kunze
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

Re: [Python-ideas] async objects

2016-10-05 Thread Sven R. Kunze
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

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

2016-10-05 Thread Sven R. Kunze
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 to avo

Re: [Python-ideas] async objects

2016-10-05 Thread Sven R. Kunze
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

Re: [Python-ideas] async objects

2016-10-05 Thread Sven R. Kunze
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

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

2016-10-04 Thread Sven R. Kunze
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

2016-10-04 Thread Sven R. Kunze
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

Re: [Python-ideas] from __pip__ import

2016-09-19 Thread Sven R. Kunze
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 <srku...@mail.de <mailto:srku...@mail.de>> wrot

Re: [Python-ideas] from __pip__ import

2016-09-19 Thread Sven R. Kunze
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

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

2016-09-07 Thread Sven R. Kunze
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 all

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

2016-10-28 Thread Sven R. Kunze
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)

2016-10-28 Thread Sven R. Kunze
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

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

2016-10-28 Thread Sven R. Kunze
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] Showing qualified names when a function call fails

2016-10-28 Thread Sven R. Kunze
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

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

2016-10-12 Thread Sven R. Kunze
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

Re: [Python-ideas] Null coalescing operator

2016-10-15 Thread Sven R. Kunze
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

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

2016-10-22 Thread Sven R. Kunze
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

2016-10-22 Thread Sven R. Kunze
+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

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

2016-10-17 Thread Sven R. Kunze
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

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

2016-10-20 Thread Sven R. Kunze
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

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

2016-10-20 Thread Sven R. Kunze
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

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

2016-10-20 Thread Sven R. Kunze
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] Python multi-dimensional array constructor

2016-10-21 Thread Sven R. Kunze
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,

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

2016-10-21 Thread Sven R. Kunze
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

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

2016-10-21 Thread Sven R. Kunze
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

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

2016-10-21 Thread Sven R. Kunze
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.

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

2016-11-18 Thread Sven R. Kunze
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

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

2016-11-14 Thread Sven R. Kunze
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

Re: [Python-ideas] Null coalescing operator

2016-11-02 Thread Sven R. Kunze
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

2016-11-03 Thread Sven R. Kunze
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

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

2016-10-11 Thread Sven R. Kunze
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

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

2016-10-13 Thread Sven R. Kunze
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?". I'm p

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

2016-10-12 Thread Sven R. Kunze
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

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

2016-10-13 Thread Sven R. Kunze
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. We

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

2016-10-11 Thread Sven R. Kunze
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

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

2016-10-15 Thread Sven R. Kunze
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

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

2016-10-15 Thread Sven R. Kunze
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.

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

2016-10-16 Thread Sven R. Kunze
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

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

2016-10-17 Thread Sven R. Kunze
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

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

2016-10-17 Thread Sven R. Kunze
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

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

2016-10-17 Thread Sven R. Kunze
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

2016-10-17 Thread Sven R. Kunze
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

2016-10-17 Thread Sven R. Kunze
On 17.10.2016 22:31, Paul Moore wrote: On 17 October 2016 at 21:06, Sven R. Kunze <srku...@mail.de> 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

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

2017-01-13 Thread Sven R. Kunze
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] Things that won't change (proposed PEP)

2017-01-12 Thread Sven R. Kunze
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

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

2017-03-03 Thread Sven R. Kunze
On 03.03.2017 19:29, Ed Kellett wrote: The reasons already stated boil down to "lists aren't dicts so they shouldn't share methods", which seems ill-advised at best, and "I wouldn't use this". I wonder if those arguing against it also think dicts should not have item access: a[0] dict or

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

2017-03-03 Thread Sven R. Kunze
On 03.03.2017 21:09, Chris Barker wrote: On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: For me to think (list/tuple).get() was needed would be if lots of folk either cast their lists to dicts or made their own list-di

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

2017-03-03 Thread Sven R. Kunze
On 03.03.2017 16:24, Yury Selivanov wrote: TBH I think that optional parameters isn't a problem requiring new syntax. We probably do need syntax for positional-only arguments (since we already have them in a way), but optional parameters can be solved easily without a new syntax. Syntax like:

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

2017-03-03 Thread Sven R. Kunze
to post to a mailing list... -CHB On Fri, Mar 3, 2017 at 12:09 PM, Chris Barker <chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>> wrote: On Fri, Mar 3, 2017 at 12:02 PM, Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: For me to t

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

2017-03-03 Thread Sven R. Kunze
On 03.03.2017 20:35, Ethan Furman wrote: On 03/03/2017 11:01 AM, Sven R. Kunze wrote: On 03.03.2017 19:29, Ed Kellett wrote: The reasons already stated boil down to "lists aren't dicts so they shouldn't share methods", which seems ill-advised at best, and "I wouldn't use th

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

2017-03-03 Thread Sven R. Kunze
On 03.03.2017 18:06, Ethan Furman wrote: On 03/02/2017 12:36 PM, Sven R. Kunze wrote: 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

Re: [Python-ideas] Positional-only parameters

2017-03-02 Thread Sven R. Kunze
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

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

2017-03-03 Thread Sven R. Kunze
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

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

2017-03-03 Thread Sven R. Kunze
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

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

2017-03-03 Thread Sven R. Kunze
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

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

2017-03-03 Thread Sven R. Kunze
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

Re: [Python-ideas] + operator on generators

2017-06-28 Thread Sven R. Kunze
On 28.06.2017 16:01, Koos Zevenhoven wrote: For a moment, I was wondering what the double emphasis was for, but then I realized you are simply calling `statement.__why__()`​ directly instead of the recommended `spoiler(statement)`. Doing this for years now. Sometimes, when

Re: [Python-ideas] Improving Catching Exceptions

2017-06-28 Thread Sven R. Kunze
On 28.06.2017 15:26, Nick Coghlan wrote: 1. In 3.3+ you can just catch ImportError, check "exc.name", and re-raise if it's not for the module you care about I see, didn't know that one. I gave it a try and it's not 100% the behavior I have expected, but one could workaround if the valid

Re: [Python-ideas] + operator on generators

2017-06-28 Thread Sven R. Kunze
On 28.06.2017 20:37, Koos Zevenhoven wrote: Oh, I've been very close to getting one of those. But then I should probably get a pair of glasses too ;). :D ​​That pattern annoys people and negates the benefits of views and generators.​ Sure, that's why I am in favor of this proposal. It

Re: [Python-ideas] Improving Catching Exceptions

2017-06-28 Thread Sven R. Kunze
On 28.06.2017 21:14, Nathaniel Smith wrote: With PEP 479 there was a different and better way to generate a StopIteration if you wanted one (just 'return'). Here I'm afraid existing projects might actually be relying on the implicit exception leakage in significant numbers :-/ My concern as

Re: [Python-ideas] Python 4: Concatenation

2017-06-30 Thread Sven R. Kunze
On 30.06.2017 13:51, Jamie Willis wrote: Just as an aside, if a concatenation operator *was* included, a suitable operator would be "++", this is the concatenation operator in languages like Haskell (for strings) and the majority of Scala cases. Alternatively "<>" is an alternative, being the

Re: [Python-ideas] + operator on generators

2017-07-05 Thread Sven R. Kunze
On 30.06.2017 00:57, Jan Kaliszewski wrote: Please, note that it can be upturned: maybe they are not so common as they could be because of all that burden with importing from separate module -- after all we are saying about somewhat very simple operation, so using lists and `+` just wins because

Re: [Python-ideas] + operator on generators

2017-06-28 Thread Sven R. Kunze
On 28.06.2017 11:09, Nick Coghlan wrote: The other thing to look for would be list() and list.extend() calls. I know I use those quite a bit in combination with str.join, where I don't actually *need* a list, it's just currently the most convenient way to accumulate all the components I'm

Re: [Python-ideas] Improving Catching Exceptions

2017-06-27 Thread Sven R. Kunze
On 27.06.2017 13:41, Nick Coghlan wrote: The shallow exception notion breaks a fairly fundamental refactoring principle in Python: you should be able to replace an arbitrary expression with a subfunction or subgenerator that produces the same result without any of the surrounding code being able

  1   2   >