Re: [Python-ideas] discontinue iterable strings

On Sun, Aug 21, 2016 at 12:28 AM Alexander Heger wrote: > Did I leave anything out? >> How would you weigh the benefits against the problems? >> How would you manage the upgrade path for code that's been broken? >> > > FIrst one needs to add the extension string attributes like >

Re: [Python-ideas] add __contains__ into the "type" object

This suggestion is really problematic IMHO. "isinstance" is a nominal check. I can't ask "isinstance(x, Callable[int, int])" because that would imply solving the halting problem. so "isinstance(x, Y)" does not mean "is it true that x is an element of the type Y" but rather "is it true that x was

Re: [Python-ideas] Positional-only parameters

Here's a proof-of-concept for the decorator. It does not address the issue of passing aliases to positional arguments to **kwargs - I guess this requires changes in the CPython's core. (Sorry about the coloring, that's how it's pasted) from inspect import signature, Parameter from functools

Re: [Python-ideas] Shuffled

Naive shuffled() can be emulated using a single expression: sorted(lst, key=lambda _: random()) So there's even less incentive for standardization. ~Elazar ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Shuffled

(Just to be clear, I wasn't trying to suggest this as more than an ad-hoc solution for a throwaway script. But to me, "sorted by random key" is almost as obvious as "shuffled", perhaps more so for non english speakers with little background in CS terms; the words "sorted" and "random" jumps to the

[Python-ideas] typing.modifiers

With the new variable annotation syntax, it is possible to implement a useful "modifiers" library, all used as superclasses. Possible modifiers: * Named / Struct: annotation-defined fields. No monkey patching. * Immutable / Const * Sealed / Final: unsubclassable class * Array: a mutable

Re: [Python-ideas] typing.modifiers

Thanks for the reply בתאריך יום ו׳, 16 בספט' 2016, 13:16, מאת Steven D'Aprano ‏< st...@pearwood.info>: > On Fri, Sep 16, 2016 at 12:10:22AM +0000, אלעזר wrote: > > [...] > > Benefits of putting such a collection in stdlib (instead of as an > external > > package)

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

This has come up before. It will be a special case of making "if" without "else" result in a special "empty" type that is not part of the iteration. As in `[1, (2 if False) ] == [1]`. בתאריך יום א׳, 11 בספט' 2016, 13:29, מאת Bernardo Sulzbach ‏< mafagafogiga...@gmail.com>: > On 09/11/2016 06:36

Re: [Python-ideas] Delay evaluation of annotations

On Sun, Sep 25, 2016 at 10:14 PM David Mertz wrote: > All of those might promote changes in tools. But the tools exist to aid > working with a language, not the other way around. > > I can't think of a way to know that this string is code and that string is an actual string. And

Re: [Python-ideas] Delay evaluation of annotations

On Sun, Sep 25, 2016 at 9:28 PM David Mertz <me...@gnosis.cx> wrote: > On Sep 25, 2016 10:59 AM, "אלעזר" <elaz...@gmail.com> wrote: > > 2. It is not naturally supported by syntax highlighters and IDEs. They > can be made to support it, but most will not. > >

Re: [Python-ideas] Delay evaluation of annotations

in some way, or otherwise it wasn't visible. Again, I assume ".__annotations__" access evaluates them in the original context. I couldn't find any useful example yet. Elazar בתאריך שבת, 24 בספט' 2016, 22:07, מאת Stephen J. Turnbull ‏< turnbull.stephen...@u.tsukuba.ac.jp>:

Re: [Python-ideas] Add "equal" builtin function

It is a real problem. People are used to write `seq == [1, 2, 3]` and it passes unnoticed (even with type checkers) that if seq changes to e.g. a tuple, it will cause subtle bugs. It is inconvenient to write `len(seq) == 3 and seq == [1, 2, 3]` and people often don't notice the need to write it.

Re: [Python-ideas] Add "equal" builtin function

On Thu, Oct 6, 2016 at 5:53 PM Sjoerd Job Postmus <sjoerd...@sjoerdjob.com> wrote: > On Thu, Oct 06, 2016 at 02:45:11PM +0000, אלעזר wrote: > > It is a real problem. People are used to write `seq == [1, 2, 3]` and it > > passes unnoticed (even with type checkers) that

Re: [Python-ideas] Improve error message when missing 'self' in method definition

Isn't it possible to implement it as a pure Python exception hook? On Wed, Oct 5, 2016 at 10:04 PM Ivan Levkivskyi wrote: > > On 5 October 2016 at 20:55, Yury Selivanov > wrote: > > > Speaking of, I'm not much of a C hacker, and messing with

Re: [Python-ideas] Make partial a built-in

Guido, can you please elaborate? "What's going on" is usually that the same arguments are going to be passed over and over again, and the programmer wanted to avoid this repetition. The other option is adjusting the function to a predefined interface. The alternative to partial is writing a

[Python-ideas] Generics Syntax

This suggestion is so obvious that it's likely has been discussed, but I can't find any reference (It's not what PEP-3124 talks about). Generic class syntax, now: _T_co = TypeVar('_T', covariant=True) class Container(Generic[_T_co]): @abstractmethod def

Re: [Python-ideas] Generics Syntax

; > wrote: > >> On 15 September 2016 at 11:21, אלעזר <elaz...@gmail.com> wrote: >> >>> This suggestion is so obvious that it's likely has been discussed, but I >>> can't find any reference (It's not what PEP-3124 talks about). >>> >>> &g

Re: [Python-ideas] Generics Syntax

Does that mean that if I did, it would be reconsidered? On Thu, Sep 15, 2016 at 12:43 PM Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 15 September 2016 at 11:21, אלעזר <elaz...@gmail.com> wrote: > >> This suggestion is so obvious that it's likely has been discussed,

Re: [Python-ideas] Generics Syntax

hu, Sep 15, 2016 at 2:03 PM Nick Coghlan <ncogh...@gmail.com> wrote: > On 15 September 2016 at 19:53, Ivan Levkivskyi <levkivs...@gmail.com> > wrote: > > > > > > On 15 September 2016 at 11:46, אלעזר <elaz...@gmail.com> wrote: > >> > >>

Re: [Python-ideas] from __pip__ import

> [ERROR]: Your autotools build scripts are 200 lines longer than your > program. Something’s wrong. > http://kirbyfan64.github.io/ > On Sep 19, 2016 11:26 AM, "אלעזר" <elaz...@gmail.com> wrote: > >> Many proposals to add something to stdlib are rejected her

Re: [Python-ideas] from __pip__ import

tend to want it for special cases as well. :) > > > Cheers, > > Sven > > On 19.09.2016 18:55, אלעזר wrote: > > A library in PyPi still requires installing it, which undermine many of > the benefits. It won't help me with my gist/activestate recipe, code tha

Re: [Python-ideas] from __pip__ import

Thanks Joonas. I withdraw my proposal - nothing more is strictly needed. It should be idiomatic somehow, but I don't have any specific suggestion. On Mon, Sep 19, 2016 at 7:59 PM Joonas Liik <liik.joo...@gmail.com> wrote: > On 19 September 2016 at 19:55, אלעזר <elaz...@gmai

Re: [Python-ideas] Make partial a built-in

But the foo() finds the function to call, so foo.bind() could be made to find it too. בתאריך יום ג׳, 20 בספט' 2016, 08:24, מאת Stefan Behnel ‏<stefan...@behnel.de >: > אלעזר schrieb am 19.09.2016 um 17:59: > > If at all, it should be function.bind(). It was discussed and dropp

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

On Tue, Sep 20, 2016 at 4:56 AM Steven D'Aprano wrote: > On Mon, Sep 19, 2016 at 01:35:53PM -0700, João Matos wrote: > > Hello, > > > > I don't see why creating a clear command would interfere with > dict.clear() > > which is a function/method. > > For the same reason that

Re: [Python-ideas] Make partial a built-in

Yeah I did say it was a strawman :) On Tue, Sep 20, 2016 at 11:17 AM Chris Angelico <ros...@gmail.com> wrote: > On Tue, Sep 20, 2016 at 6:09 PM, אלעזר <elaz...@gmail.com> wrote: > > I meant something like making it a "__bind__" (just a strawman > suggestion)

Re: [Python-ideas] Make partial a built-in

On Tue, Sep 20, 2016 at 10:54 AM Chris Angelico <ros...@gmail.com> wrote: > On Tue, Sep 20, 2016 at 5:01 PM, אלעזר <elaz...@gmail.com> wrote: > > But the foo() finds the function to call, so foo.bind() could be made to > > find it too. > > class Demo: > def

Re: [Python-ideas] from __pip__ import

I believe that at least some of these problems can be addressed given that pip *knows* that this import is an in-script import. So the list of corner cases will be shorter. Elazar On Tue, Sep 20, 2016 at 1:35 PM Paul Moore <p.f.mo...@gmail.com> wrote: > On 19 September 2016 at 23:

Re: [Python-ideas] from __pip__ import

On Tue, Sep 20, 2016 at 1:42 PM Paul Moore <p.f.mo...@gmail.com> wrote: > On 20 September 2016 at 00:28, אלעזר <elaz...@gmail.com> wrote: > > On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull > > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> > &

Re: [Python-ideas] from __pip__ import

t; > On Tue, Sep 20, 2016 at 1:56 PM Paul Moore <p.f.mo...@gmail.com> wrote: > >> On 20 September 2016 at 11:46, אלעזר <elaz...@gmail.com> wrote: >> > So it should be something like >> > >> > from unsafe.__pip__ import benchmark >> > >&

Re: [Python-ideas] from __pip__ import

- is so much better. Elazar On Tue, Sep 20, 2016 at 1:56 PM Paul Moore <p.f.mo...@gmail.com> wrote: > On 20 September 2016 at 11:46, אלעזר <elaz...@gmail.com> wrote: > > So it should be something like > > > > from unsafe.__pip__ import benchmark > > > &g

Re: [Python-ideas] from __pip__ import

, and other answers will have comments saying "just add this statement to the beginning of your script". On Mon, Sep 19, 2016 at 11:24 PM Paul Moore <p.f.mo...@gmail.com> wrote: > On 19 September 2016 at 19:52, אלעזר <elaz...@gmail.com> wrote: > > Of course it doesn't a

Re: [Python-ideas] Delay evaluation of annotations

On Fri, Sep 23, 2016 at 4:17 AM Nick Coghlan wrote: ... > As others have noted, the general idea of allowing either a > placeholder name or the class name to refer to a suitable type > annotation is fine, though - that would be a matter of implicitly > injecting that name

Re: [Python-ideas] Delay evaluation of annotations

On Fri, Sep 23, 2016 at 5:54 AM Chris Angelico wrote: > On Fri, Sep 23, 2016 at 12:35 PM, Steven D'Aprano > wrote: > > The straight-forward and simple way of writing a recursive spam() > > function surprises beginners, but they might go years or their

Re: [Python-ideas] Delay evaluation of annotations

On Fri, Sep 23, 2016 at 6:06 AM Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, Sep 22, 2016 at 07:21:18PM +0000, אלעזר wrote: > > On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano <st...@pearwood.info> > wrote: > > > > > On Thu, Sep 22, 2016 at 05:19:

Re: [Python-ideas] Delay evaluation of annotations

On Fri, Sep 23, 2016 at 6:24 AM Nick Coghlan <ncogh...@gmail.com> wrote: > On 23 September 2016 at 13:06, Steven D'Aprano <st...@pearwood.info> > wrote: > > On Thu, Sep 22, 2016 at 07:21:18PM +, אלעזר wrote: > >> "Expression" is somet

Re: [Python-ideas] Delay evaluation of annotations

On Fri, Sep 23, 2016 at 3:11 PM Steven D'Aprano <st...@pearwood.info> wrote: > On Fri, Sep 23, 2016 at 10:17:15AM +0000, אלעזר wrote: > > On Fri, Sep 23, 2016 at 6:06 AM Steven D'Aprano <st...@pearwood.info> > wrote: > > > On Thu, Sep 22, 2016 at 07:21:18PM +,

Re: [Python-ideas] Delay evaluation of annotations

On Fri, Sep 23, 2016 at 12:05 AM Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 22 September 2016 at 22:02, אלעזר <elaz...@gmail.com> wrote: > >> On Thu, Sep 22, 2016 at 10:58 PM David Mertz <me...@gnosis.cx> wrote: >> >>> On Thu, Sep 22, 2016

Re: [Python-ideas] Delay evaluation of annotations

On Fri, Sep 23, 2016 at 12:18 AM Chris Angelico wrote: > # Recursion in functions > def spam(): > return spam() > I just note that it *is* surprising, for most users, that you can't be sure that this is a recursion, yet. So it if you want a trusted-upon recursion you

Re: [Python-ideas] Delay evaluation of annotations

On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano <st...@pearwood.info> wrote: > On Thu, Sep 22, 2016 at 05:19:12PM +0000, אלעזר wrote: > > Hi all, > > > > Annotations of function parameters and variables are evaluated when > > encountered. > > Right, like

Re: [Python-ideas] Delay evaluation of annotations

On Thu, Sep 22, 2016 at 10:45 PM David Mertz <me...@gnosis.cx> wrote: > On Thu, Sep 22, 2016 at 12:35 PM, אלעזר <elaz...@gmail.com> wrote: > >> In such a hypothetical future world we might come to allow, e.g. >>> `Sequence[#CustomThing]` where some gen

Re: [Python-ideas] Delay evaluation of annotations

On Thu, Sep 22, 2016 at 11:02 PM David Mertz <me...@gnosis.cx> wrote: > On Thu, Sep 22, 2016 at 12:59 PM, אלעזר <elaz...@gmail.com> wrote: > >> I don't If this feature is "nice, but does not worth the complication", >>> then so be it; I can't claim I

Re: [Python-ideas] Delay evaluation of annotations

On Thu, Sep 22, 2016 at 10:58 PM David Mertz <me...@gnosis.cx> wrote: > On Thu, Sep 22, 2016 at 12:35 PM, אלעזר <elaz...@gmail.com> wrote: > >> I think we're talking about different things here. I just referred to the >> common need to use the name of the cu

Re: [Python-ideas] Delay evaluation of annotations

On Thu, Sep 22, 2016 at 11:02 PM David Mertz <me...@gnosis.cx> wrote: > On Thu, Sep 22, 2016 at 12:59 PM, אלעזר <elaz...@gmail.com> wrote: > >> I don't If this feature is "nice, but does not worth the complication", >>> then so be it; I can't claim I

Re: [Python-ideas] Make partial a built-in

On Tue, Sep 20, 2016 at 9:18 PM Stephan Houben wrote: > I must admit I am a bit partial to partial, you can do fun things like > this: > > >>> from functools import partial > >>> @partial(partial, partial) > ... def add(x, y): > ... return x+y > ... > >>> add(3)(4) > 7

Re: [Python-ideas] Make partial a built-in

On Wed, Sep 21, 2016 at 12:04 AM Terry Reedy wrote: > On 9/20/2016 11:51 AM, Guido van Rossum wrote: > > ... (The greater flexibility of lambda, pointed out by David Mertz, is > another.) > > I just wanted to point out that the greater flexibility of lambda is a very good

Re: [Python-ideas] Make partial a built-in

is outside the whole class, it might be very far away from your logic, doing a very simple thing that is not needed anywhere else. Elazar On Wed, Sep 21, 2016 at 5:32 AM Dan Sommers <d...@tombstonezero.net> wrote: > On Tue, 20 Sep 2016 15:29:36 +, אלעזר wrote: > > > The alter

Re: [Python-ideas] typing.modifiers

On Fri, Sep 16, 2016 at 1:16 PM Steven D'Aprano <st...@pearwood.info> wrote: > On Fri, Sep 16, 2016 at 12:10:22AM +0000, אלעזר wrote: > > [...] > > Benefits of putting such a collection in stdlib (instead of as an > external > > package) include: > > Slow do

Re: [Python-ideas] from __pip__ import

laz...@gmail.com> wrote:‬ > On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> אלעזר writes: >> >> > Another use case, though I admit not the top priority of anyone here, >> is >> > that of assig

Re: [Python-ideas] from __pip__ import

On Tue, Sep 20, 2016 at 2:34 AM Chris Angelico <ros...@gmail.com> wrote: > On Tue, Sep 20, 2016 at 9:20 AM, Stephen J. Turnbull > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > אלעזר writes: > > > > > Another use case, though I ad

Re: [Python-ideas] from __pip__ import

But grepping and piping could work I assume? On Tue, Sep 20, 2016 at 2:41 AM Chris Angelico wrote: > On Tue, Sep 20, 2016 at 9:27 AM, Xavier Combelle > wrote: > > I find the idea of tracking the dependencies in the script might be a > > good idea. >

Re: [Python-ideas] from __pip__ import

On Tue, Sep 20, 2016 at 3:06 AM Ethan Furman <et...@stoneleaf.us> wrote: > On 09/19/2016 04:38 PM, אלעזר wrote: > > > I was talking specifically about advanced courses, in which an assignment > > is "implement a side-channel attack using data" and you can

Re: [Python-ideas] from __pip__ import

AM, MRAB <pyt...@mrabarnett.plus.com> wrote: > > On 2016-09-19 18:20, אלעזר wrote: > >> > >> Obviously > >> > >> from __pip__ import "run-lambda>=0.1.0" > >> > >> Which is ugly but not my fault :) > >> >

Re: [Python-ideas] from __pip__ import

nonesuch (from > versions: ) > No matching distribution found for nonesuch > 1 > > > On Mon, Sep 19, 2016 at 3:46 PM, אלעזר <elaz...@gmail.com> wrote: > >> On Tue, Sep 20, 2016 at 1:40 AM Paul Moore <p.f.mo...@gmail.com> wrote: >> >>> On 19 Septemb

Re: [Python-ideas] from __pip__ import

On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > אלעזר writes: > > > Another use case, though I admit not the top priority of anyone here, is > > that of assignment checkers. In most courses I took at the universit

Re: [Python-ideas] typing.modifiers

Thank you all! אלעזר (AKA Elazar) On Sat, Sep 17, 2016 at 4:53 AM Steven D'Aprano <st...@pearwood.info> wrote: > On Sat, Sep 17, 2016 at 03:39:08AM +1000, Chris Angelico wrote: > > On Fri, Sep 16, 2016 at 11:22 PM, אלעזר <elaz...@gmail.com> wrote: > > > P.S.

[Python-ideas] Delay evaluation of annotations

Hi all, Annotations of function parameters and variables are evaluated when encountered. This makes it necessary to use string representation for names that are not yet bound, which affects almost every class definition. It is also easy to forget, and the result might be a (very uninteresting)

Re: [Python-ideas] Suggestion: Clear screen command for the REPL

"Bash on Ubuntu on windows" responds to CTRL+D just fine. I don't really know how it works, but it looks like it is based on the Windows terminal emulator. Elazar בתאריך יום ה׳, 29 בספט' 2016, 06:36, מאת Chris Angelico ‏: > On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano

Re: [Python-ideas] Delay evaluation of annotations

Thank you all. I think this thread is pretty much close by now. I understand at least most of your concerns and I will take time to shape my idea. I wanted to note one last thing, though, regarding my claim that annotations are not actually standard expressions: Guido had once expressed his

Re: [Python-ideas] Delay evaluation of annotations

3, 2016 at 11:58 PM, אלעזר <elaz...@gmail.com> wrote: > "Unknown evaluation time" is scary. _for expressions_, which might have > side > > effects (one of which is running time). But annotations must be pure by > > convention (and tools are welcome to warn about it)

Re: [Python-ideas] Delay evaluation of annotations

small the change to fix the > > second command is, it only matters that it *would* have to change in > > some way. > > This is a bit unfair to אלעזר, although it's been a long thread so I > can understand why some of his ideas have gone missing. His proposals > have g

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

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]. All the examples follow this intuition, IIUC. Elazar בתאריך יום ד׳, 12

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

Mertz <me...@gnosis.cx> wrote: > > On Wed, Oct 12, 2016 at 12:38 PM, אלעזר <elaz...@gmail.com> wrote: > > What is the intuition behind [1, *x, 5]? The starred expression is > replaced with a comma-separated sequence of its elements. > > I've never actually used the `[

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

בתאריך יום ו׳, 14 באוק' 2016, 12:19, מאת Michel Desmoulin ‏< desmoulinmic...@gmail.com>: > Regarding all those examples: > > Le 14/10/2016 à 00:08, אלעזר a écrit : > > Trying to restate the proposal, somewhat more formal following Random832 > > and Paul's suggestion.

Re: [Python-ideas] PEP 505 -- None-aware operators

On Fri, Oct 14, 2016 at 4:14 PM Gustavo Carneiro wrote: > Sorry if I missed the boat, but only just now saw this PEP. > > Glancing through the PEP, I don't see mentioned anywhere the SQL > alternative of having a coalesce() function: >

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

On Thu, Oct 13, 2016 at 5:10 PM Steven D'Aprano wrote: > On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote: > > About the list constructor: we construct a list by writing [a,b,c] or by > > writing [b for b in bs]. The end result is a list > > I construct lists

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

On Thu, Oct 13, 2016 at 11:42 PM Paul Moore wrote: > I remain puzzled. > > Given the well-documented and understood transformation: > > [fn(x) for x in lst if cond] > > translates to > > result = [] > for x in lst: >if cond: > result.append(fn(x)) > > please can

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

On Thu, Oct 13, 2016 at 2:35 AM Steven D'Aprano <st...@pearwood.info> wrote: > On Wed, Oct 12, 2016 at 04:11:55PM +0000, אלעזר wrote: > > > Steve, you only need to allow multiple arguments to append(), then it > makes > > perfect sense. > > I think you're m

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

Steve, you only need to allow multiple arguments to append(), then it makes perfect sense. בתאריך יום ד׳, 12 באוק' 2016, 18:43, מאת Steven D'Aprano ‏< st...@pearwood.info>: > On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote: > > Hello list > > > > I love the "new" unpacking

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

On Sat, Oct 15, 2016 at 8:45 PM Chris Angelico <ros...@gmail.com> wrote: > On Sun, Oct 16, 2016 at 4:38 AM, אלעזר <elaz...@gmail.com> wrote: > > On Sat, Oct 15, 2016 at 8:36 PM Chris Angelico <ros...@gmail.com> wrote: > >> > >> On Sun, Oct 16, 201

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

On Sat, Oct 15, 2016 at 1:49 PM Steven D'Aprano wrote: ... > And the transformation of *t for the items of t (I don't care if it is a > real transformation in the implementation, or only a fictional > transformation) cannot work in a list comp. Let's make the number of >

Re: [Python-ideas] Settable defaulting to decimal instead of float

I think such proposals are special cases of a general theme: a compiler pragma, similar to "from __future__", to make Python support domain-specific syntax in the current file. Whether it's decimal literals or matrix/vector literals etc. I think it will be nice to make some tool, external to

Re: [Python-ideas] Positional-only parameters

On Wed, Mar 1, 2017 at 9:26 PM Serhiy Storchaka wrote: > On 28.02.17 23:17, Victor Stinner wrote: > > My question is: would it make sense to implement this feature in > > Python directly? If yes, what should be the syntax? Use "/" marker? > > Use the @positional() decorator?

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On Fri, Jul 28, 2017 at 12:51 AM Chris Angelico wrote: > On Fri, Jul 28, 2017 at 7:22 AM, Pavol Lisy wrote: > > > We have: > > from module import x, y, z # where order is not important > > > > Could we have something similar with ntuple (SimpleNamespace,

Re: [Python-ideas] fnmatch.filter_false

There shouldn't be any difference at all. Checking the for invert can be outside of the loop, which will make the loop itself exactly as it is now. Just like what's been done with normcase. On Wed, May 17, 2017 at 8:55 PM wrote: > Top posting, apologies. > > I'm sure

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

On Mon, May 15, 2017 at 6:30 PM Guido van Rossum wrote: > This should be worked into a PEP, instead of living on as a bunch of python-ideas posts and blogs. ... > Will someone please write a PEP? If by "this" you mean adding to stdlib something like @record class Point:

Re: [Python-ideas] Allow function to return multiple values

What is the difference between returning a tuple and returning two values? I think at least theoretically it's different wording for precisely the same thing. Elazar בתאריך יום ה׳, 1 ביונ' 2017, 17:21, מאת Markus Meskanen ‏< markusmeska...@gmail.com>: > Why isn't a tuple enough? You can do

Re: [Python-ideas] Membership of infinite iterators

בתאריך יום ג׳, 17 באוק׳ 2017, 00:13, מאת Terry Reedy ‏: > On 10/15/2017 9:12 PM, Jason Campbell wrote: > ... > > itertools.cycle could use membership from the underlying iterable > > If the underlying iterable is an iterator, this does not work. You > could define a Cycle class

[Python-ideas] Add a more disciplined ways of registering ABCs

Hi all, tl;dr: I propose adding a `register()` decorator, to be used like this: @abc.register(Abc1, Abc2) class D: ... For preexisting classes I propose adding a magic static variable `__registered__`, to be handled by ABCMeta: class Abc1(metaclass=ABCMeta):

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

On Mon, Sep 11, 2017 at 10:07 PM Lukasz Langa wrote: > This is off topic for discussion of this PEP. > > It would require another one (essentially an extension of PEP 484) to get > passed for your idea to be standardized. > I'm not sure whether this is directed to me; so just

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

I like it. For previous discussion of this idea see here: https://mail.python.org/pipermail/python-ideas/2016-September/042527.html I don't see this mentioned in the PEP, but it will also allow (easy) description of contracts and dependent types. Elazar On Mon, Sep 11, 2017 at 6:59 PM Lukasz

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

On Mon, Sep 11, 2017 at 8:58 PM Steven D'Aprano <st...@pearwood.info> wrote: > On Mon, Sep 11, 2017 at 04:06:14PM +0000, אלעזר wrote: > > I like it. For previous discussion of this idea see here: > > > https://mail.python.org/pipermail/python-ideas/2016-September/042527.

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

בתאריך יום ג׳, 21 בנוב׳ 2017, 19:36, מאת Chris Barker ‏< chris.bar...@noaa.gov>: > ... > And what's the use-case, really? beyond the use case for all sorts of > static typing... > I don't understand the question. The use case was explained before - people want to have better ways to reason

[Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?

Hi, The dangers of eval and exec are obvious and well known to advanced users, but the availability as built-in functions makes it too tempting for beginners or even medium-level programmers. You can see questions about these function pretty often in stackoverflow (roughly once a day

Re: [Python-ideas] Looking for input to help with the pip situation

On Tue, Nov 7, 2017 at 2:45 PM Nick Coghlan wrote: > On 7 November 2017 at 03:52, Michel Desmoulin > wrote: > And assume that stuff in any tutorial you make they know this stuff. > > > > This is a strong barrier or entry IMO. > > Sure, but it's

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

On Tue, Oct 31, 2017 at 12:18 PM Koos Zevenhoven wrote: > On Tue, Oct 31, 2017 at 11:24 AM, Petr Viktorin wrote: > >> On 10/31/2017 09:54 AM, Koos Zevenhoven wrote: >>> >>> >>> ​I wonder if that's more easily understood if you write it along these >>>