[Python-ideas] Re: A memory map based data persistence and startup speedup approach
> 严懿宸(文极) via Python-ideas writes: > > Currently, we’ve made it a third-party library and have been > > working on open-sourcing. Stephen J. Turnbull wrote: > Thank you! I guess "working on" means "the lawyers have it" so we'll > be patient. :-) > I'm not sure whether your purpose is to get code review, or general > exposure. If the former, you might get better results from the Speed > list (https://mail.python.org/mailman3/lists/speed.python.org/). If > the latter, you should also post to python-list > (https://mail.python.org/mailman/listinfo/python-list or > comp.lang.python on Usenet). I'm not sure whether the speed list is still active. I'd personally try python-...@python.org or the python-dev section on discuss.python.org. (Full disclosure: I have seen earlier versions of Yichen's group's work and I am very impressed.) --Guido ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6543VS7PLYRSF3Q7GYGZZRAF5NT2KMCZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP7 may need to add a info
Good catch! You can submit a PR or issue to the peps project in the Python organization on GitHub. On Fri, Dec 3, 2021 at 00:24 wrote: > Hi! > When I read PEP7 and check Cpython source code, I found a deficiency that > in https://www.python.org/dev/peps/pep-0007/#code-lay-out. > In this section, document said that > ''' > For external functions and variables, we always have a declaration in an > appropriate header file in the "Include" directory, which uses the > PyAPI_FUNC() macro, like this: > PyAPI_FUNC(PyObject *) PyObject_Repr(PyObject *); > ''' > but when i check python 3.7.12+ and python 2.7.13, external variables > actually uses the PyAPI_DATA() macro, like this: > ''' > PyAPI_DATA(PyTypeObject) PySuper_Type; /* built-in 'super' */ > ''' > I wondered whether my error or the document error. > bobozi. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/B6YJ6DNHYJ3PHMCXYROT7ZILFXYGCSRR/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RQ7K25GP7HJCYEBSXL35HB24WET6WQDT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Runtime-accessible attribute docstrings
+1
On Thu, Nov 18, 2021 at 09:31 Michael Foord wrote:
>
>
> On Thu, 18 Nov 2021 at 04:38, Steven D'Aprano wrote:
>
>> On Wed, Nov 17, 2021 at 02:26:16PM -, tmkehrenb...@gmail.com wrote:
>>
>> > @dataclass
>> > class A:
>> > """Docstring for class A."""
>> > x: int
>> > """Docstring for x"""
>> > y: bool = True
>> > "Docstring for y"
>> >
>> > It is a bit awkward that the docstring is *below* the definition of the
>> > attribute, but it can't be put above because it could be confused for
>> > the class docstring.
>>
>> Function and class docstrings follow *below* the function/class
>> signature, so I don't think that's a problem.
>>
>> However a real problem is that bare strings like that are already legal,
>> although only as a no-op. People sometimes use them as multiline
>> comments.
>>
>> So we would have no real way of distinguishing between these cases:
>>
>> class A:
>> """Docstring for class A."""
>> x: int
>> """Docstring for x"""
>> y: bool = True
>> """Just a comment."""
>>
>> Making such strings syntactically meaningful would be a breaking change,
>> although one with a very small impact. (Some strings which were
>> previously ignored by the interpreter will now be kept in memory as
>> docstrings.)
>>
>>
> It wouldn't be a breaking change, there's no compatibility issue as
> nothing could break from this. It's a new feature so you'd have an
> unexpected attribute docstring that you're not using.
>
> Michael
>
>
>
>>
>> > My proposal would be to just enshrine this syntax as the syntax for
>> > attribute docstring, and to make them available at runtime. They would
>> > be stored in a dictionary like the type annotations. For example like
>> > this:
>> >
>> > A.__attrdoc__ == {"x": "Docstring for x", "y": "Docstring for y"}
>>
>> You could get that same effect with a decorator:
>>
>>
>> @attrdoc(x="Doctring for x",
>> y="Doctring for y")
>> class A:
>> """Class docstring."""
>> x: int
>> y: bool = True
>>
>>
>> There's some duplication of the names, which is sad, but otherwise I
>> don't mind it.
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/2F7CZRNSEEWRIBUFTTR3CBTLWO6APKJW/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
>
> Michael Foord
>
> Python Consultant, Contractor and Trainer
>
> https://agileabstractions.com/
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/OGSJU4YK6WX6FNK3C5BWCOPYCZMHRJ4P/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JCMMFJO3VSEPQN5YMALAL55GW2XM5ALS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding pep8-casing-compliant aliases for the entire stdlib
One thought: No. On Thu, Nov 11, 2021 at 05:41 Matt del Valle wrote: > So I was reading the docs for the `threading` module and I stumbled upon > this little note: > > Note: > > In the Python 2.x series, this module contained camelCase names for some > methods and functions. These are deprecated as of Python 3.10, but they are > still supported for compatibility with Python 2.5 and lower. > > > And it got me thinking. > > Given that there is some precedent, would it be feasible to make a > concerted effort to add aliases across the board for all public-facing > stdlib types and functions that don't follow pep8-recommended casing? > > I realize that large chunks of the stdlib predates pep8 and therefore use > various non-uniform conventions. For example, the logging module is fully > camelCased, and many core types like `str` and `list` don't use PascalCase > as pep8 recommends. The `collections` module is a veritable mosaic of > casing conventions, with some types like `deque` and `namedtuple` being > fully lowercased while others like `Counter` and `ChainMap` are PascalCased. > > > My motivation for this twofold: > > 1) I'll confess that this has just always been a wart that has bothered me > way more than it has any right to. I just *hate* it. Somewhere deep > inside my lizard-brain it makes me unhappy to have disparate naming > conventions in my code. I realize this isn't a good reason in and of itself > but I wonder if this might not be the case for others as well. While I've > come to accept it because that's just how it is, maybe it doesn't have to > be this way? > > 2) It's always been an extra thing to explain when teaching python to > someone. I always try to cover pep8 very early to discourage people I'm > training from internalizing bad habits, and it means you have to explain > that the very standard library itself contains style violations that would > get flagged in most modern code reviews, and that they just have to keep in > mind that despite the fact that the core language does it, they should not. > > > So the scope of my suggestion is as follows: > > - lowercase types become PascalCase (e.g., `str` -> `Str`, > `collections.defaultdict` -> `collections.DefaultDict`) > > - lowercase attributes/functions/methods become snake_case (no changes for > names that only contain a single word, so `str.lower()` would be > unaffected, but `str.removeprefix()` would get the alias > `str.remove_prefix()`) > > - pep8 and the python docs are updated to state that the pep8-compliant > forms of stdlib names should be strongly preferred over the legacy names, > and that IDEs and linters should include (configurable?) weak warnings to > discourage the use of legacy-cased stdlib names > > - `help()` would be special-cased for builtin types to no longer display > any current non-pep8-compliant names, and the python docs would also no > longer show them, instead only making a note at the top of the page as with > the `threading` module. > > > Given the horrors of the python 2.7 schism I don't think there's any rush > to officially deprecate or remove the current non-pep8 names at all. I > think that's the sort of thing that can happily and fully be kicked down > the road. > > If we add aliases and they see widespread adoption to the point where the > non-pep8 forms are barely ever even seen out in the wild then maybe in 10 > or 20 years time when the steering council is deliberating on a new major > python version they can consider rolling the removal of legacy badly-cased > names into it. And if not then no big deal. > > So yeah, thoughts? > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/4MRTK7XL7LUJ3YAZ4UXEEUTM3LS4TMER/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/M2H6J7ABPKJNQGJBEDI4M5PLMRJ6EHXY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
Agreed, class namespaces are weird. :-) On Sun, Oct 31, 2021 at 23:38 Chris Angelico wrote: > On Mon, Nov 1, 2021 at 5:15 PM Greg Ewing > wrote: > > > > On 1/11/21 4:59 am, David Mertz, Ph.D. wrote: > > > b = b > > > > I don't want to live in a universe where this could be anything > > other than a no-op in Python. > > > > Be careful what you say: there are some technicalities. If you mean > that it won't change the behaviour of the object referred to by b, > then I absolutely agree, but there are ways that this can be more than > a no-op. Notably, it has very good meaning as a keyword argument (it > means "pass b along, named b"), and as a function parameter (meaning > "accept b, defaulting to b from the outer scope"); and even as a > stand-alone statement, it isn't technically meaningless (it'll force b > to be a local). > > But yes, I agree that I don't want this to force the evaluation of > something, which continues to be called b. Even though that's > technically possible already if you have a weird namespace, I wouldn't > call that a good way to write code. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/HQI3ULA6ZAYEHU7JMKZYLLTAG2IFWIVI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YSQZOQ4TG7X2KBEOR37GMBQOTPECMTPI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671 proof-of-concept implementation
once again, you're offering something that is often correct and > sometimes a flat-out lie, where I'm offering something that adds a > clear and obvious structure. If you naively assume that everything in > __defaults__ is a two-element tuple (which is the case for early-bound > defaults), you'll get an obvious IndexError when you hit a late-bound > default, so even a basic adjustment will still be safe. By your > method, unless something is aware of late defaults, it will subtly get > things wrong. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BEQ25J4HICMLQVSQNNLGHAZNAXTJ74TL/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HJVU57PV4OUOQEXV5FGOUCY5NYU56OKQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __len__ to ipaddress._BaseNetwork
BEst thing you can do is create an issue on bugs.python.org and attach a
pull request that makes _BaseNetwork a subclass of Sequence. Then maybe the
advantages will be clear -- or maybe in the process of writing the code you
realize that the idea is not so good after all. (I'm not a user of this
class so I don't have an opinion either way.)
On Tue, Oct 26, 2021 at 6:41 AM wrote:
> Currently, ipaddress._BaseNetwork (and by extension, ipaddress.IPv4Network
> and ipaddress.IPv6Network) does not have a __len__ method, it only has
> num_addresses.
>
> This makes the following code not work:
>
> >>> random.choice(ipaddress.ip_network('6.0.0.0/8'))
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/nyuszika7h/.pyenv/versions/3.10.0/lib/python3.10/random.py",
> line 378, in choice
> return seq[self._randbelow(len(seq))]
> TypeError: object of type 'IPv4Network' has no len()
>
> The workaround is a bit ugly:
>
> >>> (network := ipaddress.ip_network('
> 6.0.0.0/8'))[random.randrange(network.num_addresses
> <http://6.0.0.0/8'))%5Brandom.randrange(network.num_addresses>)]
> IPv4Address('6.60.184.142')
>
> With a custom subclass, all works well:
>
> >>> class MyIPv4Network(ipaddress.IPv4Network):
> ... def __len__(self):
> ... return self.num_addresses
> ...
> >>> random.choice(MyIPv4Network('6.0.0.0/8'))
> IPv4Address('6.40.110.63')
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4OHZ6QZWDI3U2ADI5A36UU73OOXFOGJE/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/7SLNYEPBUJMZY2JL6YJCJZJKUKJCM2AK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
There are other options. Maybe you can't combine early and late binding defaults in the same signature. Or maybe all early binding defaults must precede all late binding defaults. FWIW have you started an implementation yet? "If the implementation is easy to explain, ..." On Mon, Oct 25, 2021 at 10:49 AM Chris Angelico wrote: > On Tue, Oct 26, 2021 at 4:36 AM Guido van Rossum wrote: > > > > On Mon, Oct 25, 2021 at 10:28 AM Chris Angelico > wrote: > >> > >> [...] The two options on the table are: > >> > >> 1) Allow references to any value that has been provided in any way > >> 2) Allow references only to parameters to the left > >> > >> Option 2 is a simple SyntaxError on compilation (you won't even get as > >> far as the def statement). Option 1 allows everything all up to the > >> point where you call it, but then might raise UnboundLocalError if you > >> refer to something that wasn't passed. > > > > > > Note that if you were to choose the SyntaxError option, you'd be > breaking new ground. Everywhere else in Python, undefined names are runtime > errors (NameError or UnboundLocalError). > > > > I'm considering this to be more similar to mismatching local and > global usage, or messing up nonlocal names: > > >>> def spam(): > ... ham > ... global ham > ... > File "", line 3 > SyntaxError: name 'ham' is used prior to global declaration > >>> def spam(): > ... def ham(): > ... nonlocal eggs > ... > File "", line 3 > SyntaxError: no binding for nonlocal 'eggs' found > > The problem is the bizarre inconsistencies that can come up, which are > difficult to explain unless you know exactly how everything is > implemented internally. What exactly is the difference between these, > and why should some be legal and others not? > > def f1(x=>y + 1, y=2): ... > def f2(x=>y + 1, y=>2): ... > def f3(x=>y + 1, *, y): ... > def f4(x=>y + 1): y = 2 > def f5(x=>y + 1): > global y > y = 2 > > And importantly, do Python core devs agree with less-skilled Python > programmers on the intuitions? > > If this should be permitted, there are two plausible semantic meanings > for these kinds of constructs: > > 1) Arguments are defined left-to-right, each one independently of each > other > 2) Early-bound arguments and those given values are defined first, > then late-bound arguments > > The first option is much easier to explain, but will never give useful > results for out-of-order references (unless it's allowed to refer to > the containing scope or something). The second is closer to the "if x > is None: x = y + 1" equivalent, but is harder to explain. > > Two-phase initialization is my second-best preference after rejecting > with SyntaxError, but I would love to see some real-world usage before > opening it up. Once permission is granted, it cannot be revoked, and > it might turn out that one of the other behaviours would have made > more sense. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/46ZWYA2Q6TQGKTYA5Z5MLPXZLM6ABAH5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RJX3N23RMK2M7CXALRUKHVKELMBWQVFU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
On Mon, Oct 25, 2021 at 10:28 AM Chris Angelico wrote: > [...] The two options on the table are: > > 1) Allow references to any value that has been provided in any way > 2) Allow references only to parameters to the left > > Option 2 is a simple SyntaxError on compilation (you won't even get as > far as the def statement). Option 1 allows everything all up to the > point where you call it, but then might raise UnboundLocalError if you > refer to something that wasn't passed. > Note that if you were to choose the SyntaxError option, you'd be breaking new ground. Everywhere else in Python, undefined names are runtime errors (NameError or UnboundLocalError). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JXHIOW7A6SZONPCAFFRCDZD2C5VIMVCK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax for late-bound arguments
More about thunks. I've resisted the temptation to look at the Wikipedia page -- this is from memory. On Sat, Oct 23, 2021 at 11:39 PM Steven D'Aprano wrote: > > I would prefer to see this situation handled as part of a > > larger-scale > > change of adding some kind of "inline lambda" which executes directly in > > the calling scope. > > That would be what I called a "thunk" in two posts now, stealing the > term from Algol. > > It would be nice if one of the core devs who understand the deep > internals of the interpreter could comment on whether that sort of > delayed evaluation of an expression is even plausible for Python. > IIRC, a thunk in Algol was more or less defined as "substitute the argument in each use". There was no expression in the function definition, just an argument. Translating to Python, we'd have something like this (all arguments were thunks by default): def foo(arg): print(arg) arg = arg + 1 x = 42 foo(x) print(x) This would print 42 and 43. Writing foo(42) would produce an error. But if you had another function def bar(arg) print(arg) it would be okay to write bar(42). A key property (IIRC) was that the thunk would be evaluated each time it was used. This led to "Jensen's device" where you could write def foo(a, b, n): total = 0 for a in range(1, n+1): # IIRC Algol spelled this 'for a := 1 to n' total += b return total and you'd call it like this: foo(x, x**2, 10) which would compute the sum of the squares of i for i i range(10). It went out of style because it was complex to implement and expensive to execute -- for example, the 'n' argument would be a thunk too. You can't easily introduce this in Python because Python is built on not knowing the signature of foo when the code for the call foo(x, x**2, 10) is compiled. So it wouldn't be sufficient to mark 'a' and 'b' as thunks in the 'def foo(a, b, n)' line. You'd also have to mark the call site. Suppose we introduce a \ to indicate thunks in both places. (This is the worst character but enough to explain the mechanism.) You'd write def foo(\a, \b, n): total = 0 for a in range(1, n+1): total += b return total and you'd call it like x = None # dummy foo(\x, \x**2, 10) Now the compiler has enough information to compile code for the thunks. Since thunks can be used as l-values as well as r-values, there would be two hidden functions, one to get the value, another to set it. The call would pass an object containing those two functions and the code in the callee would translate each use of a thunk argument into a call to either the getter or the setter. Above, the getter functions for x and x**2 are simple: get_a = lambda: x get_b = lambda: x**2 (Defined in the caller's scope.) The setter function for the first argument would be a bit more complex: def set_a(val): nonlocal x x = val The second argument's setter function is missing, since 'x+42' is not an l-value. (We'd get a runtime error if foo() assigned to b.) If we wanted thunks without assignment and without Jensen's device, we would only need a getter function. Then \x in the caller would just pass lambda: x, and an argument marked with \a in a function definition would cause code to be generated that calls it each time it is used. Getting rid of the need to mark all thunk arguments in the caller would require the compiler to have knowledge of which function is being called. That would require an amount of static analysis beyond what even mypy and friends can do, so I don't think we should try to pursue that. The key property of a thunk, IMO, is that it is evaluated in the caller's scope. It's no different than a function defined in the caller. I don't think it would be a good substitute for late-binding default arguments. (You could make something up that uses dynamic scoping, but that's a whole different can of worms.) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WLRGA3GYYGYY3TDEOEKXR52OEJRALAR2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults
On Sat, Oct 23, 2021 at 9:21 PM Chris Angelico wrote: > On Sun, Oct 24, 2021 at 2:52 PM David Mertz, Ph.D. > wrote: > > > > On Sat, Oct 23, 2021, 11:46 PM David Mertz, Ph.D. > >>> > >>> def f(x=defer: a + b): > >>> a, b = 3, 5 > >>> return x > >>> > >>> Would this return 8, or a defer-expression? If 8, then the scope isn't > truly dynamic, since there's no way to keep it deferred until it moves to > another scope. If not 8, then I'm not sure how you'd define the scope or > what triggers its evaluation. > > > > > > Oh... Keep in mind I'm proposing a strawman deliberately, but the most > natural approach to keeping an object deferred rather than evaluated is > simply to say so: > > > > def f(x=defer: a + b): > > a, b = 3, 5 > > fn2(defer: x) # look for local a, b within fn2() if needed > > # ... other stuff > > return x # return 8 here > > > > How would it know to look for a and b inside fn2's scope, instead of > looking for x inside fn2's scope? > I am worried that this side-thread about dynamic scopes (which are a ridiculous idea IMO) will derail the decent proposal of the PEP. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/67GZJXK7LIXT5EG5TX6T5TGPUVXHWB5A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Syntax for late-bound arguments
I like that you're trying to fix this wart! I think that using a different syntax may be the only way out. My own bikeshed color to try would be `=>`, assuming we'll introduce `(x) => x+1` as the new lambda syntax, but I can see problems with both as well :-). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T4VPHDZJUP4QYIXJA26JQ6EQJJKRUEYP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions
On Sun, Oct 17, 2021 at 4:38 PM Steven D'Aprano wrote: > Right-o, the old "heterogeneous tuples versus homogeneous lists" > distinction, I remember that from the old 1.5 days. I haven't heard it > mentioned for a long time! > You must not have looked at type annotations then. :-) Type annotations legitimize this, by favoring the syntax list[int] for a homogeneous list versus tuple[int, str, bool] for a heterogeneous tuple. (There's a syntax for a homogeneous tuple too, but it's intentionally slightly longer.) So this rule of thumb is definitely not dead (as you seemed to imply). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/E5XVQE4WZJGLIQGLPOHU64T4YQZUC4XG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions
On Sat, Oct 16, 2021 at 12:21 PM David Mertz, Ph.D. wrote: > I'm not making any claims about tuple creation speed vs. list creation on > microbenchmarks. It might we'll be 10% faster to create a million item > tuple than a million item list. Or maybe the opposite, I don't know. > The thing to know about this (for everyone) is that creating a new tuple of known size requires a single allocation while creating a new list always requires two allocations. Where this really makes a difference is not when you have a million items but when you create thousands or millions of objects of modest size -- for lists it takes twice as many allocations. If the number of items is not known there are different strategies depending on what API you use; interestingly, the strategy deployed by PySequence_Tuple() has a comment claiming it "can grow a bit faster than for lists because unlike lists the over-allocation isn't permanent." Finally, the bytecode generated for (*a, *b) creates a list first and then turns that into a tuple (which will be allocated with the right size since it's known at that point). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MNQBV6ORMV6DHUV44M524TCJHCLOBKI5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions
Seems sensible to me. I’d write the equivalency as
for x in y: answer.extend([…x…])
On Sat, Oct 16, 2021 at 07:11 Erik Demaine wrote:
> Extended unpacking notation (* and **) from PEP 448 gives us great ways to
> concatenate a few iterables or dicts:
>
> ```
> (*it1, *it2, *it3) # tuple with the concatenation of three iterables
> [*it1, *it2, *it3] # list with the concatenation of three iterables
> {*it1, *it2, *it3} # set with the union of three iterables
> {**dict1, **dict2, **dict3} # dict with the combination of three dicts
> # roughly equivalent to dict1 | dict2 | dict3 thanks to PEP 584
> ```
>
> I propose (not for the first time) that similarly concatenating an unknown
> number of iterables or dicts should be possible via comprehensions:
>
> ```
> (*it for it in its) # tuple with the concatenation of iterables in 'its'
> [*it for it in its] # list with the concatenation of iterables in 'its'
> {*it for it in its} # set with the union of iterables in 'its'
> {**d for d in dicts} # dict with the combination of dicts in 'dicts'
> ```
>
> The above is my attempt to argue that the proposed notation is natural:
> `[*it for it in its]` is exactly analogous to `[*its[0], *its[1], ...,
> *its[len(its)-1]]`.
>
> There are other ways to do this, of course:
>
> ```
> [x for it in its for x in it]
> itertools.chain(*its)
> sum(it for it in its, [])
> functools.reduce(operator.concat, its, [])
> ```
>
> But none are as concise and (to me, and hopefully others who understand *
> notation) as intuitive. For example, I recently wanted to write a
> recursion
> like so, which accumulated a set of results from within a tree structure:
>
> ```
> def recurse(node):
># base case omitted
>return {*recurse(child) for child in node.children}
> ```
>
> In fact, I am teaching a class and just asked a question on a written exam
> for
> which several students wrote this exact code in their solution (which
> inspired
> writing this message). So I do think it's quite intuitive, even to those
> relatively new to Python.
>
> Now, on to previous proposals. I found this thread from 2016 (!); please
> let
> me know if there are others.
>
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/SBM3LYESPJMI3FMTMP3VQ6JKKRDHYP7A/#DE4PCVNXBQJIGFBYRB2X7JUFZT75KYFR
>
> There are several arguments for and against this feature in that thread.
> I'll
> try to summarize:
>
> Arguments for:
>
> * Natural extension to PEP 448 (it's mentioned as a variant within PEP 448)
>
> * Easy to implement: all that's needed in CPython is to *remove* some code
> blocking this.
>
> Arguments against:
>
> * Counterintuitive (to some)
>
> * Hard to teach
>
> * `[...x... for x in y]` is no longer morally equivalent to
> `answer = []; for x in y: answer.append(...x...)`
> (unless `list1.append(a, b)` were equivalent to `list1.extend([a, b])`)
>
> Above I've tried to counter the first two "against" arguments.
> Some counters to the third "against" argument:
>
> 1. `[*...x... for x in y]` is equivalent to
> `answer = []; for x in y: answer.extend(...x...)`
> (about as easy to teach, I'd say)
>
> 2. Maybe `list1.append(a, b)` should be equivalent to `list1.extend([a,
> b])`?
> It is in JavaScript (`Array.push`). And I don't see why one would expect
> it to append a tuple `(a, b)`; that's what `list1.append((a, b))` is for.
> I think the main argument against this is to avoid programming errors,
> which is fine, but I don't see why it should hold back an advanced feature
> involving both unpacking and comprehensions.
>
> Erik
> --
> Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7G732VMDWCRMWM4PKRG6ZMUKH7SUC7SH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/CQPULNM6PM623PLXF5Z63BIUZGOSQEKW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Accessing target name at runtime
uitable decorator. It's a great
>> way to create a namespace. You can do all kinds of namespace-like
>> things by starting with a declarative structure and then giving that
>> to whatever function you like.
>>
>> ChrisA
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/QADKWE5MIVB43CZTRULRNLSFTRF4FFIM/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> Here is a pseudo-program showing where I would like to use this token in
> my own code if it existed. I think besides the cases where one is forced to
> always repeat the variable name as a string (namedtuple, NewType) this
> is an easy way to express clear intent to link the variable name to either
> its value or original source.
>
> >>> REGION = os.getenv(<<<)
> >>> db_url = config[REGION][<<<]
> >>>
> >>> name = arguments.get(<<<)
> >>>
> >>> con = connect(db_url)
> >>> knights = <<<
> >>> horse = <<<
> >>> con.execute(f"SELECT * FROM {knights} WHERE {horse}=?", (name,))
>
> Using the new token like this will remove bugs where the variable name was
> spelled correctly, but the string doing the lookup has a typo. Admittedly
> this
> is a small set of bugs, but I have run into them before. Where I see this
> being
> a bigger advantage is purposefully linking variables names within python to
> names outside, making it easier to refactor and easier to trace usage
> across
> an entire service and across different environments.
>
> For the other use, in factory functions, I believe we have just come to
> accept
> that it is okay to have to repeat ourselves to dynamically generate certain
> objects in a dynamic language. The fact is that variable names are relevant
> in python and can be a useful piece of information at runtime as well as
> compile time or for static analysis. This is why some objects have a
> __name__: it is useful information despite the fact it may not always be
> accurate.
>
> >>> def foo(): pass
> >>>
> >>> bar = foo
> >>> del foo
> >>> bar.__name__
> 'foo'
>
> It may not be incredibly common but it is a power that the compiler has
> that
> is not really available to the programmer. And not every place where
> variable
> name access can be used would benefit from being implemented with the
> large class object and the complex implementation of a metaclass.
>
> Regards,
> ~ Jeremiah
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7EKOQIYWGI3ARZH4QL77SSUWTOULGQN7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FGP2AAAFNGSKHTAYVNQEXWW6PO2E6VUE/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing additional string operators
Maybe we should only accept operators as aliases for existing methods. x-y could mean x.removesuffix(y) I don't think x~y is intuitive enough to use. On Wed, Oct 13, 2021 at 8:03 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > Chris Angelico writes: > > > +1, although it's debatable whether it should be remove suffix or > > remove all. I'd be happy with either. > > If by "remove all" you mean "efefef" - "ef" == "", I think that's a > footgun. Similarly for "efabcd" - "ef" == "abcdef" - "ef". > > Steve > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/UGRD4QCDGRPOOCDMLPZ7EXWJFKM22AGO/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XASP7G7O74AHFNBLVFQN6WKFDYEHCUEZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On Tue, Oct 12, 2021 at 5:21 PM Jeremiah Vivian < nohackingofkrow...@gmail.com> wrote: > So I guess I'll just have to keep this to myself. > I know this is disappointing, but in this case I agree with Jelle -- this particular idea does not fit well in Python's design, it looks like an attempt at saving one opcode (or a few characters to type) for a relatively rare use case. However, I recommend that you don't give up! There are many ways Python can still use improvement, and a few more attempts will help you calibrate your ideas with what might be acceptable. I would also like to remind various other posters that sarcasm is *not* a good way to welcome newbies. The name of the list is python-ideas, not python-ideas-to-shoot-down-sarcastically. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DB6E55DGSAUORG4HMFHSXBPD4OQRLF73/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dict_items.__getitem__?
You have to check the C code to be sure, but IIRC the latest dict implementation has a dense array of the values in insert order, and the hash table (which has gaps) contains indexes into the values array. So you could easily index into the values array (which I believe also has the keys) in O(1) time. Though what happens to the dense array when a key is deleted? It must leave a gap there too. So, never mind, you’d have to walk through the array counting items but not gaps, and that’s O(n). Which explains why we don’t have such an API. But please check the C code! —Guido On Sun, Oct 10, 2021 at 07:18 Alex Waygood wrote: > Should `dict.items()` be indexable now that dicts are ordered? I say yes. > Why shouldn't it? > > > Would there be a way to ensure that this had the same time complexity as > indexing of sequences? If "yes", I would support this — I think it would be > useful in some situations, and it would be more efficient than existing > mechanisms to obtain the *n*th key from a dictionary. If (as I presume), > the answer is "no", then I would not support this — I think it would give > the misleading impression that obtaining the *n*th key/value from a > dictionary is just as efficient as obtaining the *n*th item from a list > or tuple. > > Best, > Alex > > On 10 Oct 2021, at 05:05, Finn Mason wrote: > > > > On Sat, Oct 9, 2021, 9:56 PM Steven D'Aprano wrote: > >> [Snip...] > > > Newbies won't know first() lives in itertools, and those experienced >> enough to know it is there probably won't bother to use it. >> > > A very good point. > > Let's get back to the original topic. Should `dict.items()` be indexable > now that dicts are ordered? I say yes. Why shouldn't it? > > > -- > Finn Mason > >> ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/OOR2AUMA7UMHHVW7XLLUXHTNKGRXTPU4/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/RHNNAZR2ZBYZFQ75VHR3FUMVY6GWDDB6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BISXD643VSNQVE6RFPWGZNH5SL3GE3QE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: More efficient list copying
On Sat, Oct 2, 2021 at 7:42 AM Steven D'Aprano wrote:
> This half-baked idea is inspired by this thread here:
>
>
> https://mail.python.org/archives/list/python-ideas@python.org/message/5LGWV3YLCNBVSL4QHQKJ7RPNTMWOALQA/
>
> which in turn was inspired by this Stackoverflow post:
>
>
> https://stackoverflow.com/questions/56966429/getting-pairs-of-one-item-and-the-rest-over-a-python-list
>
> Problem: today, more and more people are using Python to work with Big
> Data, or at least Biggish Data. For some folks, it is not unusual to
> have lists with a gigabyte or more or data. So imagine you have a list
> with a hundred million items, and you need a copy of the entire list.
> Easy:
>
> alist = [...] # 100 million items
> blist = alist[:]
>
> And that ought to be pretty efficient too, making the slice is basically
> just a copy of a bunch of pointers, plus a bit of overhead. A good
> implementation should have lightning fast list slicing, close to the
> speed of memcopy in C. Give or take.
>
No, it would also have to increment the reference count of each item (since
blist owns a reference to each). That's what makes this slow.
> But now suppose you want a copy of all the items except the item in
> position (let's say) 1000. Here's a bad way:
>
> blist = alist[:]
> del blist[1000]
>
> That's inefficient because the list has to shift almost a hundred
> million items over, and I think they have to be moved one at a
> time. Which is slowish, even in C.
But this doesn't need to update reference counts (except of the one deleted
item) and the move is done using C memmove(), which perhaps isn't as fast
as memcpy() but still unbeatably fast.
> Here's another way:
>
> blist = alist[:1000] + alist[1001:]
>
> That has to make a slice (copy 1000 items), a second slice (copy another
> many million items), then make a third copy to concatenate them, then
> garbage collect the two temporary slices.
>
Yeah, probably the worst way.
And while you might have enough memory for double the original list
> (alist and blist) you might not have enough for triple (alist, the two
> slices, blist).
>
> There are lots of other variants we could come up with, but ultimately
> we're doing lots of extra work that has to be thrown away, and that
> costs time or memory or both.
>
That's always the case when you use Python though. You use it because it's
convenient, not because it's particularly efficient.
> How about if lists had an in-place method for doing a fast copy of
> pointers from one list to another? We could do this:
>
> blist = [None]*(len(alist)-1) # Preallocate.
> blist.copyfrom(alist, index=0, start=0, end=1000)
> blist.copyfrom(alist, index=1000, start=1001)
>
> No temporary slices are needed.
>
> Here's a pure-Python (and therefore slow) implementation:
>
> def copyfrom(dest, source, index=0, start=0, end=None):
> if end is None:
> end = len(source)
> if len(dest) - index < end - start:
> raise ValueError('destination too small')
> for i in range(start, end):
> dest[index+i-start] = source[i]
>
> In pure Python, copying each item over one by one will save memory but
> cost a lot of time. Doing it as a method in C should save both memory
> and time. The implementation could optimize the cases where the source
> is a list, and fall back on iteration for other sequence types.
>
> Now *personally* I don't work with a lot of Big Data, so this doesn't
> really scratch any of my personal itches, but I thought I'd throw it out
> there for others to tell me why it's a dumb idea :-)
>
At the very least it might lead to a recommendation based on which
operation is implemented most efficiently. Though you should just measure
it for various N.
Are you actually observing that people are doing this with regular lists?
Don't people working with Big Data usually use Pandas, which is built on
NumPy arrays and custom data structures?
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FD7H5K5UAKBYZOOZUHTAKFIIN3XE2W56/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Shorthand syntax for lambda functions that have a single parameter
Over in typing-sig we're considering a new syntax for callable *types*, which would look like (int, int, str) -> float. A matching syntax for lambda would use a different arrow, e.g. (x, y, z) => x+y+z. On Wed, Sep 29, 2021 at 11:51 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > Dominik Vilsmeier writes: > > > Hence the proposal is to add a new syntax via the new token `?`. > > I find that unreadable. > > If you're going to add new syntax, either bite the bullet and just > allow 'λ' for 'lambda' (my preference as an old lisper), or > 'x → f(x)' (following MRAB's earlier suggestion). Or maybe omitting > the function name from a def: 'def (x): f(x)'. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/K6ZOKOHBJQLCRDDWARTIPYGZB3IN25SG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WF5ZJ5DWOJD2BMI6FGQMSNPPL7USFOBW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Draft: Power Assertion
First you need to fond a core dev to sponsor you (Steven D’A?). That person
will guide you through the process.
On Sat, Sep 25, 2021 at 08:30 Noam Tenne wrote:
> So should I just scratch this and rewrite a PEP for an extensible
> assertion mechanism?
>
> On Fri, Sep 24, 2021, at 14:04, Noam Tenne wrote:
>
> Hi All,
>
> Following the discussions on "Power Assertions: Is it PEP-able?", I've
> drafted this PEP.
> Your comments are most welcome.
>
> PEP:
> Title: Power Assertion
> Author: Noam Tenne
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 24-Sep-2021
>
>
> Abstract
>
>
> This PEP introduces a language enhancement named "Power Assertion".
>
> The Power Assertion is inspired by a similar feature found in the
> `Groovy language`_ and is an extension to the core lib's ``assert``
> keyword.
>
> When an assertion expression evaluates to ``False``, the output shows
> not only the failure, but also a breakdown of the evaluated expression
> from the inner part to the outer part.
>
> .. _Groovy language:
> http://docs.groovy-lang.org/next/html/documentation/core-testing-guide.html#_power_assertions
>
>
> Motivation
> =
>
> Every test boils down to the binary statement "Is this true or false?",
> whether you use the built-in assert keyword or a more advanced
> assertion method provided by a testing framework.
> When an assertion fails, the output is binary too —
> "Expected x, but got y".
>
> There are helpful libraries like Hamcrest which give you a more
> verbose breakdown of the difference and answer the question
> "What exactly is the difference between x and y?".
> This is extremely helpful, but it still focuses on the difference
> between the values.
>
> Keep in mind that a given state is normally an outcome of a series of
> states, that is, one outcome is a result of multiple conditions and causes.
> This is where Power Assertion comes in. It allows us to better
> understand what led to the failure.
>
>
> The Community Wants This
>
>
> As mentioned in the abstract, this feature was borrowed from Groovy.
> It is a very popular feature within the Groovy community, also used by
> projects such as `Spock`_.
>
> On top of that, it is very much needed in the Python community as well:
>
> * `Power Assertion was explicitly requested`_ as a feature in the
> `Nimoy`_ testing framework
> * There's a `similar feature in pytest`_
>
> And when `discussed in the python-ideas`_ mailing list, the responses
> were overall positive:
>
> * "This is cool." - Guido van Rossum
> * "I was actually thinking exactly the opposite: this would more
> useful in production than in testing."
> - 2QdxY4RzWzUUiLuE＠potatochowder.com
> * "What pytest does is awesome. I though about implementing it in the
> standard compiler since seen it the first time." - Serhiy Storchaka
>
> .. _Spock: https://spockframework.org/
> .. _Power Assertion was explicitly requested:
> https://stackoverflow.com/a/58536986/198825
> .. _similar feature in pytest:
> https://docs.pytest.org/en/latest/how-to/assert.html
> .. _discussed in the python-ideas:
> https://mail.python.org/archives/list/python-ideas@python.org/thread/T26DR4BMPG5EOB3A2ELVEWQPYRENRXHM/
>
>
> Rational
>
>
> Code Example
>
>
> ::
>
> class SomeClass:
> def __init__(self):
> self.val = {'d': 'e'}
>
> def __str__(self):
> return str(self.val)
>
> sc = SomeClass()
>
> assert sc.val['d'] == 'f'
>
> This routine will result in the output:
>
> ::
>
> Assertion failed:
>
> sc.val['d'] == f
> | ||
> | eFalse
> |
> {'d': 'e'}
>
>
> Display
> ---
>
> In the output above we can see the value of every part of the
> expression from left to right, mapped to their expression fragment
> with the pipe (``|``).
> The number of rows that are printed depend on the value of each
> fragment of the expression.
> If the value of a fragment is longer than the actual fragment
> (``{'d': 'e'}`` is longer than ``sc``), then the next value (``e``)
> will be printed on a new line which will appear above.
> Values are appended to the same line until it overflows in length to
> horizontal position of the next fragment.
>
> This way of presentation is clearer and more human friendly than the
> output offered by pytest's solution.
>
> The information that’s displayed is dictated by the type.
> If the type is a constant value, it
[Python-ideas] Re: PEP Draft: Power Assertion
On Sat, Sep 25, 2021 at 00:56 Steven D'Aprano wrote: > On Fri, Sep 24, 2021 at 11:23:00PM -0700, Guido van Rossum wrote: > > > > Is there no room for making it easier to do this with less invasive > > > changes to the stdlib, or are Steven d'A's "heroic measures in an > > > import hook" the right way to go? > > > > > > Other Steve > > > > > > There’s room for that, but that’s not what’s being proposed (yet :-). > > I'm confused. My reading of the pre-PEP is that that is precisely what > it is proposing: changing the way assert works so that the value of each > sub-expression is available to be displayed to the user. Presumably any > framework or library would be able to access that information. > > Have I missed something? I don't see anything in the proposal about > creating new stdlib frameworks or changing unittest. But others were. Anyway, I admit that I didn’t read the PRP carefully enough and was confused about what it proposes. My next responses: - The name “Power Assertions” is terrible. It sounds like a Microsoft product. :-) - I was envisioning something that provides an API that would allow a test framework to do what pytest does; not a behavior chance to the assert statement by default. - Please, please collaborate with the pytest developers on the design. —Guido -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6OSPVMGPPOKRNIQ7ITSM57MWHQCBQSA6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Draft: Power Assertion
On Fri, Sep 24, 2021 at 22:07 Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > Guido van Rossum writes: > > > I think this is by far the best option. Pytest can evolve much faster > than > > the stdlib. > > Is there no room for making it easier to do this with less invasive > changes to the stdlib, or are Steven d'A's "heroic measures in an > import hook" the right way to go? > > Other Steve There’s room for that, but that’s not what’s being proposed (yet :-). —Guido > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/K33XPSZVDHFTBXURX5I64OV4ZK65BTX6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP Draft: Power Assertion
On Fri, Sep 24, 2021 at 19:49 Christopher Barker wrote: > Alternatively, take the approach taken with distutils and setuptools— > officially accept that a full featured test framework will be left to third > parties. > I think this is by far the best option. Pytest can evolve much faster than the stdlib. —Guido > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5X7ESOCGBP25YNEF3F3XWVDQHOV37N6R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Typing Callable Ellipsis -- support for type hints a la Callable[[int, float, ...], None]
This is a question for typing-sig. Over on typing-sig we are looking at alternatives to Callable, so it's unlikely that any changes to Callable itself will be accepted. Instead of `...`, we will probably use `*args`, similar to what is used in the `def` syntax. Feel free to peruse the typing-sig archives to learn more about the current status: https://mail.python.org/archives/list/typing-...@python.org/ --Guido On Wed, Sep 22, 2021 at 1:04 AM Randolf Scholz wrote: > @Valentin Berlier > > That would probably be possible, but the question here is, given that > `Callable` is a built-in, is it sensible to expect `Callable` to support > this behaviour. > > I would say yes, because it is extremely intuitive, especially with > regards to the fact that the widely used numpy library already uses > Ellipsis in a fashion semantically consistent with this proposal. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/L6BTMIIMNSXX37YQA7J5VCOI7TOKOX5O/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/WE6MSPQNAKZIBNBJ3IN5MIKO6E7NIIV5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
To make chdir() return a context manager *and* keep it working without calling `__enter__`, it would have to call `getcwd()`, which I've heard is expensive. So I don't think that would work, alas. On Wed, Sep 15, 2021 at 11:55 AM Eric V. Smith wrote: > On 9/15/2021 2:48 PM, Eric Fahlgren wrote: > > On Wed, Sep 15, 2021 at 12:21 AM Eric V. Smith wrote: > >> And I'm not crazy about the name "workdir". To me, it sounds like it >> returns something, not sets and resets something. But I don't have a >> particularly great alternative in mind: in my own code I've used >> "change_dir", which isn't awesome either. >> > > Our version is named "pushdir", modeled after shell's pushd (even though > pushdir is a context manager and does auto-pop). Everyone figures out what > it does at a glance. > > That's a great name! > > Although I think having os.chdir() return a context manager is a better > design (assuming it can work, but at first blush it would seem so). > > Eric > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/U5UQFDAJ4KWG2OQ3YMP2THMSJ72JRV6Y/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LZL4YXXRW4TBBSFZVW46PTTUOT36LX62/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
For the stdlib context managers that I know of, all-lowercase seems the convention. Would it even be a class? The simplest implementation would use contextlib.contextmanager (unless that’s a undesirable dependency for os.py). —Guido On Tue, Sep 14, 2021 at 17:53 Finn Mason wrote: > BTW, should it be `WorkDir` instead of `workdir` because it's a class, or > would that be too inconsistent? > > > On Tue, Sep 14, 2021, 6:47 PM Finn Mason wrote: > >> >> On Tue, Sep 14, 2021, 5:36 PM Cameron Simpson wrote: >> >>> On 15Sep2021 07:50, Chris Angelico wrote: >>> >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote: >>> >> I know I'm atypical, but I have quite a lot of multithreaded stuff, >>> >> including command line code. So while it'd be ok to avoid this context >>> >> manager for my own code, I fear library modules, either stdlib or >>> pypi, >>> >> quietly using this in their code, making them unuseable in the general >>> >> case. Unrepairably unuseable, for the user. >>> > >>> >Library code shouldn't be changing the working directory, context >>> >manager or not. That belongs to the application. >>> >>> Entirely agree. >>> >>> I'm concerned that convenient stackable chdir is a bug magnet, and would >>> creep into library code. Maybe not in the stdlib, but there's no point >>> writing such a context manager if it isn't going to be used, and >>> therefore it could get used in library code. Imagine when a popular pypi >>> module starts using it internally and breaks a multithreaded app >>> previously relying on it? >>> >> >> I don't think we should worry about it "creeping into library code." The >> thread-unsafety is not a cause of this context manager. It comes from the >> preexisting `os.chdir()`. If the library is changing the CWD, it's already >> thread-unsafe. It's not because of the new context manager. All >> `os.workdir()` does is make things easier. >> However, if it's implemented (which I personally support), there should >> still of course be a warning in the documentation. But I'd like to >> emphasize that *it is not because of `workdir()` itself, but the >> underlying `chdir()`!* >> >> On 14Sep2021 15:16, Guido van Rossum wrote: >> >Here I think we need to drop our perfectionist attitude. >> >> I completely agree. >> >>> ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/J4L3I3QWV65GPKHJ5RZ4NASGX7ZIS774/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/X6IGI33OS7534GF7CCFUKJXTG5OMJAXA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
On Tue, Sep 14, 2021 at 4:36 PM Cameron Simpson wrote: > On 15Sep2021 07:50, Chris Angelico wrote: > >On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson wrote: > >> I know I'm atypical, but I have quite a lot of multithreaded stuff, > >> including command line code. So while it'd be ok to avoid this context > >> manager for my own code, I fear library modules, either stdlib or pypi, > >> quietly using this in their code, making them unuseable in the general > >> case. Unrepairably unuseable, for the user. > > > >Library code shouldn't be changing the working directory, context > >manager or not. That belongs to the application. > > Entirely agree. > > I'm concerned that convenient stackable chdir is a bug magnet, and would > creep into library code. Maybe not in the stdlib, but there's no point > writing such a context manager if it isn't goingg to be used, and > therefore it could get used in library code. Imagine when a popular pypi > module starts using it internally and breaks a multithreaded app > previously relying on it? > I know where I'd file a bug. :-) "Bug magnet" is an extremely subjective pejorative term. When the *better* way to do things (os.workdir()) is harder than the *easy* way to do (os.chdir()), which is the real bug magnet? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/66ZPA74HWFPYB7G7ZLHLONX32KSWIW4E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: os.workdir() context manager
Here I think we need to drop our perfectionist attitude. When I saw
Marc-Andre's proposal my first response was also "but what about threads."
But really, os.chdir() is the culprit here, and since it's a syscall we
can't fix it. If we can live with that, we can live with the proposed
os.workdir(). The docs just need a warning about threads.
Yes, you could create a thread-safe version of this by overriding open() --
and several hundred other functions that refer to pathnames natively. Such
a project will inevitably have serious backwards compatibility concerns
(any use of pathnames from C extensions will not work right) so it's just
not going to be done.
If we don't offer this in the stdlib, users will just implement this
themselves, poorly (for example, by not restoring the original when done).
On Tue, Sep 14, 2021 at 2:43 PM Cameron Simpson wrote:
> On 14Sep2021 21:43, M.-A. Lemburg wrote:
> >- The context manager is not thread safe. There's no thread safe model
> > for the current work dir. OTOH, scripts usually don't use threads,
> > so not a big deal.
>
> This is the source of my concerns. Though of course it applies to any
> process global state. It would need this stated up front in big letters
> (as of course does chdir itself). My real concern is that this can leak
> into other functions whose use then makes whatever uses them to become
> inherently and unrepairably not thread safe.
>
> I know I'm atypical, but I have quite a lot of multithreaded stuff,
> including command line code. So while it'd be ok to avoid this context
> manager for my own code, I fear library modules, either stdlib or pypi,
> quietly using this in their code, making them unuseable in the general
> case. Unrepairably unuseable, for the user.
>
> I think what would be more useful is a context manager which worked on a
> threading.local which pushed/popped a reference directory path, and had
> an open() method which used that (and friends for other pathname based
> functions).
>
> In my own code I'd write this like (sketch, untested):
>
> from cs.threads import State as ThreadState
>
> class RefDir(ThreadState)
>
> def __init__(self, refpath=None):
> if refpath is None:
> refpath = os.getcwd()
> self.refpath = abspath(refpath)
>
> def open(self, path, *a, **kw):
> if not isabs(path):
> path = os.path.join(self.refpath, path)
> return open(path, *a, **kw) # calls the builtin open()
>
> ... listdir, mkdir, etc etc ...
>
> # on reflection, __enter__ and __exit__ would make the below even
> # more convenient
> @contextmanager
> def dirpath(newrefpath):
> ''' Push `newrefpath` for the duration of the context manager.
> '''
> with self(refpath=newrefpath):
> yield self.refpath
>
> and then use it like this:
>
> R = RefDir()
>
> with R.dirpath('/some/new/place') as newpath:
> ...
> with R.open("something.txt") as f:
> ... work on /some/new/place/something.txt ...
>
> In the above, cs.threads.State is a threading.lcoal subclass which is
> also a context manager whose operation pushes arbitrary attribute
> values. Great for thread safe execution scoped state. Like this
> example.
>
> All that said, I wrote pretty much exactly what you describe just the
> other week for umask().
>
> Cheers,
> Cameron Simpson
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/EJETKXD7PAW3XKD5AW4OM45XKDSNX2QJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KS3KYQA65NS47CMY5LAEMPNINUNRZRY3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
Maybe you all could collaborate on a PEP? This sounds a worthy topic. On Sun, Sep 12, 2021 at 08:37 Serhiy Storchaka wrote: > 12.09.21 17:28, Guido van Rossum пише: > > This is cool. > > > > AFAIK pytest does something like this. How does your implementation > differ? > > What pytest does is awesome. I though about implementing it in the > standard compiler since seen it the first time. > > > What is your argument for making this part of the language? Why not a > > 3rd party library? > > It needs a support in the compiler. The condition expression should be > compiled to keep all immediate results of subexpressions on the stack. > If the final result is true, immediate results are dropped. If it is > false, the second argument of assert is evaluated and its value together > with all immediate results of the first expression, together with > references to corresponding subexpressions (as strings, ranges or AST > nodes) are passed to the special handler. That handler can be > implemented in a third-party library, because formatting and outputting > a report is a complex task. The default handler can just raise an > AttributeError. > > > What about asserts that are not used for testing, but as classic “unless > > there’s a bug, this should hold”? Those may not want to incur the extra > > cost. > > The only extra cost is that immediate results are temporary save on > stack instead of just be dropped. It increases the size of bytecode and > stack, but I don't think it will be significant. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/S673FXNSAWR3UWKNLIYTBVDAWONDPWWJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/E67KVRNCGWB5CULMKOSQSOBS36RLYLFA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Power Assertions: Is it PEP-able?
This is cool.
AFAIK pytest does something like this. How does your implementation differ?
What is your argument for making this part of the language? Why not a 3rd
party library?
What about asserts that are not used for testing, but as classic “unless
there’s a bug, this should hold”? Those may not want to incur the extra
cost.
—Guido
On Sun, Sep 12, 2021 at 07:09 wrote:
> Hi all,
>
> I’d like your comments and feedback on an enhancement that introduces
> power assertions to the Python language.
>
> Proposal
>
> This feature is inspired by a similar feature of the Groovy language[1],
> and is effectively a variant of the `assert` keyword.
> When an assertion expression evaluates to `False`, the output shows not
> only the failure, but also a breakdown of the evaluated expression from the
> inner part to the outer part.
>
> For example, a procedure like:
> ```python
> class SomeClass:
> def __init__(self):
> self.val = {'d': 'e'}
>
> def __str__(self):
> return str(self.val)
>
> sc = SomeClass()
>
> assert sc.val['d'] == 'f'
> ```
>
> Will result in the output:
>
> ```python
> Assertion failed:
>
> sc.val['d'] == f
> | ||
> | eFalse
> |
> {'d': 'e'}
> ```
> See link [2] if the formatting above is screwed up.
>
> In the output above we can see the value of every part of the expression
> from left to right, mapped to their expression fragment with the pipe (`|`).
> The number of rows that are printed depend on the value of each fragment
> of the expression.
> If the value of a fragment is longer than the actual fragment (`{'d':
> 'e'}` is longer than `sc`), then the next value (`e`) will be printed on a
> new line which will appear above.
> Values are appended to the same line until it overflows in length to
> horizontal position of the next fragment.
>
> The information that’s displayed is dictated by the type.
> If the type is a constant value, it will be displayed as is.
> If the type implements `__str__`, then the return value of that will be
> displayed.
>
> It is important to note that expressions with side effects are affected by
> this feature. This is because in order to display this information, we must
> store references to the instances and not just the values.
>
> Rational
>
> Every test boils down to the binary statement "Is this true or false?",
> whether you use the built-in assert keyword or a more advanced assertion
> method provided by a testing framework.
> When an assertion fails, the output is binary too — "Expected x, but got
> y".
>
> There are helpful libraries like Hamcrest which give you a more verbose
> breakdown of the difference and answer the question "What exactly is the
> difference between x and y?".
> This is extremely helpful, but it still focuses on the difference between
> the values.
>
> We need to keep in mind that a given state is normally an outcome of a
> series of states, that is, one outcome is a result of multiple conditions
> and causes.
> This is where power assertion comes in. It allows us to better understand
> what led to the failure.
>
> Implementation
>
> I’ve already built a fully functional implementation[2] of this feature as
> part of my Python testing framework - Nimoy[3].
> The current implementation uses AST manipulation to remap the expression
> to a data structure[4] at compile time, so that it can then be evaluated
> and printed[5] at runtime.
>
>
> [1]
> http://docs.groovy-lang.org/next/html/documentation/core-testing-guide.html#_power_assertions
> [2]
> https://browncoat-ninjas.github.io/nimoy/examples/#power-assertions-beta
> [3] https://github.com/browncoat-ninjas/nimoy/
> [4]
> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/ast_tools/expression_transformer.py#L77
> [5]
> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/assertions/power.py
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/T26DR4BMPG5EOB3A2ELVEWQPYRENRXHM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EEVHXKWUMVSEPAR73WOBQM3BO7NESPBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Ooh, that’s a nice idea. If the message is an exception instance, raise it instead of AssertionError. Unfortunately it’s not 100% backwards compatible. We could address that with the syntax assert cond, raise=ExcType(args) Maybe we could deprecate the case assert cond, ExcType(args) So that eventually the raise= keyword can become optional. —Guido On Thu, Sep 9, 2021 at 09:04 Juancarlo Añez wrote: > Steven, > > The purpose is to make it easier to make software more resilient. > > The inspiration was this article that reminded me that software *_will > always fail_*, and also reminded me about all the discussions around DBC > and Eiffel: > > https://www.youtube.com/watch?v=AaZ_RSt0KP8 > > > IOW, my premise is that we should be using *_lots_* of assertions, > *_always_*, and that for that we need to make them easier to write, and > easier to handle in the event of the unavoidable failures. Seeking > unit-test coverage is not enough because unit tests don't run in production. > > I will concede that code written under the *"Python culture"* tends to be > resilient because the semantics of defaults and border conditions are > explicit in the documentation, and implemented thus. > > Perhaps it's enough to allow for: > > *assert **cond**, *ExType(args) > > > > On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano > wrote: > >> On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote: >> > I won't propose a syntax, but I think it would be useful if *assert* >> could >> > raise an exception different from *AssertionError*. >> > >> > This is in the context of "Design by contrast" (DBC) as a useful >> companion >> > to "Test-driven development" and other forms of external tests. >> >> I don't see why that would be useful. DBC assertions are assertions. You >> are *asserting* that a condition is always true. Since it is always >> true, it should be safe to disable those DBC assertion checks once your >> software is in production. >> >> I could *maybe* see that having fine distinction between pre-condition, >> post-condition and invariant failures would be useful, but without a >> system in place to allow those to be globally enabled/disabled >> separately, what's the point? >> >> In any case, in the event of a contract failure, there's really nothing >> you can do except log the error and exit. Raising errors like TypeError >> etc will encourage people to abuse assertions and contracts by catching >> those exceptions, for checking caller-supplied parameters and user data, >> or for flow control. >> >> >> -- >> Steve >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Juancarlo *Añez* > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3HUS3M74VI2ECMOSGAN4QLLI3PZWXA3H/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ADQCK6Z4QLMXDDVRILAZROFOJD3T6YSJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: open functions in dbm submodule need to support path-like object
If someone posted a Pull Request that added this, it would be looked upon favorably I'm sure. On Tue, Sep 7, 2021 at 8:31 AM Christopher Barker wrote: > it looks like this as had a BPO for over a year: > > https://bugs.python.org/issue40563 > > I suggest pinging that (and maybe python-dev) to see what's up. > > NOTE: first check 3.10 :-) > > -CHB > > > On Tue, Sep 7, 2021 at 5:05 AM Evan Greenup via Python-ideas < > python-ideas@python.org> wrote: > >> Currently, in Python 3.9, `dbm.open()`, `dbm.gnu.open()` and >> `dbm.ndbm.open()` doesn't support path-like object, class defined in >> `pathlib`. >> >> It would be nice to add support with it. >> >> Sent with ProtonMail Secure Email. >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/22OBR3A3GZLHR56P7GMWAFHSNN4CAZ7T/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/RSIU7TT6R2Y2FZQAWS24BQN2VIYDDLPU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/O7LJFFWWH6G3XYO2KAK6JM3V6W2GA34W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add @parametrize decorator to unittest library
On Mon, Sep 6, 2021 at 21:45 Christopher Barker wrote: > Just use pytest. > For third party code I agree, it’s the way to go. —Guido -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/75MAGYGI3NKUTVFWQ4P3QHO5OX6JQORF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
On Fri, Sep 3, 2021 at 5:37 PM Christopher Barker wrote: > On Fri, Sep 3, 2021 at 1:13 PM Guido van Rossum wrote: > >> But the text of the error message will explain all you need for debugging >> and testing. >> > > debugging, probably yes. > > But it's a lot easier to check that a particular Exception is raised than > to have to check for the Exception and also parse the error message. > > Honestly, I haven't figured out a use case for this particular example, > but I do appreciate finer grained Exceptions in general. > Hm. More is not always better. (Today's entry for the 20th "Zen of Python" line. :-) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JXXR2LUZKYM4JZ6ID4FLHGCEPHRUAMIW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
But the text of the error message will explain all you need for debugging and testing. On Fri, Sep 3, 2021 at 10:08 AM Christopher Barker wrote: > > > On Fri, Sep 3, 2021 at 9:35 AM Guido van Rossum wrote: > >> The question is, would anyone ever want to make a distinction between the >> two in *real* code? >> > > I expect not. > > However, finer grained exception may help with debugging and testing. > > -CHB > > > > > find it unlikely that someone would write >> >> try: >> sum(x, y, z) >> except TypeError: >> ... >> >> If you bury the sum() call deep inside other code, I'd say your >> try/except net is too wide. >> >> On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin >> wrote: >> >>> On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka >>> wrote: >>> > >>> > There are two different kinds of TypeError: if the end user passes an >>> > instance of wrong type and if the author of the library makes an error >>> > in implementation of some protocols. >>> > >>> > For example, len(obj) raises TypeError in two cases: if obj does not >>> > have __len__ (user error) and if obj.returns non-integer >>> (implementation >>> > error). for x in obj raises TypeError if obj does not have __iter__ >>> > (user error) and if iter(obj) does not have __next__ (implementation >>> error). >>> > >>> > User errors can be fixed on user side, implementation errors can only >>> be >>> > fixed by the author of the class. Even if the user and the author is >>> the >>> > same person, these errors point to different places of code. >>> > >>> > Would it be worth to add a special TypeError subclass for >>> implementation >>> > errors to distinguish them from user errors? How to name it >>> > (ImplementationError, ProtocolError, etc)? >>> >>> I think that it would be good to make TypeError more fine-grained. >>> Another example is: >>> >>> >>> sum(1, 2, 3) >>> Traceback (most recent call last): >>> File "", line 1, in >>> TypeError: sum() takes at most 2 arguments (3 given) >>> >>> There can be reasons in library code to catch TypeError that might >>> arise from bad user input but in those situations you would usually >>> not want to catch this TypeError. The error from calling a function >>> with the wrong number of arguments would usually mean a bug in the >>> library code which should not be caught. Conversely if the user input >>> is a callable and you do want to catch the error resulting from it >>> being called with the wrong number of arguments then catching >>> TypeError is too broad again. Something like BadArgumentsError would >>> be better. >> >> >>> >>> -- >>> Oscar >>> ___ >>> Python-ideas mailing list -- python-ideas@python.org >>> To unsubscribe send an email to python-ideas-le...@python.org >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/python-ideas@python.org/message/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> *Pronouns: he/him **(why is my pronoun here?)* >> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PODUQXNURYYPUJBBYS6T4O4X2XT3WOA2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a special TypeError subclass for implementation errors
The question is, would anyone ever want to make a distinction between the two in *real* code? I find it unlikely that someone would write try: sum(x, y, z) except TypeError: ... If you bury the sum() call deep inside other code, I'd say your try/except net is too wide. On Fri, Sep 3, 2021 at 4:24 AM Oscar Benjamin wrote: > On Fri, 3 Sept 2021 at 08:10, Serhiy Storchaka > wrote: > > > > There are two different kinds of TypeError: if the end user passes an > > instance of wrong type and if the author of the library makes an error > > in implementation of some protocols. > > > > For example, len(obj) raises TypeError in two cases: if obj does not > > have __len__ (user error) and if obj.returns non-integer (implementation > > error). for x in obj raises TypeError if obj does not have __iter__ > > (user error) and if iter(obj) does not have __next__ (implementation > error). > > > > User errors can be fixed on user side, implementation errors can only be > > fixed by the author of the class. Even if the user and the author is the > > same person, these errors point to different places of code. > > > > Would it be worth to add a special TypeError subclass for implementation > > errors to distinguish them from user errors? How to name it > > (ImplementationError, ProtocolError, etc)? > > I think that it would be good to make TypeError more fine-grained. > Another example is: > > >>> sum(1, 2, 3) > Traceback (most recent call last): > File "", line 1, in > TypeError: sum() takes at most 2 arguments (3 given) > > There can be reasons in library code to catch TypeError that might > arise from bad user input but in those situations you would usually > not want to catch this TypeError. The error from calling a function > with the wrong number of arguments would usually mean a bug in the > library code which should not be caught. Conversely if the user input > is a callable and you do want to catch the error resulting from it > being called with the wrong number of arguments then catching > TypeError is too broad again. Something like BadArgumentsError would > be better. > > -- > Oscar > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3CLXFC52JIBCFXMXRFA5I6F4RDU5ZYP3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MXVBSNUTLVJVKWIVUK7MSCKM4YDPEL4Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
My conclusion is that you should ignore PEP 8 for your use case and write “if len(a) == 0”. On Wed, Aug 25, 2021 at 06:13 Tim Hoffmann via Python-ideas < python-ideas@python.org> wrote: > Guido van Rossum wrote: > > So then the next question is, what's the use case? What code are people > > writing that may receive either a stdlib container or a numpy array, and > > which needs to do something special if there are no elements? Maybe > > computing the average? AFAICT Tim Hoffman (the OP) never said. > > There's two parts to the answer: > > 1) There functions e.g. in scipy and matplotlib that accept both numpy > arrays and lists of flows. Speaking from matplotlib experience: While > eventually we coerce that data to a uniform internal format, there are > cases in which we need to keep the original data and only convert on a > lower internal level. We often can return early in a function if there is > no data, which is where the emptiness check comes in. We have to take extra > care to not do the PEP-8 recommended emptiness check using `if not data`. > > 2) Even for cases that cannot have different types in the same code, it is > unsatisfactory that I have to write `if not seq` but `if len(array) == 0` > depending on the expected data. IMHO whatever the recommended syntax for > emptiness checking is, it should be the same for lists and arrays and > dataframes. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/Q6KZEXFLJ6TEFSDQM3SXXIVGNFNURPYT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JVNSGTXFPCODPGEPX2N4SWB7LIMPGTVS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
What sort of code would be able to do anything useful with either a sequence or a queue? Queues aren’t iterable. This seems a case of hyper-generalization. On Tue, Aug 24, 2021 at 22:19 Christopher Barker wrote: > Bringing this back on list: > > On Tue, Aug 24, 2021 at 9:58 PM David Mertz, Ph.D. > wrote: > >> Sorry, I should have been more explicit. The several kinda of queues can >> all "contain" items, but do not respond to len(). >> > > yeah, I should have looked more closely at your list > > Though i would consider that an oversight, len(a_queue) could be handy. > > There is qsize() -- I wonder if there's a reason not to have __len__ do > the same thing -- O(n) maybe? See Guido's point that there's an assumption > tha len() will be O(1). > > This is an argument for the OP's point -- there is no standard way to > check emptiness. > > -CHB > > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/EEK7QHRGT2P5WLEOOJCPJQSR6VEDAJVC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DCHSJADNALHHBLXW45EVXSEFCFCIHJD4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
“Container” is a kind of pun, it’s something with a __contains__ method.
The thing you’re looking for is “Collection”, which is the base for
sequences, mappings and sets.
I also note that the discussion seems quite stuck.
—Guido
On Tue, Aug 24, 2021 at 21:55 Christopher Barker
wrote:
> It seems the conversation has confused two related concepts:
>
> 1) The default bool() implementation (Truthiness) -- this is what the OP
> said was recommended by PEP 8: "For sequences, (strings, lists, tuples),
> use the fact that empty sequences are false:" -- there is some debate about
> that whether this is a good recommendation or not, but i don't think that's
> the OPs point. Rather:
>
> 2) That there is no standard way to explicitly test containers for
> "emptiness" - - there is only length, with the assumption that
> len(something) == 0 or not len(something) is a good way to test for
> emptiness.
>
> I still don't see why length is not perfectly adequate, but i wonder if
> there are any "containers" i.e.things that could be empty, in the std lib
> that don't support length.
>
> Looking in the ABCs, a Container is something that supports `in`, and a
> Sized is something that supports len()-- so in theory, there could be a
> Container that does not have a length. Are there any in the std lib?
>
> Perhaps the ABCs are instructive in another way here -- if we were to add
> a __empty__ or some such dunder, what ABC would require it? Container? or
> yet another one-method ABC?
>
> -CHB
>
>
> On Tue, Aug 24, 2021 at 8:39 PM David Mertz, Ph.D.
> wrote:
>
>> I wanted to do a survey of various "aggregates" in Python to see if any
>> stand out as making the usual `if stuff: ...` troublesome. I wrote a
>> little script at
>> https://github.com/DavidMertz/LanguagePractice/blob/main/python/aggregates.py
>> .
>>
>> I'm being deliberately vague about an "aggregate." It might not be a
>> collection strictly speaking, but it is something that might seems to
>> "contain" values in some sense. Basically, I think that standard library
>> and built-in stuff behaves per PEP8. Some other libraries go their own
>> way. I throw in a linked-list implementation I found on PyPI. I've never
>> used it beyond this script; but per what it is, it cannot implement `len()`
>> on O(1) (well, it *could* if it does extra bookkeeping; but then it's kinda
>> a different thing).
>>
>> In NumPy land, the np.empty vs. np.zeros case is another oddball. On my
>> system, my memory happened to have some prior value that wasn't zero; that
>> could vary between runs, in principle.
>>
>> These are the results:
>>
>> Expr: '' | Value: ''
>> Truth: False | Length: 0
>> Expr: list() | Value: []
>> Truth: False | Length: 0
>> Expr: tuple() | Value: ()
>> Truth: False | Length: 0
>> Expr: dict() | Value: {}
>> Truth: False | Length: 0
>> Expr: set() | Value: set()
>> Truth: False | Length: 0
>> Expr: bytearray() | Value: bytearray(b'')
>> Truth: False | Length: 0
>> Expr: bytearray(1) | Value: bytearray(b'\x00')
>> Truth: True | Length: 1
>> Expr: bytearray([0]) | Value: bytearray(b'\x00')
>> Truth: True | Length: 1
>> Expr: array.array('i') | Value: array('i')
>> Truth: False | Length: 0
>> Expr: array.array('i', []) | Value: array('i')
>> Truth: False | Length: 0
>> Expr: Nothing() | Value: EmptyNamedTuple()
>> Truth: False | Length: 0
>> Expr: deque() | Value: deque([])
>> Truth: False | Length: 0
>> Expr: deque([]) | Value: deque([])
>> Truth: False | Length: 0
>> Expr: ChainMap() | Value: ChainMap({})
>> Truth: False | Length: 0
>> Expr: queue.Queue() | Value:
>> Truth: True | Length: No length
>> Expr: asyncio.Queue() | Value:
>> Truth: True | Length: No length
>> Expr: multiprocessing.Queue() | Value: > object at 0x7f0940dd2190>
>> Truth: True | Length: No length
>> Expr: np.ndarray(1,) | Value: array([5.e-324])
>> Truth: True | Length: 1
>> Expr: np.ndarray((1,0)) | Value: array([], shape=(1, 0), dtype=float64)
>> Truth: False | Length: 1
>> Expr: np.empty((1,)) | Value: array([5.e-324])
>> Truth: True | Length: 1
>> Expr: np.zeros((1,)) | Value: array([0.])
>> Truth: False | Length: 1
>> Expr: np.zeros((2,)) | Value: array([0., 0.])
>> Truth: No Truthiness | Length: 2
>> Expr: np.ones((1,)) | Value: array([1.])
>> Truth: True | Length: 1
>> Expr: np.ones((2,)) | Value: array([1., 1.])
>> Truth: No Truthiness | Length: 2
>&
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
On Tue, Aug 24, 2021 at 7:23 PM MRAB wrote: > On 2021-08-25 00:48, Guido van Rossum wrote: > > Hi Tim, > > > > I'm sorry if this has been brought up before, but *aside from PEP 8* is > > there anything wrong with using "if len(a)" for nonempty, or "if not > > len(a)" for empty? > > > What is the cost of 'len'? If it's always O(1), then it's not a problem, > but if it's not O(1) (counting the items in a tree, for example) and > you're not interested in how many items there are but only whether > there's at least one, then... > It's a pretty universal assumption that len() is O(1) -- something that doesn't do that probably shouldn't implement __len__(). (And yeah, there's probably some tree package around that does implement an O(N) __len__(). People do a lot of silly things though, we can't handle *everything*.) > It would seem to work for numpy and pandas arrays, and it works for > > builtin sequences. Also, it has the advantage of being 100% backwards > > compatible. :-) > > > > Surely conforming to PEP 8 shouldn't need an addition to the language or > > stdlib? Or does it not work? > It was pointed out to me that numpy allows arrays that have no elements but a nonzero first dimension. People could disagree about whether that should be considered empty. I'm not sure about Pandas, but IIRC a Dataframe is always a table of rows, with all rows having the same number of columns. Here I'd say that if there's at least one row in the table, I'd call it non-empty, even if the rows have no columns. This conforms to the emptiness of [()]. It's possible that there's a common use case in the data science world where this should be counted as empty, but to me, that would be inconsistent -- a row with zero columns is still a row. (For numpy arrays my intuition is less clear, since there's more symmetry between the dimensions.) So then the next question is, what's the use case? What code are people writing that may receive either a stdlib container or a numpy array, and which needs to do something special if there are no elements? Maybe computing the average? AFAICT Tim Hoffman (the OP) never said. PS. Why is anyone thinking that an array containing all zeros (and at least one zero) might be considered empty? That seems a totally different kind of test. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3FKVLFJLVZIARGNIA7VQBJS3V3BAD3O5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: We should have an explicit concept of emptiness for collections
Hi Tim, I'm sorry if this has been brought up before, but *aside from PEP 8* is there anything wrong with using "if len(a)" for nonempty, or "if not len(a)" for empty? It would seem to work for numpy and pandas arrays, and it works for builtin sequences. Also, it has the advantage of being 100% backwards compatible. :-) Surely conforming to PEP 8 shouldn't need an addition to the language or stdlib? Or does it not work? On Tue, Aug 24, 2021 at 3:42 PM Tim Hoffmann via Python-ideas < python-ideas@python.org> wrote: > Ethan Furman wrote: > > On 8/24/21 3:03 PM, Tim Hoffmann via Python-ideas wrote: > > > **How do you check if a container is empty?** > > > IMHO the answer should not depend on the container. > > I think this is the fly in the ointment -- just about everything, from > len() to bool(), to add, to iter() /all/ depend > > on the container -- even equality depends on the container. `and`, > `or`, and `not` partially depend on the container > > (via bool()). Only `is` is truly independent. > > Sorry, I think you got me wrong: The meaning and thus implementation > depends on the type (e.g. each container defines its own __len__()). > However the syntax for querying length that is still uniformly > `len(container)`. Likewise I'd like to have a uniform syntax for emptiness, > and not different syntax for different types (`if not container` / `if > len(array) == 0` / `if dataframe.empty`). > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/LRK6HHQKBH2Y4USB7DAJNOUF5NE62ZYD/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5KTHNWMKZBRDQSRO7C4WCX4KG22QWCG2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: NAN handling in statistics functions
Urgh. That's a nasty dilemma. I propose that the default should be return
NAN, since that's what you'd expect if you did the super-naive arithmetic
version (e.g. mean(x, y, z) = (x+y+z)/3).
On Mon, Aug 23, 2021 at 8:55 PM Steven D'Aprano wrote:
> At the moment, the handling of NANs in the statistics module is
> implementation dependent. In practice, that *usually* means that if your
> data has a NAN in it, the result you get will probably be a NAN.
>
> >>> statistics.mean([1, 2, float('nan'), 4])
> nan
>
> But there are unfortunate exceptions to this:
>
> >>> statistics.median([1, 2, float('nan'), 4])
> nan
> >>> statistics.median([float('nan'), 1, 2, 4])
> 1.5
>
> I've spoken to users of other statistics packages and languages, such as
> R, and I cannot find any consensus on what the "right" behaviour should
> be for NANs except "not that!".
>
> So I propose that statistics functions gain a keyword only parameter to
> specify the desired behaviour when a NAN is found:
>
> - raise an exception
>
> - return NAN
>
> - ignore it (filter out NANs)
>
> which seem to be the three most common preference. (It seems to be
> split roughly equally between the three.)
>
> Thoughts? Objections?
>
> Does anyone have any strong feelings about what should be the default?
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/EDRF2NR4UOYMSKE64KDI2SWUMKPAJ3YM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PXLFIB4Y2EJ757E5Y7FGJG26CVDMO4S2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Stack-scoped variables
Oh, I like that. It does feel like a property of the variable. (But can you efficiently enumerate all context vars when creating a thread?) I imagine that thread pools add some complication, because you don’t want to inherit these accidentally between tasks run by the same worker. On Thu, Aug 19, 2021 at 14:28 Paul Prescod wrote: > On Thu, Aug 19, 2021 at 8:43 AM Guido van Rossum wrote: > >> Perhaps we need a library for creating/managing threads that inherits all >> current context values? >> > > Or is it a "kind of context variable that is shared among threads?" That > was more the direction my mind was going. > > Context variables that hold explicitly or implicitly immutable values > are safe to share. Context variables that hold values intended to be > mutated: seldom. > > What if it were some kind of ContextVar subclass or flag where you would > say you did or didn't want something shared? > > And for legacy modules like decimal, you could turn on the flag somehow to > get the sharing behaviour. > > Sometimes threads are made by third-party libraries and those libraries > don't know anything about the context. > > In my case, the pattern was: > > 1. my code set context variable > 2. my code configured a third party library with a callback > 3. the third party library used threading for perf reasons > 4. it called my callback, which failed due to the context variable failing > to be inherited > > I believe (after only thinking about it for a day or so) that one can > generally determine the right "sharing rule" at the point of definition of > a ContextVar, based on the semantics and type of the Var. > > On Thu, Aug 19, 2021 at 8:43 AM Guido van Rossum wrote: > >> Perhaps we need a library for creating/managing threads that inherits all >> current context values? >> >> On Thu, Aug 19, 2021 at 7:48 AM Paul Prescod wrote: >> >>> There are certain values that are managed independent of any specific >>> code-accessible object. The decimal precision is a good example: >>> >>> https://docs.python.org/3/library/decimal.html >>> >>> We can call these context variables. As your code shows, the true "home" >>> of the "prec" value is not some object you manage in your code, but rather >>> some background object called the Context. >>> >>> The Context is not inherited by sub-threads. >>> >>> Your code is fine, because you did not use threads. Replace the map with >>> concurrent.futures code (as in my example). >>> >>> Your code will not work properly anymore. This is the issue. >>> ___ >>> Python-ideas mailing list -- python-ideas@python.org >>> To unsubscribe send an email to python-ideas-le...@python.org >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/python-ideas@python.org/message/6YU3RZ6WDWVJI7QEJKICJZN72B5FYOEV/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> *Pronouns: he/him **(why is my pronoun here?)* >> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> >> > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KWDN3T7QUEBLGL3YBHDIARHDEAQJMW43/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Stack-scoped variables
Perhaps we need a library for creating/managing threads that inherits all current context values? On Thu, Aug 19, 2021 at 7:48 AM Paul Prescod wrote: > There are certain values that are managed independent of any specific > code-accessible object. The decimal precision is a good example: > > https://docs.python.org/3/library/decimal.html > > We can call these context variables. As your code shows, the true "home" > of the "prec" value is not some object you manage in your code, but rather > some background object called the Context. > > The Context is not inherited by sub-threads. > > Your code is fine, because you did not use threads. Replace the map with > concurrent.futures code (as in my example). > > Your code will not work properly anymore. This is the issue. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/6YU3RZ6WDWVJI7QEJKICJZN72B5FYOEV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZSOM5DJ3JFCXJDANRWTRVF3LHYNJ2EDJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP idea
That's proposed in PEP 645 (https://www.python.org/dev/peps/pep-0645/). Personally I think it's not necessary, we should just write MyType | None. (Yes, this is directly from TypeScript.) On Sun, Aug 15, 2021 at 6:10 AM Will Bradley wrote: > Hi all, > > As of 3.10 (PEP 604) we've gotten syntactical support for a common type > operation— namely, typing.Union[Type1, Type2] can now be written as Type1 | > Type2 . This is achieved via overriding the __or__ method. > > I propose the ? symbol as sugar for typing.Optional, so that > typing.Optional[MyType] can be written as MyType? . (Yes, this is lifted > directly from C#.) > > Thoughts? Is it unnecessary now that we can write MyType | None as of 3.10? > > Thanks, > Will > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/VYZOMTCNSSAJNAYHRE5A5BJUMACY57SF/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VOEC3A6GMSLMIXU2WBUKKXCWVH673BCT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Notation for subscripts.
Have you seen PEP 637? IIRC it has discussions on a[] and a[*x]. Note that
it was rejected, but the idea of a[*x] is being resurrected for PEP 646.
On Fri, Aug 13, 2021 at 5:43 AM Matsuoka Takuo
wrote:
> Dear Developers,
>
> Given a subscriptable object s, the intended rule for the notation for
> getting an item of s seems that, for any expression {e}, such as
> "x, ",
> s[{e}]
> (i.e., s[x, ] if {e} is "x, ") means the same as
> s[({e})]
> (i.e., s[(x, )] in the considered case), namely, should be evaluated
> as s.__getitem__(({e})) (or s.__class_getitem__(({e})) when that
> applies). If this is the rule, then it looks simple and hence
> friendly to the user. However, there are at least two exceptions:
>
> (1) The case where {e} is the empty expression "":
> The expression
> s[]
> raises SyntaxError instead of being evaluated in the same way as
> s[()] is.
>
> (2) The case where {e} contains "*" for unpacking:
> An expression containing the unpacking notation, such as
> s[*iterable, ]
> raises SyntaxError instead of being evaluated in the same way as
> s[(*iterable, )] in this example, is.
>
> Are these (and other if any) exceptions justified? If not, I propose
> having the described rule to have full effect if that would simplify
> the syntax. This would affect currently working codes which rely on
> SyntaxError raised in either of the described ways (through eval, exec
> or import??). I wonder if reliance on SyntaxError in these cases
> should be supported in all future versions of Python.
>
> Best regards,
> Takuo Matsuoka
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/V2WFMNVJLUBXVQFPNHH4TJNRYNPK2BKJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/L6CXI6OWIXS7ADXWHE4K2FJUMQSAOAYI/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: writelines2?
Let's leave poor writelines alone. It's an old API, if you want something different, there are a zillion other ways (e.g. print(*x, sep="\n") ). I wonder how much research the OP did before they claimed "writelines is a very big misnomer to many python developers". On Tue, Jul 13, 2021 at 8:46 AM MRAB wrote: > On 2021-07-13 15:11, sandhoners...@gmail.com wrote: > > Maybe (to be consistent with other functions like print), end= since > that would allow even custom line endings > > > I'm not sure about the name 'end'. The 'print' function has 'end', but > it's printed only at the end(!); .writelines would write it after every > line. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/2SYIBL275IIHMSPAT6J4K3TIA7HXEKV5/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RBWD6GIK5JTAM4PDWU6X6O4JWTOXZWUD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)
On Mon, Jul 5, 2021 at 5:05 PM Chris Angelico wrote:
> On Tue, Jul 6, 2021 at 9:39 AM Greg Ewing
> wrote:
> >
> > On 6/07/21 9:56 am, Jim Baker wrote:
> > >
> > > d = deferred_tag"Some expr: {:(x*2)}"
> > >
> > > All that is happening here is that this being wrapped in a lambda,
> which
> > > captures any scope lexically as usual.
> >
> > Is there reason to think this will be a common enough requirement
> > to justify having an abbreviated syntax for a parameterless lambda
> > that's only available in template expressions?
> >
>
> If it's just being wrapped in a lambda function, probably nothing, but
> I think that that would be *very* surprising behaviour. People will
> expect that the expressions' values will be collected at the point you
> hit the interpolated string, not later when it gets used.
>
It would be surprising indeed if this was the *default* behavior, that's
why you have to specially mark it using {:...} in Jim's proposal.
IIUC the idea is that the entire template becomes effectively a lambda.
It's useful if the evaluation is relatively expensive and may never be
needed, e.g. for logging at a level that is off in production. We can
debate whether it's better to mark individual substitutions with something
like {:...} or whether we should mark the template as a whole (obviously
the marking must be understandable by the parser).
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TUAFAIOH2WEHZOKQZ4RF2M6H6KVI7CMY/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)
FWIW, we could make f-strings properly nest too, like you are proposing for backticks. It's just that we'd have to change the lexer. But it would not be any harder than would be for backticks (since it would be the same algorithm), nor would it be backward incompatible. So this is not an argument for backticks. Separately, should there be a way to *delay* evaluation of the templated expressions (like we explored in our private little prototype last year)? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/E5JBLCI3J357CCEKNC7ME5ZX6KORPYBD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
On Fri, Jun 25, 2021 at 12:17 PM Christian Heimes wrote: > On 25/06/2021 20.17, Guido van Rossum wrote: > > On Fri, Jun 25, 2021 at 8:22 AM Bluenix > <mailto:bluenix...@gmail.com>> wrote: > > > > I am not fully aware of how ssl.SSLContext is used, but adding > > __slots__ would prevent this. You would see an error similar to: > > AttributeError: 'MyClass' object has no attribute 'my_attribute' > > > > > > That's a reasonable solution, except that it's not backwards compatible. > > It's possible that there is code out there that for some reason adds > > private attributes to an SSLContext instance, and using __slots__ would > > break such usage. (They could perhaps fix their code by using a dummy > > subclass, but that could well become a non-trivial change to their code, > > depending on where they get their SSLContext instances.) > > > > So unless there's evidence that nobody does that, we're stuck with the > > status quo. I'm adding Christian Heimes to the thread in case he has a > > hunch either way. > > I agree, it is a backwards incompatible change. Also __slots__ won't > work. The class has class attributes that can be modified in instances. > Oh, I see. There are two class attributes, sslsocket_class and sslobject_class, and their docs say they can be overridden per instance. Could we perhaps create a custom descriptor that allows both per-instance and per-class assignment and lookup? > You cannot have attributes that are both class and instance attributes > with __slots__. We'd have to overwrite __setattr__() and block unknown > attributes of exact instances of ssl.SSLContext. > Well, if we don't think it's supported behavior to subclass SSLContext, perhaps we could do that. The bug in the OP's code (misspelling minimum_version in assignment) is pretty hard to find. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VGSFW6UXY7NRHZ6OUWJMXABFVVFMHIQN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
On Fri, Jun 25, 2021 at 11:42 AM Chris Angelico wrote: > On Sat, Jun 26, 2021 at 4:20 AM Guido van Rossum wrote: > > > > On Fri, Jun 25, 2021 at 8:22 AM Bluenix wrote: > >> > >> I am not fully aware of how ssl.SSLContext is used, but adding > __slots__ would prevent this. You would see an error similar to: > AttributeError: 'MyClass' object has no attribute 'my_attribute' > > > > > > That's a reasonable solution, except that it's not backwards compatible. > It's possible that there is code out there that for some reason adds > private attributes to an SSLContext instance, and using __slots__ would > break such usage. (They could perhaps fix their code by using a dummy > subclass, but that could well become a non-trivial change to their code, > depending on where they get their SSLContext instances.) > > > > So unless there's evidence that nobody does that, we're stuck with the > status quo. I'm adding Christian Heimes to the thread in case he has a > hunch either way. > > > > Another possible solution - although I'm not sure how practical this > would be - would be to have __init__ accept only specific keyword > arguments. You could do something like: > > ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT, > minimum_version=ssl.PROTOCOL_TLSv1_1) > > and it would work, but if you misspell "minimum_version", it would > error out. That's actually what I expected it to do, based on the > signature; but it doesn't, it simply ignores the argument. Not > actually sure what it does with kwargs. > But that's not what the OP wrote -- his code used an attribute assignment. It looks like SSLContext just throws the *args and **kwds away. You *must* set the attribute. I don't know why it has *args and **kwds at all -- maybe so that you can subclass it and define an __init__ that takes those? It all seems a mystery to me. I've never used this directly -- I've always just used urllib's default for https URLs. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HVOEIESRKDOZMZ7RVQEQFK23HJ6TTTC7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
On Fri, Jun 25, 2021 at 8:22 AM Bluenix wrote: > I am not fully aware of how ssl.SSLContext is used, but adding __slots__ > would prevent this. You would see an error similar to: AttributeError: > 'MyClass' object has no attribute 'my_attribute' > That's a reasonable solution, except that it's not backwards compatible. It's possible that there is code out there that for some reason adds private attributes to an SSLContext instance, and using __slots__ would break such usage. (They could perhaps fix their code by using a dummy subclass, but that could well become a non-trivial change to their code, depending on where they get their SSLContext instances.) So unless there's evidence that nobody does that, we're stuck with the status quo. I'm adding Christian Heimes to the thread in case he has a hunch either way. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/U7N5K542MGEAC3VXDPJEVUV4OPB6QJ2P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: disallow assignment to unknown ssl.SSLContext attributes
Would a static type checker have found this? On Fri, Jun 25, 2021 at 02:07 Thomas Grainger wrote: > I was debugging some code that was using TLSv1.2 when I expected it to > only support TLSv1.3, I tracked it down to a call to: > > context.miunimum_version = ssl.TLSVersion.TLSv1_3 > > it should have been: > > context.minimum_version = ssl.TLSVersion.TLSv1_3 > > I'd like invalid attribute assignment to be prevented at runtime > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/RPD5OICSY3KLVXKIYWFTABNIA7F7YWG3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BHZNLW2647Z6KYRP672J63RJ7CDGUUVV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
On Fri, Jun 18, 2021 at 10:15 PM Steven D'Aprano
wrote:
> On Fri, Jun 18, 2021 at 09:33:49PM -0700, Guido van Rossum wrote:
>
> > Now, this shouldn't be considered an airtight argument against [*chunk
> for
> > ...], but it does show that there's no straightforward explanation of its
> > meaning through equivalence (like the OP seemed to think), and I think
> this
> > is what Serhiy was also getting at in his post.
>
> Indeed. I was initially confused by what Ben thought was a simple and
> obvious connection between star unpacking in some other contexts and his
> suggestion for comprehensions. The analogy with `[*a]` never crossed my
> mind, and I don't think that we should look at this as literally the
> application of sequence unpacking in a comprehension, for reasons I gave
> in my earlier post.
>
> But having it explained to me, I think that treating this as an analogy
> rather than literal unpacking works. We already give unary star and
> double star a number of meanings, not all of which are related:
>
>
> - import wildcard;
>
> - capture positional and keyword parameters `def func(*args, **kw)`
>
> - sequence and keyword unpacking in function calls;
>
> - sequence capture in assignment targets `head, *a, tail = items`
>
> - sequence unpacking in list etc displays;
>
>
> Have I missed any?
>
What you seem to be (intentionally) missing is that all but the import
wildcard *are* closely related, even though they are specified separately
in the syntax. (Saying that they are unrelated would be like saying that
the name occurring after a 'def' keyword and the function name occurring in
a function call are unrelated. :-)
> We could define *star comprehensions* as syntactic sugar for nested
> comprehensions, to aid in flattening nested sequences and mappings.
>
> [*expression for name in sequence if condition]
>
> results in this:
>
> result = []
> for name in sequence:
> if condition:
> for tmp in expression:
> result.append(tmp)
> return result
>
> I haven't thought deeply into this, but I think that if the starred
> expression is anything but a simple name, it may require parentheses?
>
> *name # okay
> *(name.attr or []) # everything else needs parens
>
The grammar for the last three forms you give allows pretty much any
expression, for example
https://github.com/python/cpython/blob/291848195f85e23c01adb76d5a0ff9c6eb7f2614/Grammar/python.gram#L504-L506
> Alternatively, we could just do something that people have been asking
> about since Python 1.5 and provide a flatten builtin or list method :-)
>
Probably a builtin, since in my mind I want to write flatten(a), never
a.flatten(), and it would be useful for any kind of sequence of sequences
(or even iterable of iterables).
I think I would find flatten(a) more readable than [*chunk for chunk in a],
and more discoverable: this operation is called "flatten" in other
languages, so users are going to search the docs or help for that.
But there could be endless debate about whether flatten( ("x", "y") )
should return a list or a tuple...
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KTZLOA6DIRIJ4QHCZBVQGD36AX6JZQ5V/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
On Fri, Jun 18, 2021 at 8:40 PM Steven D'Aprano wrote:
> On Fri, Jun 18, 2021 at 07:38:49AM -0700, Guido van Rossum wrote:
>
> > Note the ambiguity around whether the user might have meant
> >
> > [x,(y for y in a)]
> >
> > or
> >
> > [(x, y) for y in a]
>
> We already have a rule to disambiguate generator comprehensions: they
> must always be parenthesized unless they are already parenthised:
>
> g = (y for y in a) # parens required
> t = 999, (y for y in a) # parens required
>
> func((y for y in a)) # inner parens optional
>
Yes, that's exactly what I was referring to.
> That’s a good enough reason for me to also disallow *chunks.
>
> That's an odd way to look at it. We must disallow an unambiguous syntax
> because a completely different syntax would have been ambiguous if we
> didn't already have a rule in place that disambiguates it.
>
Maybe, but the two are not unrelated. In other contexts, when we accept
"*chunk", and 'chunk' equals "1, 2", we also accept "1, 2" in the original
position, and it means the same thing. This is useful as an explanation of
the semantics of the unary '*' operator[1]. For example
# Given:
chunk = 1, 2
# Equivalent:
f(*chunk)
f(1, 2)
# Equivalent:
[*chunk]
[1, 2]
So then if we were to allow this:
[*chunk for chunk in ...]
we ought to consider this equivalent:
[1, 2 for chunk in ...]
(Note there's nothing that says the expressions to the left of 'for' need
to involve the for-control variable 'chunk'. :-)
Now, this shouldn't be considered an airtight argument against [*chunk for
...], but it does show that there's no straightforward explanation of its
meaning through equivalence (like the OP seemed to think), and I think this
is what Serhiy was also getting at in his post.
__
[1] Does the unary star operator have a name when used like this in Python?
In JavaScript the equivalent syntax ("...chunk", where the "..." are a
literal ellipsis) is called "spread". We could borrow this term.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/M5U7L54BRZU6KSI42RGZBOPIS4R4HGNJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
On Fri, Jun 18, 2021 at 00:43 Serhiy Storchaka wrote:
> 18.06.21 00:22, Ben Rudiak-Gould пише:
> > Okay, slightly off-topic, but can we *please* allow
> >
> > [*chunk for chunk in list_of_lists]
> >
> > some day. I think it was left out because some discussion concluded it
> > would be too confusing, which is ridiculous. I assumed it would work and
> > was confused to find that it didn't. It's blatantly inconsistent.
>
> It was originally proposed in PEP 448 (Additional Unpacking
> Generalizations) but was excluded after discussing.
>
> If we allow
>
> [*chunk for chunk in list_of_lists]
>
> we should allow also
>
> [x, y for x in a]
>
> which would be equivalent to
>
> [a[0], y, a[1], y, a[2], y, ...]
Note the ambiguity around whether the user might have meant
[x,(y for y in a)]
or
[(x, y) for y in a]
That’s a good enough reason for me to also disallow *chunks.
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/6I63FWKEDQ4RJPUL4CQK22KFCKIIPU5X/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
Wow, strong language. Not really helping people see it your way. On Thu, Jun 17, 2021 at 14:26 Ben Rudiak-Gould wrote: > On Thu, Jun 17, 2021 at 12:37 AM Serhiy Storchaka > wrote: > >> And it is equivalent to pure Python code >> >> [x for chunk in list_of_lists for x in chunk] >> > > Okay, slightly off-topic, but can we *please* allow > > [*chunk for chunk in list_of_lists] > > some day. I think it was left out because some discussion concluded it > would be too confusing, which is ridiculous. I assumed it would work and > was confused to find that it didn't. It's blatantly inconsistent. > > It's not even the performance I care about, it's the unreadability of > having an extra "for i_have_to_think_of_yet_another_variable_name in > whatever" at the end of the list comprehension (at maximum distance from > where the variable is used). I've wished for this feature ridiculously many > times. > > >> It would be >> possible to make the compiler recognizing such pattern and generating >> more efficient bytecode (LIST_EXTEND instead of an internal loop with >> LIST_APPEND), but I am not sure that this case is common enough to >> complicate the compiler. >> > > In my personal experience it's very common. > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/YH7COSZIV5BWQ3EOEA5MQMBHMB3OQNND/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7C6VIG52AEBKTEE4KD5MIGTHINEFWZEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate sum of lists
Just trolling along, flattening a list could be written as functools.reduce(list.__iadd__, xs, []) Right? On Wed, Jun 16, 2021 at 22:53 David Mertz wrote: > On Thu, Jun 17, 2021, 1:38 AM Chris Angelico > >> >>> list(chain.from_iterable(list_of_lists)) >> >> > More-itertools has flatten(): >> https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.flatten. >> That seems better than a method specific to lists. >> >> ... which is built on top of chain.from_iterable. :) >> > > Oh, of course. And anyone can put it in their personal utility library > too. I just meant it in the sense that the name might be more intuitive to > beginners. > >> ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/2T53ADB3TVQJF2UENEXKB5G5ZWTQOQVW/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QTXUMBUHFWBG572NPD6YUNT3FEUCIDEC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Define functions without parentheses (if no parameters given)
On Fri, Jun 11, 2021 at 7:47 AM Jelle Zijlstra wrote: > > El jue, 10 jun 2021 a las 19:30, Cameron Simpson () > escribió: > >> On 11Jun2021 10:01, Cameron Simpson wrote: >> >> It also struck me: functions with _no_ parameters are pretty rare. >> >> [...] >> > I got curious so I checked a large codebase I have access to. Out of 85540 > functions, 8244 take no arguments. Many of them are test functions. > I'm sure the idea is dead now, but it reminds me of an amusing anecdote I heard in college. You may not have heard of a language named Algol-68, but it was a big thing when I learned programming in Amsterdam in the late '70s. Like its predecessor, Algol-60, it had a feature where parameter-less functions could both be *defined* and *called* without parentheses. Now, in Algol-60, this was easy, because there were no function pointers, so whenever the compiler saw the name of a parameter-less function, it would generate the code to call it. (Example: "x := random*2".) But Algol-68 *did* have function pointers, so the language design committee had to introduce a complicated wrinkle into the type system so that you could write things like "f := random" (interpreting it as a function pointer) but also "x := 2*random" (calling it). The distinguishing property was the type of the receiving end (i.e., f had to be declared as a parameterless function pointer, and x had to be a number). So one of the classes I took near the end of my studies was taught by the lead author of Algol-68 (Adriaan van Wijngaarden). He was well respected and near retirement age, so he could do what he wanted in class, and sometimes he just told anecdotes from the past (I'd love such a job :-). One day the issue with parameter-less functions came up, and by then a new language named C had gained some notoriety. C, of course, has function pointers and parameter-less functions, but both the declaration and the call must use an empty pair of parentheses (i.e, "x = 2*random()", like Python). Van Wijngaarden told us, somewhat ruefully, that, had the design committee known that programmers would be happy to write that empty pair of parentheses, they would have been able to simplify a significant corner of Algol-68's type system. This was one of the seminal ideas that went into Python's design. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DQGLY3ZLFMGVOC4JE7E2TLMWDROK2PAE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()
On Fri, Jun 4, 2021 at 3:08 PM Thomas Güttler wrote: > > > Am Fr., 4. Juni 2021 um 19:20 Uhr schrieb Guido van Rossum < > gu...@python.org>: > >> PEP 501 is unlikely to be accepted *as is*. But it’s still a good >> starting point. >> >> > OK, before starting a new project, it maybe makes sense to finish the > first. > > Why not reject PEP-501 officially? Maybe with a reason. Then we know > what's wrong with it. > You'd have to ask its author. Most likely he'll just withdraw the PEP completely without telling you anything more. In short, I don't think you're going to get much out of trying to get anyone to say anything "official" about PEP 501. If you really want to know more, you could probably dig up the discussions around that PEP and learn from that. > After that is done, we can think about a new start. > There's no need to wait for that. > What do you think? > > > > > >> Personally I would look for inspiration towards JavaScript template >> literals ( >> >> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals), >> combined with f-string-like interpolation. >> >> > I personally really would like to avoid the dollar sign which gets used in > JS template literals. > Well of course. The Python equivalent would use the exact same interpolation syntax as f-strings (and before it, str.format()). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7O5NKN3XUJQJLC3S6JGPT7QBVPD3GUUF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()
PEP 501 is unlikely to be accepted *as is*. But it’s still a good starting point. Personally I would look for inspiration towards JavaScript template literals ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals), combined with f-string-like interpolation. On Fri, Jun 4, 2021 at 07:24 Matt del Valle wrote: > Interpolation templates were recently brought up here ( > https://mail.python.org/archives/list/python-ideas@python.org/thread/5AW73ICBD4CVCRUNISRNAERPPF2KSOGZ/), > and Guido mentioned that in his opinion the SC would be unlikely to > reconsider PEP 501 in its current state. I trust that he has a much better > insight into this sort of thing than the rest of us, so he's likely right, > but if I'm honest I wasn't able to find any of the actual reasons why PEP > 501 was deferred in the Rationale or Discussion sections of the PEP. > > If anyone has any insight into the actual reasons why PEP 501 might be > considered unworkable in its current state, I'd be really curious to find > out what they are. It's hard to argue in favor of a feature if you don't > know what the actual arguments against it are. > > The rationale for it at least seems quite solid to me, as it provides > powerful templating and injection-safety functionality. It's not a purely > hypothetical feature either, as it has been quite successful in other > languages like C#. > > If the success of f-strings over the last five years is anything to go by, > people also seem to overwhelmingly prefer this style of string formatting > compared to `str.format` or `%` formatting. I literally can't think of a > single modern Python codebase I've seen lately where f-strings weren't the > main method of string-formatting employed. > > Is it something in the implementation then? Or something else? > > On Fri, Jun 4, 2021 at 1:37 PM Chris Angelico wrote: > >> On Fri, Jun 4, 2021 at 10:02 PM Thomas Güttler >> wrote: >> > >> > Hi, >> > >> > I have a crazy idea how to extend Python for web development. >> > >> > What do you think? What are the next steps? >> > >> > [chomp details] >> >> Something like this - but more generic - has been proposed already: >> >> https://www.python.org/dev/peps/pep-0501/ >> >> There've been a few variants on the idea, but I think PEP 501 is the >> best summary. >> >> If you want to press forward with this, I think that would be the best >> starting point. >> >> ChrisA >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/WZHFKMUKSSS6LLJGQUX7DVGP5EOL7M46/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/PWZALQJKKECGNAWT4SA63AVT6HUPIAF3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KI6U4RWFWZQUBAJTUI44TYZEBXJEIZJG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: The name Ellipsis should be a constant
Andre, did you have an experience where something related to Ellipsis/... confused you? It is not clear to me what exactly prompted you to single out Ellipsis (or it’s repr()?) On Mon, May 31, 2021 at 08:37 André Roberge wrote: > > > On Mon, May 31, 2021 at 12:20 PM MRAB wrote: > >> On 2021-05-31 15:55, Paul Bryan wrote: >> > If you're proposing prevention of monkey patching Ellipsis, I think >> > you'll have to go all-in on all builtins. >> > >> > For example: >> > >> >>>> str = int >> > >> >>>> str >> > >> > >> > >> >>>> str == int >> > >> > True >> > >> > >> If you rebind str to int, the repr of str will say , so you >> can tell that something's happened, but the repr of ... is always >> 'Ellipsis', even though you've rebound Ellipsis. >> > > Exactly. > > Thinking some more about it, perhaps the confusion would be sufficiently > reduced if the repr of '...' would be 'Ellipsis (...)', and use this repr > to appear in error messages rather than simply the name Ellipsis. > > > >> >> > >> > On Mon, 2021-05-31 at 11:37 -0300, André Roberge wrote: >> >> In Python `...` is referred to as `Ellipsis` and cannot be assigned to. >> >> Yet, one can assign any value to the name `Ellipsis`. >> >> >> >> Consider the following: >> >> >> >> ``` >> >> >>> ... >> >> Ellipsis >> >> >>> ... == Ellipsis >> >> True >> >> >>> Ellipsis >> >> Ellipsis >> >> >>> Ellipsis = 3 >> >> >>> Ellipsis >> >> 3 >> >> >>> ... = 4 >> >> File "", line 1 >> >> ... = 4 >> >> ^ >> >> SyntaxError: cannot assign to Ellipsis >> >> >>> # But I just did assign a new value to the name Ellipsis above. >> >> >>> Ellipsis >> >> 3 >> >> >>> ... >> >> Ellipsis >> >> >>> ... == Ellipsis >> >> False >> >> ``` >> >> >> >> For consistency, `Ellipsis` (the name) should **always** refer to the >> >> same object that `...` refers to, so that both could not be assigned a >> >> new value. >> >> >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/NE2FAW3XDFYUIMILV4BC2XT6VKLC4P6V/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/DIRDIQFK72LFHYJNAD5BWL3L5SPAUMVM/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DWOVJOTJZQGTLVDEQ76XAI5ZD4M3KSCI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bring back PEP 501
gt;> >Registered at Amtsgericht Duesseldorf: HRB 46611 >> >https://www.egenix.com/company/contact/ >> > https://www.malemburg.com/ >> > >> > >> > ___ >> > Python-ideas mailing list -- python-ideas@python.org >> > To unsubscribe send an email to python-ideas-le...@python.org >> > https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> > Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/FXSHIJ5TV6ZRN2D74FEFEGSHTB4LKGQJ/ >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> > >> >> -- >> Marc-Andre Lemburg >> eGenix.com >> >> Professional Python Services directly from the Experts (#1, May 08 2021) >> >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >> >>> Python Product Development ...https://consulting.egenix.com/ >> >> >> ::: We implement business ideas - efficiently in both time and costs ::: >> >>eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 >> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg >>Registered at Amtsgericht Duesseldorf: HRB 46611 >>https://www.egenix.com/company/contact/ >> https://www.malemburg.com/ >> >> ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/MYKV5BUW4IBSWRDNIUARKAHXM4R5HZO3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/36ZVYYCEOZLOJJWXGSMK2L6FZ7ZLS24B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: symbolic math in Python
Oh no, not the vertical bar hack. :-( ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/B4XH4Q5PJNE65DHHIIMIZ76XSXBE4Y2T/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fractions vs. floats - let's have the cake and eat it
On Tue, May 18, 2021 at 12:39 AM Martin Teichmann < martin.teichm...@gmail.com> wrote: > [...] > To give an example (this is not fake, but from the prototype): > > >>> 2/5 > 0.4 > >>> (2/5).denominator > 5 > >>> isinstance(2/5, float) > True > >>> type(2/5) > > > Note that this is only done at compile time, no such behavior is done at > run time, everything just behaves like normal floats: > > >>> two=2 > >>> five=5 > >>> (two/five) > 0.4 > >>> (two/five).numerator > Traceback (most recent call last): > File "", line 1, in > AttributeError: 'float' object has no attribute 'numerator' > This violates a basic property of Python. If 1/2 has a certain property, then `x = 1; y = 2; x/2` should have the same property. Please don't go down this road. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/R3B7CA4KSOVECDRHCSYSXPNEHGOYZP5C/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: division of integers should result in fractions not floats
I should probably explain (again) why I am not a fan of such a change. I blogged about this before -- this is mostly a treatise about / vs. //, but it explains my reservations about this proposal as well: http://python-history.blogspot.com/2009/03/problem-with-integer-division.html In particular: """ For example, in ABC, when you divided two integers, the result was an exact rational number representing the result. [...] In my experience, rational numbers didn't pan out as ABC's designers had hoped. A typical experience would be to write a simple program for some business application (say, doing one’s taxes), and find that it was running much slower than expected. After some debugging, the cause would be that internally the program was using rational numbers with thousands of digits of precision to represent values that would be truncated to two or three digits of precision upon printing. This could be easily fixed by starting an addition with an inexact zero, but this was often non-intuitive and hard to debug for beginners. """ -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3J5DRJLHZYL33ZBTN4SOR7PNYEZ3IKYC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`
On Sun, May 9, 2021 at 5:08 PM Chris Angelico wrote: > On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano > wrote: > > > > On Sun, May 09, 2021 at 04:45:55PM -, Thomas Grainger wrote: > > > > > now that python2.7 is EOL, it might be worth resurrecting this syntax > > [...] > > > except E1, E2, E3 as e: > > > > What advantages will this new syntax bring us? > > > > Will it allow us to do things that we can't currently do? > > > > When would you use it in preference to the existing syntax? By this I > > mean both under what circumstances, and at what time (tomorrow? in a > > year? in ten years?). > > > > Is there an aim beyond saving two characters? > > > > It would remove a level of frustration. I've watched a lot of novice > programmers, and some intermediate programmers, run into a source of > (now completely unnecessary) pain that changing this: > > except ValueError: > > into this: > > except ValueError, TypeError: > > doesn't work. Yes, it's a quick SyntaxError, but the editor won't show > it up (since most editors are Python 2 compatible, and wouldn't be > checking this level of syntax anyway), so there's X amount of time > spent coding, then go to run the thing, and it won't work the way they > expect it to. > We've had arguments like this before, and we've usually taken the position that we shouldn't compromise the language to cater to imperfect tools. Editors that are Python-aware should just catch up with Python 3 syntax. Editors that don't check this level of syntax definitely shouldn't be used as motivation at all. (I just tried this in the latest VS Code Insiders edition, and the Python support does catch this.) Also, I wonder what made those users think to try that? Maybe they read a tutorial or StackOverflow issue suggesting the Python 2 syntax? > If it weren't for the Python 2 issues, would there be any good reason > for demanding parentheses? We don't need them in a for loop: > > for i, thing in enumerate(stuff): > Someone else (Steven?) already pointed out in this thread that there are other places where 'as ' or 'as ' as used, the relative precedence of commas and 'as' is different than the proposal here: import foo.bar as foobar, bar.foo as barfoo is parsed as import (foo.bar as foobar), (bar.foo as barfoo) Similarly, with something as foo, something_else as bar: ... is parsed as with (something as foo), (something_else as bar): ... And similar in pattern matching. It's true that adding "as e" makes it read oddly, but that's the only > real point against it - other than a question of "when". > I think never is a perfectly fine answer. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7XREC6PDF2YG55WVDXHJHWZQJNYJIC7X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
Wow, super helpful response. On Mon, Apr 12, 2021 at 1:26 PM Brendan Barnwell wrote: > On 2021-04-12 03:13, Stéfane Fermigier wrote: > > The public API of a library is the one which is documented as > > such. > > > > > > Right, except that in practice: > > > > 1) Many useful libraries are not documented or properly documented. > > Then they're buggy. I'm not convinced by the argument that "in > practice" people do things they shouldn't do and that therefore we > should encourage them to do more of that. > > > 2) People don't read the docs (at least not always, and/or not in > details). > > Insofar as someone relies on behavior other than that given in the > docs, they are being foolish. Again, I'm not convinced by the argument > that "in practice" people do foolish things and that therefore we should > encourage them to do more of that. > > -- > Brendan Barnwell > "Do not follow where the path may lead. Go, instead, where there is no > path, and leave a trail." > --author unknown > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/DWI2MI3FRPRNOC7AS6CC3YBWLOOVZYZA/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/F57J672KTTK6FRA7ITRUVTRYBF2A3P57/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
On Sun, Mar 14, 2021 at 10:55 PM Ethan Furman wrote: > I completely agree with this. One of the hallmarks of Python is the > ability to query, introspect, and modify Python code. It helps with > debugging, with experimenting, with fixing. Indeed, one of the few > frustrating bits about Python is the inability to work with the C portions > as easily as the Python portions (note: I am /not/ suggesting we do away > with the C portions). > > What would be the benefits of locking down modules in this way? I owe you an answer here. For large projects with long lifetimes that expect their API to evolve, experience has taught that any part of the API that *can* be used *will* be used, even if it was clearly not intended to be used. And once enough users have code that depends on reaching into some private part of a package and using a method or attribute that was available even though it was undocumented or even clearly marked as "internal" or "private", if an evolution of the package wants to remove that method or attribute (or rename it or change its type, signature or semantics/meaning), those users will complain that the package "broke their code" by making a "backwards incompatible change." For a casually maintained package that may not be a big deal, but for a package with serious maintainers this can prevent ordered evolution of the API, especially since a package's developers may not always be aware of how their internal attributes/methods are being used or perceived by users. So experienced package developers who are planning for the long term are always looking for ways to prevent such situations (because it is frustrating for both users and maintainers). Being able to lock down the exported symbols is just one avenue to prevent disappointment in the future. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XDLAAQKWDSPOJ6HKVTBEZEK6KYM5PQGP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding syntax for the empty set
Please. Use. set().
On Sat, Apr 10, 2021 at 02:03 Serhiy Storchaka wrote:
> 09.04.21 19:08, micro codery пише:
> >
> > You can now use `{*()}` as a syntax for empty set.
> >
> > I saw that in the ast module and think it's clever, mainly in a good
> > way. I don't think it is the same as having dedicated syntax for the
> > empty set partly because I think it needs to be taught. I don't think a
> > new pythonista would turn to empty tuple unpacking to get the empty set,
> > where I do think that either set() or {,} would be natural, at least
> > after some trial and exceptions.
>
> Do you think that {,} does not need to be taught? It is a new special
> syntax which needs paragraphs in tutorial and language reference. In
> contrary, {*()} is a simple combination of already described syntax
> elements.
>
> > It also doesn't give quite the
> > optimization as {,}.
>
> It is a trivial optimization. It was not implemented yet only because
> such code is never used in tight loops, empty set creation is very rare
> operation at all. We prefer to keep the compiler simpler and focus on
> optimizing common operations which has significant effect.
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ASBHWYDCPR3D2FCVLGPHELPRJUJOWHLL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MWBML4BCZ5I3OR2L64JW7WZLZSUTU6GJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python Idea - extension of 'with'
But if there are two proposals with conflicting semantics for the same
syntax that kills both ideas, doesn’t it? Because apparently it’s not clear
what the syntax should mean.
On Fri, Apr 9, 2021 at 00:28 Serhiy Storchaka wrote:
> 08.04.21 17:59, anthony.flury via Python-ideas пише:
> > I was wondering whether a worthwhile extension might be to allow the
> > `with` statement to have an `except` and `else` clauses which would
> > have the same
> > semantics as wrapping the `with` block with a try - for example the
> > above would now look like:
> >
> >
> > with open('config.cfg', 'r') as cfg:
> > # Process the open file
> > config = load_config(cfg)
> > except FileNotFound:
> > logging.info('Config file not found - using default
> configuration')
> > except PermissionError:
> > logging.warning('Cannot open config .cfg - using default
> > configuration')
> > config = default_config()
> > else:
> > logging.info('Using config from config.cfg')
>
> A year or two ago I proposed the same syntax with different semantic: to
> catch only exceptions in the context manager, not in the with block.
> Exceptions in the with block you can catch by adding try/except around
> the with block, exceptions in the with block and the context manager you
> can catch by adding try/except around the with statement, but there is
> no currently way to catch only exceptions in the context manager.
>
> It is quite a common problem, I encounter it several times per year
> since then. I still have a hope to add this feature, and it will
> conflict with your idea.
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/OMAEC4EPAWBXBIHHLY75M6GTN6OL4MP4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/YSNU23SVDJSRI5IR4UYDJDORCZFLL7PG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Looking for people interested in a Python register virtual machine project
On Tue, Mar 23, 2021 at 12:40 PM Skip Montanaro wrote: > I've not attempted to make any changes to calling conventions. It > occurred to me that the LOAD_METHOD/CALL_METHOD pair could perhaps be > merged into a single opcode, but I haven't really thought about that. > Perhaps there's a good reason the method is looked up before the > arguments are pushed onto the stack (call_function()?). In a > register-based VM there's no need to do things in that order. > IIRC the reason is that Python's language reference promises left-to-right evaluation here. So o.m(f()) needs to evaluate o.m (which may have a side effect if o overrides __getattr__) before it calls f(). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BKYWRGTA3J3ZEJXLZPPTUCZWKJGA7OSR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Looking for people interested in a Python register virtual machine project
As I wrote, Skip’s Porto+PEP is not proposing to delete locals that are not used in the rest of the function, only registers. So the voiced concerns don’t apply. On Sun, Mar 21, 2021 at 23:59 Chris Angelico wrote: > On Mon, Mar 22, 2021 at 5:37 PM Ben Rudiak-Gould > wrote: > > > > On Sun, Mar 21, 2021 at 11:10 PM Chris Angelico > wrote: > >> > >> At what point does the process_objects list cease to be referenced? > >> After the last visible use of it, or at the end of the function? > > > > > > In Python as it stands, at the end of the function, as you say. > > > > Skip Montanaro's PEP suggested that in his register machine, locals > would be dereferenced after their last visible use. I don't think that's > intrinsically a bad idea, but it's not backward compatible. The thing with > the process objects was just an example of currently working code that > would break. > > > > The example has nothing to do with PyQt5 really. I just happen to know > that QProcess objects kill the controlled process when they're collected. I > think it's a bad design, but that's the way it is. > > > > Another example would be something like > > > > td = tempfile.TemporaryDirectory() > > p = subprocess.Popen([..., td.name, ...], ...) > > p.wait() > > > > where the temporary directory will hang around until the process exits > with current semantics, but not if td is deleted after the second line. Of > course you should use a with statement in this kind of situation, but > there's probably a lot of code that doesn't. > > > > Thanks for the clarification. I think the tempfile example will be a > lot easier to explain this with, especially since it requires only the > stdlib and isn't implying that there's broken code in a third-party > library. > > I don't like this. In a bracey language (eg C++), you can declare that > a variable should expire prior to the end of the function by including > it in a set of braces; in Python, you can't do that, and the normal > idiom is to reassign the variable or 'del' it. Changing the semantics > of when variables cease to be referenced could potentially break a LOT > of code. Maybe, if Python were a brand new language today, you could > define the semantics that way (and require "with" blocks for anything > that has user-visible impact, reserving __del__ for resource disposal > ONLY), but as it is, that's a very very sneaky change that will break > code in subtle and hard-to-debug ways. > > (Not sure why this change needs to go alongside the register-based VM, > as it seems to my inexpert mind to be quite orthogonal to it; but > whatever, I guess there's a good reason.) > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/C3CUQYW3TQGJHC7SP5B4QJXFDV2XTEXB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5TBFVUF6OTDFWQHEAC6ZJ4LQ64D5DZWA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Looking for people interested in a Python register virtual machine project
On Sun, Mar 21, 2021 at 3:35 PM Chris Angelico wrote:
> On Mon, Mar 22, 2021 at 7:49 AM Ben Rudiak-Gould
> wrote:
> >
> > In the "Object Lifetime" section you say "registers should be cleared
> upon last reference". That isn't safe, since there can be hidden
> dependencies on side effects of __del__, e.g.:
> >
> > process_objects = create_pipeline()
> > output_process = process_objects[-1]
> > return output_process.wait()
> >
> > If the process class terminates the process in __del__ (PyQt5's QProcess
> does), then implicitly deleting process_objects after the second line will
> break the code.
> >
>
> Hang on hang on hang on. After the second line, there are two
> references to the last object, and one to everything else. (If
> create_pipeline returns two objects, one for each end of the pipe,
> then there are two references to the second one, and one to the
> first.) Even if you dispose of process_objects itself on the basis
> that it's not used any more (which I would disagree with, since it's
> very difficult to manage that well), it shouldn't terminate the
> process, because one of the objects is definitely still alive.
>
In the hypothetical scenario, presumably create_pipeline() returns a list
of process objects, where the process class somehow kills the process when
it is finalized. In that case dropping the last reference to
process_objects[0] would kill the first process in the pipeline. I don't
know if that's good API design, but Ben states that PyQt5 does this, and it
could stand in for any number of other APIs that legitimately destroy an
external resource when the last reference is dropped. (E.g., stdlib
temporary files.)
Curiously, this is about the opposite problem that we would have if we were
to replace the current reference counting scheme with some kind of
traditional garbage collection system.
> This is nothing to do with a register-based VM and everything to do
> with standard Python semantics, so this can't change.
>
Exactly. The link with a register-based VM is that if we replaced the value
stack with temporary local variables (as the "register-based" VM scheme
does), we'd have to decide on the lifetimes of those temporary variables.
Finalizing them when the function returns might extend the lifetimes of
some objects compared to the stack-based scheme. But finalizing all local
variables (temporary or not) as soon as they are no longer needed by
subsequent code could *shorten* the lifetimes, as in the above example.
A reasonable solution would be to leave the lifetimes of explicitly named
locals alone, but use the proposed ("as soon as possible") scheme for
temporary variables. This would appear to match how values on the value
stack are treated. Honestly that's how I read the quoted section of Skip's
proto-PEP (since it explicitly mentions registers). A version of the
example that exhibits the same questionable behavior would be this:
return create_pipeline()[-1].wait()
Presumably this would not work correctly with the PyQt5 process class.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VRHX3JRVL6ZDXHBLWVNNYTMPGW5ERYBH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Installer/target architecture mismatch
Can you file a bug for this on bpo and add Steve Dower to the nosy list? On Fri, Mar 19, 2021 at 17:04 Dany Lisiansky wrote: > An odd suggestion/request here, hope it's the right place to discuss it. > > So I was trying to install python on the Xbox series S (yup..), so far I > got the embedded x86_64 version for windows to work, however, I was unable > to get packages to install properly. > I'm not familiar enough with Windows to know how the installation is > supposed to be laid out, but I figured it might be just a side affect from > using the embedded version. > Now I need to mention that the Xbox is an odd NT based system, it can run > win32/UWP apps, but it comes with a strict requirement of x86_64 and > therefore has no SysWoW64 to support i386. > Naturally, I tried to use the distributed installer, and that's when I > found out that the x86_64 installer itself was in fact compiled for i386. > I can compile a one-off build for myself and go on with my life, but I > also realized it's an oversight because the installer should never assume > the target system has backwards compatibility for older architectures and > stick to the target architecture throughout the installation phase. > > I know It's an extreme edge case, but I guess it's valid and make sense. > Let me know what you think, and how (or if) I should proceed from here. > > DanyL. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/C7UQTGKJCSHBMIXGRMRDSZJOL3LLQF2Q/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BZADOG37KZ3N2KFZNSQXLMECMEWQFAKT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: dataclasses keyword-only fields, take 2
That's a really good question. I think that `__match_args__` should *only*
contain the non-kw-only args, so that you would have to write `case C(a, c,
b=b, d=d)` to match on all four attributes (but typically you'd probably
just write `case C(a, c)` -- that's about the same as `case C(a, c, b=_,
d=_)` except it doesn't even care whether b and d are set at all.
On Tue, Mar 16, 2021 at 1:36 PM Eric V. Smith wrote:
> And now I have a question for you, Guido.
>
> I'm looking at the code and I see the additions for __match_args__. Is
> there any bad interaction between this proposal and the match statement? I
> assume __match_args__ be the re-ordered arguments to __init__, but I want
> to make sure.
>
> So this:
> @dataclasses.dataclass
> class C:
> a: Any
> b: Any = field(kw_only=True)
> c: Any
> d: Any = field(kw_only=True)
>
> Which generates:
>
> def __init__(self, a, c, *, b, d):
> Would have __match_args__ equal to ('a', 'c', 'b', 'd'), right? Even
> though the repr would have fields in order a, b, c, d.
>
> Eric
> On 3/15/2021 7:45 PM, Guido van Rossum wrote:
>
> Good proposal! I have a few questions.
>
> On Mon, Mar 15, 2021 at 2:22 PM Eric V. Smith wrote:
>
>> [I'm sort of loose with the terms field, parameter, and argument here.
>> Forgive me: I think it's still understandable. Also I'm not specifying
>> types here, I'm using Any everywhere. Use your imagination and
>> substitute real types if it helps you.]
>>
>> Here's version 2 of my proposal:
>>
>> There have been many requests to add keyword-only fields to dataclasses.
>> These fields would result in __init__ parameters that are keyword-only.
>>
>> In a previous proposal, I suggested also including positional arguments
>> for dataclasses. That proposal is at
>>
>> https://mail.python.org/archives/list/python-ideas@python.org/message/I3RKK4VINZUBCGF2TBJN6HTDV3PVUEUQ/
>> . After some discussion, I think it's clear that positional arguments
>> aren't going to work well with dataclasses. The deal breaker for me is
>> that the generated repr would either not work with eval(), or it would
>> contain fields without names (since they're positional). There are
>> additional concerns mentioned in that thread. Accordingly, I'm going to
>> drop positional arguments from this proposal.
>>
>> Basically, I want to add a flag to each field, stating whether the field
>> results in a normal parameter or a keyword-only parameter to __init__.
>> Then when I'm generating __init__, I'll examine those flags and put the
>> normal arguments first, followed by the keyword-only ones.
>>
>> The trick becomes: how do you specify what type of parameter each field
>> represents?
>>
>>
>> What attrs does
>> ---
>>
>> First, here's what attrs does. There's a parameter to their attr.ib()
>> function (the moral equivalent of dataclasses.field()) named kw_only,
>> which if set, marks the field as being keyword-only. From
>> https://www.attrs.org/en/stable/examples.html#keyword-only-attributes :
>>
>> >>> @attr.s
>> ... class A:
>> ... a = attr.ib(kw_only=True)
>> >>> A()
>> Traceback (most recent call last):
>>...
>> TypeError: A() missing 1 required keyword-only argument: 'a'
>> >>> A(a=1)
>> A(a=1)
>>
>> There's also a parameter to attr.s (the equivalent of
>> dataclasses.dataclass), also named kw_only, which if true marks every
>> field as being keyword-only:
>>
>> >>> @attr.s(kw_only=True)
>> ... class A:
>> ... a = attr.ib()
>> ... b = attr.ib()
>> >>> A(1, 2)
>> Traceback (most recent call last):
>>...
>> TypeError: __init__() takes 1 positional argument but 3 were given
>> >>> A(a=1, b=2)
>> A(a=1, b=2)
>>
>>
>> dataclasses proposal
>>
>>
>> I propose to adopt both of these methods (dataclass(kw_ony=True) and
>> field(kw_only=True) in dataclasses. The above example would become:
>>
>> >>> @dataclasses.dataclass
>> ... class A:
>> ... a: Any = field(kw_only=True)
>>
>> >>> @dataclasses.dataclass(kw_only=True)
>> ... class A:
>> ... a: Any
>> ... b: Any
>>
>> But, I'd also like to make this a little easier to use, especially in
>> the case where you're defining a dataclass that has some normal fields
>> and some keyword-only fields. Using the attrs approach, you'd need to
>> declare the keyword-only fields using the "=field(kw_only=T
[Python-ideas] Re: allow initial comma
Hi Roland,
Can you please give up on this particular idea? You've given it a fair try,
and nobody is showing any interest in changing Python to match your
proposal. That's usually a good indication that it will Never Happen, and
if you keep arguing beyond that point you tend to be written off as out of
tune.
Personally, I'd like to remind you that when I designed Python my ideal was
to use punctuation in ways that are similar to the way it is used in plain
English, with exceptions only for forms commonly found in many other
programming languages such as foo.bar. Leading with a comma is most
definitely not something one would do in English.
I hope to see you continue brainstorming on other ideas.
--Guido
On Fri, Mar 12, 2021 at 5:21 AM roland.puntaier--- via Python-ideas <
python-ideas@python.org> wrote:
> I had posted this as https://github.com/python/peps/issues/1867
> The discussion so far is below.
>
> Please make some arguments.
>
> The major point to me is, that the symmetry is broken,
> which leads to extra editing actions, like removing the comma in the first
> line.
> I guess, this was the reason to allow the comma after the last line/entry:
> `[1,2,]`.
> ``[,1,2]`` should also be allowed, too.
>
> The best argument is one that says: less or more effort in this or that
> situation.
> For example, with `[1,2,]`, in line-wise formatting,
> one can do without special action at the last line (removing the comma
> there).
>
> All code from previous versions of Python would still work
> after a `[,1,2]` syntax allowance were introduced.
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> Allow initial comma
> ===
>
> Final comma works:
>
> t = (
> 1,
> 2,
> )
> x = [
> 1,
> 2,
> ]
> y = {
> 1,
> 2,
> }
> z = {
> 1:11,
> 2:22,
> }
> def fun(
> a,
> b,
> ):
> pass
>
> Initial comma does not work:
>
> t = (
> , 1
> , 2
> )
> x = [
> , 1
> , 2
> ]
> y = {
> , 1
> , 2
> }
> z = {
> , 1:11
> , 2:22
> }
> def fun(
> , a
> , b
> ):
> pass
>
>
> To make the syntax symmetric in this regard\
> gives more freedom to format the code.
>
> I occasionally found the restriction an unnecessary nuisance.
>
> Before writing a PEP, I would like to discuss,
>
> - whether something like that has been proposed already?
> - what counter-arguments there could be?
>
>
> =
> pxeger wrote:
>
> =
>
> This is not the appropriate place to propose language changes.
> Try the [python-ideas](
> https://mail.python.org/mailman3/lists/python-ideas.python.org/)
> mailing list. However, I don't think you'll get anyone to agree.
>
> What kind of code style are you using where you want to put commas at
> the start of the line? That is totally non-standard
> (see [PEP 8](https://www.python.org/dev/peps/pep-0008)), ugly, and
> confusing.
>
> Arbitrary symmetry is not a good reason for changing the language. We
> don't have a `tnirp` function just for the sake of symmetry with
> `print` because it would be pointless and add extra complication
>
>
>
> =
> rpuntaie wrote:
>
> =
>
> I surely agree, that not ignoring the sequence is essential. Else one
> would loose identifier space and thus information. I would never have
> the idea to make all permutations of `p.r.i.n.t` point to the same
> function. Therefore you just made a bad example.
>
> But the comma is just a separator. Why did they allow to have the
> comma before a closing bracket/parenthesis/brace? Because of symmetry
> between lines, is my guess.
>
> Occasionally one sees many spaces just the have the final comma
> aligned vertically. That could be avoided by placing the comma at the
> beginning.
>
> I personally also have a macro in the editor that evaluates a line in
> the parameter list, but drops an initial comma before doing that.
> Therefore this is my preferred formatting.
[Python-ideas] Re: Enum: determining if a value is valid
You have a good point (and as static typing proponent I should have thought
of that).
Maybe there is not actually a use case for passing an arbitrary default?
Then maybe overloading __contains__ (‘in’) might be better? The ergonomics
of that seem better for the dominant use case (“is this a valid value for
that enum?”).
On Mon, Mar 15, 2021 at 21:37 Matt Wozniski wrote:
> I find the idea of having the constructor potentially return something
> other than an instance of the class to be very... off-putting. Maybe it's
> the best option, but my first impression of it isn't favorable, and I can't
> think of any similar case that exists in the stdlib today off the top of my
> head. It seems like we should be able to do better.
>
> If I might propose an alternative before this gets set in stone: what if
> `Enum` provided classmethods `from_value` and `from_name`, each with a
> `default=`, so that you could do:
>
> Color.from_value(1) # returns Color.RED
> Color.from_value(-1) # raises ValueError
> Color.from_value(-1, None) # returns None
>
> Color.from_name("RED") # returns Color.RED
> Color.from_name("BLURPLE") # raises ValueError
> Color.from_name("BLURPLE", None) # returns None
>
> That still allows each concept to be expressed in a single line, and
> remains explicit about whether the lookup is happening by name or by value.
> It allows spelling `default=None` as just `None`, as we desire. And instead
> of being a `__contains__` with unusual semantics coupled with a constructor
> with unusual semantics, it's a pair of class methods that each have fairly
> unsurprising semantics.
>
> ~Matt
>
> On Mon, Mar 15, 2021 at 3:55 PM Guido van Rossum wrote:
>
>> +1
>>
>> On Mon, Mar 15, 2021 at 12:48 PM Ethan Furman wrote:
>>
>>> On 3/15/21 11:27 AM, Guido van Rossum wrote:
>>> > On Mon, Mar 15, 2021 at 10:53 AM Ethan Furman wrote:
>>>
>>> >> Part of the reason is that there are really two ways to identify an
>>> >> enum -- by name, and by value -- which should `__contains__` work
>>> with?
>>> >
>>> > The two sets don't overlap, so we could allow both. (Funny
>>> > interpretations of `__contains__` are not unusual, e.g.
>>> > substring checks are spelled 'abc' in 'fooabcbar'.)
>>>
>>> They could overlap if the Enum is a `str`-subclass -- although having
>>> the name of one member match the value of a different member seems odd.
>>>
>>> >> I think I like your constructor change idea, with a small twist:
>>> >>
>>> >> Color(value=, name=, default=)
>>> >>
>>> >> This would make it possible to search for an enum by value or by name,
>>> >> and also specify a default return value (raising an exception if the
>>> >> default is not set and a member cannot be found).
>>> >
>>> >
>>> > So specifically this would allow (hope my shorthand is clear):
>>> > ```
>>> > Color['RED'] --> Color.RED or raises
>>> > Color(1) -> Color.RED or raises
>>> > Color(1, default=None) -> Color.RED or None
>>> > Color(name='RED', default=None) -> Color.RED or None
>>> > ```
>>> > This seems superficially reasonable. I'm not sure what
>>> > Color(value=1, name='RED') would do -- insist that both value and
>>> > name match? Would that have a use case?
>>>
>>> I would enforce that both match, or raise. Also not sure what the
>>> use-case would be.
>>>
>>> > My remaining concern is that it's fairly verbose -- assuming we don't
>>> > really need the name argument, it would be attractive if we could
>>> > write Color(1, None) instead of Color(1, default=None).
>>> >
>>> > Note that instead of Color(name='RED') we can already write this:
>>> > ```
>>> > getattr(Color, 'RED') -> Color.RED or raises
>>> > getattr(Color, 'RED', None) -> Color.RED or None
>>>
>>> Very good points.
>>>
>>> Everything considered, I think I like allowing `__contains__` to verify
>>> both names and values, adding `default=` to the constructor for
>>> the value-based "gimme an Enum or None" case, and recommending `getattr`
>>> for the name-based "gimme an Enum or None" case.
>>>
>>> --
>>> ~Ethan~
>>> ___
>>> Python-ideas mailing list -- python-ideas@python.org
>>> To unsubscribe send an email to
[Python-ideas] Re: dataclasses keyword-only fields, take 2
es.dataclass > class B: > a: Any > _: dataclasses.KW_ONLY > b: Any > > This would generate: > > def __init__(self, a, *, b): > > This example is equivalent to: > > @dataclasses.dataclass > class B: > a: Any > b: Any = field(kw_only=True) > > The name of the KW_ONLY field doesn't matter, since it's discarded. I > think _ is a fine name, and '_: dataclasses.KW_ONLY' would be the > pythonic way of saying "the following fields are keyword-only". > > My example above would become: > > @dataclasses.dataclass > class LotsOfFields: > a: Any > _: dataclasses.KW_ONLY > b: Any = 0 > c: Any = 'foo' > d: Any > e: Any = 0.0 > f: Any > g: Any = () > h: Any = 'bar' > i: Any = 3+4j > j: Any = 10 > k: Any > > Which I think is a lot clearer. > > The generated __init__ would look like: > > def __init__(self, a, *, b=0, c='foo', d, e=0.0, f, g=(), h='bar', > i=3+4j, j=10, k): > > The idea is that all normal argument fields would appear first in the > class definition, then all keyword argument fields. This is the same > requirement as in a function definition. There would be no switching > back and forth between the two types of fields: once you use KW_ONLY, > all subsequent fields are keyword-only. A field of type KW_ONLY can > appear only once in a particular dataclass (but see the discussion below > about inheritance). > > > Re-ordering args in __init__ > > > If, using field(kw_only=True), you specify keyword-only fields before > non-keyword-only fields, all of the keyword-only fields will be moved to > the end of the __init__ argument list. Within the list of > non-keyword-only arguments, all arguments will keep the same relative > order as in the class definition. Ditto for within keyword-only arguments. > > So: > > @dataclasses.dataclass > class C: > a: Any > b: Any = field(kw_only=True) > c: Any > d: Any = field(kw_only=True) > > Then the generated __init__ will look like: > > def __init__(self, a, c, *, b, d): > > __init__ is the only place where this rearranging will take place. > Everywhere else, and importantly in __repr__ and any dunder comparison > methods, the order will be the same as it is now: in field declaration > order. > Can you be specific and show what the repr() would be? E.g. if I create C(1, 2, b=3, d=4) the repr() be C(a=1, b=3, c=2, d=4), right? > This is the same behavior that attrs uses. > Nevertheless I made several typos trying to make the examples in my sentence above correct. Perhaps we could instead disallow mixing kw-only and regular args? Do you know why attrs does it this way? > Inheritance > --- > > There are a few additional quirks involving inheritance, but the > behavior would follow naturally from how dataclasses already handles > fields via inheritance and the __init__ argument re-ordering discussed > above. Basically, all fields in a derived class are computed like they > are today. Then any __init__ argument re-ordering will take place, as > discussed above. > > Consider: > > @dataclasses.dataclass(kw_only=True) > class D: > a: Any > > @dataclasses.dataclass > class E(D): > b: Any > > @dataclasses.dataclass(kw_only=True) > class F(E): > c: Any > > This will result in the __init__ signature of: > > def __init__(self, b, *, a, c): > > However, the repr() will still produce the fields in order a, b, c. > Comparisons will also use the same order. > This can be simulated by flattening the inheritance tree and adding explicit field(kw_only=True) to all fields of classes using kw_only=True in the class decorator as well as all fields affected by _: KW_ONLY, right? So the above would behave like this: @dataclasses.dataclass class F: a: Any = field(kw_only=True) b: Any c: Any = field(kw_only=True) which IIUC indeed gives the same __init__ signature and repr(). > Conclusion > -- > > Remember, the only point of all of these hoops is to add a flag to each > field saying what type of __init__ argument it becomes: normal or > keyword-only. Any of the 3 methods discussed above (kw_only flag to > @dataclass(), kw_only flag to field(), or the KW_ONLY marker) all have > the same result: setting the kw_only flag on one or more fields. > > The value of that flag, on a per-field basis, is used to re-order > __init__ arguments, and is used in generating the __init__ signature. > It's not used anywhere else. > > I expect the two most common use cases to be the kw_only flag to > @dataclass() and the KW_ONLY marker. I would expect
[Python-ideas] Re: Enum: determining if a value is valid
+1 On Mon, Mar 15, 2021 at 12:48 PM Ethan Furman wrote: > On 3/15/21 11:27 AM, Guido van Rossum wrote: > > On Mon, Mar 15, 2021 at 10:53 AM Ethan Furman wrote: > > >> Part of the reason is that there are really two ways to identify an > >> enum -- by name, and by value -- which should `__contains__` work with? > > > > The two sets don't overlap, so we could allow both. (Funny > > interpretations of `__contains__` are not unusual, e.g. > > substring checks are spelled 'abc' in 'fooabcbar'.) > > They could overlap if the Enum is a `str`-subclass -- although having the > name of one member match the value of a different member seems odd. > > >> I think I like your constructor change idea, with a small twist: > >> > >> Color(value=, name=, default=) > >> > >> This would make it possible to search for an enum by value or by name, > >> and also specify a default return value (raising an exception if the > >> default is not set and a member cannot be found). > > > > > > So specifically this would allow (hope my shorthand is clear): > > ``` > > Color['RED'] --> Color.RED or raises > > Color(1) -> Color.RED or raises > > Color(1, default=None) -> Color.RED or None > > Color(name='RED', default=None) -> Color.RED or None > > ``` > > This seems superficially reasonable. I'm not sure what > > Color(value=1, name='RED') would do -- insist that both value and > > name match? Would that have a use case? > > I would enforce that both match, or raise. Also not sure what the > use-case would be. > > > My remaining concern is that it's fairly verbose -- assuming we don't > > really need the name argument, it would be attractive if we could > > write Color(1, None) instead of Color(1, default=None). > > > > Note that instead of Color(name='RED') we can already write this: > > ``` > > getattr(Color, 'RED') -> Color.RED or raises > > getattr(Color, 'RED', None) -> Color.RED or None > > Very good points. > > Everything considered, I think I like allowing `__contains__` to verify > both names and values, adding `default=` to the constructor for > the value-based "gimme an Enum or None" case, and recommending `getattr` > for the name-based "gimme an Enum or None" case. > > -- > ~Ethan~ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/UQBSDZQJWBKMOVSUES7HEDJTYR76Y5N2/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZK7KKABFNSFC4UY763262O2VIPZ5YDPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enum: determining if a value is valid
On Mon, Mar 15, 2021 at 10:53 AM Ethan Furman wrote: > On 3/12/21 5:28 PM, Guido van Rossum wrote: > > On Fri, Mar 12, 2021 at 1:52 PM Ethan Furman wrote: > > >> A question that comes up quite a bit on Stackoverflow is how to test > >> to see if a value will result in an Enum member, preferably without > >> having to go through the whole try/except machinery. > >> > >> A couple versions ago one could use a containment check: > >> > >> if 1 in Color: > >> > >> but than was removed as Enums are considered containers of members, > >> not containers of the member values. > > > > Maybe you were a bit too quick in deleting it. Was there a serious > > bug that led to the removal? Could it be restored? > > Part of the reason is that there are really two ways to identify an > enum -- by name, and by value -- which should `__contains__` work with? > The two sets don't overlap, so we could allow both. (Funny interpretations of `__contains__` are not unusual, e.g. substring checks are spelled 'abc' in 'fooabcbar'.) > >> At this point I see three options: > >> > >> 1) add a `get(value, default=None)` to EnumMeta (similar to > `dict.get()` > > > > But the way to convert a raw value to an enum value is Color(1), not > > Color[1], so Color.get(1) seems inconsistent. > > Very good point. > > > Maybe you can just change the constructor so you can spell this as > > Color(1, default=None) (and then check whether that's None)? > > An interesting idea. > > >> 2) add a recipe to the docs > > > > But what would the recipe say? Apparently you're looking for a one-liner, > > since you reject the try/except solution. > > The recipe would be for a method that could be added to an Enum, such as: > > @classmethod > def get_by_value(cls, value, default=None): > for member in cls: > if member.value == value: > return member > return default > But that's a non-solution -- people can figure out how to write such a helper just fine (although probably using try/except) but they don't want to -- they have *one* line where they want to do this check and so they're going for a local solution -- probably the try/except. > >> 3) do nothing > > > > Always a good option. :-) > > Yes, but not always a satisfying one. :) > > > Where's that StackOverflow item? How many upvotes does it have? > > > 93 - How do I test if int value exists in Python Enum without using > try/catch? > https://stackoverflow.com/q/43634618/208880 > > 25 - How to test if an Enum member with a certain name exists? > https://stackoverflow.com/q/29795488/208880 > > 3 - Validate value is in Python Enum values > https://stackoverflow.com/q/54126570/208880 > > 2 - How to check if string exists in Enum of strings? > https://stackoverflow.com/q/63335753/208880 > > I think I like your constructor change idea, with a small twist: > > Color(value=, name=, default=) > > This would make it possible to search for an enum by value or by name, and > also specify a default return value (raising an exception if the default is > not set and a member cannot be found). > So specifically this would allow (hope my shorthand is clear): ``` Color['RED'] --> Color.RED or raises Color(1) -> Color.RED or raises Color(1, default=None) -> Color.RED or None Color(name='RED', default=None) -> Color.RED or None ``` This seems superficially reasonable. I'm not sure what Color(value=1, name='RED') would do -- insist that both value and name match? Would that have a use case? My remaining concern is that it's fairly verbose -- assuming we don't really need the name argument, it would be attractive if we could write Color(1, None) instead of Color(1, default=None). Note that instead of Color(name='RED') we can already write this: ``` getattr(Color, 'RED') -> Color.RED or raises getattr(Color, 'RED', None) -> Color.RED or None ``` -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CIXFX5SL5DX4ISZOWXJFFYVQK53FGQ27/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
Hi Steve, I don't think I can explain adequately why I challenged you, so I'll just apologize. Your feedback (about the 'export' proposal, and about my challenge of your credentials) is duly noted. Sorry! --Guido On Sun, Mar 14, 2021 at 4:11 PM Stestagg wrote: > On Sun, Mar 14, 2021 at 8:22 PM Guido van Rossum wrote: > >> If you feel so strongly about it maybe we need to see some credentials. >> What's your background? (This may sound like an odd request, but reputation >> matters, and right now I have no idea who you are or why I should take your >> opinion seriously, no matter how eloquently it is stated.) >> >> > Hi Guido, I have enormous respect for you, but have no interest in > attempting to prove I'm a 'good-enough egg' to warrant your serious > attention. > > The entire question makes me somewhat uncomfortable, and to illustrate > why, I'm going to willfully misinterpret it to make my point: > > My background is: White, Middle-class British male, mid-30s, my family is > descended from the illigitimate son of the governor of the Isle of Wight. > I've dined with the Queen, and my last two schools were both over 400 years > old. Does this qualify me for attention? What if I were a BAME teen woman > living in Bangladesh? > > Of course, sarcastic responses aside, I assume you meant technical > background/credentials. Similar concerns still apply there, this > python-ideas list is full of people with ideas, many of which are held > strongly, that don't get their background questioned openly (although, as > in most communities, there's evidence of this happening subtextually in > places). > > In fact, when I previously pointed out a critical flaw in one of your > proposals in another thread on this list, I wasn't questioned about my > credentials then (I assume because you realised your mistake at that > time). If you're still interested in my CV, it's easily findable online, > along with other technical context about me that may be relevant to > assessing my worthiness. > > Regardless of the above, I'm not going to argue further about the proposal > or my plea to keep some control/override. That's why I made my case as > robustly as I could initially. It's a single data-point, other people may > reinforce it, or counter it, in the disucssion. By broaching the subject, > I was hoping to ensure that this aspect of the proposed change would be > considered, if you decide I'm not worth it, then that's your call. > > Regards > > Steve > > Note that C extensions allow none of the introspection mechanisms you're >> proposing here (they have a `__dict__` but it is fully controlled by the >> author of the C code) and they thrive just fine. >> >> I am happy with giving module authors a way to tell the system "it's >> okay, users can reach in to access other attributes as well". But I think >> module authors should *also* be given a way to tell the system "please >> prevent users from accessing the private parts of this API no matter how >> hard they try". And using 'export' seems a reasonable way to enable the >> latter. (To be clear I am fine if there's a flag to override this default >> even when 'export' is used.) >> >> I know there are package authors out there who have this desire to >> restrict access (presumably because they've been burned when trying to >> evolve their API) and feel so strongly about it that they implement their >> own restrictive access controls (without resorting to writing C code). >> >> On Sun, Mar 14, 2021 at 12:42 PM Stestagg wrote: >> >>> On Sun, 14 Mar 2021 at 18:58, Guido van Rossum wrote: >>> >>>> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel wrote: >>>> >>>>> > import the_module >>>>> >>>>> > the_module.sys >>>>> >>>>> > would work, but >>>>> >>>>> > from the_module import sys >>>>> >>>>> > would not work? >>>>> >>>>> > That might be odd and confusing. >>>>> >>>>> Good point. I'm not familiar with CPython internals so I'm not sure >>>>> how this would work on the implementation side, but I definitely think it >>>>> would be important to not have an inconsistency here. >>>>> >>>> >>>> So I think there is no technical reason why we couldn't make it so that >>>> a module that uses `export` returns a proxy that only lets you use >>>> attributes that are explicitly exported. If users disagree with this, they >>>> can negotiate
[Python-ideas] Re: Add an export keyword to better manage __all__
If you feel so strongly about it maybe we need to see some credentials. What's your background? (This may sound like an odd request, but reputation matters, and right now I have no idea who you are or why I should take your opinion seriously, no matter how eloquently it is stated.) Note that C extensions allow none of the introspection mechanisms you're proposing here (they have a `__dict__` but it is fully controlled by the author of the C code) and they thrive just fine. I am happy with giving module authors a way to tell the system "it's okay, users can reach in to access other attributes as well". But I think module authors should *also* be given a way to tell the system "please prevent users from accessing the private parts of this API no matter how hard they try". And using 'export' seems a reasonable way to enable the latter. (To be clear I am fine if there's a flag to override this default even when 'export' is used.) I know there are package authors out there who have this desire to restrict access (presumably because they've been burned when trying to evolve their API) and feel so strongly about it that they implement their own restrictive access controls (without resorting to writing C code). On Sun, Mar 14, 2021 at 12:42 PM Stestagg wrote: > On Sun, 14 Mar 2021 at 18:58, Guido van Rossum wrote: > >> On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel wrote: >> >>> > import the_module >>> >>> > the_module.sys >>> >>> > would work, but >>> >>> > from the_module import sys >>> >>> > would not work? >>> >>> > That might be odd and confusing. >>> >>> Good point. I'm not familiar with CPython internals so I'm not sure how >>> this would work on the implementation side, but I definitely think it would >>> be important to not have an inconsistency here. >>> >> >> So I think there is no technical reason why we couldn't make it so that a >> module that uses `export` returns a proxy that only lets you use attributes >> that are explicitly exported. If users disagree with this, they can >> negotiate directly with the module authors. It's not a principle of Python >> that users *must* be given access to implementation details, after all -- >> it was just more convenient to do it this way when the language was young. >> (For example, it's not possible to root around like this in C extensions -- >> these only export what the author intends to export.) >> >> > > If this is implemented, then please ensure that some mechanism is included > (either keeping __dict__, or functions in inspect, or some other mechanism) > to both get and set all attributes of a module irrespective of any > export/__all__ controls. > > I understand that perspective that says library authors should be able to > control their API, for various reasons, but this has to be balanced against > the fact that library authors are not perfect, and can either include bugs, > or fail to consider all reasonable use-cases when designing their code. > Historically, this has been done, by convention, through use of the "_" > private specifier for module-level objects. > > The value of being able to (in specific cases) reach into third-party > code, and customize it to work for your specific situation should not be > disregarded. > > I think every large codebase that I've worked with has had to monkey-patch > a method deep within at least one third-party library at runtime, in > production (this is also commonly used for testing purposes), at some point > to work-around either a limitation of the library, incompatibility with > other library, or to patch a bug. This also applies to module-globals that > are themselves imported modules, being able to rebind a name to reference a > different module (within careful constraints) in a library module has saved > me several times. > > If external visibility of code units within libraries starts to be > restricted so that this sort of patching isn't possible, then the cost of > fixing some problems may start to become significantly greater. > > I strongly believe that the access to members of modules should be kept as > similar to the access of members of class instances as possible. Not only > will this keep the model simpler, the same arguments and/or concerns apply > when talking about classes as when talking about modules. Maybe this means > that non-exported members of modules get name-mangled as protected class > attributes do, or maybe the '__dict__' member is always exported. > > I think the idea of resolving the issues mentioned above by talking with > third-party module authors directly, seems like an unlik
[Python-ideas] Re: Add an export keyword to better manage __all__
On Sun, Mar 14, 2021 at 7:11 AM Theia Vogel wrote: > > import the_module > > > the_module.sys > > > would work, but > > > from the_module import sys > > > would not work? > > > That might be odd and confusing. > > Good point. I'm not familiar with CPython internals so I'm not sure how > this would work on the implementation side, but I definitely think it would > be important to not have an inconsistency here. > You probably should design this in partnership with someone who's more familiar with those internals. I believe that familiarity with Python internals is pretty important if you want to be able to design a new feature. Without thinking about the implementation you might design something that's awkward to implement; but you might also not think of something that's easy to do in the implementation but not obvious from superficial usage. (There are two lines in the Zen of Python devoted to this. :-) It is already possible to completely customize what happens when you write "import X". The returned object doesn't even strictly need to have a `__dict__` attribute. For `from X import Y` it first does `import X` (but doesn't bind X in your namespace) and then gives you `X.Y`, except if `Y` is `*`, in which case it looks in `X.__all__`, or if that's not found it looks in `X.__dict__` and imports all keys not starting with `_`. So to support `from X import *` you need either `__all__` or `__dict__`, else you get an import error (but neither of those is needed to support `from X import Y` or `import X; X.Y`). So I think there is no technical reason why we couldn't make it so that a module that uses `export` returns a proxy that only lets you use attributes that are explicitly exported. If users disagree with this, they can negotiate directly with the module authors. It's not a principle of Python that users *must* be given access to implementation details, after all -- it was just more convenient to do it this way when the language was young. (For example, it's not possible to root around like this in C extensions -- these only export what the author intends to export.) I do think that this means that existing libraries need to be careful when adding `export` statements, because it effectively becomes a backwards incompatibility. We could also implement a flag to weaken the strictness in this area (the flag would have to be set by the module, not by the importing code). Such a proxy could also be used to implement lazy imports, to some extent. (I'm not sure how to do `from X import Y` lazily -- it would have to wrap `Y` in another proxy, and then it becomes awkward, e.g. if `Y` is supposed to represent a simple number or string -- we don't want any other part of the language or stdlib to need to become aware of such proxies.) Long answer short, yes, we can make it so that `the_module.sys` in your example above is forbidden -- if we want to. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2GCHG5TMEYNPYKXQBCM2CK5LG7SRRRD6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
On Fri, Mar 12, 2021 at 6:23 PM Peter Ludemann wrote: > [I wonder why C didn't adopt BCPL's convention for eliding semi-colons? > ...] > [Presumably because it caused too many surprising behaviors...] -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4FN7WKW4BJP6XWJPQGFF63RYN2PU5JCC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add an export keyword to better manage __all__
ys as _sys" -- it makes doing the wrong thing the default state. > > > Proposal: > > > > Add a contextual keyword "export" that has meaning in three places: > > 1. Preceding an "import" statement, which directs all names imported by > that >statement to be added to __all__: > > import sys > export import .foo > export import ( > A, > B, > C, > D > ) from .bar > > # __all__ == ["foo", "A", "B", "C", "D"] > > 2. Preceding a "def", "async def", or "class" keyword, directing that > function >or class's name to be added to __all__: > > def private(): pass > export def foo(): pass > export async def async_foo(): pass > export class Foo: pass > > # __all__ == ["foo", "async_foo", "Foo"] > > 3. Preceding a bare name at top-level, directing that name to be added to >__all__: > > x = 1 > y = 2 > export y > > # __all__ == ["y"] > > > # Big Caveat > > For this scheme to work, __all__ needs to not be auto-populated with names. > While the behavior is possibly suprising, I think the best way to handle > this is > to have __all__ not auto-populate if an "export" keyword appears in the > file. > While this is somewhat-implicit behavior, it seems reasonable to me to > expect that > if a user uses "export", they are opting in to the new way of managing > __all__. > Likewise, I think manually assigning __all__ when using "export" should > raise > an error, as it would overwrite all previous exports and be very confusing. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/HL3P7CXZX3U5SMNIJODL45BE6E72MWTI/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LQL4VRXWWDYRYCOHQYWV4GMZO542HV6E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Enum: determining if a value is valid
On Fri, Mar 12, 2021 at 1:52 PM Ethan Furman wrote: > A question that comes up quite a bit on Stackoverflow is how to test to > see if a value will result in an Enum member, preferably without having to > go through the whole try/except machinery. > > A couple versions ago one could use a containment check: > >if 1 in Color: > > but than was removed as Enums are considered containers of members, not > containers of the member values. Maybe you were a bit too quick in deleting it. Was there a serious bug that led to the removal? Could it be restored? > It was also possible to define one's own `_missing_` method and have it > return None or the value passed in, but that has also been locked down to > either return a member or raise an exception. > > At this point I see three options: > > 1) add a `get(value, default=None)` to EnumMeta (similar to `dict.get()` > But the way to convert a raw value to an enum value is Color(1), not Color[1], so Color.get(1) seems inconsistent. Maybe you can just change the constructor so you can spell this as Color(1, default=None) (and then check whether that's None)? > 2) add a recipe to the docs > But what would the recipe say? Apparently you're looking for a one-liner, since you reject the try/except solution. > 3) do nothing > Always a good option. :-) Where's that StackOverflow item? How many upvotes does it have? -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QRDMKZBL54GU7A7OSDB5GG2HIAGCDTLE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
This argument pretty much kills the proposal.
On Fri, Mar 12, 2021 at 9:01 AM Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
> To my mind there are too many differences between running code as a
> script and running it in the REPL. This would, presumably, add another
> one: the initial line would be executed without waiting to see if there
> is a dot continuation line. And it just feels wrong to have a complete
> syntactically valid line of code ... not be a complete line of code.
> You can always add outer brackets, as in other situations where lines of
> code become over-long:
>
> y = (x.rstrip("\n")
> .split(":")[0]
> .lower())
>
> -1
> Rob Cliffe
>
> On 12/03/2021 15:32, Matt Williams wrote:
> > Hi,
> >
> > It's becoming more popular in Python to have interfaces which are built
> around method chaining as a way of applying operations to data. For example
> in pandas is moving more towards a default model where methods do not
> change the object in-place but instead return an altered version (or at
> least an altered view) of it.
> >
> > The major downside to method chaining is that it ends up creating long
> lines of code which can become hard to read. The two main solutions to this
> are 1) break down the chain and give the steps their own variable names and
> 2) split it over multiple lines using `\` as a line continuation.
> >
> > e.g.:
> >
> >y = x.rstrip("\n").split(":")[0].lower()
> >
> > would become
> >
> >y = x.rstrip("\n") \
> > .split(":")[0] \
> > .lower()
> >
> > I find the continuation character visually distracting, easy to forget
> and does not allow for line-by-line commenting (causing `SyntaxError:
> unexpected character after line continuation character`):
> >
> >y = x.rstrip("\n") \
> > .split(":")[0] \ # grab the key name
> > .lower()
> >
> > My idea is to alter the syntax of Python to allow doing:
> >
> >y = x.rstrip("\n")
> > .split(":")[0]
> > .lower()
> >
> > i.e., not requiring an explicit line continuation character in the case
> where the next line starts with a period.
> >
> > I've had a search through the archives and I couldn't see this
> discussion before. Feel free to point me to it if I've missed anything.
> >
> > Cheers,
> > Matt
> > ___
> > Python-ideas mailing list -- python-ideas@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GVVLTS2EYLB7WKQ625RUOXSQHR3SOQ6E/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/JZZHPUSTBSWPKIZJ7AERBKLQYGJBU2QO/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implicit line continuation for method chaining
Can we skip ahead to considering how to implement this? I can think of two
approaches: either hack the lexer to special-case a newline followed by a
period (which currently can never start a line), or redesign the syntax to
allow NEWLINE INDENT ‘.’ . NEWLINE ‘.’ DEDENT at the
end of an expression. Both have pros and cons.
Discuss how this allows for certain typos to pass as valid syntax.
On Fri, Mar 12, 2021 at 07:42 Matt Williams wrote:
> Hi,
>
> It's becoming more popular in Python to have interfaces which are built
> around method chaining as a way of applying operations to data. For example
> in pandas is moving more towards a default model where methods do not
> change the object in-place but instead return an altered version (or at
> least an altered view) of it.
>
> The major downside to method chaining is that it ends up creating long
> lines of code which can become hard to read. The two main solutions to this
> are 1) break down the chain and give the steps their own variable names and
> 2) split it over multiple lines using `\` as a line continuation.
>
> e.g.:
>
> y = x.rstrip("\n").split(":")[0].lower()
>
> would become
>
> y = x.rstrip("\n") \
>.split(":")[0] \
>.lower()
>
> I find the continuation character visually distracting, easy to forget and
> does not allow for line-by-line commenting (causing `SyntaxError:
> unexpected character after line continuation character`):
>
> y = x.rstrip("\n") \
>.split(":")[0] \ # grab the key name
>.lower()
>
> My idea is to alter the syntax of Python to allow doing:
>
> y = x.rstrip("\n")
>.split(":")[0]
>.lower()
>
> i.e., not requiring an explicit line continuation character in the case
> where the next line starts with a period.
>
> I've had a search through the archives and I couldn't see this discussion
> before. Feel free to point me to it if I've missed anything.
>
> Cheers,
> Matt
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/LWB3U5BTGC4CT26U4AB676SKGED3ZOEX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3BNMTY74DDQMTD6PVH3ZGCVMBCSW3SQ5/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Dataclasses, keyword args, and inheritance
I've seen comments from Eric V Smith in this thread and in the PR. If he's in favor and it can be done in a backwards compatible way then he can guide you to acceptance and merging of your PR. But like all of us he has limited time. On Wed, Mar 10, 2021 at 6:15 AM Laurie O wrote: > I've had tens of people show interest in my proposal, asking what the > blocker is in acceptance. As far as I know, no Python developer has shown > any interest in it. > > My proposal is to automatically make any non-default fields become > keyword-only `__init__` parameters, with no need to have any arguments > passed to the `dataclass` decorator. > > My PR: https://github.com/python/cpython/pull/17322 > > My previous mailing-list message: > https://mail.python.org/archives/list/python-ideas@python.org/message/2V2SCUFMK7PK3DVA7D77AVXWIXNTSQDK/ > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/KPVB2G64BHFGGOTXZQXT3AU7SIO5ABJE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IN3D7UQQI4HSKSCUPMU3C3RTUG6NWUKG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Barrier Object in asyncio lib
On Fri, Feb 26, 2021 at 10:09 AM Yves Duprat wrote: > I was expecting an explanation about the initial request. > Is there an oversight (??) or an another reason to not have a Barrier > primitive in asyncio ? > Probably because nobody working on asyncio at the time had any experience using threading.Barrier. I know that I have used all the other primitives, but I don't recall ever having used Barrier. I don't think there's anything deeper than that. You should probably just open a bpo issue (mention this thread) and submit a PR linked there. I can't promise to review it though. :-) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GNUCKA2MCVROCVLWRQUTMUG7CGOVQQV6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Deprecate/change the behaviour of ~bool
Also, code that is expecting an int should not behave differently when it receives a bool. On Mon, Feb 22, 2021 at 17:47 Chris Angelico wrote: > On Tue, Feb 23, 2021 at 12:14 PM Soni L. wrote: > > > > Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the > > same as not bool. Hopefully nobody actually relies on this but > > nevertheless, it would be a backwards-incompatible change so the whole > > deprecation warnings and whatnot would be required. > > There are quite a few ways in which bitwise operators are not the same > as boolean operators. What would be the advantage of having them be > the same in just this one case? > > > In particular, this is nice for xnor operator: a ^~ b. This currently > > works on ints, but not on bools, while most other operators, including > > xor, do successfully work on bools. > > You could write it as a ^ (not b), as long as you don't mind it giving > back an integer rather than a bool. Fundamentally, you're doing > bitwise operations on integers, and expecting them to behave as if > they have only a single bit each, so another way to resolve this might > be to mask it off at the end with "& 1". > > If this makes your code horrendously ugly, perhaps it would be better > to create your own "one-bit integer" class, which responds to all > bitwise operators by automatically masking down to one bit? > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/6HLSLQMMKYNLSEQCIIDVKXIGV2TZFREE/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CHWNS222IJQQHXBTXXMSSD2GQZ4QAE7A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
On Mon, Feb 15, 2021 at 9:02 AM Ricky Teachey wrote:
> [...]
> But if we could expand the proposal to allow both anonymous and named
> functions, that would seem like a fantastic idea to me.
>
> Anonymous function syntax:
>
> (x,y)->x+y
>
> Named function syntax:
>
> f(x,y)->x+y
>
Proposals like this always baffle me. Python already has both anonymous and
named functions. They are spelled with 'lambda' and 'def', respectively.
What good would it do us to create an alternate spelling for 'def'?
I know that in JavaScript there are different ways to define functions
('function' and '=>'), and they have subtly different semantics. (For
example, regarding 'this'. Such an incredible mess!) We don't need
different semantics in Python.
I can sympathize with trying to get a replacement for lambda, because many
other languages have jumped on the arrow bandwagon, and few Python
first-time programmers have enough of a CS background to recognize the
significance of the word lambda. But named functions? Why??
> But since Guido wants to save the right shaft operator for type hinting,
> and named functions do need a way to write type hints, maybe the best thing
> to do is use an equal sign shaft for the function definition and the right
> shaft for the type hint:
>
> f(x,y)=>x,y->str
>
> >>> f('a','b')
> 'ab'
> >>> f(1,2) # type hint error
>
Another thing. Type hints are not interpreted at runtime, and I don't
expect this to change in the near to middle future.
Plus, that syntax really has nothing to recommend it.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ATG3LCZRNRM3T33NNRALXXLAA7YR6XSU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Arrow functions polyfill
Okay, here’s my dilemma. It looks like this thread wants to devise a new
syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
great, but doesn’t open new vistas.
OTOH, for people using type annotations, a much more pressing issue is an
alternative for typing.Callable that is more readable, and supports extra
features that Callable doesn’t, like keyword args, varargs, and pos-only.
If you can do both with the same arrow, great, but if the arrows must
differ (for some technical reason, e.g. types in cast()), I want -> for
Callable, and you can have => for lambda.
—Guido
On Mon, Feb 15, 2021 at 02:51 Steven D'Aprano wrote:
> On Mon, Feb 15, 2021 at 02:12:03AM +1100, Chris Angelico wrote:
> > On Sun, Feb 14, 2021 at 8:42 PM Steven D'Aprano
> wrote:
> > > We should not choose the more confusing, error-prone solution out of
> > > fear of being different. Python is already different from Javascript in
> > > every regard:
> > >
> >
> > Is it really?
>
> Well, they're both Turing Complete, so I guess not different in *every*
> regard :-)
>
> By the way, I'm not judging the differences.
>
>
> > > - the basic execution model is different;
> > Don't know what you mean here, but I thought they were the same.
>
> Python has a purely dynamic execution model; Javascript has a hybrid
> two-pass model that combines elements of static and dynamic execution,
> and which allows code like this to run:
>
> print(f(3));
>
> function f(a) {
> return a*2;
> }
>
>
> (not in an interactive REPL of course).
>
> Although both Python and Javascript have dynamic typing, Python's
> type model is stronger (i.e. stricter) than Javascript's.
>
> 1 + '2' # an error in Python, 12 in Javascript.
>
> In Python, every thing is an object; in Javascript, some things are
> objects, and some things are primitive values.
>
>
> > > - the object model is different;
> > Same object model.
>
> Absolutely not. Javascript is based on the prototype object model, and
> Python is based on the class object model.
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain
>
>
> > > - the numeric model is different;
> > Python has more data types, but that's not as fundamental a difference
> > as you might think
>
> Python has a numeric tower; Javascript has a single floating point type.
> It's hard to build a tower with a single brick :-)
>
>
> > > -the truthy/falsey model is different;
> > There are different rules about WHAT is truthy/falsy, but, again, the
> > differences aren't fundamental
>
> The differences are precisely my point.
>
>
> > > - the syntax is different;
> > > - the list of keywords is different;
> > > - the standard library is different;
> > > - the list of operators is different;
> > Well, of course. If these four were the same, they'd be the same
> > language. These four differ between Py2 and Py3 too.
>
> Yes, the fact that they are different languages is my point.
>
>
> > > - even basic equality is different;
> > Yes, although that's more historic than anything else - most people
> > use "===" which has mostly the same semantics as Python's equality
>
> "Mostly the same", apart from being completely different :-(
>
> Javascript's === tests for "same type and equal" for primitive values,
> and is equivalent to Python's `is` for objects. It cannot be overloaded.
>
>
> > > - the culture of the community is different.
> > TBH neither community has a single culture.
>
> Of course neither group of people is a monoculture of identical
> clones. That would be the Haskell community *wink*
>
> But in general, the JS/Node.js community embraces practices which are
> rejected by the Python community, such as the use of micro-packages.
> Remember left-pad?
>
> This four-line package got nearly fifty million downloads last week:
>
> https://www.npmjs.com/package/isarray
>
> That's about 78 times per second.
>
> If I published that on PyPI, I would be amazed if I got 78 downloads in
> a year.
>
>
> --
> Steve
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/7RDIPZDPOZUU7AD5JFE2BNQH75OAAGS7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/UJ32U33U4FL4GAOERD77CMB5QFJNHF63/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern Matching -- Removing Name Binding from Partial Matching
I should add that I accidentally left out a word. It should be “... liable to *overwrite* any or all names ...” On Sun, Feb 14, 2021 at 12:10 Abdulla Al Kathiri < alkathiri.abdu...@gmail.com> wrote: > That makes sense. As Guido mentioned, this is similar to reusing a > variable in a for-loop. You do it at your own risk. Ok consider me > convinced. I will use the following sentence to explain name binding in > partial matching: > *“Match statements are liable to any or all names bound in any of the > patterns used, and your code is incorrect if you aren't prepared for that."* > > > On 14 Feb 2021, at 7:20 PM, Chris Angelico wrote: > > On Sun, Feb 14, 2021 at 11:26 PM Abdulla Al Kathiri > wrote: > > > My idea was that in the case of partial matching or full matching without > passing the guard, the binding names has some sort of self destruction and > return to the previous state. Using different variable names would resolve > the issue and if I want to modify the global variables, I could choose to > do so in the case block after the case succeeded. At least, this way, it > would be more explicit, conveying the person intention (or forgetting if > the original global value was later needed). I saw many people online > talking about this the last couple of days so I thought I would bring it up > here. Any other syntax variant could be used to achieve the same thing. > > > It's not about syntax. Python doesn't have an idea of "self > destruction and return to the previous state". The nearest equivalent > is a very special case at the end of an exception handler, where after > "except Exception as e:" you'll get an implicit "e = None; del e" to > prevent a refloop. That's not a return to the previous state, that's a > conscious clearing of one reference. > > If this "unwinding" were desired, the best way would be to simply make > it a permanent part of the match semantics - no syntax for selecting > which behaviour you want. There's no backward compatibility to be > maintained (yet). But that would be inconsistent with the rest of > Python, where things happen step by step, and if something breaks, > everything prior to it has happened. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/5K65WY7B6O7EO5ZKWZZCS3OYV2HCIBQJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/LQWGSE7DYQHXQQCVJDDRXROZ7WHYDHQQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido (mobile) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CXLTVIRD3BWQIQTQMKQXR7NWJ7Y6I6SI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Pattern Matching -- Removing Name Binding from Partial Matching
The solution here is not to use the same name for two different concepts in
the first place. Python doesn't have scopes associated with blocks, only
with functions, and occasionally this means you have to pick your names
carefully -- the same happens e.g. if you reuse a variable as a for-loop
control variable.
You can say that you don't want failed cases to bind any variables -- but
what if the pattern succeeds and now a guard (the 'if' clause) needs to
check the variable? We went down the route of how to make this work and in
the end decided it would be too complicated.
Or what if a case succeeds, and then after the match statement is over and
done with (not in `case _:`) you still wanted access to the global 'name'?
The long and short of it is that match statements are liable to any or all
names bound in any of the patterns used, and your code is incorrect if you
aren't prepared for that.
A variant of the syntax to allow alternate semantics sounds worse.
On Fri, Feb 12, 2021 at 10:30 PM Abdulla Al Kathiri <
alkathiri.abdu...@gmail.com> wrote:
> I will explain it in the following few lines of code..
>
> name = "George"
> year = 2021
>
> d = {"name": "Mike", "year": 1919}
>
> match d:
>
> case {"name": name, "year": 1917}:
> print("match 1 found”)
> # I want to remove binding "name" here from partial
> matching
>
> case {"year": year, "name": "Michael”}:
> print("match 2 found”)
> # I want to remove binding "year" here from partial
> matching.
> # Basically removing all name bindings after every
> partial/failed matching
>
> case _:
> print("match not found!”)
> print(f"{name = }, {year = }”)
>
> ### Output ###:
> match not found!
> name = 'Mike', year = 1919
>
> But I want :var: 'name' to stay being the global name “George" and :var:
> 'year' being the global year 2021 if an exact matching is not found.
>
> Maybe it is done the way it is for speed optimization (overhead reduction
> or something), but what if I don't care about speed and I care about having
> no un-intentional side-effects?
>
> Can we do something like the following to solve this issue?
> match d, partial_binding=False:
> case … : ...
> case … : ...
> with partial_binding=True by default.
>
> Any other idea in how to prevent name binding due to partial matching from
> happening? Any previous discussions on this?
>
> Thanks,
>
> Abdulla
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/HOFNVZ6KJA6SHCE4NCLPSK27XLDMK7VR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/ROVCZOFH7OXVI32VPS2K5SAF2FXUA3UN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternate lambda syntax
On Thu, Feb 11, 2021 at 8:58 PM Random832 wrote:
> On Thu, Feb 11, 2021, at 06:48, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Thu, 11 Feb 2021 12:24:55 +0100
> > "J. Pic" wrote:
> >
> > > Hi all,
> > >
> > > Lambdas can be defined as such:
> > >
> > > w = lambda: [12]
> > > x = lambda y: len(y)
> > >
> > > I'd like to propose the following:
> > >
> > > w = (): [12]
> >
> > What will be the meaning of {(): [12]} ? Hint: it will be a dictionary
> > of empty tuple mapping to a list, where do you see lambda here?
>
> This could be solved with parentheses, but I think it'd probably be better
> to use similar syntax to C#, Java, and Javascript instead, and use () ->
> [12] or () => 12...
>
Agreed. I'd prefer the JavaScript solution, since -> already has a
different meaning in Python return *type*. We could use -> to simplify
typing.Callable, and => to simplify lambda.
> It's worth noting that all three of these are later additions to their
> respective languages, and they all have earlier, more difficult, ways of
> writing nested functions within expressions. Their designers saw the
> benefit of an easy lambda syntax, why don't we?
>
Probably we were blinded by the endless search for for multi-line lambdas.
It's not too late.
> It also may be worth looking at what it would take to allow asynchronous
> lambdas. Syntactically, while "any lambda containing await" is tempting,
> the lack of static typing means that we need a way to specify async lambdas
> that do not contain await. Javascript prefixes the argument list with async
> [i.e. "async () => ..." or "async onearg => ..."], as does C# even though
> it could in principle get away without doing so because of static typing.
>
Makes sense.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/AR5B36GAMB32DXUY2RMG36ADJ5YJRMWD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generic NamedTuples
Did you bring this up on the original issue?
On Mon, Feb 8, 2021 at 10:21 AM Ben Avrahami wrote:
> In both python 3.7 and 3.8, typing.NamedTuple had some strange behaviour
> regarding multiple inheritance. This behaviour was solved in 3.9
> (bpo-36517), but this fix also barred me from a feature very close to my
> heart: the generic named tuple
>
> ```
> T = TypeVar('T')
> class LLNode(NamedTuple, Generic[T]):
> value: T
> next: Optional[LLNode[T]]
> ```
>
> bpo-36517 was committed because any additional features of other classes
> would be missing from the NamedTuple class at runtime. But Generic has no
> features at runtime, and thus this snippet actually works as expected in
> python 3.7/8. But in 3.9, it raises a TypeError, as bpo-36517 completely
> barred any other bases in a typing.NameTuple subclass.
>
> I propose that instead of wholesale barring multiple inheritance in
> NamedTuple, NamedTuple will allow some pre-defined bases alongside it. It
> will only allow do-nothing mixins with no runtime features (I can only
> think of `Generic` Aliases atm, but perhaps others exist). As before, these
> bases will be actually omitted from the class's bases at runtime.
>
> Any thoughts?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XZVZT3U237UCEI4FT6MZVU5MBZICV6ST/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EHHVQ2J5EILIM74BKVQIXE3U4QDLHRBE/
Code of Conduct: http://python.org/psf/codeofconduct/
