Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

Steven D'Aprano wrote: The iterator protocol is that iterators must: - have a __next__ method; - have an __iter__ method which returns self; and the test for an iterator is: obj is iter(obj) By that test, it identifies as a sequence, as does testing it for the presence of __len__: >>>

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

Steven D'Aprano wrote: I suggest we provide a separate mapview() type that offers only the lazy sequence API, without trying to be an iterator at the same time. Then we would be back to the bad old days of having two functions that do almost exactly the same thing. My suggestion was made in

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

Steven D'Aprano wrote: Perhaps more like the principle of most astonishment: the object changes from sized to unsized even if you don't modify its value or its type, but merely if you look at it the wrong way: Yes, but keep in mind the purpose of the whole thing is to provide a sequence

Re: [Python-ideas] Suggested MapView object (Re: __len__() for map())

Chris Angelico wrote: I can't help thinking that it will be extremely surprising to have the length remain the same while the items get consumed. That can be fixed. The following version raises an exception if you try to find the length after having used it as an iterator. (I also fixed a bug

[Python-ideas] Suggested MapView object (Re: __len__() for map())

Steven D'Aprano wrote: For backwards compatibilty reasons, we can't just make map() work like this, because that's a change in behaviour. Actually, I think it's possible to get the best of both worlds. Consider this: from operator import itemgetter class MapView: def __init__(self,

Re: [Python-ideas] __len__() for map()

Adam Johnson wrote: def takewhile_lessthan4(x): if x < 4: return x raise StopIteration tuple(map(takewhile_lessthan4, range(9))) # (0, 1, 2, 3) I really don't understand why this is true, under 'normal' usage, map shouldn't have any reason to silently swallow a StopIteration

Re: [Python-ideas] __len__() for map()

E. Madison Bray wrote: So I might want to check: finite_definite = True for it in my_map.iters: try: len(it) except TypeError: finite_definite = False if finite_definite: my_seq = list(my_map) else: # some other algorithm If map is being passed into your

Re: [Python-ideas] __len__() for map()

E. Madison Bray wrote: I still believe that the actual proposal of making the arguments to a map(...) call accessible from Python as attributes of the map object (ditto filter, zip, etc.) is useful in its own right, rather than just having this completely opaque iterator. But it will only help

Re: [Python-ideas] __len__() for map()

E. Madison Bray wrote: if I have a function that used to take, say, a list as an argument, and it receives a `map` object, I now have to be able to deal with map()s, and I may have checks I want to perform on the underlying iterables before, say, I try to iterate over the `map`. This sounds

Re: [Python-ideas] Serialization of CSV vs. JSON

David Shawley wrote: I'm +1 on adding support for serializing datetime.date and datetime.datetime *but* I'm -1 on automatically deserializing anything that looks like a ISO-8601 in json.load*. The asymmetry is the only thing that kept me from bringing this up previously. This asymmetry

Re: [Python-ideas] Implementing a set of operation (+, /, - *) on dict consistent with linearAlgebrae

julien tayon wrote: like the + of [] could be the + of "RecordAlgebrae" If you're proposing to change the behaviour of '+' on the built-in list type, that's not going to happen. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] gevent-like Coroutines in Python

Ron Reiter wrote: I feel like having the await syntax trigger by default on any awaitable invocation in a coroutine context makes much more sense. Guido seems to regard the requirement to use 'await' as a feature, not a bug. He says he likes to be able to see where all the potential suspension

Re: [Python-ideas] Problems (and solutions?) in writing decorators

Jonathan Fine wrote: I also find writing decorators a bit hard. It seems to be something I have to learn anew each time I do it. Particularly for the pattern @deco(arg1, arg2) def fn(arg3, arg4): > # function body Perhaps doing something with partial might help here. Anyone here

Re: [Python-ideas] Return for assignment blocks

Calvin Spealman wrote: You know what, I /can't/ think of other good examples than slightly improved decorators. So, maybe its not that great an idea if it can't be applied to at least a few more use cases. The class version might be useful for things like namedtuple that dynamically create

Re: [Python-ideas] Powerset

Wes Turner wrote: Is there a name for an iteration of the powerset which is more useful for binary search? I.e. instead of starting with null set, start with the "middle" ( r/2 ). You'll have to provide more detail about what you want to search and how you intend to search it. There isn't a

Re: [Python-ideas] Revisiting Immutable Mappings

Chris Barker - NOAA Federal via Python-ideas wrote: Or maybe come up with a new name We should call it a birdseyedict, because of this: http://www.vulture.com/2016/12/unearthing-a-rare-1971-monty-python-film-all-about-peas.html -- Greg ___

Re: [Python-ideas] Support parsing stream with `re`

Stephen J. Turnbull wrote: Subject to COW, I presume. Probably in units smaller than the whole file (per page?) It can be COW or not, depending on the options passed to mmap. And yes, it's mapped in units of pages. -- Greg ___ Python-ideas mailing

Re: [Python-ideas] Support parsing stream with `re`

Chris Angelico wrote: In contrast, a mmap'd file is memory that you do indeed own. Although it's not really accurate to say that it's owned by a particular process. If two processes mmap the same file, the physical memory pages holding it appear in the address spaces of both processes. --

Re: [Python-ideas] Support parsing stream with `re`

Jonathan Fine wrote: Provided mmap releases memory when possible, It will. The virtual memory system will read pages from the file into RAM when needed, and re-use those RAM pages for other purposes when needed. It should be pretty much the most efficient solution possible. -- Greg

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Chris Angelico wrote: But as a part of the function's declared intent, it's fine to have a postcondition of "the directory will be empty" even though something could drop a file into it. If you only intend the contract to serve as documentation, I suppose that's okay, but it means you can't

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Chris Angelico wrote: It is still fundamentally difficult to make assertions about the file system as pre/post contracts. When you consider race conditions, I'd say it's impossible. A postcondition check involving the file system could fail even if the function does its job perfectly. -- Greg

Re: [Python-ideas] Add .= as a method return value assignment operator

Steven D'Aprano wrote: Think about a more complex assignment: text .= encode(spam) + str(eggs) I think the only sane thing would be to disallow that, and require the RHS to have the form of a function call, which is always interpreted as a method of the LHS. -- Greg

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

David Mertz wrote: the reality is that they really ARE NOT much different from assertions, in either practice or theory. Seems to me that assertions is exactly what they are. Eiffel just provides some syntactic sugar for dealing with inheritance, etc. You can get the same effect in present-day

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Chris Angelico wrote: if you let your API docs rot when you make changes that callers need to be aware of, you have failed your callers. Yes, I find that documentation auto-generated from code is usually a poor substitute for human-written documentation. Dumping your formally-written contracts

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

Chris Angelico wrote: For example, matplotlib's plt.show() method guarantees that... a plot will be shown, and the user will have dismissed it, before it returns. Unless you're inside Jupyter/iPython, in which case it's different. Or if you're in certain other environments, in which case it's

Re: [Python-ideas] Moving to another forum system where

Chris Barker via Python-ideas wrote: One of the problems with the assignment expression discussion is that it got pretty far on python-ideas, then moved to python-dev, where is was further discussed (and there were parallel thread on the two lists) As long as there are two lists with similar

Re: [Python-ideas] Moving to another forum system where

James Lu wrote: I believe GitHub has direct email capability. If you watch the repository and have email notifications on, you can reply directly to an email and it will be sent as a reply. Can you start a new topic of conversation by email, though? The best solution would to have admins

Re: [Python-ideas] Moving to another forum system where moderation is possible

Mikhail V wrote: I think there are forum systems which allow you to post by email so it is possible to get the same effect as with mailing list, if you really want. I hope that, if any such change is made, a forum system is chosen that allows full participation via either email or news.

Re: [Python-ideas] Moving to another forum system where moderation is possible

Mark E. Haase wrote: Many e-mails to this list do nothing more than say +1 or -1 without much added discussion. Are there really all that many? They seem relatively rare to me. Certainly not enough to annoy me. -- Greg ___ Python-ideas mailing list

Re: [Python-ideas] Moving to another forum system where moderation is possible

Mark E. Haase wrote: I would also appreciate a +1 button. Many e-mails to this list do nothing more than say +1 or -1 without much added discussion. A tiny bit of discussion is still better than none at all. And even if there's no discussion, there's a name attached to the message, which makes

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

Chris Barker via Python-ideas wrote: "efficient is better than inefficient" kind of goes without saying... Perhaps we should just replace the entire Zen with "Good is better than bad." Insert your own subjective ideas on what constitutes "good" and "bad" and you're set to go. :-) -- Greg

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

Guido van Rossum wrote: Facts to consider: (a) the OP's address is ...@yandex.com , a well-known Russian website (similar to Google); (b) there's a Canadian actress named Samantha Quan. Now I'm waiting for the Kremlin to deny rumours that the Canadian actress Samantha Quan

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

Tim Delaney wrote: And I can't think of an elegant replacement for "ugly" to pair with "elegant". There's "inelegant", but it doesn't have the same punch as "ugly". And I think Tim deliberately chose a very punchy word for that line, to reflect that we care a *lot* about aesthetics in Python.

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

Calvin Spealman wrote: I ask everyone on this thread being rude to please step back and try to look at the issue without your bias and knee-jerk reactions. I've given it some thought, and this is what I think: As has been pointed out, context is important. The reason that shunning people for

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

M.-A. Lemburg wrote: For me, it refers to a general feeling of consistency, pureness and standing out on its own. It's abstract and doesn't have anything to do with humans. Yep. And the proposed replacement "clean/dirty" doesn't even mean the same thing. It's entirely possible for a thing to

Re: [Python-ideas] Retire or reword the "Beautiful is better than ugly" Zen clause

Jacco van Dorp wrote: You can have master and slave devices - for example, if I have a PC that tells a robot what to do, my PC is the master and the robot the slave. If we're going to object to "slave", we should object to "robot" as well, since it's derived from a Czech word meaning "forced

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

Stephan Houben wrote: To be honest, quite apart from the Unicode issue, I never had a need to reverse a string in real code. Yeah, seems to me it would only be useful if you were working on some kind of word game such as a palindrome generator, or if your string represents something other than

Re: [Python-ideas] Keyword only argument on function call

Rhodri James wrote: that syntax looks at best highly misleading -- how many parameters are we passing? I don't like it at all. Maybe something like this would be better: f(=a, =b, =c) Much more suggestive that you're passing a keyword argument. As for whether consistent naming is a good

Re: [Python-ideas] Executable space protection: NX bit,

Jonathan Fine wrote: # Evil code! ask_delete.__code__, ask_save.__code__ = ask_save.__code__, ask_delete.__code__ If an attacker can trick you into executing that line of code, he can probably just delete your data directly. -- Greg ___

Re: [Python-ideas] Pre-conditions and post-conditions

Jonathan Fine wrote: I've just read and article which makes a good case for providing pre-conditions and post-conditions. http://pgbovine.net/python-unreadable.htm There's nothing in there that talks about PBC-style executable preconditions and postconditions, it's all about documenting the

Re: [Python-ideas] Add recordlcass to collections module

Zaur Shibzukhov wrote: > `Recordclass` is defined on top of` memoryslots` just like `namedtuple` > above` tuple`. Attributes are accessed via a descriptor (`itemgetset`), > which supports both` __get__` and `__set__` by the element index. > > As a result, `recordclass` takes up as much memory

Re: [Python-ideas] Fix some special cases in Fractions?

Neil Girdhar wrote: Powers of other numbers have to keep the same behavior since in general those kinds of expressions don't create rational numbers. There are infinitely many other rational numbers that *could* be given the same treatment, though, e.g. (-8) ** (2/3). If you don't want to

Re: [Python-ideas] Fix some special cases in Fractions?

Neil Girdhar wrote: we want branch continuity in the power. After all, floating point values have some inaccuracy, and we wouldn't want chaotic behavior, i.e., small changes to the power to have drastic changes to the result. This is not like Fraction where we know that x ** Fraction(1, 3)

Re: [Python-ideas] Fix some special cases in Fractions?

Jonathan Goble wrote: How? Raising something to the 2/3 power means squaring it and then taking the cube root of it. On reflection, "wrong" is not quite accurate. A better word might be "surprising". (-1) ** (2/3) == 1 would imply that 1 ** (3/2) == -1. I suppose that could be considered true

Re: [Python-ideas] Fix some special cases in Fractions?

Jeroen Demeyer wrote: On 2018-08-30 06:39, Neil Girdhar wrote: I'd like these to be Fraction(1), Fraction(1), and Fraction(0). Why? I cannot think of any natural use case why you would want Fractions for a few special cases on an operation which returns non-Fractions generically. Also,

Re: [Python-ideas] Pre-conditions and post-conditions

Jonathan Fine wrote: My message of support for Ivan quoted the Eiffel docs. https://www.eiffel.org/doc/eiffel/ET-_Design_by_Contract_%28tm%29%2C_Assertions_and_Exceptions During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with

Re: [Python-ideas] Pre-conditions and post-conditions

Wes Turner wrote: I'm going to re-write that in a pseudo-Eiffel like syntax: Maybe some magic could be done to make this work: def __init__(self, img: np.ndarray, x: int, y: int, width: int, height: int) -> None: def __require__(): x >= 0

Re: [Python-ideas] On evaluating features [was: Unpacking iterables for augmented assignment]

Guido van Rossum wrote: we might propose (as the OP did) that this: a, b, c += x, y, z could be made equivalent to this: a += x b += y c += z But not without violating the principle that lhs += rhs is equivalent to lhs = lhs.__iadd__(lhs) Granted, this rule inevitably

Re: [Python-ideas] A GUI for beginners and experts alike

Mike Barnett wrote: Unsubscribing from this mess. “Python Ideas” ? We didn't mean to drive you away! Python discussions have a tendency to roam far and wide. It doesn't mean we're not interested in what you have to say. Any new package is naturally going to invite comparisons with similar

Re: [Python-ideas] A GUI for beginners and experts alike

Here are some PyGUI versions of the ABC Challenge. # Modal from GUI import ModalDialog, Label, TextField, Row, Column, Grid from GUI.StdButtons import DefaultButton, CancelButton from GUI.Alerts import note_alert a = TextField(width = 100) b =

Re: [Python-ideas] A GUI for beginners and experts alike

Chris Barker - NOAA Federal wrote: Now that you say that, I think I’m mingling memories — there was another project that attempted to wrap TKInter, wxPython, QT .. I always thought that was ill advised. You're probably thinking of "anygui" (named in the spirit of "anydbm"). As far as I

Re: [Python-ideas] A GUI for beginners and experts alike

Chris Barker via Python-ideas wrote: In fact, there was an effort along these lines a few years back: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ I don't know that it's seen much development lately. It hasn't, sorry to say. Turns out that writing and maintaining what is

Re: [Python-ideas] Does jargon make learning more difficult?

Stephen J. Turnbull wrote: Abe Dillon writes: > That's interesting. So the parser can see one token past, for instance; > what would be the end of an expression, see "if", and know to expand the > AST? Yes, if you want to think about it that way. For understanding what kinds of things an

Re: [Python-ideas] Does jargon make learning more difficult?

Steven D'Aprano wrote: The only difference between dict and lambda is time. Well, "more arbitrary" was perhaps a rather loose way of saying it. What I meant was that the chain of associations is shorter for "lambda" than for "s-expression", because the "s" refers to a word the reader is

Re: [Python-ideas] Does jargon make learning more difficult?

Chris Angelico wrote: for those who know Greek, it's like calling something an "S-expression", which is fairly obviously an abbreviation for something. ("Symbolic expression", I think? Someone might correct me there.) Yes, except that lambda is an even more arbitrary choice of letter -- as far

Re: [Python-ideas] Does jargon make learning more difficult?

Abe Dillon wrote: They still find it's better to use a red break light symbol with the aim of clearly communicating to non-experts. The handbrake warning light on my dashboard has a symbol that represents a brake drum and a pair of brake shoes, and the word "BRAKE" written underneath it.

Re: [Python-ideas] Does jargon make learning more difficult?

Stephan Houben wrote: Church's lambda notation was the first way to write down a function without naming it, in the 1930's. That's debatable. It could be argued that calculus makes use of anonymous functions, e.g. the expression d/dx (x**2 + 2*x - 3) describes a function of x without

Re: [Python-ideas] Does jargon make learning more difficult?

Rhodri James wrote: This, by the way, is why think using the same syntax for function definition and generator definition was a mistake. I think I remember arguing the same thing back when generators were being devised. But there are arguments the other way too. From the outside, a generator

Re: [Python-ideas] Does jargon make learning more difficult?

Steven D'Aprano wrote: Not "process the sorted list", but reify the sort verb into an actual thing (an object or value) and then process that thing itself. This is mind-bending when you think about it, far more mind-blowing than the normal linguistic process of nouning verbs and verbing

Re: [Python-ideas] Off topic: 'strike a balance' - second language English

Jonathan Fine wrote: Matlab says: "Here, copy paste this and it'll work". To the point that the workspace is designed to automatically strip >>> from any copy and pasted commands. Maybe this is something Python's REPL should do? -- Greg ___

Re: [Python-ideas] Does jargon make learning more difficult?

Alexandre Brault wrote: On 2018-08-15 03:32 PM, MRAB wrote: On 2018-08-15 18:27, MRAB wrote: > While we're at it, what's the only creature that's known commonly and only by its scientific name? I would have guessed Tyrannosaurus Rex I would have thought pretty much any dinosaur. -- Greg

Re: [Python-ideas] Does jargon make learning more difficult?

Jonathan Fine wrote: Puffinus puffinus is the scientific name for Puff the Magic Dragon? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct:

Re: [Python-ideas] Does jargon make learning more difficult?

Steve Barnes wrote: * Brakes are used to apply breaking, I hope they actually apply braking, not breaking. :-) * A dinosaur is specifically an extinct terrible (formerly considered) lizard Which technically is not a lizard. -- Greg ___

Re: [Python-ideas] Syntactic sugar to declare partial functions

Chris Angelico wrote: No, lambda calculus isn't on par with brakes - but anonymous functions are, and if they're called "lambda", you just learn that. It's like saying that people would find it easier to learn to drive if "brakes" were called "stoppers" or something. I don't think that's true.

Re: [Python-ideas] Syntactic sugar to declare partial functions

Abe Dillon wrote: [Bruce Leban] Lambda calculus IS computer science. It's a foundation of computer science. That doesn't mean it "IS" computer science. Set theory is a foundation of computer science. It's still it's own discipline. Lambda calculus is considered a part of computers

Re: [Python-ideas] Redefining method

Jamesie Pic wrote: def o.bar(self): ... You could get almost the same effect with from functools import partial def bar(self, other_args): ... o.bar = partial(bar, o) But IMO this is nowhere near being a common enough thing to do to justify having special syntax for it. --

Re: [Python-ideas] PEP 505: None-aware operators

Abe Dillon wrote: others countering that `person.name ` is not how periods are used in natural languages, so using other symbols in unintuitive ways is perfectly fine. Dots have been used for attribute access in so many languages for so long that it has become the normal

Re: [Python-ideas] As-do statements/anonymous blocks in python

James Lu wrote: as expr [do comma-separated-expressions]: >block means evaluate expr, then call the result of the expression. If do is present, call it with the argument list after do. This kind of thing has been proposed before. Although it seems like a straightforward idea, there are

Re: [Python-ideas] PEP 505: None-aware operators

David Mertz wrote: Sorry. From my tablet. "Bug magnets" (it really, really wants to autocorrect that) At least it didn't correct it to "butt magnets". :-) -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] PEP 505: None-aware operators

David Mertz wrote: "APL and Perl territory" means "use lots of punctuation characters in somewhat cryptic ways, often combining several for a distinct semantics." And APL takes it a step further by freely making up new characters when it runs out of existing ones. At least nobody has

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

Calvin Spealman wrote: Operators that only vary by case would be... confusing. Also I'd prefer to see AND and OR (or maybe And and Or) reserved for possible use as overridable, non-short-circuiting forms of "and" and "or" for use by DSLs. -- Greg

Re: [Python-ideas] PEP 505: None-aware operators: operators ?= and ?? and OR

Nathan wrote: How many programmer will read "||" or "OR" as a classic "or" operator? It will certainly confuse someone who has any C reflexes, since "||" in C is just a boolean "or". -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] PEP 505: None-aware operators

Rhodri James wrote: On 19/07/18 07:06, Greg Ewing wrote: There's no such tradition for the new operators being proposed. There is, actually, it's just not a long one. C# has had null-aware operators for a while, for example. THere's a precedent, yes, but I wouldn't call it a tradition

Re: [Python-ideas] PEP 505: None-aware operators

Rhodri James wrote: If anyone can think of a good word for "if it isn't None, otherwise", I'd be all for it :-) I don't think there's any single Engish word that captures all of that, so we'd have to invent one. Some suggestions: inno (If Not None, Otherwise) oft (Or, Failing That) --

Re: [Python-ideas] PEP 505: None-aware operators

Jonathan Fine wrote: Perhaps "argue" is not the right word here. It sounds too much for or against. And it has implications of being heated and angry. At least arguing about the nature of argument is a very Pythonic thing to do. "That's not arguing, it's just contradiction!" "No, it isn't!"

Re: [Python-ideas] PEP 505: None-aware operators

Chris Angelico wrote: I'd love to hear an explanation of WHY this doesn't look like Python any more. For instance, is the + operator somehow wrong for Python, and it should have been the word "add"? There's a very long tradition of using the symbol "+" to represent addition, so it's something

Re: [Python-ideas] The future of Python parallelism. The GIL. Subinterpreters. Actors.

MRAB wrote: The shared object's refcount would be incremented and the sharing function would return a proxy to the shared object. Refcounting in the thread/process would be done on the proxy. When the proxy is closed or garbage-collected, the shared object's refcount would be decremented.

Re: [Python-ideas] Add the imath module

Danilo J. S. Bellini wrote: If we have a fast and exact primality test up to 2**64, a signature like this would help: def is_prime(n, probabilistic=False): Two separate functions would be better, by the "no constant boolean parameters" rule. -- Greg

Re: [Python-ideas] Add the imath module

Stephan Houben wrote: Should we call sort then probable_sort, since the non-zero probability exists of it going wrong due to a stray cosmic ray? And in the interests of full disclosure, we should call Python a probable language, running on a probable computer. -- Probable Greg

Re: [Python-ideas] grouping / dict of lists

MRAB wrote: I think that building an iterable of 2-tuples to pass to 'grouped' is much like following a decorate-sort-undecorate pattern when sorting, or something similar when using 'min' or 'max'. Passing an iterable of items and optionally a key function is simpler, IMHO. It should

Re: [Python-ideas] Where should grouping() live

Steven D'Aprano wrote: I propose that a better name which indicates the non-lazy nature of this function is *grouped* rather than grouping, like sorted(). +1 As for where it belongs, perhaps the collections module is the least worst fit. But then there's the equally strong purist argument

Re: [Python-ideas] Where should grouping() live

David Mertz wrote: Just make grouping() a generator function rather than a plain function. This lets us get an incremental grouping of an iterable. This can be useful if the iterable is slow or infinite, but the partial groupings are useful in themselves. Do you have any real-world

Re: [Python-ideas] grouping / dict of lists

Nicolas Rolin wrote: grouping(((len(word), word) for word in words)) That actually has one more level of parens than are needed, you can just write grouping((len(word), word) for word in words) -- Greg ___ Python-ideas mailing list

Re: [Python-ideas] Allow a group by operation for dict comprehension

Steven D'Aprano wrote: On Thu, Jun 28, 2018 at 10:01:00AM -0700, Chris Barker via Python-ideas wrote: In [*46*]: {a:[t[0] *for* t *in* b] *for* a,b *in* groupby(sorted(student_school_list, key=*lambda* t: t[1]), key=*lambda* t: t[ ... > the rest ought to be legal Python but

Re: [Python-ideas] Allow a group by operation for dict comprehension

Nicolas Rolin wrote: student_by_school = {group_by(school): student for school, student in student_school_list} In the spirit of making the target expression look like a template for the generated elements, {school: [student...] for school, student in student_school_list} -- Greg

Re: [Python-ideas] Should nested classes in an Enum be Enum members?

Guido van Rossum wrote: Sounds to me really strange that the nested class would become a member. Probably because everything becomes a member unless it's a function (maybe decorated)? Maybe it would have been better if Enums got told what type their members are supposed to be, an only

Re: [Python-ideas] Fwd: Replacing Infinite while Loops with an Iterator: async edition

j...@math.brown.edu wrote: On Jun 23, 2018, at 21:11, Nathaniel Smith > wrote: He's asking for an async version of the 'iter' builtin, presumably something like: async def aiter(async_callable, sentinel): while True: value = await

Re: [Python-ideas] Replacing Infinite while Loops with an Iterator: async edition

j...@math.brown.edu wrote: it would be nice if we could write an async version of this, as in ``async for chunk in aiter(...)``. The time machine seems to have taken care of this: https://docs.python.org/3.6/reference/compound_stmts.html#the-async-for-statement -- Greg

Re: [Python-ideas] Secure string disposal (maybe other inmutable seq types too?)

Christian Heimes wrote: It's just a 90% secure solution, because the data will eventually land in public buffers. Seems like the only completely foolproof solution would have to involve some kind of quantum storage that can't be copied without destroying it. -- Greg

Re: [Python-ideas] Secure string disposal (maybe other inmutable seq types too?)

Christian Heimes wrote: You'd also need to ensure that the memory page is never paged to disk or a visible to gdb, ptrace, or any other kind of debugger. If the attacker can attach a debugger to your process, they can already do a lot worse than snoop on your secret strings. -- Greg

Re: [Python-ideas] Secure string disposal (maybe other inmutable seq types too?)

Paul Moore wrote: a = SafeStr("my secret data") ... work with a as if it were a string del a But in order to create the SafeStr, you need to first have the data in the form of an ordinary non-safe string. How do you dispose of that safely? -- Greg

Re: [Python-ideas] Secure string disposal (maybe other inmutable seq types too?)

Chris Angelico wrote: Downside: You can't say "I'm done with this string, destroy it immediately". Also it would be hard to be sure there wasn't another copy of the data somewhere from a time before you got around to marking the string as sensitive, e.g. in a file buffer. -- Greg

Re: [Python-ideas] Remember the Vasa

Paddy3118 wrote: Here's and letter: http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0977r0.pdf This is why it's important for a language to have a BDFL. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Operator for inserting an element into a list

Chris Angelico wrote: kwargs.pop("some_key") could plausibly be spelled del kwargs["some_key"] if del were (like yield) upgraded to expression. Except that "delete" is a really misleading name for such an operation! -- Greg ___ Python-ideas mailing

Re: [Python-ideas] Operator for inserting an element into a list

Mikhail V wrote: But I see from various posts in the web and SO - people just want to spell it compact, and keep the 'item' part clean of brackets. Where have you seen these posts? -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Operator for inserting an element into a list

Michael Selik wrote: The += operator was meant as an alias for ``x = x + 1``. The fact that it mutates a list is somewhat of a surprise. That's very much a matter of opinion. For every person who thinks this is a surprise, you can find another that thinks it's obvious that += should mutate a

Re: [Python-ideas] Operator for inserting an element into a list

Mikhail V wrote: It s just very uncommon to see standalone statements like: x.method() for me it came into habit to think that it lacks the left-hand part and =. You must be looking at a very limited and non-typical corpus of Python code. Mutating method calls are extremely common in most

Re: [Python-ideas] Give regex operations more sugar

Oleg Broytman wrote: import re as regular_expressions_operations Personally I would use import re as ridiculously_enigmatic_operations -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Give regex operations more sugar

Steven D'Aprano wrote: So math.sin is little different from math_sin, but the fact that math alone is a module, a first-class object, and not just a prefix of the name, makes a big difference. This is important because it provides ways of referring to things in the module without having to

Re: [Python-ideas] Give regex operations more sugar

Steven D'Aprano wrote: - should targets match longest first or shortest first? or a flag to choose which you want? - what if you have multiple targets and you need to give some longer ones priority, and some shorter ones? I think the suggestion made earlier is reasonable: match them in

<    1   2   3   4   5   6   7   8   9   >