[Python-ideas] Re: Python with braces formal proposal?

On Mon, Jan 4, 2021 at 1:30 PM Paul Sokolovsky wrote: > > Which leads us back to the question - did anyone of those who did that > over decades ever bothered to post some kind of "spec" for this > alternative syntax? > Is there a lot that needs to be specified? I imagine that the braces would

[Python-ideas] Access to source code when using exec()

When using `exec(string)`, the standard Python REPL, or `python -c` in a terminal, the executed source code is not stored anywhere and cannot be retrieved (except in the `-c` case by looking at `sys.argv`). This means that: - The source line doesn't show up in tracebacks, e.g: >>>

[Python-ideas] Re: Getting rid of FOR loops and simplifying cicular convolutions with Circular Indexing

Here's about 9 million lines that would stop working: https://github.com/search?l=Python=except+IndexError=Code On Thu, Nov 26, 2020 at 10:20 AM Mathew M. Noel via Python-ideas < python-ideas@python.org> wrote: > Circular indexing will only extend the range of allowable indices to the > set of >

[Python-ideas] Re: unix filter, one liners, awk

Try https://github.com/ksamuel/Pyped On Thu, Nov 5, 2020 at 8:03 PM Hans Ginzel wrote: > Is there a reason, why not to make python useful for practical one liners > to replace perl and awk? > There is page Powerful Python One-Liners, >

[Python-ideas] Re: Dict unpacking assignment

On Fri, Oct 23, 2020 at 5:43 PM David Mertz wrote: > On Fri, Oct 23, 2020, 5:44 AM Alex Hall > >> (Heretical question: do we *really* need to distinguish it in syntax? >> Iterator unpacking a dict seems like a dumb idea, I wouldn't be sad if we >> broke compatibilit

[Python-ideas] Re: Dict unpacking assignment

On Fri, Oct 23, 2020 at 11:10 AM Steven D'Aprano wrote: > > but that doesn't make it make sense to write `... = **values` as you > > suggest. > > Iterator unpacking on a dict already works: > > py> d = {'a': 10, 'b': 20} > py> spam, eggs = d > py> spam, eggs > ('a', 'b') > > so

[Python-ideas] Re: Dict unpacking assignment

On Fri, Oct 23, 2020 at 5:27 AM Steven D'Aprano wrote: > Background > -- > > Iterable unpacking assignment: > > values = (1, 2, 3) > a, b, c = *values > > is a very successful and powerful technique in Python. > Your proposed syntax seems to rest on being similar to this syntax

[Python-ideas] Re: except-try block

On Sun, Oct 11, 2020 at 6:48 PM David Mertz wrote: > I'm not advocating for it (nor against it). But the OP proposes something > clear different from the example in current Python. > > On Sun, Oct 11, 2020, 12:39 PM Wes Turner > >> try: >> f = open('myfile.txt') >> s = f.readline() >>

[Python-ideas] Re: Method to efficiently advance iterators for sequences that support random access

On Tue, Oct 6, 2020 at 7:21 PM Christopher Barker wrote: > > > On Tue, Oct 6, 2020 at 10:14 AM Marco Sulla > wrote: > >> What I do not understand is why you need to use the iterator instead >> of using the iterable itself. This way you can jump to whatever >> position without slicing. >> > > if

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020 at 4:56 AM Steven D'Aprano wrote: > But that's a *separate problem*. Regexes can't assign directly either. > And we wouldn't want them to! (It's okay for a regex to have it's own > internal namespace, like named groups, but it shouldn't leak out into > the locals or

[Python-ideas] Re: f-strings as assignment targets

On Fri, Sep 18, 2020 at 3:46 AM Steven D'Aprano wrote: > If there is anything that might justify the name "tuple (or list) > literal" it would be a tuple with each item a literal: > > (1, "a", None) > > but certainly not one containing expressions or names: > > (spam+1, eggs(),

[Python-ideas] Re: Magic attribute for attribute names retrieving

This sounds a lot like this suggestion to add a nameof function/operator: https://mail.python.org/archives/list/python-ideas@python.org/thread/UUFFAI3FZMQRVPDCUPZEOAZCRNXKWFDE/#IHXME3F5XEQZAN6JSK2PMC4UOWV7AVSF On Thu, Sep 17, 2020 at 10:37 PM Joseph Perez wrote: > A lot of libraries use string

[Python-ideas] Re: f-strings as assignment targets

On Thu, Sep 17, 2020 at 9:50 PM Ricky Teachey wrote: > On Thu, Sep 17, 2020 at 3:44 PM Alex Hall wrote: > >> >> On Thu, Sep 17, 2020 at 9:27 PM Ricky Teachey wrote: >> >>> A difficulty I have with the idea as presented is this. >>> >>> If I

[Python-ideas] Re: f-strings as assignment targets

On Thu, Sep 17, 2020 at 9:27 PM Ricky Teachey wrote: > > On Thu, Sep 17, 2020 at 2:57 PM Brendan Barnwell > wrote: > >> On 2020-09-16 21:52, Dennis Sweeney wrote: >> > TL;DR: I propose the following behavior: >> > >> > >>> s = "She turned me into a newt." >> > >>> f"She turned me into

[Python-ideas] Re: f-strings as assignment targets

On Thu, Sep 17, 2020 at 8:57 PM Brendan Barnwell wrote: > On 2020-09-16 21:52, Dennis Sweeney wrote: > > TL;DR: I propose the following behavior: > > > > >>> s = "She turned me into a newt." > > >>> f"She turned me into a {animal}." = s > > >>> animal > > 'newt' > > > >

[Python-ideas] Re: Python-ideas Digest, Vol 166, Issue 76

On Thu, Sep 17, 2020 at 8:49 PM Chris Angelico wrote: > The only time you can safely mutate locals() is when you're at top > level and it's the same as globals(). > It's safe in class definitions, right? At least in CPython it seems to work. I've done that a few times, most recently to

[Python-ideas] Re: locals and exec

On Thu, Sep 17, 2020 at 8:33 PM Alexis Masson wrote: > On Fri, Sep 18, 2020 at 2:13 AM Alexis Masson > wrote: > > This, in addition with locals().update(_), feels much better to me. > Furthermore, it would allow other string-like classes, such as bytes or > bytearray, to use that feature. >

[Python-ideas] Re: f-strings as assignment targets

On Thu, Sep 17, 2020 at 2:38 PM Dennis Sweeney wrote: > === Existing way of achieving this === > > As of now, you could achieve the behavior with regular expressions: > > >>> import re > >>> pattern = re.compile(r'It is (.+):(.+) (.+)') > >>> match = pattern.fullmatch("It is 11:45

[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

+1 because the general idea is one of my most commonly used utility functions. There should also be a similar function for writing to a file, e.g. json.dumpf if we stick to this naming scheme. As an alternative, pathlib.Path.read/write_text are pretty cool, maybe we could have .read/write_json?

[Python-ideas] Re: 'Infinity' constant in Python

On Sat, Sep 5, 2020 at 12:43 AM Greg Ewing wrote: > On 5/09/20 10:15 am, Chris Angelico wrote: > > Remember that if this matters to you, you can "from math import inf". > > But you still need to use full eval on your repr, which could > be a serious security problem in some contexts. If it were

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Thu, Aug 27, 2020 at 6:32 PM Steven D'Aprano wrote: > Personally, I found your examples underwhelming because they're mostly > repetitions of the same pattern. > That's surprising to me. When I see the same pattern over and over that's when I most want to refactor into a common

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Thu, Aug 27, 2020 at 3:37 PM M.-A. Lemburg wrote: > If I'm not mistaken, all those listed cases fall under the second case > I mentioned (branching on length). > > If your API allows for optional list entries, then it's better to > branch on length (e.g. as in the pytest case). If this

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Thu, Aug 27, 2020 at 3:09 PM M.-A. Lemburg wrote: > I disagree on the above assessment. I have had such a get() builtin > in mxTools for more than 20 years now and found that I hardly ever > used it: > > https://www.egenix.com/products/python/mxBase/mxTools/doc/#_Toc293606201 > > The reason

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Thu, Aug 27, 2020 at 10:15 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull < > > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > > > > If the "key

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

t for the ABC (there was an unfortunate naming > conflict -- we have dict and Mapping, list and Sequence, but set and Set...) > > On Wed, Aug 26, 2020 at 2:16 PM Alex Hall wrote: > >> On Wed, Aug 26, 2020 at 10:10 PM Christopher Barker >> wrote: >> >>> Honestly, I haven't

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 10:10 PM Christopher Barker wrote: > Honestly, I haven't delved into type checking much, so maybe I'm making > this up, but what if you write a function that is type hinted to take a > Mapping, and uses | or |=, and all the test code uses a built in dict, and > all seems

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 7:56 PM Guido van Rossum wrote: > On Wed, Aug 26, 2020 at 10:45 AM Alex Hall wrote: > >> On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum >> wrote: >> >>> But for your convenience you are proposing a problematic change (see >>>

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 7:30 PM Guido van Rossum wrote: > But for your convenience you are proposing a problematic change (see posts > by others). > I think we've established it's problematic to add it to the Sequence ABC, but in terms of only adding it to specific sequences like lists, I don't

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 4:32 PM Guido van Rossum wrote: > FWIW I don’t think we should add a .get() method for Sequence or for list. > It reeks of hyper-correctness. > What do you mean by this? I want the method because it's useful and convenient, not because it's 'correct'. I don't think that

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 5:00 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > If the "keyword arguments in __getitem__" feature is added, .get() is > purely redundant. (Of course this thread would then become "make > 'default' a standard keyword argument for mutable

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 1:41 AM Steven D'Aprano wrote: > On Tue, Aug 25, 2020 at 10:22:20AM -0700, Christopher Barker wrote: > > > This one is easier than most because it's pretty much a do we or don't we > > question, with the spelling semantics, all pretty much already decided. > > Is it to be

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Aug 26, 2020 at 1:47 AM Greg Ewing wrote: > As a point of interest, is get() considered an official part of the > mapping protocol, or just nice-to-have? > > The docs don't seem to be very clear about that. There used to be > some tables listing the methods making up the core sequence

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Tue, Aug 25, 2020 at 7:23 PM Christopher Barker wrote: > Though I haven't quite seen it said explicitly -- is this proposed to be > added to the Sequence ABC? > > If so, there is a potential problem -- the ABC's "namespace" is not > reserved, so if you add .get(), then any code out in the

[Python-ideas] Re: Adding additionnal common request handlers to http.server

On Tue, Aug 25, 2020 at 7:15 PM Christopher Barker wrote: > On Tue, Aug 25, 2020 at 8:11 AM Simon wrote: > >> I find that flask's approach to this is quite pythonic. It's also >> relatively easy to use and explain. >> >> This is a good point, I think you distracted a bit earlier by saying it >

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

; > I had to spread `len(stack)` in a lot of places. > > People said about the length of a list is usually known, but when you use > it as a stack is the oposit. > > Em ter, 25 de ago de 2020 09:44, Alex Hall > escreveu: > >> On Thu, Jul 2, 2020 at 10:33 PM Alex Hall w

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Thu, Jul 2, 2020 at 10:33 PM Alex Hall wrote: > On the other hand, `list.get` seems very doable to me. It's not new > syntax. It would be extremely easy to learn for anyone familiar with > `dict.get`, which is pretty much essential knowledge. You'd probably have > some peo

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On Tue, Aug 25, 2020 at 8:11 AM Christopher Barker wrote: > After, of course, looking and seeing what's already out there. (though a > quick search in PyPi turns up, surprisingly, nothing. Lots of packages that > have to do with logging, but nothing that looks like a Pythonic API -- at > least

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 9:54 AM Random832 wrote: > On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote: > > But thus brings up a broader question: > > > > Why not allow slice syntax as an expression everywhere? Everywhere I’ve > > tried, it’s a syntax error now, but is there any technical

[Python-ideas] Re: Add parse_duration to datetime - a golang like fucntion to parse duration

On Sat, Aug 22, 2020 at 7:29 PM Richard Damon wrote: > On 8/22/20 1:07 PM, Stephen J. Turnbull wrote: > > If anything is to be added, I would prefer using ISO 8601 durations. > > > > https://en.wikipedia.org/wiki/ISO_8601#Durations > > > > The main differences are use of "P" and "T" to signal

[Python-ideas] Re: raise TypeError when giving wrong type of argument in functions

I think the most popular library for this is typeguard: https://github.com/agronholm/typeguard I've also seen a couple of other similar libraries: https://github.com/FelixTheC/strongtyping/issues/33 https://github.com/seandstewart/typical/issues/24 On Sat, Aug 22, 2020 at 3:01 PM wrote: > I

[Python-ideas] Re: Universal set

On Mon, Aug 10, 2020 at 2:20 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > haael writes: > > > Could we add the idea of "negative" sets to Python? That means > > sets that contain EVERYTHING EXCEPT certain elements. > > This is usually called the "complement" of a set.

[Python-ideas] Re: Inline Try-Except Clause

On Fri, Aug 7, 2020 at 5:24 PM Paul Moore wrote: > On Fri, 7 Aug 2020 at 16:21, David Mertz wrote: > > > > On Fri, Aug 7, 2020 at 4:58 AM Brendan Barnwell > wrote: > >> > >> It seems that the rationale that was used in the PEP was fairly > >> narrowly focused on the comparison with things like

[Python-ideas] Re: Default behavior for random.sample when no k

I agree that calling random.shuffle imperatively is annoying. But I don't think your proposed solution is readable. You're not taking a sample. A sample generally implies a strict subset, usually quite a small one. I've often thought there should just be a `random.shuffled()` function which

[Python-ideas] Re: Function suggestion: itertools.one()

In my personal toolbox of utility functions, this is by far the function I use most often, although it's implemented slightly differently and I call it `only`. I think it's very useful and it would be great to have in the standard library to encourage people to write safer code. Often this is

[Python-ideas] Re: Thoughts about implementing object-compare in unittest package?

On Sun, Jul 26, 2020 at 11:01 PM Ethan Furman wrote: > On 7/26/20 10:31 AM, Henry Lin wrote: > > > You're right, declaring `__eq__` for the class we want to compare would > > solve this issue. However, we have the tradeoff that > > > > * All classes need to implement the `__eq__` method to

[Python-ideas] Re: Faster object representation for UIs

You may be interested in my library https://github.com/alexmojaki/cheap_repr It was created precisely for the purpose of generating many reprs quickly for my debugging libraries. On Fri, Jul 24, 2020 at 5:17 PM Gábor Bernát wrote: > Hello, I'd like to bring to your attention >

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

It should do the import for you. As was proposed: ``` print(f"My dict: {d!p}") ``` should be equivalent to ``` import pprint print(f"My dict: {pprint.pformat(d)}") ``` The import should happen in the same scope. Modifying the global namespace could be confusing. A quick test shows that adding

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

On Mon, Jul 20, 2020 at 10:36 AM Rob Cliffe via Python-ideas < python-ideas@python.org> wrote: > May I repeat: Spelling 'if break:' and 'if not break:' rather than say > 'on_break:' etc. would avoid adding new keywords. > > I don't know what to do about the zero iterations case, though. > It

[Python-ideas] Re: Restricting Python

I'm making [a platform for learning Python]( https://github.com/alexmojaki/futurecoder) which needs to allow users to run arbitrary Python code on the server. Each user gets their own process and I use `import resource; resource.setrlimit(resource.RLIMIT_NOFILE, (0, 0))` to prevent opening any

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

+1. I imagine I would use this fairly often, particularly in debugging or interactive sessions. It goes well with the magic `=` in f-strings, e.g. `print(f"{d=!p}")`. It's more useful than the others because the manual way requires an import. It's easy to learn, easy to remember, and fits

[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments

On Fri, Jul 10, 2020 at 2:33 PM Steven D'Aprano wrote: > On Fri, Jul 10, 2020 at 11:52:19AM +0100, Jonathan Fine wrote: > > > FUTURE > > Let's proceed. We continue to use d = Dummy(). Given that > >>>> key = d[1, 2, 3, a=4, b=5] > > is allowed, what should we be able to say about the

[Python-ideas] Re: Add builtin function for min(max())

On Sun, Jul 5, 2020 at 2:36 PM Federico Salerno wrote: > On the topic of NaNs: I think in the face of ambiguity, we should refuse > the temptation to guess and raise ValueError when the values given are not > comparable to the point of clearly determining whether `value` is or isn't > within

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Fri, Jul 3, 2020 at 5:36 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > > `dct.get('foo')?.get(0)?.get('bar')`. > > > > I would quite like to have PEP 505, but I don't know how to revive it. > And > &g

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Thu, Jul 2, 2020 at 9:33 PM Daniel. wrote: > Em ter., 30 de jun. de 2020 às 15:49, Alex Hall > escreveu: > >> I think I'm missing something. Daniel wants a `list.get` method with >> similar semantics to `dict.get`. So instead of writing: >> >> ``` &g

[Python-ideas] Re: An alternative way of defining properties (warning: contains creative abuse of the class statement)

On Thu, Jul 2, 2020 at 11:33 AM Chris Angelico wrote: > On Thu, Jul 2, 2020 at 7:06 PM Alex Hall wrote: > > > > On Thu, Jul 2, 2020 at 9:34 AM Chris Angelico wrote: > >> > >> (Not sure why this is on python-ideas - wouldn't python-list be more > >> a

[Python-ideas] Re: An alternative way of defining properties (warning: contains creative abuse of the class statement)

On Thu, Jul 2, 2020 at 9:34 AM Chris Angelico wrote: > (Not sure why this is on python-ideas - wouldn't python-list be more > appropriate? Keeping it where it is for now though.) > As someone not familiar with the other lists...why? It's a proposal of an idea that could use some debate. Isn't

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

On Wed, Jul 1, 2020 at 6:23 AM Christopher Barker wrote: > On Tue, Jun 30, 2020 at 8:55 PM David Lowry-Duda > wrote: > >> On the other hand, it seems far more likely to miss keys in a dictionary >> than it is to repeatedly mistake indices in a list. >> > > exactly -- dict keys are arbitrary,

[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?

I think I'm missing something. Daniel wants a `list.get` method with similar semantics to `dict.get`. So instead of writing: ``` try: x = lst[i] except IndexError: x = default ``` one could write `x = lst.get(i, default)`. How would you rewrite that with PEP 505? I've also wanted this a

[Python-ideas] Re: Access (ordered) dict by index; insert slice

I think Hans would like to do `my_dict.items()[0]` for example, which shouldn't conflict with anything. On Fri, Jun 26, 2020 at 7:48 PM Brett Cannon wrote: > Why can't you do `tuple(dict.items())` to get your indexable pairs? > > Otherwise there are no plans as you would have to introduce a new

[Python-ideas] Re: giving set.add a return value

Previous discussions on this: https://mail.python.org/archives/list/python-ideas@python.org/thread/ASHOHN32BQPBVPIGBZQRS24XHXFMB6XZ/ https://mail.python.org/archives/list/python-ideas@python.org/thread/K5SS62AB5DFFZIJ7ASKPLB2P3XGSYFPC/ (seems like part of the above discussion that got separated)

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

On Sun, Jun 14, 2020 at 3:14 PM Sebastian M. Ernst wrote: > > Am 14.06.20 um 14:56 schrieb Alex Hall: > > It would help a lot if you could show some examples. > > There you go: > > > ```python > > > > import math > > a = 1.01 > > b = 0

[Python-ideas] Re: approximate equality operator ("PEP 485 follow-up")

On Sun, Jun 14, 2020 at 2:44 PM Sebastian M. Ernst wrote: > I have overloaded the modulo operator in some test code and it actually > helps a lot to make some logic more readable. > It would help a lot if you could show some examples. ___ Python-ideas

[Python-ideas] Re: Operator ">" for functions

Wouldn't it make more sense to write `def some_function(a in (1, 2,3), b):`, meaning `a in (1, 2,3)` must be true? Similarly you could have `def some_function(a > 0):` to mean `a > 0` must be true. On Sat, Jun 13, 2020 at 2:55 PM artem6191 wrote: > This operator will allow to send arguments to

[Python-ideas] Re: JSON Serializing UUID objects

On Wed, Jun 10, 2020 at 4:09 PM J. Pic wrote: > Good point, but then I'm not sure the decoder could be used for untrusted > json anymore. > > Another solution would be to generate a schema in a separate variable, > which would represent the JSON structure with Python types. > For that there are

[Python-ideas] Re: JSON Serializing UUID objects

On Wed, Jun 10, 2020 at 3:42 PM J. Pic wrote: > I understand, do you think the python standard library should provide a > JSONEncoder and JSONDecoder that supports python standard library objects ? > > It would be optional to use, but if you use it then any object from the > python standard

[Python-ideas] Re: PYTHONLOGGING env variable

On Sat, Jun 6, 2020 at 6:46 AM Steven D'Aprano wrote: > I think the first thing that needs to be done, before creating a bpo > issue, is to get consensus that it's both a plausible idea and a good > idea, and I don't think that the discussion did either. > > Discussion starts here: > > >

[Python-ideas] Re: Augment abc.Set API (support named set methods for dictionary view objects)

On Mon, Jun 1, 2020 at 8:50 PM Brandt Bucher wrote: > > These would be mixin methods, not abstract. Set already implements the > various operators based on the abstract methods, it could easily add more > mixin methods which would delegate to the operators. Classes which override > the operators

[Python-ideas] Re: Augment abc.Set API (support named set methods for dictionary view objects)

On Mon, Jun 1, 2020 at 5:31 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > > > On Jun 1, 2020, at 3:32 AM, a...@yert.pink a...@yert.pink > wrote: > > > > I propose that the `Set` ABC API should be augmented to contain all of > the named methods. This would provide consistency in

[Python-ideas] Re: Optional keyword arguments

On Sat, May 30, 2020 at 6:00 AM Steven D'Aprano wrote: > On Fri, May 29, 2020 at 06:03:30PM +0200, Alex Hall wrote: > > > > I never said that Python's scoping rules were implementation details. > > > > > > I said that the storage mechanism of *how* local vari

[Python-ideas] Re: Optional keyword arguments

On Fri, May 29, 2020 at 7:05 PM David Mertz wrote: > On Fri, May 29, 2020 at 3:19 AM Stephen J. Turnbull < > turnbull.stephen...@u.tsukuba.ac.jp> wrote: > >> # Just too ugly for me! >> def foo(x=lambda: random.randint(0,9)): >> >> x = x() >> # ... >> > > I think this is a

[Python-ideas] Re: Optional keyword arguments

On Fri, May 29, 2020 at 2:18 PM Steven D'Aprano wrote: > On Thu, May 28, 2020 at 12:11:38PM +0200, Alex Hall wrote: > > > Consider this code: > > > > ``` > > x = 1 > > > > def foo(): > > print(x) > > x = 2 > > > >

[Python-ideas] Re: Python __main__ function

On Thu, May 28, 2020 at 9:52 PM Paul Sokolovsky wrote: > On Fri, 29 May 2020 05:33:57 +1000 > Chris Angelico wrote: > > People can already put all their main logic into a function. If you > > want to unit-test your main function, that's the best way to do it. > Yes, and I want to make it easy,

[Python-ideas] Re: Python __main__ function

On Thu, May 28, 2020 at 12:57 PM Paul Sokolovsky wrote: > And in all fairness, all good ideas already came to somebody else years > ago. There's https://www.python.org/dev/peps/pep-0299/ , successfully > rejected yet back in 2002. (So, feel free to use it in your own > environment/Python

[Python-ideas] Re: Optional keyword arguments

On Thu, May 28, 2020 at 12:38 PM Greg Ewing wrote: > On 28/05/20 8:57 pm, Steven D'Aprano wrote: > > The default value used by a parameter is certainly important, and one of > > the most common reasons I call `help(func)` is to see what the default > > values are. They should be in the

[Python-ideas] Re: Optional keyword arguments

On Thu, May 28, 2020 at 11:57 AM Steven D'Aprano wrote: > On Wed, May 27, 2020 at 05:03:09AM +1000, Chris Angelico wrote: > > > def foo(): > > if False: x = 0 > > # what is x now? > > > > There is no *value* in x, yet x has a state. > > In Python code, no, it has no state, it's just an

[Python-ideas] Re: Optional keyword arguments

On Thu, May 28, 2020 at 9:01 AM Greg Ewing wrote: > On 28/05/20 12:38 pm, Rob Cliffe wrote: > > why not go > > further (as the OP suggested as far as I recall) > > and allow the more concise > > > > def order(eggs = 4, spam ?= Spam()): > > etc. > > That clutters up the header with

[Python-ideas] Re: Optional keyword arguments

On Tue, May 26, 2020 at 9:24 PM Chris Angelico wrote: > On Wed, May 27, 2020 at 5:19 AM Alex Hall wrote: > > > > On Tue, May 26, 2020 at 9:05 PM Chris Angelico wrote: > >> > >> And the "is this name bound" check would potentially > >> hav

[Python-ideas] Re: Optional keyword arguments

On Tue, May 26, 2020 at 9:05 PM Chris Angelico wrote: > And the "is this name bound" check would potentially > have other value, too. > Can you think of any examples? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an

[Python-ideas] Re: Optional keyword arguments

On Mon, May 25, 2020 at 6:24 PM Dominik Vilsmeier wrote: > On 25.05.20 17:29, Ricky Teachey wrote: > > > On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas < > python-ideas@python.org> wrote: > >> (Possibly heretical) Thought: >> ISTM that when the decision was made that arg default

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 11:17 PM Tim Peters wrote: > [Guido] > >> I’ve never been able to remember whether (f@g)(x) means f(g(x)) or > g(f(x)). That pretty much kills the idea for me. > > [David Mertz] > > Well, it means whichever one the designers decide it should mean. But > obviously it's a

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 10:53 PM David Mertz wrote: > On Sun, May 24, 2020, 3:43 PM Guido van Rossum wrote: > >> I’ve never been able to remember whether (f@g)(x) means f(g(x)) or >> g(f(x)). That pretty much kills the idea for me. >> > > Well, it means whichever one the designers decide it

[Python-ideas] Re: Optional keyword arguments

On Sun, May 24, 2020 at 10:05 PM Dominik Vilsmeier wrote: > On 24.05.20 18:34, Alex Hall wrote: > > > OK, let's forget the colon. The point is just to have some kind of > 'modifier' on the default value to say 'this is evaluated on each function > call', while still having so

[Python-ideas] Re: Function composition

. Alex' forbiddenfruit.curse is > pretty cool looking. But it does require explicitly cursing each > individual function that might be composed. > forbiddenfruit patches the type, look again. I used a loop because there isn't just one FunctionType: `type(compose) != type(len)`. > Al

[Python-ideas] Re: Optional keyword arguments

On Sat, May 23, 2020 at 2:37 AM Steven D'Aprano wrote: > On Thu, May 21, 2020 at 02:50:00PM +0200, Alex Hall wrote: > > or a more realistic example: > > > > def func(options=:{}): > > > Add annotations and walrus operator: > > def flummox(options:d

[Python-ideas] Re: Optional keyword arguments

On Sat, May 23, 2020 at 11:34 PM Tiago Illipronti Girardi < tiagoigira...@gmail.com> wrote: > A programmer making the least effort wouldn't update themselves on the > grammar: the patch would be useless. This is taking my words a bit far. Typing annotations are tedious and have to be done

[Python-ideas] Re: Function composition

On Sun, May 24, 2020 at 4:55 PM David Mertz wrote: > Changed subject line. This is far from original topic. > > On Sun, May 24, 2020, 9:35 AM Ram Rachum wrote: > >> What's wrong with using @? If I understand correctly, it's used for >> matrix multiplication, which is far enough from function

[Python-ideas] Re: len(path) == len(str(path))

On Sun, May 24, 2020 at 3:38 PM Ram Rachum wrote: > What's wrong with using @? If I understand correctly, it's used for matrix > multiplication, which is far enough from function composition to avoid > confusion. And it's slightly similar visually to a circle. > The matrix multiplication PEP

[Python-ideas] Re: len(path) == len(str(path))

On Sun, May 24, 2020 at 1:58 PM Ram Rachum wrote: > Well, looks like this proposal is dead in the water. Thanks for your > opinions everybody, I'll close the PR. > > Also, for Alex and Richard, `path.parts` would do the trick. > >> > > I know, that's why I

[Python-ideas] Re: len(path) == len(str(path))

On Sun, May 24, 2020 at 1:42 PM Bernardo Sulzbach < berna...@bernardosulzbach.com> wrote: > "Serhiy and Remi objected, because it might not be obvious that the length > of the path would be the length of string." I find this _really_ > unintuitive. If anything, I would expect len(p) to be the

[Python-ideas] Re: Optional keyword arguments

On Sat, May 23, 2020 at 2:52 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Alex Hall writes: > > > In all cases it's not immediately clear what the actual default value > is, > > or even what kind of object is meant to be passed to

[Python-ideas] Re: Optional keyword arguments

On Thu, May 21, 2020 at 2:50 PM Alex Hall wrote: > Personally I think the best way forward on this would be to accept PEP > 505. It wouldn't solve this particular problem in the most concise way but > it would be pretty good and would be more broadly useful. > Having thought about

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Thu, May 21, 2020 at 4:36 PM Thierry Parmentelat < thierry.parmente...@inria.fr> wrote: > > Again, if I saw a unicode arrow used as syntax on GitHub or something in > the wild right now, I would think it's an error, which incidentally would > be correct. Wouldn't you? > > yes, like I would

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Thu, May 21, 2020 at 4:09 PM Thierry Parmentelat < thierry.parmente...@inria.fr> wrote: > > > > On 21 May 2020, at 15:45, Alex Hall wrote: > > > > Many (probably most) people are going to come across a unicode symbol > having previously only encountered AS

[Python-ideas] Re: type hints : I'd like to suggest allowing unicode → as an alternative to ->

On Wed, May 20, 2020 at 8:36 AM Thierry Parmentelat < thierry.parmente...@inria.fr> wrote: > Plus, it’s not only IDE’s, I’m prominently concerned by beginners and > students, who start reading code on sources like github, or teaching > websites, or notebooks; one cannot expect all these stacks to

[Python-ideas] Re: Optional keyword arguments

On Thu, May 21, 2020 at 12:27 AM James Lu wrote: > > This is already valid in 3.8, so we should forget about overloading := > > with a second meaning. > > def func(x=(a:=expression), y=a+1): > def func(x:=options): > > These two syntaxes do not conflict with each other. > Technically no, but

[Python-ideas] Re: str.strip: argument maxstrip

On Wed, May 20, 2020 at 12:44 PM Henk-Jaap Wagenaar < wagenaarhenkj...@gmail.com> wrote: > foobar.removesuffix('=').removesuffix('=') > > would work right now in 3.9 (I think). > > Can confirm: ``` >>> 'abc==='.removesuffix('=').removesuffix('=') 'abc='

[Python-ideas] Re: str.strip: argument maxstrip

On Wed, May 20, 2020 at 2:46 AM Cameron Simpson wrote: > On 19May2020 15:43, David Mertz wrote: > Reiterating the Python 3.9 suggestion, what about: > > salt2 = salt.cutsuffix(('==', '=')) > Tuple arguments were rejected in the PEP. ``` Python 3.10.0a0 (heads/master:bac170cd93, May 20 2020,

[Python-ideas] Re: str.strip: argument maxstrip

On Tue, May 19, 2020 at 9:43 PM David Mertz wrote: > Currently, I'd probably program my intention like this. Let's assume this > is something where the '=' is allowed in the middle. > Getting increasingly hypothetical... Anyway, you could write: ``` assert not salt.endswith("=" * 3) # at

[Python-ideas] Re: str.strip: argument maxstrip

On Tue, May 19, 2020 at 2:58 PM computermaster360 . < computermaster...@gmail.com> wrote: > I often find myself in a need of stripping only a specified amount of > characters from a string (most commonly a single character). I have been > implementing this in an ad-hoc manner, which is quite

[Python-ideas] Re: str.strip: argument maxstrip

On Tue, May 19, 2020 at 8:49 PM David Mertz wrote: > elif fmt == "PBKDF2_SHA256": > h = base64.b64encode(base64.b64decode(text)[:32]) > # a terrible hack follows, use "adapted base64" alphabet > (using . instead of + and with no padding) > h =

  1   2   3   >