Re: [Python-ideas] Fwd: Define a method or function attribute outside of a class with the dot operator

Chris Angelico wrote: Which is why these proposals always seem to gravitate to "anything you can assign to", There might be some parsing difficulties with that, e.g. def foo(x)[5](y, z): ... That should be acceptable, because foo(x)[5] is something assignable, but foo(x) looks like

Re: [Python-ideas] Let’s make escaping in f-literals impossible

Chris Angelico wrote: f"This is a number: {13:0\u07c4}" If I understand correctly, the proposal intends to make it easier for a syntax hightlighter to treat f"This is a number: {foo[42]:0\u07c4}" as f"This is a number: {foo[42] :0\u07c4}" ----

Re: [Python-ideas] SI scale factors in Python

Chris Angelico wrote: If units are retained, what you have is no longer a simple number, but a value with a unit, and is a quite different beast. (For instance, addition would have to cope with unit mismatches (probably by throwing an error), and multiplication would have to combine the units

Re: [Python-ideas] New Python syntax for continuing definitions for existing classes

Chris Angelico wrote: Yes. You could tweak that by looking at cls.__module__ and grab it from sys.modules, but I kept the example simple. However, I would NOT use the standard name lookup mechanism. Most classes in builtins won't let you monkeypatch them anyway, so I'm not sure it's worth the

Re: [Python-ideas] async objects

Paul Moore wrote: I don't know *that* much about Erlang, but Python's model is that of a single shared address space with (potentially multiple) threads of code running, having access to that address space. I don't know much about Erlang either, but from what I gather, it's a functional

Re: [Python-ideas] async objects

Nathaniel Smith wrote: It wasn't that we created these keywords to solve some implementation problem and then inflicted them on users. I disagree -- looking at the history of how we ended up with async/await, it looks to me like this is exactly what *did* happen. First we had generators. Then

Re: [Python-ideas] async objects

Nathaniel Smith wrote: The core distinguishing feature between async/await and gevent is the visibility of suspension points, so it might as well be the case that async/await is designed for exactly those people who want visible suspension points. They're not quite independent axes, though.

Re: [Python-ideas] async objects

Nick Coghlan wrote: When a language usage pattern is supported for that long, but folks still don't grok how it might benefit them, you have a UX problem, and one of the ways to address it is to take the existing pattern and give it dedicated syntax, which is exactly what PEP 492 did. However,

Re: [Python-ideas] async objects

Yury Selivanov wrote: To start, no matter how exactly you want to approach this, it would require us to do a *complete rewrite* of CPython internals. This is so complex that we wouldn't be able to even estimate how long it would take us. You could ask the author of Stackless -- he did

Re: [Python-ideas] Overloading operators for testing

Arek Bulski wrote: def __glob_eq__(a,b): if not a == b: raise FoundInequalityError(a,b) return True assert obj1 == obj2 #<-- using eq above How would you ensure that this overriding only applied in the places you want it? You don't want to change the meaning of == in the code

Re: [Python-ideas] Delay evaluation of annotations

אלעזר wrote: it feels like a placeholder for this meaning would be better. E.g.: class A: def __add__(self, other: CLS) -> CLS: ... That's fine for a class that refers to itself, but what about classes that refer to each other? This only addresses a small part of the

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

אלעזר wrote: @partial(partial, partial(partial, partial)) def add(a, b, c): return a + b + c For large numbers of arguments, it's much clearer if you write it this way: >>> from functools import partial as badger, partial as mushroom >>> @badger(badger, badger(badger, badger(badger,

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

Terry Reedy wrote: In the default mode with user code executed in a separate no-window process, there is currently no way for the child process to know the current size of Shell's tk text window in the parent process. On unix it should be possible to let the child know if it's connected

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

Steven D'Aprano wrote: Obviously if I write 1.1K then I'm expecting a float. Why is it obvious that you're expecting a float and not a decimal in that case? The SI units are all decimal, and I think if we support these, we should insist that K == 1000, not 1024. For binary scale factors,

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

Erik Bray wrote: Then following my own logic it would be desirable to also allow the nested for loop syntax of list comprehensions outside them as well. The only use for such a syntax would be to put an inadvisable amount of stuff on one line. When describing a procedural series of steps, the

Re: [Python-ideas] async objects

Yann Kaiser wrote: The way I see it, the great thing about async/await as opposed to threading is that it is explicit about when execution will "take a break" from your function or resume into it. Another thing is that async/await tasks are very lightweight compared to OS threads, so you can

Re: [Python-ideas] Method signature syntactic sugar (especially for dunder methods)

Another advantage of dunder method names is that you can google them. Someone coming across a method called "__foo__" can easily find documentation about it, but it's not so easy to do that for special syntax. -- Greg ___ Python-ideas mailing list

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

Eric V. Smith wrote: I'd rather see the ability to have unevaluated expressions, that can later be evaluated. I'll use backticks here to mean: "parse, but do not execute the enclosed code". This produces an object that can later be evaluated with a new builtin I'll call "evaluate_now". So

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

C Anthony Risinger wrote: On Nov 6, 2016 7:32 PM, "Nathaniel Smith" > wrote: > > log.debug!(f"Message: {message_object!r}") Would the log.debug implementation need to fetch the context to evaluate the delayed expression Not if it expands to

Re: [Python-ideas] Python multi-dimensional array constructor

Todd wrote: ||| is the delimiter for the third dimension, || is the delimiter for the second dimension. This seems a bit inconsistent. It appears the rule is "n vertical bars is the delimiter for the nth dimension". By that rule, the delimiter for the first dimension should be a single

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

Steven D'Aprano wrote: So why would yield *t give us this? yield a; yield b; yield c By analogy with the function call syntax, it should mean: yield (a, b, c) This is a false analogy, because yield is not a function. However, consider the following spelling: l = [from f(t)

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: if "\u1230" <= c <= "\u123f": and: o = ord (c) if 100 <= o <= 150: Note that, if need be, you could also write that as if 0x64 <= o <= 0x96: So yours is a valid code but for me its freaky, and surely I stick to the second variant. The thing is, where did you get

Re: [Python-ideas] Proposal for default character representation

Steven D'Aprano wrote: That's because some sequence of characters is being wrongly interpreted as an emoticon by the client software. The only thing wrong here is that the client software is trying to interpret the emoticons. Emoticons are for *humans* to interpret, not software. Subtlety and

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

Steven D'Aprano wrote: t = (1, 2, 3) iterable = [t] [*t for t in iterable] If you do the same manual replacement, you get: [1, 2, 3 for t in iterable] Um, no, you need to also *remove the for loop*, otherwise you get complete nonsense, whether * is used or not. Let's try a

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

Martti Kühne wrote: You brush over the fact that *t is not limited to a replacement by a comma-separated sequence of items from t, but *t is actually a replacement by that comma-separated sequence of items from t INTO an external context. Indeed. In situations where there isn't any context for

Re: [Python-ideas] Order of loops in list comprehension

C Anthony Risinger wrote: Erlang/Elixir (sorry after 6 years python this is what I do now!) does it the same way as python: >>> [{X, Y} || X <- [1,2,3], Y <- [a,b]]. [{1,a},{1,b},{2,a},{2,b},{3,a},{3,b}] Here X is the outer loop. I think the confusion stems from doing it both ways at the

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

There was a discussion about this a while ago. From what I remember, the conclusion reached was that there are too many degrees of freedom to be able to express reduction operations in a comprehension-like way that's any clearer than just using reduce() or writing out the appropriate loops. --

Re: [Python-ideas] Order of loops in list comprehension

Alexander Heger wrote: For me the current behaviour does not seem unreasonable as it resembles the order in which you write out loops outside a comprehension That's true, but the main reason for having comprehensions syntax in the first place is so that it can be read declaratively -- as a

[Python-ideas] Order of loops in list comprehension

Random832 wrote: For me, it's the fact that: [[a for a in b] for b in ['uvw', 'xyz']] == [['u', 'v', 'w'], ['x', 'y', 'z']] which makes me want to write: [a for a in b for b in ['uvw', 'xyz']] You're not alone! Lately I've been becoming convinced that this is the way we should have done it

Re: [Python-ideas] Technical possibilities for a syntax [was: Reverse assignment operators ...]

David Mertz wrote: The most notable example of something that is "weird" and "a stupid idea" is NumPy... and *everything* in the Scientific Python ecosystem thereby. Also the built-in list type. Guido clearly disagrees about the stupidity level of this idea! -- Greg

Re: [Python-ideas] Generator-based context managers can't skip __exit__

Ram Rachum wrote: 1. I'm making a program that lets people lease machines. They can issue a command to lease 7 machines. ... If everything goes fine, I do pop_all on the exit stack so it doesn't get exited and the machines stay leased, Seems to me that would be done more easily and clearly

Re: [Python-ideas] Null coalescing operator

Zero Piraeus writes: If I write something like obj.attr, the failure mode I care about is that obj has no attribute attr, rather than that obj is specifically None (or one of a defined group of somewhat Nonelike objects). Clearly, in such a circumstance, obj is not what I

Re: [Python-ideas] Null coalescing operator

Steven D'Aprano wrote: Or even the subject line of this email thread??? Sorry, crossed over discussions. But I think it's also true that the null-coalescing idea is for cases where it's not an error for something to be None. -- Greg ___

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

Steven D'Aprano wrote: py> def gen(): ... for t in [(1, 'a'), (2, 'b'), (3, 'c')]: ... yield *t File "", line 3 yield *t ^ SyntaxError: invalid syntax Even if it was allowed, what would it mean? It could only mean "unpack the sequence t, and collect the values

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

David Mertz wrote: it would always be "Here's a Python wart to look out for if you see it in other code... you should not ever use it yourself." Do you currently tell them the same thing about the use of * in a list display? -- Greg ___ Python-ideas

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

Random832 wrote: [*map(math.exp, t) for t in [(1, 2), (3, 4)]] [*(math.exp(x) for x in t) for t in [(1, 2), (3, 4)]] Or more simply, [math.exp(x) for t in [(1, 2), (3, 4)] for x in t] I think this brings out an important point. While it would be nice to allow * unpacking in

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

Neil Girdhar wrote: At the end of this discussion it might be good to get a tally of how many people think the proposal is reasonable and logical. I think it's reasonable and logical. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

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

Sjoerd Job Postmus wrote: I think the suggested spelling (`*`) is the confusing part. If it were to be spelled `from ` instead, it would be less confusing. Are you suggesting this spelling just for generator comprehensions, or for list comprehensions as well? What about dict comprehensions?

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

Paul Moore wrote: PS I can counter a suggestion of using *f(t) rather than from f(t) in the above, by saying that it adds yet another meaning to the already heavily overloaded * symbol. We've *already* given it that meaning in non-comprehension list displays, though, so we're not really adding

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

Paul Moore wrote: 3. *fn(x) isn't an expression, and yet it *looks* like it should be ... > To me, that suggests it would be hard to teach. It's not an expression in any of the other places it's used, either. Is it hard to to teach in those cases as well? -- Greg

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: Did you see much code written with hex literals? From /usr/include/sys/fcntl.h: /* * File status flags: these are used by open(2), fcntl(2). * They are also used (indirectly) in the kernel file structure f_flags, * which is a superset of the open/fcntl flags. Open flags

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: I am not against base-16 itself in the first place, but rather against the character set which is simply visually inconsistent and not readable. Now you're talking about inventing new characters, or at least new glyphs for existing ones, and persuading everyone to use them.

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: Ok, but if I write a string filtering in Python for example then obviously I use decimal everywhere to compare index ranges, etc. so what is the use for me of that label? Just redundant conversions back and forth. I'm not sure what you mean by that. If by "index ranges"

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: Eee how would I find if the character lies in certain range? >>> c = "\u1235" >>> if "\u1230" <= c <= "\u123f": ... print("Boo!") ... Boo! -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Optimizing list.sort() by checking type in advance

Elliot Gorokhovsky wrote: if the list is all floats, just copy all the floats into a seperate array, use the standard library quicksort, and then construct a sorted PyObject* array. My question would be whether sorting list of just floats (or where the keys are just floats) is common enough

Re: [Python-ideas] [Python-Dev] Optimizing list.sort() by checking type in advance

Elliot Gorokhovsky wrote: I will be able to rule that out when I implement this as a patch instead of an extension module and test my own build. You could test it against a locally built Python without having to go that far. -- Greg ___

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: Those things cannot be easiliy measured, if at all, If you can't measure something, you can't be sure it exists at all. > In my case I am looking at what I've achieved during years of my work on it and indeed there some interesting things there. Have you *measured*

Re: [Python-ideas] INSANE FLOAT PERFORMANCE!!!

Paul Moore wrote: What I'm *not* quite clear on is why Python 3's change to reject comparisons between unrelated types makes this optimisation possible. I think the idea was that it's likely to be *useful* a higher proportion of the time, because Python 3 programmers have to be careful that

Re: [Python-ideas] Proposal for default character representation

Mikhail V wrote: And decimal is objectively way more readable than hex standard character set, regardless of how strong your habits are. That depends on what you're trying to read from it. I can look at a hex number and instantly get a mental picture of the bit pattern it represents. I can't

Re: [Python-ideas] Things that won't change (proposed PEP)

Stephen J. Turnbull wrote: Greg Ewing writes: > FCLAP - Frequent Criticisms Levelled Against Python It reads better if you don't insist that they be frequent. (This may only play in America.) Criticisms Frequently Levelled Against Python would be another possibility... -- G

Re: [Python-ideas] Things that won't change (proposed PEP)

Chris Barker wrote: Frequently Asked Criticisms Doesn't quite make sense -- one doesn't "ask" criticisms. How about: FCLAP - Frequent Criticisms Levelled Against Python -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Proposal: Query language extension to Python (PythonQL)

Terry Reedy wrote: PQL expressions should be quoted and passed to the dsl processor, as done with SQL and other DSLs. But embedding one language as quoted strings inside another is a horrible way to program. I really like the idea of a data manipulation language that is seamlessly integrated

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

Paul Moore wrote: Is this a well-defined idea? ... There's nothing describing how multiple values would be stored in the same file/transmitted in the same stream. I think this is something that's outside the scope of the spec. But since the grammar makes it clear when you've reached the end

Re: [Python-ideas] Thread-safe generators

Serhiy Storchaka wrote: but should not affect performance since locking is used only when you faced with a generator running in other thread. I don't think that's true, because the first thread to use a generator has to lock it as well. And even if there is only one thread in existence when

Re: [Python-ideas] Binary arithmetic does not always call subclasses first

Stephan Hoyer wrote: In practice, CPython requires that the right operand defines a different method before it defers to it. I'm not sure exactly what the rationale for this behaviour is, but it's probably something along the lines that the left method should already know how to deal with that

Re: [Python-ideas] Thread-safe generators

Nick Coghlan wrote: but at the cost of changing the nature of the workload in a given thread, and hence messing with the working set of objects it has active. Does the working set of an individual thread matter to anything? Or even an individual process? As far as the virtual memory system is

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

On 7/30/2017 2:57 PM, Markus Meskanen wrote: >> How often do you get the keywords in a random order? The x, y, z example being used here is a bit deceptive, because the fields have an obvious natural order. That isn't always going to be the case. -- Greg

Re: [Python-ideas] namedtuple with ordereddict

Jim J. Jewett wrote: is there any reason not to simply define it as a view on a dict, or at least as a limited proxy to one? Some valuable characteristics of namedtuples as they are now: * Instances are very lightweight * Access by index is fast * Can be used as a dict key All of those would

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

Nick Coghlan wrote: New builtin: ntuple(x=1, y=0) Do we really want this to be a tuple, with ordered fields? If so, what determines the order? If it's the order of the keyword arguments, this means that ntuple(x=1, y=0) and ntuple(y=0, x=1) would give objects with different

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

Nick Coghlan wrote: The same applies to the ntuple concept, expect there it's the fact that it's a *tuple* that conveys the "order matters" expectation. That assumes there's a requirement that it be a tuple in the first place. I don't see that requirement in the use cases suggested here so

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

Nathaniel Smith wrote: So what should this async_signals_masked state do when we yield out from under it? If it's a thread-local, then the masking state will "leak" into other async function callstacks (or similar for regular generators), which is pretty bad. But it can't be just frame-local

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

Erik Bray wrote: My question would be to make that a language-level requirement of the context manager protocol, or just something CPython does... I think it should be a language-level requirement, otherwise it's not much use. Note that it's different from some existing CPython-only behaviour

Re: [Python-ideas] Arguments to exceptions

Paul Moore wrote: As noted, I disagree that people are not passing components because str(e) displays them the way it does. But we're both just guessing at people's motivations, so there's little point in speculating. I've no doubt that the current situation encourages people to be lazy -- I

Re: [Python-ideas] Arguments to exceptions

Terry Reedy wrote: Attaching a *constant* string is very fast, to the consternation of people who would like the index reported. Seems to me that storing the index as an attribute would help with this. It shouldn't be much slower than storing a constant string, and formatting the message would

Re: [Python-ideas] Runtime types vs static types

Steven D'Aprano wrote: I think that we should assume that def func(x:Spam()): ... will always look up and call Spam when the function is defined. Personally I think we should be moving towards not even guaranteeing that. Then we would have a chance of some day ending up with a static

Re: [Python-ideas] Runtime types vs static types

Steven D'Aprano wrote: isinstance([], List[int]) isinstance([], List[str]) How can a single value be an instance of two mutually incompatible types? I don't think there's any contradiction there, because the compatibility rules are different for static and runtime types. Statically,

Re: [Python-ideas] Arguments to exceptions

Terry Reedy wrote: It occurs to me that if the exception object has no reference to any python object, then all would be identical and only one cached instance should be needed. I don't think that's true now that exceptions get tracebacks attached to them. -- Greg

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

Nathaniel Smith wrote: A magic (implemented in C) decorator like @async_signals_masked I think would be the simplest way to do this extension. I don't have a good feeling about that approach. While implementing the decorator in C might be good enough in CPython to ensure no window of

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

Erik Bray wrote: At this point a potentially waiting SIGINT is handled, resulting in KeyboardInterrupt being raised while inside the with statement's suite, and finally block, and hence Lock.__exit__ are entered. Seems to me this is the behaviour you *want* in this case, otherwise the lock can

Re: [Python-ideas] Arguments to exceptions

Paul Moore wrote: But no-one manually raises NameError, so Ken's example wouldn't work with "real" NameErrors. Part of his suggestion was that core and stdlib code would move towards using attributes. The NameError example makes sense in that context. -- Greg

Re: [Python-ideas] Add an option for delimiters in bytes.hex()

Steven D'Aprano wrote: I've also been thinking about generalisations such as grouping lines into paragraphs, words into lines, etc. You're probably going to want considerably more complicated algorithms for that kind of thing, though. Let's keep it simple. -- Greg

Re: [Python-ideas] Dictionary destructing and unpacking.

C Anthony Risinger wrote: Incredibly useful and intuitive, and for me again, way more generally applicable than iterable unpacking. Maps are ubiquitous. Maps with a known, fixed set of keys are relatively uncommon in Python, though. Such an object is more likely to be an object with named

Re: [Python-ideas] Dictionary destructing and unpacking.

One existing way to do this: a, b, c = (mydict[k] for k in ('a', 'b', 'c')) -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Improving Catching Exceptions

Cameron Simpson wrote: try: foo(bah[5]) except IndexError as e: ... infer that there is no bah[5] ... One can easily want, instead, some kind of "shallow except", which would catch exceptions only if they were directly raised from the surface code; The problem I see

Re: [Python-ideas] A suggestion for a do...while loop

Chris Angelico wrote: And for completeness, "while not throw:". And just to completely confuse everyone, "while not pass". :-) -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code

Re: [Python-ideas] Improving Catching Exceptions

Steven D'Aprano wrote: class X: def __getitem__(self, n): if n < 0: n += len(self) if not 0 <= n < len(self): raise IndexError ... class Y: def __getitem__(self, n): self._validate(n) ... def _validate(self, n): if n <

Re: [Python-ideas] + operator on generators

David Mertz wrote: I just wish I could think of a good character that doesn't have some very different meaning in other well-known contexts (even among iterables). (a;b) Should be unambiguous as long as the parens are required. -- Greg ___

Re: [Python-ideas] π = math.pi

Victor Stinner wrote: How do you write π (pi) with a keyboard on Windows, Linux or macOS? On a Mac, π is Option-p and ∑ is Option-w. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas

Re: [Python-ideas] Security: remove "." from sys.path?

Victor Stinner wrote: You are right, it's the script directory that it added to sys.path and I would like to know if it would be possible to change that? Why do you want to change it? -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] π = math.pi

Steven D'Aprano wrote: There's not much, if any, benefit to writing: ∫(expression, lower_limit, upper_limit, name) More generally, there's a kind of culture clash between mathematical notation and programming notation. Mathematical notation tends to almost exclusively use single-character

Re: [Python-ideas] Security: remove "." from sys.path?

Is this really much of a security issue? Seems to me that for someone to exploit it, they would have to inject a malicious .py file alongside one of my script files. If they can do that, they can probably do all kinds of bad things directly. -- Greg

Re: [Python-ideas] Security: remove "." from sys.path?

Stephan Houben wrote: What about just adding the -I (isolated mode) flag to the #! line of installed scripts? Not all unix systems support passing extra arguments on a #! line. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] π = math.pi

Mikhail V wrote: I find actually symbols ≤ ≥ (inclusive comparison) nice. Yes, there are a few symbols it would be nice to have. A proper ≠ symbol would have avoided the wars between <> and !=. :-) -- Greg ___ Python-ideas mailing list

Re: [Python-ideas] Security: remove "." from sys.path?

Soni L. wrote: How about `import self.thing` (where "self" implies same dir as the current .py That wouldn't provide quite the same functionality, since currently a module alongside the main py file can be imported from anywhere, including .py files inside a package. Also I think it would be

Re: [Python-ideas] Run length encoding

In my experience, RLE isn't something you often find on its own. Usually it's used as part of some compression scheme that also has ways of encoding verbatim runs of data and maybe other things. So I'm skeptical that it can be usefully provided as a library function. It seems more like a design

Re: [Python-ideas] Add an option for delimiters in bytes.hex()

For a name, I think "group" would be better than "chunk". We talk about grouping the digits of a number, not chunking them. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of

Re: [Python-ideas] Add a .chunks() method to sequences

Victor Stinner wrote: I prefer str.join() approach: write a single chunks() function which takes a sequence, instead of modifying all sequence types around the world ;-) Even if a general sequence-chunking function is thought useful, it might be worth providing a special-purpose one as a

Re: [Python-ideas] Hexadecimal floating literals

Lucas Wiman wrote: It is inconsistent that you can write hexadecimal integers but not floating point numbers. Consistency in syntax is /fewer/ things to learn, not more. You still need to learn the details of the hex syntax for floats, though. It's not obvious e.g. that you need to use "p"

Re: [Python-ideas] Why not picoseconds?

Stephan Houben wrote: Do we realize that at this level of accuracy, relativistic time dilatation due to continental drift starts to matter? Probably also want an accurate GPS position for your computer so that variations in the local gravitational field can be taken into account. -- Greg

Re: [Python-ideas] Why not picoseconds?

Stephan Houben wrote: Interestingly, that 2.2e-16 pretty much aligns with the accuracy of the cesium atomic clocks which are currently used to *define* the second. So we move to this new API, we should provide our own definition of the second, since those rough SI seconds are just too imprecise

Re: [Python-ideas] Membership of infinite iterators

Nick Coghlan wrote: since breaking up the current single level loops as nested loops would be a pre-requisite for allowing these APIs to check for signals while they're running while keeping the per-iteration overhead low Is there really much overhead? Isn't it just checking a flag? -- Greg

Re: [Python-ideas] How assignment should work with generators?

Chris Angelico wrote: x, y, * = iter # unpack into nothing I'm surprised this isn't already allowed. It seems like the One Obvious Way to me. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] How assignment should work with generators?

Chris Angelico wrote: The problem is that it depends on internal whitespace to distinguish it from augmented assignment; Ah, didn't spot that. I guess the ellipsis is the next best thing then. An alternative would be to require parens: (x, y, *) = z -- Greg

Re: [Python-ideas] Adding a thin wrapper class around the functions in stdlib.heapq

Grant Jenks wrote: The heap algorithm is exposed through a high-level functional interface so that you can take advantage of duck-typing. This would also be true of a HeapWrapper class that wrapped an existing sequence. There's a difference between the heap functions and sorted(). The latter

Re: [Python-ideas] How assignment should work with generators?

C Anthony Risinger wrote: `a, b, ...` to me says "pull out a and b and throw away the rest"... > The mere presence of more characters (...) implies something else will *happen* to the remaining items, not that they will be skipped. It seems that many people think about unpacking rather

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

Nick Coghlan wrote: What about more English-like syntax: X or else Y The problem with constructs like this is that they look like they should mean the same thing as "X or Y". How about: x otherwise y It looks different enough from "or" that you're not going to accidentally read it

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

Stephan Houben wrote: X or else Y Sounds like a Python dialect for Mafia use. customer.repay(loan) or else apply(baseball_bat, customer.kneecaps) -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] How assignment should work with generators?

C Anthony Risinger wrote: Is __len__ a viable option now that __length_hint__ has been identified for hints? No, I misremembered that feature, sorry. But I still don't like the idea of changing behaviour depending on whether the RHS "looks like" an iterator or not. I'm not sure how to

Re: [Python-ideas] [Python-Dev] What's the status of PEP 505: None-aware operators?

Stephan Houben wrote: A if is not None else C Reading that gives me the feeling that something in my brain has slipped a tooth. It would read better with some kind of pronoun in there: A if it is not None else C Hypercard's Hypertalk had a special variable "it" that worked sort of like

Re: [Python-ideas] How assignment should work with generators?

Brendan Barnwell wrote: That's an interesting analysis, but I don't think your view is really the right one. It *is* unpacking a suitcase, it's just that *if necessary* the suitcase is constructed just in time for you to unpack it. I don't think that's right. An iterator created from a

  1   2   3   4   5   6   7   8   9   >