[Python-ideas] Re: Conditional with statements

On 08/02/2021 00:39, Brendan Barnwell wrote: On 2021-02-07 09:59, Christopher Barker wrote: All that being said, it's not that big a deal, and I personally don't try to limit to 80 chars per line anyway -- preferring 90 or 95 -- I haven't used a VT100 in decades To be honest I find

[Python-ideas] Re: Conditional with statements

re treated similarly*.  This is just an amorphous mass of code that I find much harder to grok. (YMMV but I find it hard to imagine.) Rules are all very well, but "A Foolish Consistency is the Hobgoblin of Little Minds" [PEP 8] Best wishes Rob PS Can anyone shed any light on why Alt-R d

[Python-ideas] Re: Conditional with statements

On 15/02/2021 01:58, Christopher Barker wrote: Getting OT here -- you've been warned. On Sun, Feb 14, 2021 at 2:10 AM Rob Cliffe > wrote: You've broken a number of "rules" code code formatting there ;-) Thanks for the quotation marks.  Indeed, PEP

[Python-ideas] Re: Arrow functions polyfill

On 15/02/2021 16:32, David Mertz wrote: On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum > wrote: 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 do

[Python-ideas] Re: Alternate lambda syntax

On 15/02/2021 19:47, Mike Miller wrote: On 2021-02-13 14:33, Christopher Barker wrote: On Fri, Feb 12, 2021 at 1:00 AM Brendan Barnwell mailto:brenb...@brenbarn.net>> wrote:         The only thing that would be better than lambda is a less confusing     keyword. There seems to be a fre

[Python-ideas] Re: Conditional with statements

On 16/02/2021 05:45, Christopher Barker wrote: Still OT ... But I do think you need to consider not just your editor -- if anyone else is going to read your code. They're not (in any universe I can imagine). Exactly -- the most important thing about style is that it be consist

[Python-ideas] Re: SimpleNamespace vs object

On 22/02/2021 04:51, Chris Angelico wrote: On Mon, Feb 22, 2021 at 1:11 PM Brendan Barnwell wrote: Why not just put SimpleNamespace in the collections module? The one in types could be aliased to it (or vice versa if we really don't want to change anything). That seems like it's a

[Python-ideas] Re: Arrow functions polyfill

On 23/02/2021 17:46, Stéfane Fermigier wrote: On Tue, Feb 23, 2021 at 6:13 PM Richard Damon mailto:rich...@damon-family.org>> wrote: Also note, that I am not saying that 'arrow-functions' can't happen, just that if they are created, a natural consequence is that, like with

[Python-ideas] Re: Arrow functions polyfill

On 24/02/2021 14:04, Random832 wrote: On Tue, Feb 23, 2021, at 17:01, Rob Cliffe via Python-ideas wrote: As far as I know, there is no case of valid syntax using 'lambda' where replacing 'lambda' by 'def' results in valid syntax. Can anyone provide a counter-ex

[Python-ideas] Re: Implicit line continuation for method chaining

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 syntactical

[Python-ideas] Re: Add an export keyword to better manage __all__

On 15/03/2021 05:54, Ethan Furman wrote: On 3/14/21 12:42 PM, Stestagg wrote: 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 completely agree with this.  One of the hallmarks of P

[Python-ideas] Re: On function signature mismatch, include candidate function in traceback

On 20/04/2021 19:23, Pol Welter wrote: Consider the following snippet: ``` def foo(a, b): pass foo(1, 2, 3) ``` We all know what will happen. ``` File "", line 4, in foo(1, 2, 3) TypeError: foo() takes 2 positional arguments but 3 were given ``` Would it be reasonable to incl

[Python-ideas] Re: Support more conversions in format string

But IIUC once a conversion was added, it could not be removed without breaking backward compatibility.  So I think we should be cautious about building what is in effect a Domain Specific Language and take care to get it (as) right (as possible) first time. Rob Cliffe On 21/04/2021 22:44, Cam

[Python-ideas] Re: Changing The Theme of Python Docs Site

On 30/04/2021 07:06, Abdur-Rahmaan Janhangeer wrote: The Masonite docs for example is quite nice: https://docs.masoniteproject.com/ I read as far as the 4th sentence:     "Use it for your next SaaS!" [no link atached] What on earth (I wanted to use a st

[Python-ideas] Re: String comprehension

On 30/04/2021 19:14, David Álvarez Lombardi wrote: I appreciate the feedback, but I don't think the proposed ideas address any of my points. 1. *Consistency *(with other comprehensions) You're actually adding an inconsistency: having a comprehension inside string quotes instead of not.

[Python-ideas] Re: Changing The Theme of Python Docs Site

On 02/05/2021 20:07, Abdur-Rahmaan Janhangeer wrote: Oh seems like you are a dinosaur needing some carbon dating. Thanks for the insult. Rob Cliffe ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-idea

[Python-ideas] Re: Namespaces!

On 04/05/2021 14:39, Paul Bryan wrote: A problem I sense here is the fact that the interpreter would always need to attempt to resolve "A.B.C" as getattr(getattr(A, "B"), "C") and getattr(A, "B.C"). Since the proxy would be there to serve up  the namespace's attributes, why not just let i

[Python-ideas] Re: Add a mechanism so that multiple exceptions can be caught using `except E1, E2, E3:`

On 10/05/2021 12:43, Chris Angelico wrote: On Mon, May 10, 2021 at 9:36 PM Steven D'Aprano wrote: On Mon, May 10, 2021 at 10:04:58AM +1000, Chris Angelico wrote: On Mon, May 10, 2021 at 9:57 AM Steven D'Aprano wrote: [...] Is there an aim beyond saving two characters? It would remove a l

[Python-ideas] Re: division of integers should result in fractions not floats

On 14/05/2021 22:34, Eric V. Smith wrote: My understanding of the proposal is that OP is only talking about / becomes a Fraction. So: x=1 x/2 # unchanged, still yields a float. It's only literals like "1/2" that would become Fraction(1,2). This would appear to limit the usefulness of th

[Python-ideas] Re: Introduce constants in Python (constant name binding)

On 26/05/2021 02:32, Steven D'Aprano wrote: `math.pi` says hello. The existence of math.pi and the fact that probably nobody ever has introduced a bug into their code by carelessly assigning another value to it suggests strongly that the benefit of language enforced constants is not high. B

[Python-ideas] Re: Introduce constants in Python (constant name binding)

I have certainly overridden sys.stdout, it's USEFUL, Shreyan.  (One use case was to make programs pause after each screenful of output. Probably I've also used it to suppress output.) But I didn't know about sys.__stdout__, thanks Steven. And yes, I'm at least as confused as to what the proposal

[Python-ideas] Re: Introduce constants in Python (constant name binding)

On 26/05/2021 08:25, Shreyan Avigyan wrote: Reply to Chris: There are two things I want to say about constants :- 1) Global-Local Constants - The ALL_CAPS convention variables should become constant. Good luck enforcing that on every Python programmer.  Should it apply to variable names lik

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

On 29/05/2021 00:51, micro codery wrote: I also don't know what should happen for complicated assignments, and I think this has been the death of such variable decorator discussions in the past, so I would still push for only bare identifiers, with or without a type hint (but maybe it will

[Python-ideas] Re: A __decoration_call__ method for Callable objects (WAS: Decorators on variables)

On 29/05/2021 01:26, micro codery wrote: On Fri, May 28, 2021 at 5:07 PM Rob Cliffe Comailto:rob.cli...@btinternet.com>> wrote: On 29/05/2021 00:51, micro codery wrote: I also don't know what should happen for complicated assignments, and I think this has been the death

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

I am concerned that we have too many string formatting methods:     % formatting     .format()     f-strings     string templates (are there others I've missed?). And now we have another proposed one. It's all getting a bit much.  And IMO a turnoff for people learning Python (which one should I u

[Python-ideas] Re: Deprecate sum of lists

This seems sensible to me.  I remember Guido vetoing allowing random.choice() to accept a set, and for the same reason - it encourages inefficient code. Rob Cliffe On 16/06/2021 15:50, Oliver Margetts wrote: Hi all, I came across the following performance issue with the sum function while summ

[Python-ideas] Re: Deprecate sum of lists

On 18/06/2021 16:42, Mathew Elman wrote: I don't see how allowing [x, y for x in a] follows from allowing [*chunk for chunk in list_of_lists]. Nor do I. Rob Cliffe ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an e

[Python-ideas] Re: Deprecate sum of lists

On 19/06/2021 05:33, Guido van Rossum wrote: 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

[Python-ideas] Re: Extension methods in Python

What objection do you have to creating a subclass? Adding methods to e.g. list could give you problems if you import 2 modules that each modify list and the modifications are incompatible.  It could conceivably add bugs to code that uses list in a standard way. Best wishes Rob Cliffe On 20/06/

[Python-ideas] Re: Extension methods in Python

On 24/06/2021 12:44, Richard Damon wrote: On 6/24/21 7:09 AM, Simão Afonso wrote: On 2021-06-24 20:59:31, Steven D'Aprano wrote: Seriously, there's a time to realise when arguments against a feature devolve down to utterly spurious claims that Python programmers are idiots who will be confuse

[Python-ideas] Re: Implementing a 'but' statement in for-iterations

Another wild idea:  Suppose that after a line that introduces a suite, including the final colon, you could write further lines on the same physical line, and this would be semantically equivalent to having them on separate lines with increasing indents, but a smaller indent than the following

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

On 02/07/2021 08:12, Thomas Güttler wrote: Hi Nick and all other Python ideas friends, yes, you are right. There is not much difference between PEP-501 or my proposal. One argument why I would like to prefer backticks: Some IDEs detect that you want to use a f-string automatically: You ty

[Python-ideas] Re: New 'How to Write a Good Bug Report' Article for Docs

Why not send a bug report about it to Mozilla? 😁 On 16/08/2021 23:21, Thomas Grainger wrote: It looks like it was removed unintentionally because the Mozilla support pages still reference it https://support.mozilla.org/en-US/kb/contributors-guide-writing-good-bug#w_existing-guidelines-for-writi

[Python-ideas] Re: synatx sugar for quickly run shell command and return stdout of shell command as string result

On 26/08/2021 15:44, Christopher Barker wrote: Python itself is purposely not designed to provide quick and easy shell access. Is that really true?  What evidence do you have for that statement? Best wishes Rob Cliffe ___ Python-ideas mailing list

[Python-ideas] Re: Different exceptions for assert

On 10/09/2021 23:38, Juancarlo Añez wrote: Following with the ideas on this thread, it would be possible for -OO to turn off only assertions with exceptions that descend from AssertionError. I think this would be confusing, as contrasted with the simple rule that -OO turns off assertion

[Python-ideas] Re: itertools.compress default selectors

My 2c: I don't remember ever seeing itertools.compress (although I've occasionally browsed through itertools), and I've certainly never used it.  However, having worked out what it does, my first reaction was that this would be a harmless and mildly convenient change.  But might it not lead to

[Python-ideas] Re: Adding a Version type

On 10/10/2021 13:31, Steven D'Aprano wrote: On Sat, Oct 09, 2021 at 08:16:58PM -0600, Finn Mason wrote: import sys if sys.version_info < (3, 6): # Yell at the user Please, version checking is usually an anti-pattern! You should use feature detection whenever possible, not version checki

[Python-ideas] Except * formatting

I'm sending this to python-list because my emails to python-dev keep getting bounced back (after a few days delay).  I've no idea why. Instead of `except group ...`, what about `except for ...`? No new keywords. Reads naturally in English. Hints that there is more than one kind of exception com

[Python-ideas] Re: Syntax for late-bound arguments

On 24/10/2021 03:48, Steven D'Aprano wrote: On Sun, Oct 24, 2021 at 01:16:02PM +1100, Chris Angelico wrote: And is it really a problem if we delay the late-binding to the point where the value is actually needed? Here's a toy example: # Using only early binding. def function(spam,

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

My 2¢ (perhaps it should be 3¢ as I've already contributed 2¢). Chris A did ask/  "do Python core devs agree with less-skilled Python programmers on the intuitions?"/ so putting myself firmly in the second camp (though I have been using Python for over a decade) here are my thoughts in case they

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 26/10/2021 02:12, Chris Angelico wrote: On Tue, Oct 26, 2021 at 11:44 AM Rob Cliffe via Python-ideas wrote: I prefer 1). Easier to understand and debug in examples with side-effects such as def f(a := enter_codes(), b = assign_targets(), c := unlock_missiles(), d = FIRE()): (not

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 26/10/2021 02:56, Steven D'Aprano wrote: On Tue, Oct 26, 2021 at 01:32:58AM +0100, Rob Cliffe via Python-ideas wrote: Syntax bikeshedding: I still favour     var := expr That clashes with the walrus operator. Remember that the walrus operator can appear inside the expression:

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 26/10/2021 02:56, Steven D'Aprano wrote: On Tue, Oct 26, 2021 at 01:32:58AM +0100, Rob Cliffe via Python-ideas wrote: Syntax bikeshedding: I still favour     var := expr That clashes with the walrus operator. Remember that the walrus operator can appear inside the expression:

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 26/10/2021 18:25, Chris Angelico wrote: On Tue, Oct 26, 2021 at 11:10 PM Steven D'Aprano wrote: Based on the multi-pass assignment model, which you still favour, those WOULD be quite inconsistent, and some of them would make little sense. It would also mean that there is a distinct semant

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 27/10/2021 00:50, Chris Angelico wrote: On Wed, Oct 27, 2021 at 10:38 AM Rob Cliffe wrote: There has been support for evaluating all early-bound defaults before all late-bound defaults. I have been persuaded that this is a reasonable option. AFAICS there would be little practical differ

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 27/10/2021 01:47, Chris Angelico wrote: The idea that a parameter is optional, but doesn't have a value, may itself be worth exploring (maybe some way to say "arg=pass" and then have an operator "if unset arg:" that returns True if it's unbound), but that's for another day. ChrisA Indeed. 

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 27/10/2021 00:26, Christopher Barker wrote: I'm very confused about the apparent convergence on the token "=>" for deferred parameter assignment. 1)  As others have said, it sure feels like the arrow is going the wrong way. But the bigger question I have is with the similarity to lambda

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 27/10/2021 03:12, Brendan Barnwell wrote: On 2021-10-26 17:41, Christopher Barker wrote: Python used to be such a simple language, not so much anymore :-( I quite agree, and I feel like this is my biggest reason why I don't want this "feature" (or any of another gazillion features that

[Python-ideas] Re: Syntax for late-bound arguments

+1 on the idea. Sometimes early binding is needed, sometimes late binding is needed.  So Python should provide both.  QED 😁 I'm not keen on the     var = > expr syntax.  IMO the arrow is pointing the wrong way.  expr is assigned to var. Some possible alternatives, if there is no technical reaso

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

Warning: Bear of Very Little Brain talking. Aren't we in danger of missing the wood for the (deferred-evaluation) trees here?     Late-bound-arguments defaults are USEFUL.  Being able to specify that a default value is a new empty list or a new empty set is USEFUL.  Plenty of people have ask

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 31/10/2021 08:05, Steven D'Aprano wrote: On Tue, Oct 26, 2021 at 08:59:51AM +0100, Rob Cliffe via Python-ideas wrote: And I don't understand what point you're making here.  Yes, the walrus operator can appear in various places, how is that relevant? You could write     def

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 27/10/2021 08:56, Chris Angelico wrote: On Wed, Oct 27, 2021 at 5:14 PM Brendan Barnwell wrote: But I still think it's worth noticing that the new syntax is not going to add a "full dimension". It is only going to be useful for VERY SIMPLE late-bound default values. If the late-bound d

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 31/10/2021 18:00, Brendan Barnwell wrote: On 2021-10-31 05:57, Chris Angelico wrote: Deferred expressions are not the same as late-bound argument defaults. You keep saying this, but I still don't get the point. Descriptors are not the same as properties, but we can implement properti

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 31/10/2021 21:54, David Mertz, Ph.D. wrote: On Sun, Oct 31, 2021, 5:39 PM Rob Cliffe via Python-ideas PEP 671 will be USEFUL to Python programmers.  We want it!  (When do we want it?  Now!) This feels dishonest. I believe I qualify as a Python programmer. I started using Python

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 03/11/2021 18:28, Stephen J. Turnbull wrote: Chris Angelico writes: > While it's possible to avoid some of those, we can't hold the > language back because *someone who doesn't understand* might > misunderstand. Opposing the proposal wasn't the point of quoting Steve, the point was t

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

Taking a step back: Suppose Python didn't have default values AT ALL for function parameters?  Say that unpassed parameters were always set to some sentinel value (maybe None, maybe some special value NotPassed). Would we want to add them to the language? Surely almost everybody would say yes.

[Python-ideas] Re: PEP 671: Syntax for late-bound function argument defaults

On 05/11/2021 15:57, Stephen J. Turnbull wrote: Still on the agenda as far as I can see: 1. Syntax. The proposals I can recall are a. x=>default b. *x=default c. x=@default d. maybe putting * or @ on the opposite component in b and c? e. a keyword before default

[Python-ideas] Re: Make the global/nonlocal keyword a prefix

On 14/11/2021 18:22, Chris Angelico wrote: IMO it would be kinda handy to be able to combine a global statement with an assignment, but it's not a particularly high priority for me. It would reduce a bit of repetition, but that's all. Agreed.  Sometimes I'd like to be able to write this sort

[Python-ideas] Re: Should bare logical comparisons raise a warning?

On 26/11/2021 00:12, Steven D'Aprano wrote: On Wed, Nov 24, 2021 at 07:15:58PM -, ehmatt...@gmail.com wrote: One common error that I haven't seen discussed is bare logical comparisons. They're syntactically legal so they don't raise errors, but I have never seen a real-world use case for

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 01/12/2021 10:05, Steven D'Aprano wrote: Oh great, now you're going to conflict with walrus... def process(obj:Union[T:=something, List[T]]:=func(x:=expression)+x)->T: We ought to at least try to avoid clear and obvious conflicts between new and existing syntax. Using `:=` is even w

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 02/12/2021 03:35, Steven D'Aprano wrote: On Wed, Dec 01, 2021 at 05:16:34PM +1100, Chris Angelico wrote: 1) If this feature existed in Python 3.11 exactly as described, would you use it? Yes I would, but probably not as often as counting cases of the "if param is None: ..." idiom might le

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 02/12/2021 07:05, Brendan Barnwell wrote: On 2021-12-01 18:35, Chris Angelico wrote: In my reference implementation, there is no object that stores it; it's simply part of the function. A good parallel is the if/else expression: x = float("inf") if z == 0 else y/z Is there an object that

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 01/12/2021 15:39, David Mertz, Ph.D. wrote: However, even if I assume the mythical future PEP never happens, in terms of readability, a WORD is vastly less confusing than a combination of punctuation that has no obvious or natural interpretation like '=>'.  Or rather, I think that spelli

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 01/12/2021 06:16, Chris Angelico wrote: I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 02/12/2021 14:47, Steven D'Aprano wrote: On Thu, Dec 02, 2021 at 11:00:33PM +1100, Chris Angelico wrote: I'm still unsure whether this is a cool feature or an utter abomination: def f(x=...): ... try: print("You passed x as", x) ... except UnboundLocalError: print("You didn't pass

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 03/12/2021 19:32, Adam Johnson wrote: The first unwelcome surprise was: >>> def func(a=>[]): ... return a ... >>> import inspect >>> inspect.signature(func).parameters['a'].default Ellipsis Here the current behaviour of returning `Ellipsis` is very unfor

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 03/12/2021 22:38, Chris Angelico wrote: On Sat, Dec 4, 2021 at 8:18 AM Rob Cliffe via Python-ideas wrote: On 03/12/2021 19:32, Adam Johnson wrote: The first unwelcome surprise was: >>> def func(a=>[]): ... return a ... >&g

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 04/12/2021 01:06, Chris Angelico wrote: On Sat, Dec 4, 2021 at 11:59 AM Rob Cliffe via Python-ideas wrote: On 03/12/2021 22:38, Chris Angelico wrote: On Sat, Dec 4, 2021 at 8:18 AM Rob Cliffe via Python-ideas wrote: On 03/12/2021 19:32, Adam Johnson wrote: The first unwelcome

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

Thank you for doing this research, Steven. The designers of 12 languages have chosen to provide late binding; those of 3 or 4 have provided early binding. I think this is at least tenuous evidence in favour of my belief that late binding is more useful than early binding. Best wishes Rob Cliffe

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 05/12/2021 15:16, Steven D'Aprano wrote: On Wed, Dec 01, 2021 at 12:26:33PM +, Matt del Valle wrote: I'm sure that people will learn the many uses of the arrow symbols. After all, people learn Perl and APL :-) Closer to home, we also learn all the many different uses of the star symbol

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On 05/12/2021 04:01, David Mertz, Ph.D. wrote: The cost here is that EVERY SINGLE student learning Python needs to add this new construct to their mental load. EVERY book and tutorial needs to be updated. EVERY experienced developer has to spend extra effort understanding and writing code.

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 05/12/2021 18:37, David Mertz, Ph.D. wrote: On Sun, Dec 5, 2021, 12:33 PM Chris Angelico And quite frankly, the tone of this list is sounding like "shut up, go away, don't do anything, because there are other proposals that nobody can be bothered writing up, but if they existed,

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 06/12/2021 09:44, Stephen J. Turnbull wrote: Rob Cliffe via Python-ideas writes: > Nobody has attempted (or at least completed) a PEP, never mind an > implementation, of a "generalized deferred object/type", in the last N > years or decades. Haskell anything. R

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On 06/12/2021 08:45, Steven D'Aprano wrote: On Sun, Dec 05, 2021 at 05:31:58PM -0700, Finn Mason wrote: Also, on a kind of side note, what would be a situation where early binding is advantageous to late binding? I can't think of one off the top of my head. If your language only has one, ear

[Python-ideas] Re: PEP 671 review of default arguments evaluation in other languages

On 06/12/2021 23:13, Steven D'Aprano wrote: On Mon, Dec 06, 2021 at 10:17:06AM +0000, Rob Cliffe via Python-ideas wrote: If your language only has one, early binding is better. That's your opinion.  It's not mine.  Witness the Stack Overflow questions asking why `def f(ar

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 07/12/2021 18:22, Stephen J. Turnbull wrote: Rob Cliffe via Python-ideas writes: > I think you're making my point. *shrug* You wrote "object", I took you at your word. > You're saying that the object part isn't that hard, but other parts of > it

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 08/12/2021 19:27, Paul Moore wrote: The reason deferred objects keep coming up is because they *do* have a much more compelling benefit - they help in a much broader range of cases. That may be true.  I don't know. Can anyone provide some realistic use cases?  I've read the whole thread a

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

/2021 22:40, David Mertz, Ph.D. wrote: On Wed, Dec 8, 2021, 2:58 PM Rob Cliffe via Python-ideas On 08/12/2021 19:27, Paul Moore wrote: > The reason deferred objects keep coming up is because they *do* have a much more compelling benefit - they help in a much broader range of ca

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 08/12/2021 23:09, David Mertz, Ph.D. wrote: On Wed, Dec 8, 2021, 5:55 PM Rob Cliffe via Python-ideas But AIUI (i.e. practically not at all) Dask is about parallel computing, which is not the same thing as deferred evaluation, though doubtless they overlap. Again AIUI, parallel

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

_*Objections to PEP 671 - Summary*_ There seems to be a problem understanding what the objections to PEP 671 are.  Chris A wrote: "Part of the problem is that it is really REALLY hard to figure out what the actual objections are. I asked, and the one clear answer I got was one subjective opinio

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

We seem to be arguing in circles and talking past each other here about nomenclature:     f(arg=>dflt) What does it matter if we call it "a default" or "just behaviour in the function" or "a Jabberwocky" or ""? The RELEVANT question should be "Is it useful"? Best wishes Rob Cliffe On 09/12/20

[Python-ideas] Re: Should Python enforce Type-checking in the future?

Please, no, No, NO! It has always been the policy that typing is, and will remain, optional. On 09/12/2021 20:32, deavid wrote: Hi, I would like to hear the opinion of Python's community on enforcing types in the future for the language. I've been using Python as my main language for everything

[Python-ideas] Re: PEP 671 (late-bound arg defaults), next round of discussion!

On 12/12/2021 06:02, Stephen J. Turnbull wrote: Chris Angelico writes: Of course, the *thread* is generally about argument defaults, but "everything" in it is not specifically about defaults. In *this* subthread Eric was arguing for waiting for a facility for *generic* deferral of expression

[Python-ideas] Re: Add a `count` argument to `list.remove`

Currently list.remove raises ValueError if the element is not in the list. When called with the count argument, should it raise ValueError if there are fewer than `count` occurrences of the element in the list? Best wishes Rob Cliffe On 22/12/2021 00:09, Jeremiah Vivian wrote: I expect some s

[Python-ideas] Re: Revisiting a frozenset display literal

How about     fs{1, 2, 3} ? Best wishes Rob Cliffe On 16/01/2022 12:41, Chris Angelico wrote: On Sun, Jan 16, 2022 at 11:18 PM Steven D'Aprano wrote: On Sun, Jan 16, 2022 at 09:18:40PM +1100, Chris Angelico wrote: While it's tempting, it does create an awkward distinction. f(1, 2, 3) # look

[Python-ideas] Re: Revisiting a frozenset display literal

already say a = frozenset({i+1 for i in range(3)}) which is not too bad. On Sun, 16 Jan 2022 at 14:14, Rob Cliffe via Python-ideas wrote: How about fs{1, 2, 3} ? Best wishes Rob Cliffe On 16/01/2022 12:41, Chris Angelico wrote: > On Sun, Jan 16, 2022 at 11

[Python-ideas] Re: Revisiting a frozenset display literal

On 17/01/2022 00:16, Steven D'Aprano wrote: On Sun, Jan 16, 2022 at 01:11:13PM +0000, Rob Cliffe via Python-ideas wrote: How about     fs{1, 2, 3} What does the "s" add that the set {1, 2, 3} doesn't already tell us? It helps to distinguish it from     f(1, 2, 3)     f

[Python-ideas] Re: Revisiting a frozenset display literal

I'm +1 on the idea. I'm happy with the     f{ ... } syntax (although I did suggest something else). We already have letter-prefixes, let's stick to them rather than adding something new (which conceivably might one day find another use). Best wishes Rob Cliffe On 18/01/2022 15:53, Ricky Teachey

[Python-ideas] Re: Revisiting a frozenset display literal

On 18/01/2022 19:42, MRAB wrote: On 2022-01-18 18:54, Neil Girdhar wrote: Even if f{1} creates a frozenset, I don't think f{} should create a frozenset.  I think it makes more sense to keep f{1: 2} open for frozendict if it ever makes it in.  Also, {} should be consisten with f{} (both shoul

[Python-ideas] Re: Revisiting a frozenset display literal

On 21/01/2022 11:51, Oscar Benjamin wrote: I really don't understand (having read everything above) why anyone prefers {1,2,3}.frozen() over f{1,2,3}. Yes, some people coming from some other languages might get confused (e.g. in Mathematica this is function call syntax) but that's true of any

[Python-ideas] Re: Unit variables upon their first appearance

Hi Mirmojtaba, thanks for your suggestion. I doubt this idea will fly with this syntax because it could easily be confused with the walrus operator. x := 0 is *almost* legal syntax currently.  In fact (x := 0) is legal, and it is quite possible that at some time in the future     (Dic[fruit]:=0

[Python-ideas] Re: for ... except, with ... except

On 30/07/2019 00:07:52, Guido van Rossum wrote: On Mon, Jul 29, 2019 at 3:51 PM Eric Fahlgren > wrote: On Mon, Jul 29, 2019 at 2:58 PM Guido van Rossum mailto:gu...@python.org>> wrote: I am *guessing* the problem here is something like this:

[Python-ideas] Re: for ... except, with ... except

On 30/07/2019 23:37:38, Greg Ewing wrote: Guido van Rossum wrote: I'm not sure I understand the desire to catch every possible exception right where it occurs. I've never felt this need somehow. This is my feeling too. I can't remember having a need for such needle-sharp targeting of excepti

[Python-ideas] Re: for ... except, with ... except

On 31/07/2019 00:35:59, Eric V. Smith wrote: On Jul 30, 2019, at 11:38 AM, Guido van Rossum wrote: .. with connect() as stream: # connect() or __enter__() can fail. for data in stream: # __next__() can fail write(data) # write() can fail This very much l

[Python-ideas] Re: For-expression/throwaway comprehension

On 01/08/2019 19:11:18, Guido van Rossum wrote: Here is someone declaring that the docs are less accessible than the code. I personally am disappointed, given the amount of effort that we put in those docs. But maybe this is true. If we can't get people to peruse the docs, should we bother?

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

Would this work for you? import struct floatval = 0.6441726684570312 s = struct.pack("d", floatval) # converts floatval into a string (Python 2) or bytes (Python 3), of 8 raw bytes # then serialise s To be portable between different platforms, you would also need to store whether the format i

[Python-ideas] Re: Exception handling in objects

On 14/08/2019 14:19:05, Marat Sharafutdinov wrote: While using any library there is a need to handle exceptions it raises. In ideal conditions author of library defines base exception and builds hierarchy of exceptions based on it. Moreover, all exceptions a library raises (including those t

[Python-ideas] Re: Custom string prefixes

On 29/08/2019 22:10:21, Andrew Barnert via Python-ideas wrote: As I’ve said before, I believe that anything that doesn’t have a builtin type does not deserve builtin syntax. And I don’t understand why that isn’t a near-ubiquitous viewpoint. +1 (maybe that means I'm missing something). Just cu

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

On 29/08/2019 15:32:38, Philippe Prados wrote: I try with +fooin place of ~foo. Kotlin propose the null-safety  with foo?, but this syntax has a impact of the BNF and all others tools. Le jeu. 29 août 2019 à 15:58, Ricky Teachey

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

On 29/08/2019 16:30:49, Chris Angelico wrote: isinstance(3, Union[str, int]) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python3.9/typing.py", line 764, in __instancecheck__ return self.__subclasscheck__(type(obj)) File "/usr/local/lib/python3.

  1   2   3   >