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

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

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

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

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

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

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:

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

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

Re: [Python-ideas] discontinue iterable strings

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

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

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

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

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

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

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

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

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

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

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] real numbers with SI scale factors

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

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

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

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] 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

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.

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 wor

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

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

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 to avo

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

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

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

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

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] 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

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

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

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

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

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 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

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

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__

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

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

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] 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?". I'm p

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. We

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

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

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

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

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] 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] 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

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

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

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

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

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

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

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] 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

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

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

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

Re: [Python-ideas] + operator on generators

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

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

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

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

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

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

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

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

Re: [Python-ideas] Improving Catching Exceptions

On 28.06.2017 08:00, Nick Coghlan wrote: Right, and I'd like us to keep in mind the KeyError -> AttributeError (and vice-versa) use case as well. Similar to ExitStack, it would be appropriate to make some additions to the "recipes" section in the docs that covered things like "Keep

Re: [Python-ideas] + operator on generators

On 28.06.2017 14:00, Koos Zevenhoven wrote: The programmer needs to be well aware of whether the resulting object is a Sequence or 'just' a generator. Could you elaborate more on **why**? Regards, Sven PS: I consider this proposal to be like allowing adding floats and ints together. If I

Re: [Python-ideas] + operator on generators

On 27.06.2017 21:27, David Mertz wrote: And I would like a language change that made a number of common iterable objects "chainable" without the wrapper. This wrapper could of course be used as a decorator too. E.g. generator comprehensions, things returned by itertools functions,

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

On 26.04.2017 23:50, Mark Lawrence via Python-ideas wrote: On 26/04/2017 21:50, Chris Angelico wrote: On Thu, Apr 27, 2017 at 6:24 AM, Erik wrote: The background is that what I find myself doing a lot of for private projects is importing data from databases into a

Re: [Python-ideas] Discourage operator.__dunder__ functions

On 13.04.2017 20:20, Steven D'Aprano wrote: - And finally, I fail to see how having to type an extra four characters is a "convenience". Just for the sake of completeness: Re-usage of names is always a convenience. Developers can use a string variable to access dynamically both the real

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 17.05.2017 13:37, Michel Desmoulin wrote: Having a cleaner, faster solution to declare a class would be awesome, both for dev and for teaching. That's why we all love attrs. But we are talking here about a nice-to-have feature. Python works perfectly fine without it. But since we are at it,

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

Hi Stephan, hi Ivan, On 17.05.2017 18:48, Ivan Levkivskyi wrote: from typing import NamedTuple class Foo(NamedTuple): """Foo is a very important class and you should totally use it. """ bar: int baz: int = 0 def grand_total(self): return self.bar + self.baz

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 17.05.2017 19:30, Ethan Furman wrote: Given that one of Python's great strengths is its readability, I would not use the attr library in teaching because it is not. Having a dot in the middle of words is confusing, especially when you don't already have a basis for which abbreviations are

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 17.05.2017 19:55, Stephan Houben wrote: So attrs and attrib can be used as alternatives for attr.s and attr.ib . Personally, I like the playful names. Ah, now I understand their documentation. :D I read this passage and thought: "where is the difference. Maybe, they meant omitting x=, y=

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

Hi Stephan, On 17.05.2017 08:49, Stephan Houben wrote: 2. Not subclassed from tuple. I have been bitten by this subclassing when trying to set up singledispatch on sequences and also on my classes. Would it make sense to have a 'simpleobject'? Which basically implements a NamedTuple

Re: [Python-ideas] Language proposal: variable assignment in functional context

On 17.06.2017 17:51, Nick Coghlan wrote: You've pretty much hit on why that PEP's been deferred for ~5 years or so - I'm waiting to see use cases where we can genuinely say "this would be so much easier and more readable if we had a given construct!" :) This PEP accepted, we would have 3 ways

Re: [Python-ideas] + operator on generators

Personally, I find syntactic sugar for concating interators would come in handy. The purpose of iterators and generators is performance and efficiency. So, lowering the bar of using them is a good idea IMO. Also hoping back and forth a generator/iterator-based solution and a, say,

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 20.05.2017 18:06, Nick Coghlan wrote: That's fine for someone that's already comfortable writing those behaviours by hand and just wants to automate the boilerplate away (which is exactly the problem that attrs was written to solve), but it's significantly more problematic once we assume

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

On 17.05.2017 23:29, Ivan Levkivskyi wrote: On 17 May 2017 at 20:09, Sven R. Kunze <srku...@mail.de <mailto:srku...@mail.de>> wrote: class Foo(dictlike, tuplelike, simpleobject): attribute1: User attribute2: Blog attribute3: list def __my_d

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

t;url" might be the config parameter for "Mixin1", "next_foo" for "Mixin2" and "special_model" is required/recognized by "Base". As you can imagine, testing is also easier. Regards, Sven On 19.05.2017 06:31, Eric V. Smith wrote: On 5/18

Re: [Python-ideas] π = math.pi

On 01.06.2017 08:47, Serhiy Storchaka wrote: What you are think about adding Unicode aliases for some mathematic names in the math module? ;-) math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(

Re: [Python-ideas] Language proposal: variable assignment in functional context

On 17.06.2017 02:27, Steven D'Aprano wrote: I think this is somewhat similar to a suggestion of Nick Coghlan's. One possible syntax as a statement might be: y = b + 2 given: b = a + 1 Just to get this right:this proposal is about reversing the order of chaining expressions? Instead

Re: [Python-ideas] Adding new lines to "Zen of Python"

On 08.09.2017 15:20, M.-A. Lemburg wrote: On 08.09.2017 14:47, Thomas Güttler wrote: I curious if there are any plans to update the "Zen of Python". What could be added to the "Zen of Python"? What do you think? Only the Zen Master can decide on this one and it appears there's only room for

Re: [Python-ideas] Adding a thin wrapper class around the functions in stdlib.heapq

On 22.11.2017 07:22, Nick Timkovich wrote: Functions are great. I'm a big fan of functions. However, 1. Once there are several that all have the same thing as an argument: thing_operation1(thing, arg), thing_operation2(thing, arg)...it's about time to bind them together. 2. And especially for

Re: [Python-ideas] Should Python have user-defined constants?

On 21.11.2017 19:05, אלעזר wrote: I don't understand the question. The use case was explained before - people want to have better ways to reason about their programs. Statically. Why dismiss it as a non-usecase? It's helpful for both tools and humans. Then type annotations are for them. But

Re: [Python-ideas] Adding a thin wrapper class around the functions in stdlib.heapq

Maybe, that suffices: https://pypi.python.org/pypi/xheap On 21.11.2017 03:46, bunslow wrote: Perhaps such repetition is a sign that *something* needs to be done... Thanks for the link though. I'm new enough to the community that it didn't even occur to me to search for prior discussions.

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

On 13.05.2018 11:23, Peter O'Connor wrote:  *Correction: Above code should read:     outputs = [] state = initial_state for inp in inputs: out, state = my_update_func(inp, state) outputs.append(out) Question still stands if this type of code needs compaction in the first place? List

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

On 11.05.2018 13:43, Nick Coghlan wrote: I've been thinking about this problem, and I think for the If/elif/while cases it's actually possible to allow the "binding is the same as the condition" case to be simplified to:     if command =  pattern.match(the_string):     ...     elif

  1   2   >