[Python-ideas] Re: deque: Allow efficient operations

On 30/04/20 3:32 am, Christopher Barker wrote: I've wondered about Linked Lists for a while, but while there are many versions on PyPi, I can't find one that seems to be mature and maintained. Which seems to indicate that there isn't much demand for them. I think this is probably because a lin

[Python-ideas] Re: deque: Allow efficient operations

On 29/04/20 11:32 pm, Steven D'Aprano wrote: My reasoning was that *eventually* for a big enough list, the cost of making the copy would outweigh the cost of moving the items. I don't know if my reasoning was valid or not, I think it's not. They're both O(n) in the length of the list, so at mos

[Python-ideas] Re: Adding a "once" function to functools

On 28/04/20 1:17 pm, Steven D'Aprano wrote: I think that it is silly to say that you have to be familiar with Eiffel to recognise the connection between running a function once and the word "once". The connection is very obvious after you know about it. And probably you can guess the meaning if

[Python-ideas] Re: Adding a "once" function to functools

On 28/04/20 6:34 am, Antoine Pitrou wrote: A more explicit spelling would be `@call_once`, what do you think? That's not quite right either -- you're allowed to *call* it as many times as you want. It's more like "execute once". But that's a rather long and awkward name. I don't think "once" i

[Python-ideas] Re: zip(x, y, z, strict=True)

On 25/04/20 6:07 am, Brandt Bucher wrote: Well, my use cases are "anytime the iterables should be the same length", which several on this thread have agreed is easily the majority of the time they use `zip`. If zip were being designed today, I'm sure most people wouldn't mind if it were always

[Python-ideas] Re: zip should return partial results in StopIteration

On 22/04/20 3:15 am, Chris Angelico wrote: Currently, it retains any value that was already in it - so if the shortest iterable is a generator, then its return value will be in the propagated StopIteration. Not sure if that's a guarantee and therefore covered by backward compatibility. I don't

[Python-ideas] Re: Keyword arguments self-assignment

On 20/04/20 2:57 pm, Steven D'Aprano wrote: process_files(delete=obsolete_files, archive=irrelevent_files) process_files(archive=obsolete_files, delete=irrelevent_files) That's not a use case for the proposed feature. The intended use cases are more like def fancy_file_processin

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 20/04/20 1:36 pm, Steven D'Aprano wrote: **{alpha, beta, gamma} **{:alpha, :beta, :gamma} *, alpha, beta, gamma **, alpha, beta, gamma alpha=, beta=, gamma= although I may have missed some. I'm not seeing "much" difference in complexity between them, syntax-wise. To

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 19/04/20 6:58 pm, Steven D'Aprano wrote: There are three tokens there: `**{`, an identifier, and `}`. Adding an optional comma makes four. If this is your idea of "complicated syntax", I cannot imagine how you cope with function definitions in their full generality: What I mean is that much

[Python-ideas] Re: Proposal: Keyword Unpacking Shortcut [was Re: Keyword arguments self-assignment]

On 19/04/20 7:17 am, Alex Hall wrote: there is something about all these examples (plausibility?) that feels distinctly different from your proposal. To me it seems like an unnecessarily complicated syntax that goes out of its way to look deceptively like something else.     f(a, b, c)

[Python-ideas] Re: Keyword arguments self-assignment

On 18/04/20 1:53 am, Steven D'Aprano wrote: On Sat, Apr 18, 2020 at 12:22:36AM +1200, Greg Ewing wrote: Here's another idea for the bikeshed: f(spam, pass eggs, ham) How is "pass" meaningful here? It means "pass these things on as they are". Think foo

[Python-ideas] Re: Keyword arguments self-assignment

On 18/04/20 1:56 am, oliveira.rodrig...@gmail.com wrote: This should be valid syntax: ```python return render_template("index.html", *, twitter, username=user["display_name"], channel, channelid, error, setups=database.list_setups(channelid), sched_tz, schedule, sched_tweet,

[Python-ideas] Re: Keyword arguments self-assignment

On 18/04/20 1:28 am, Chris Angelico wrote: What's the advantage of a mode switch? I don't particularly like the mode switch either. Personally I'd be happy with either f(arg=) or f(=arg) The latter is maybe more suggestive that "arg" is to be evaluated in the local scope. -- Greg _

[Python-ideas] Re: Keyword arguments self-assignment

Here's another idea for the bikeshed: f(spam, pass eggs, ham) equivalent to f(spam, eggs=eggs, ham=ham) -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.

[Python-ideas] Re: Exception spaces

On 12/04/20 3:57 am, Soni L. wrote: but those are just mitigations, not proper solutions. they reduce the risk but don't eliminate it. why shouldn't we eliminate that risk? The risk could be completely eliminated today if everyone rewrote their api-exception-raising methods to catch and rerais

[Python-ideas] Re: RFC: For Loop Invariants

On 11/04/20 5:38 pm, Steven D'Aprano wrote: That is surely okay though. If the loop is never entered at all, by the principle of vacuous truth the condition inside the loop is true. No. A loop invariant is something that is true before entering the loop, and remains true after each iteration.

[Python-ideas] Re: RFC: For Loop Invariants

On 11/04/20 10:20 am, haael wrote:     class InvariantError(AssertionError):     pass     def loop_invariant(condition:bool):     if not condition:     raise InvariantError     return True     for element in iterable if loop_invariant(condition):     loop_body

[Python-ideas] Re: Exception spaces

On 11/04/20 6:34 am, Soni L. wrote:     def _extract(self, obj):     try:     yield (self.key, obj[self.key])     except (TypeError, IndexError, KeyError):     if not self.skippable:     raise exceptions.ValidationError You can separate out the TypeErr

[Python-ideas] Re: Exception spaces

On 11/04/20 2:34 am, Chris Angelico wrote: AttributeError, KeyError/IndexError, and GeneratorExit (and StopAsyncIteration) want to say hi too. Okay, there are a few others. But the important thing for our purposes is that APIs designed specifically to use exceptions for flow control (such as St

[Python-ideas] Re: Exception spaces

On 11/04/20 12:56 am, Soni L. wrote: why's a "help us fix bugs related to exception handling" proposal getting so much pushback? I don't understand. You're proposing a syntax change, which is a *very* big deal. It requires a substantial amount of justification. idk what else those massive fra

[Python-ideas] Re: Exception spaces

On 10/04/20 11:43 pm, Soni L. wrote: it's actually fairly common to deal with KeyError instead of using dict.get or w/e. When doing that, though, it's good practice to make sure the try/except encloses the minimum amount of code needed. E.g. instead of try: value = somedict[get_m

[Python-ideas] Re: Exception spaces

On 11/04/20 1:15 am, Chris Angelico wrote: StopIteration wants to say hello :) By "rare' I mean as a proportion of APIs in existence. StopIteration is frequently used, but it's just one API. The only other one I can think of in the stdlib is EOFError, and that isn't even used all that much.

[Python-ideas] Re: Exception spaces

On 10/04/20 8:30 am, Soni L. wrote: Sometimes, you have an API:     @abc.abstractmethod     def get_property_value(self, prop):     """Returns the value associated with the given property.     Args:     prop (DataProperty): The property.     Returns:     The

[Python-ideas] Re: "except BaseException with f as result"

On 9/04/20 1:37 am, Soni L. wrote: On 2020-04-08 10:33 a.m., Greg Ewing wrote:     try:     first = next(iterator)     except abdl.exceptions.ValidationError as e: validation_handler(e)     except StopIteration as e: return stop_handler(e) ... I can do that today, can't I?

[Python-ideas] Re: "except BaseException with f as result"

On 9/04/20 1:22 am, Soni L. wrote: it's hard to reason about it if your eyes just keep jumping into the except bodies because they have the same indentation and everything as the normal code. I am gonna say my proposal improves accessibility, even if it doesn't make a difference to most ppl.

[Python-ideas] Re: "except BaseException with f as result"

On 8/04/20 1:14 pm, Soni L. wrote:     def get_property_values(self, prop):     try:     factory = self.get_supported_properties()[prop]     except KeyError with keyerror_handler;     iterator = factory(self._obj)     try:     first = next(iterator)   

[Python-ideas] Re: Improvement: __json__

On 7/04/20 4:57 am, Wes Turner wrote: Python object > JSON  > object requires type information to be serialized. Not necessarily -- Java's json library uses reflection on compile time type information to deserialise json into an object hierarchy. You tell it the class corresponding to the top l

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

On 1/04/20 7:08 am, Serhiy Storchaka wrote: 31.03.20 20:52, Antoine Pitrou пише: Your search is incomplete, for example you failed to account for occurrences of "cheese" and "milkshake". Should we deprecate the word "wheel" as well, since it's a reference to cheese? -- Greg __

[Python-ideas] Re: Instance method to test equivalence between set and iterable

On 23/03/20 11:10 pm, M.-A. Lemburg wrote: The Python way is the mathematically correct way of interpreting the terms "subset" and "superset". Generally in maths it's usually more convenient if the simplest terminology includes edge cases. For example, the definition of a powerset would be more

[Python-ideas] Re: dunder methods for encoding & prettiness aware formal & informal representations

On 20/03/20 4:55 pm, Steven D'Aprano wrote: Are you aware that dunder names are reserved for Python's use? Nobody is going to put you in jail if you use an unofficial dunder name. You just run the risk that your use of it will conflict with some official use in the future. -- Greg ___

[Python-ideas] Re: dunder methods for encoding & prettiness aware formal & informal representations

On 16/03/20 2:27 pm, Christopher Barker wrote: I imagine a LOT of code out there (doctests, who know what else) does in fact expect the str() of builtins not to change -- so this is probably dead in the water. Also, strs and reprs of arbitrary objects often end up in places such as log files w

[Python-ideas] Re: Make `del x` an expression evaluating to `x`

On 13/03/20 12:30 pm, Marco Sulla via Python-ideas wrote: As you can see, Thing(abcd) has the same id of Thing(ab). So what Eric Wieser wanted is already implemented in Python, for temporary objects. This is probably an accident. It's not really re-using an object, it's just that the object cre

[Python-ideas] Re: Make `del x` an expression evaluating to `x`

On 13/03/20 4:02 am, Eric Wieser wrote: For consistency, `x = (del foo.attr)` and `x = (del foo[i])` could also become legal expressions, and `__delete__`, `__delattr__`, and `__delitem__` would now have return values. Existing types would be free to continue to return `None`. That would mean

[Python-ideas] Re: IDEA: Allow override of all assignments of a built in type to be a different type

On 5/03/20 11:09 pm, Steve Barnes wrote: just about any financial calculations for example - I have seen quite a lot of such code that works in pennies or cents and then scales the results for example. But how much real-world financial code uses hard-coded amounts of money, rather than reading

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

On 5/03/20 4:08 pm, Richard Damon wrote: Sometimes I wonder if since Python supports dynamic typing of results, might not do better by removing the NaN value from Floats and Decimals, and make the operations that generate the NaN generate an object of a special NaN type. I don't see what prob

[Python-ideas] Re: Magnitude and ProtoMagnitude ABCs — primarily for argument validation

On 4/03/20 7:42 am, Steve Jorgensen wrote: That's a much better term. `Orderable` and `ProtoOrderable`. I would suggest "TotallyOrdered" and "PartiallyOrdered". -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an e

[Python-ideas] Re: Incremental step on road to improving situation around iterable strings

On 24/02/20 9:32 am, jdve...@gmail.com wrote: It is a common "pattern" in any languages to walk along strings, letter by letter. Maybe in some other languages, but I very rarely find myself doing that in Python. There is almost always some higher level way of doing what I want. if strings are

[Python-ideas] Re: Proposal: Complex comprehensions containing statements

On 22/02/20 11:45 am, Andrew Barnert via Python-ideas wrote: there’s no reason you can’t write `[(yield None) for _ in range(3)]` to gather the first three values sent into your generator Currently this doesn't quite do what you might expect. It doesn't make the enclosing function into a gener

[Python-ideas] Re: `raise as` to raise with current exception as cause

My reaction to this whole discussion is to question whether it's worth having two different forms of exception chaining in the first place. It seems to be a subtle distinction that most programmers either aren't aware of or can't be bothered making when they write a 'raise' statement. I'm not con

[Python-ideas] Re: Traits

On 8/02/20 5:59 am, Soni L. wrote: Traits are an alternative to Multiple Inheritance. They solve the problem of name conflicts by making them an ambiguity error and requiring you to disambiguate (at call site). This sounds like something that would work better in a statically typed language, w

[Python-ideas] Re: addition of "nameof" operator

On 2/02/20 6:12 am, Guido van Rossum wrote: Alex, this is not ever going to be added to Python, For clarity, are you rejecting the whole idea of a "nameof" feature, or just bytecode-hack implementations of it? -- Greg ___ Python-ideas mailing list -

[Python-ideas] Re: addition of "nameof" operator

On 1/02/20 6:15 am, Richard Damon wrote: One issue I am seeing is that x = nameof(foo.bar) is crossing the line between compile time and run time behaviors. The resultant string, “bar” needs to be generated at compile time, but the operation still needs to do a check at run-time to determine if t

[Python-ideas] Re: Add a PyObject_VaCallFunction to C API??

On 8/01/20 9:22 am, hrfu...@gmail.com wrote: how can I know if a PyObject_Call(...) or PyObject_GetAttr(...) returns a new ref or a borrowed ref? I read online ( Python 3 ) that they are returning new references. But does everyone comply with it? They always return new references. Yes, everyone

[Python-ideas] Re: Target-and-expression lists and if-try

On 1/01/20 11:28 am, Andrew Barnert via Python-ideas wrote: The first is to extend unpacking assignment to target-or-expression lists. Like this: x, 0, z = vec But it doesn’t bind anything to the second element; instead, it checks if that element is 0, and, if not, raises a ValueError.

[Python-ideas] Re: more readable "if" for multiple "in" condition

if a or b or c is in x: if a and b and c are in x: -- Greg ___ 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 ar

[Python-ideas] Re: Fix statistics.median()?

On 30/12/19 12:19 pm, David Mertz wrote: I'm sort of convinced that Posits better approximate the behavior of rationals than do IEEE-754 floats: https://en.m.wikipedia.org/wiki/Unum_(number_format) Is it just me, or is that Wikipedia article abysmally written? I feel like I gained a negative

[Python-ideas] Re: Testing for NANs [was Re: Fix statistics.median()?]

On 30/12/19 3:47 am, Steven D'Aprano wrote: I'd like to understand the use-case here. I guess it is "signalling NANs are an error, quiet NANs are missing data". Am I right? I'm having trouble seeing what signalling NaNs are useful for in general. If something has gone badly enough wrong that a

[Python-ideas] Re: "and if" and "or if" for trailing if statements - including explicit fallthrough

On 22/12/19 9:04 am, Soni L. wrote: switch (op) {   [...]   case OP_TAILCALL: {     adjust_regs();     some_other_stuff();     /* fallthrough */   }   case OP_CALL: {     make_the_call_happen();     break;   } } Relying on fall-through in a switch is a micro-optimisation that may hel

[Python-ideas] Re: Argumenting in favor of first()

On 14/12/19 6:44 am, Christopher Barker wrote: I think we all agree that it does not belong in __builtins__, Do we? I'm not convinced. We already have all() and any() in builtins, which are similar in that they operate on iterators or iterables. -- Greg

[Python-ideas] Re: Python slicing

On 13/12/19 9:59 am, Steven D'Aprano wrote: So a[] would be: temp = # A syntax error. a[temp] not an empty tuple. That's the way it is now, but it doesn't have to be that way. There is some logic to the proposal. Currently the argument passed to __getitem__ is what you would get

[Python-ideas] Re: Argumenting in favor of first()

On 12/12/19 4:39 am, Daniel Moisset wrote: I think a solution nobody has proposed in this thread is relaxing the next builtin, so it calls iter() on the argument when it doesn't implement the iterator protocol. > Do you think this fails to cover the > original problems in any way? It would sti

[Python-ideas] Re: Argumenting in favor of first()

On 11/12/19 9:45 pm, Steven D'Aprano wrote: But that's not what happens if you call `first(iterable)` multiple times. Calling it once is fine, but people will call it multiple times. Would it help if it were called "one" instead of "first"? -- Greg _

[Python-ideas] Re: Argumenting in favor of first()

On 9/12/19 7:37 am, Guido van Rossum wrote: def first(it, /, default=None):     it = iter(it)     try:     return next(it)     except StopIteration:     return default Can you provide any insight into why you think it's better for it never to raise an exception, as opposed to rais

[Python-ideas] Re: Suggestion for language addition

On 4/12/19 1:51 pm, Jan Bakuwel wrote: Has it been rejected as PEP or as an idea? There has never been a PEP on it as far as I remember. Probably because it always gets shot down before it gets anywhere near that stage. One of the probable reasons for that is summed up by "preferably only one

[Python-ideas] Re: Sets for easy interning(?)

On 4/12/19 12:53 pm, Soni L. wrote: Okay, sometimes it's also used for that. But the main use-case is for lowering RAM usage for immutable objects. Citation needed. If that's true, why does Python intern names used in code, but not strings in general? I'd say because looking names up in dicts b

[Python-ideas] Re: Suggestion for language addition

On 4/12/19 11:06 am, Jan Bakuwel wrote: If being brought up many times, sounds like a perfect candidate for a PEP to me. The implication is that it has been brought up AND REJECTED multiple times. But you do have a point -- a rejected PEP would provide documentation of the reasons against

[Python-ideas] Re: Sets for easy interning(?)

On 4/12/19 7:26 am, Andrew Barnert via Python-ideas wrote: If you’re using interning for functionality, to distinguish two equal strings that came from different inputs or processes, your code is probably broken. That's not what interning is normally used for. Usually it's to allow test for eq

[Python-ideas] Re: Renaming json.load()

On 1/12/19 5:00 am, Ricky Teachey wrote: Perhaps aliases of objects could be something worth baking into the language itself. We would have to be using aliases a *lot* to make something like this worthwhile. I don't think that's something we should be doing or encouraging. Also, for the use ca

[Python-ideas] Re: Renaming json.load()

On 1/12/19 8:54 am, Andrew Barnert via Python-ideas wrote: but that their intuition for ++ doesn’t make sense for Python while their intuition for += does. Another couple of possible reasons: * There is far less use for ++ in Python. In C, it's extremely common to step through arrays by incre

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 20/11/19 12:14 pm, Andrew Barnert wrote: Off the top of my head, there’s Smalltalk, which I suspect is where Guido got the idea, and ObjC, which got it from Smalltalk, and Swift, which got it from ObjC, I don't think Smalltalk/ObjC do quite the same thing. Sometimes you see a pattern like

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 20/11/19 6:51 am, Andrew Barnert via Python-ideas wrote: A class can bind attributes in __new__ and return a fully initialized object. If that’s perfectly ok, why doesn’t every class do everything in __new__, in which case there’s no reason for __init__ to exist at all? If Python had been de

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 20/11/19 6:50 am, Soni L. wrote: I still feel like opening the file but delaying the exception would be more beneficial That would break anything that tests for the existence of a file by attempting to open it. -- Greg ___ Python-ideas mailing lis

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 19/11/19 3:32 pm, Random832 wrote: For one thing, it'd have to *truly never* fail. Even if open() itself truly never failed, there would still be room to get yourself into trouble. E.g. with (open(get_filename_1()), open(get_filename_2())) as (f1, f2): ... If get_filename_2()

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 19/11/19 4:54 am, Paul Moore wrote: "should only manage one resource" is not actually correct - the whole *point* of something like nested() would be to manage multiple resources I think a better way to say it would be that the __enter__ method should be atomic -- it should either acquire al

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 18/11/19 8:17 am, Oscar Benjamin wrote: PEP 343 gives the example of "opened" which doesn't have this problem https://www.python.org/dev/peps/pep-0343/#examples but apparently that didn't make it to the final release of 2.5 (I guess that's what Greg is referring to). Probably. I may also ha

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 17/11/19 10:34 am, Andrew Barnert wrote: On Nov 16, 2019, at 13:13, Greg Ewing wrote: It might be better to keep it as purely a context manager, and not load it down with any other baggage. Doesn’t `closing` already take care of that (and other things besides files, too)? No, because

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 17/11/19 4:54 am, Ricky Teachey wrote: I think it'd be at least as confusing as the current situation. It might be better to keep it as purely a context manager, and not load it down with any other baggage. I wouldn't try to make it remember the current directory. Like a generator expr

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 16/11/19 4:30 am, Joao S. O. Bueno wrote: Just add __enter__ and __exit__ to tuples themselves! That wouldn't give the same result, though. E.g. if you're using open(), a failure to open a later file in the list should trigger the __exit__ of earlier ones. But using a tuple, all the files ha

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

Another idea -- use semicolons to separate "as" clauses in a with statement, and allow newlines after them. with open(name1) as f1; open(name2) as f2; open(name3) as f3: ... -- Greg ___ Python-ideas mailing list -- pytho

[Python-ideas] Re: Adding fixed-point decimals as an option to replace floating-point

On 15/11/19 7:39 am, Chris Angelico wrote: But in your source code, if you type 4.1, you are asking for the floating-point value The idea of providing decimal literals comes up from time to time, but so far it hasn't gotten anywhere. The problem is that it would make the core interpreter depend

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On 15/11/19 5:54 am, Paul Moore wrote: On Thu, 14 Nov 2019 at 16:42, Random832 wrote: So, uh... what if we didn't need backslashes for statements that begin with a keyword and end with a colon? Not sure about ambiguity, but it would require a much more powerful parser than Python currently h

[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation

On Nov 13, 2019, at 10:26, gabriel.ka...@mail.de wrote: with ( open(fname1) as f1, open(fname2) as f2, open(fname3) as f3, open(fname4) as f4 ): Maybe you should be able to do something like with: open(fname1) as f1: open(fname2) as f2: open(fname3)

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

On 12/11/19 4:10 am, Random832 wrote: well *of course* the goal was not to slow down actual production of text, but this does not imply the method by which "speeding up by preventing jams" was to be achieved was not by slowing down the physical process of pressing keys. That wasn't the method,

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

On 11/11/19, 12:41 PM, Richard Damon wrote: it was DESIGNED to be inefficient (that was one of its design goals, to slow typesetters down to be slower than the machine they were working on). This is most likely a myth, see https://en.wikipedia.org/wiki/QWERTY -- Greg __

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

Abe Dillon wrote: I don't disagree that infix notation is more readable because humans have trouble balancing brackets visually. I don't think it's just about brackets, it's more about keeping related things together. An expression such as b**2 - 4*a*c can be written unambiguously without

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

Abe Dillon wrote: Why not use a more consistent notation like add(x, y) instead of x + y when we know addition is a function and all other functions (usually) follow the f(x, y) notation? Because math is old. No, it's because infix notation is *more readable* than function notation when formu

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

Mike Miller wrote: There is: U+2B32 ⬲ LEFT ARROW WITH CIRCLED PLUS But there would need to be more. At this point you're creating a mini-language by combining symbols, which the OP seems to be against, since he describes things like ":=" and "<-" condescendingly as "ascii soup". -

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

Andrew Barnert via Python-ideas wrote: On Nov 6, 2019, at 08:59, Chris Angelico wrote: No, because "x <-- y" is already legal syntax You could handle that by making the grammar more complicated. Or just have the tokeniser treat "<--" as a single token, the same way that it treats "<=" as a

[Python-ideas] Re: Python should take a lesson from APL: Walrus operator not needed

martin_05--- via Python-ideas wrote: The transition to only allowing "←" (and perhaps other symbols) could be planned for Python 4. Requiring non-ascii characters in the core language would be a very big change, especially for something as ubiquitous as assignment. Much more justification than

[Python-ideas] Re: foo.setParseAction(lambda a, b, c: raise FuckPython(":("))

Random832 wrote: I have, occasionally, wanted to be able to resume a function after handling an exception ... In a hypothetical implementation that would allow such a thing, having the raise return a value in such a scenario might not be unreasonable. For that to be of any use, the code that ra

[Python-ideas] Re: foo.setParseAction(lambda a, b, c: raise ForkPython(":("))

Andrew Barnert via Python-ideas wrote: I don’t know what NIY means here, Not Invented Yet. It's used by the time machine to prevent temporal paradoxes due to anachronistic use of technology, for example if you try to use van Finkelstein's algorithm for solving the halting problem before 2186...

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

Andrew Barnert wrote: A function to recursively flatten a nested list should only work on lists; it should stop on a string, but it should also stop on a namedtuple or a 2x2 ndarray or a dict. True, but then it still makes no difference whether iterating over a string gives more strings or some

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

Christopher Barker wrote: wouldn't it? once you got to an object that couldn't be iterated, you'd know you had an atomic value. I'm thinking of things like a function to recursively flatten a nested list. You probably want it to stop when it gets to a string, and not flatten the string into a l

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

David Mertz wrote: But it's hard to think of an occasion when I would have needed to enter a space by code point rather than just quoted. If you ever desperately need to enter some Python code using a keyboard with a broken space key, you might be glad to have the option! -- eval('\x70\x72\x6

[Python-ideas] Re: Python 4000: Have stringlike objects provide sequence views rather than being sequences

Christopher Barker wrote: I've always wondered how disruptive it would be to add a char type I'm not sure if it would help much. Usually the problem with strings being sequences of strings lies in the fact that they're sequences at all. Code that operates generically on nested sequences often h

[Python-ideas] Re: Percent notation for array and string literals, similar to Perl, Ruby

Andrew Barnert via Python-ideas wrote: Someone earlier in this thread said we could optimize calling split on a string literal, just as we can and do optimize iterating over a list literal in a for statement. The counter argument—which I thought you were adding onto—is that this would be bad bec

[Python-ideas] Re: Add collections.abc.Struct as virtual base class of namedtuple classes and dataclass-decorated classes.

Andrew Barnert via Python-ideas wrote: I think what he’s looking for is the adjective that goes with the quasi-word “struct” as used in C, and in Python’s ctypes and C API. The type name “Struct” isn’t bad here, but the adjective “structural” has to many other connotations. Structy type? Struct

[Python-ideas] Re: Resolve append/add API inconsistency between set and list

Steve Jorgensen wrote: IMO, the problem with the "you can create your own" solution is that this is such a common thing Can you provide some examples of use cases from the wild? If it's as common as you say, this should be easy to do. -- Greg ___ Pyt

[Python-ideas] Re: Add Subscriptable ABC

Chris Angelico wrote: Python's base object has a lot of extremely useful functionality, Yes, I agree that all that stuff is useful. I'm not saying that Python's object type shouldn't have it, just that it's incompatible with having a strict type system. -- Greg

[Python-ideas] Re: Add Subscriptable ABC

Chris Angelico wrote: The question then would be: why is object() not hashable? It's not hashable because it's supposed to be the ultimate base type for all other objects, and not every object is hashable. It only seems odd if you're used to the idea that you get a bunch of default behaviours

[Python-ideas] Re: Add Subscriptable ABC

Chris Angelico wrote: The hashability issue is a logical consequence of accepting that the above violations are reasonable and practically useful. A more principled way to handle this wouild be for object not to be hashable, and have another base type for hashable objects. Hashable would then b

[Python-ideas] Re: Add Subscriptable ABC

On Tue, Oct 1, 2019 at 8:48 AM Ben Rudiak-Gould > wrote: Is it? Subtyping in type theory satisfies some axioms, one of which is transitivity. The addition of the ABCs broke transitivity: >>> issubclass(list, object) True >>> issubclass(

[Python-ideas] Re: Add a slot for "keys" in tp_as_mapping

Serhiy Storchaka wrote: PyDict_Merge() is called every time when you have a call like `f(a=1, **kw)` So would not be worth to add slots for keys (and maybe for values and items) to the tp_as_mapping structure? Only if looking up those methods is taking a substantial proportion of time. Measu

[Python-ideas] Re: Simpler syntax for async generators

George Fischhof wrote: With this syntax the use / programmer do not have to write async def, nor await, because after the yield the await should come automatically. I don't see how you can eliminate the await in your example generator. Can you show us how it would look in its entirety under you

[Python-ideas] Re: PEP-603: Adding a frozenmap type to collections

Yury Selivanov wrote: A *persistent data structure* is defined as a data structure that preserves the previous version of the data when the data is modified. Such data structures are effectively *immutable*, as operations on them do not update the structure in-place, but instead always yield a ne

[Python-ideas] Re: Automatic translation of Python to assembly language

Mark @pysoniq wrote: Translating a single language directly to assembly gives the best optimizations because most of the commonly used compilers, like GCC, LLVM and Clang, use an intermediate language intended for many languages, and compiles to a number of target architectures. To take advanta

[Python-ideas] Re: Automatic translation of Python to assembly language

Mark @pysoniq wrote: It would be most helpful if you could provide an example of how they contain "few technical details." I ask because I was afraid they were too technical! Your blog posts about optimisation mostly talk about standard things that have been known for decades. E.g. "keep vari

[Python-ideas] Re: Automatic translation of Python to assembly language

Antoine Pitrou wrote: Also, performance numbers without a detailed description of what's exactly measured (including code for the benchmark) are useless. Benchmarks are great -- you can find one that proves whatever you want! -- Greg ___ Python-ideas

[Python-ideas] Re: Automatic translation of Python to assembly language

Mark @pysoniq wrote: Finally, with both of these, you need to do more than just point and click. I don't want to have to point and click. I want a command that I can put into my Makefile. Can I do that with your product? -- Greg ___ Python-ideas ma

[Python-ideas] Re: Custom string prefixes

Steven D'Aprano wrote: I don't think that stpa...@gmail.com means that the user literally assigns to locals() themselves. I read his proposal as having the compiler automatical mangle the names in some way, similar to name mangling inside classes. Yes, but at some point you have to define a f

<    1   2   3   4   5   6   7   8   9   >