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?

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] 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?

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] 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 tur

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

Something to consider in all of this is that Python floats often *don't* produce NaNs for undefined operations, but raise exceptions instead: >>> 1.0/0.0 Traceback (most recent call last): File "", line 1, in ZeroDivisionError: float division by zero >>> math.sqrt(-1.0) Traceback (most recent

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] 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. -- 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] 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 ___ Python-i

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 si

Re: [Python-ideas] Return for assignment blocks

Calvin Spealman wrote: def ignore_exc(exc_type): return def (func): > ... Something very similar has been suggested before, you might like to review the previous discussion. -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Return for assignment blocks

The idea is okay, but I'm not keen about the syntax, because it doesn't read well as English. Currently "def" can be read as the verb "define", but "return define" doesn't make sense. Maybe it would be better as a pseudo-decorator: @return def f(args): ... But I'm inclined to ag

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 cla

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 intereste

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] 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 https://ma

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 bothers

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 lik

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: 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 functi

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 ra

[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, func,

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 -

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 inter

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 the

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__: >>> m

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

Chris Angelico wrote: On Thu, Dec 13, 2018 at 3:07 PM Chris Barker - NOAA Federal via Python-ideas wrote: obj is iter(obj) Is that a hard and fast rule? Yes, it is. https://docs.python.org/3/library/stdtypes.html#iterator-types The docs aren't very clear on this point. They claim this i

Re: [Python-ideas] [asyncio] Suggestion for a major PEP

Christophe Bailly wrote: I copy paste the main idea from an article I have written: contextual async All of your examples there are C++. It's not clear how any of this relates to Python. Do we have the tools to do this ? Yes beca

Re: [Python-ideas] Add regex pattern literal p""

Steven D'Aprano wrote: _t1 = re.compile(r"(\d)\1") # compile-time _t2 = re.compile(r"(\s)\1") # compile-time re.compile(_t1.pattern + _t2.pattern) # run-time It would be weird if p"(\d)\1" + p"(\s)\1" worked but re.compile(r"(\d)\1") + re.compile(r"(\s)\1") didn't. -- Greg _

Re: [Python-ideas] Add regex pattern literal p""

I don't see a justification for baking REs into the syntax of Python. In the Python world, REs are just one tool in a toolbox containing a great many tools. What's more, it's a tool that should be used with considerable reluctance, because REs are essentially unreadable, so every time you use one

Re: [Python-ideas] tkinter: time for round buttons?

Terry Reedy wrote: It is using native widgits of the platform that people on the platform are used to. Indeed, and because of that, you *shouldn't* have any control over it. People get annoyed when a GUI follows an author's personal preferences instead of platform conventions. -- Greg

Re: [Python-ideas] Backtick expression: similar to a shorter lambda syntax

Calvin Spealman wrote: The one positive I see is that because there is no open and closing pair of backticks, like parens or brackets, you can't easily nest this syntax and I actually like how it inherently discourages or makes that impossible! Perhaps surprisingly, the backtick syntax in Pyth

Re: [Python-ideas] kwargs for return

Stephen J. Turnbull wrote: Common Lisp has this feature. Lua also has something like this, but it's more built-in. The syntax looks deceptively similar to tuple packing and unpacking in Python, but it's magical. I wouldn't like to see that kind of magic in Python. -- Greg

Re: [Python-ideas] Add list.join() please

Brendan Barnwell wrote: Personally what I find is perverse is that .join is a method of strings but does NOT call str() on the items to be joined. Neither do most other string methods: >>> s = "hovercraft" >>> s.count(42) Traceback (most recent call last): File "", line 1, in TypeError:

Re: [Python-ideas] Add list.join() please

Alex Shafer via Python-ideas wrote: 1) I'm in favor of adding a stringify method to all collections Are you volunteering to update all the collection classes in the world written in Python? :-) -- Greg ___ Python-ideas mailing list Python-ideas@pyth

Re: [Python-ideas] Clearer communication

Adrien Ricocotam wrote: On a forum (no matter the form), you can edit the original post. Thus, when something was unclear, false or needed an edit, the author (or others) can edit the original post. So when someone actually reads the original post, s-he doesn't have to read the 20 mails of clea

Re: [Python-ideas] Clearer communication

Adrien Ricocotam wrote: I think something that hasn't been cited is the poor readability of code posted by mails. It's juste aweful to me. You may have a trick for good formating but I think that's a good point for other systems, or at least complementary systems to mails. In my experience, t

Re: [Python-ideas] Clearer communication

Abe Dillon wrote: As I've pointed out before, putting things in chronological order doesn't force people to read anything, it just favors new over old. Um, what? People talking about chronological order here mean *oldest to newest*, not the other way around. This is not meant to "favour" anyth

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

MRAB wrote: Well, if we were using an English prefix, wouldn't it be "unhomogeneous"? If we're sticking with Greek it would have to be something like "anhomogeneous". -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.o

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Adrien Ricocotam wrote: I honestly don’t understand what you don’t like the @ syntax. Another probkem with @ is that it already has an intended meaing, i.e. matrix multiplication. What if you have two vectors of matrices and you want to multiply corresponding ones? -- Greg

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Ronald Oussoren via Python-ideas wrote: On 3 Feb 2019, at 21:34, David Mertz > wrote: >> Using @ both for matrix multiplication and element-wise application could be made to work, but would be very confusing. The way @ is defined in numpy does actually work for both.

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Adrien Ricocotam wrote: >>> # Compute the length of each element of the Vector `v` >>> v.apply(len) >>> v @ len Another example with parameters >>> # Replace all "a" by "b" >>> v.apply(lambda s: s.replace("a", "b")) >>> v @ (lambda s: s.replace("a", "b")) My personal opinion is that the t

Re: [Python-ideas] __first__ method

The Big Cheese wrote: however at the start of this module it imports os and glob and it also runs some setup for how it reads the sensors and has such I have to just do 'import temperature' and then every time I create a sensor I have to call temperature.Sensor which isn't as nice. I think yo

Re: [Python-ideas] PEP 8 update on line length

Samuel Colvin wrote: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: I don't see how anyone can say that would be more readable with a 80 character line limit. I would argue that it *is* more readable if it's not all on o

Re: [Python-ideas] PEP 8 update on line length

Samuel Colvin wrote: I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header. But to me, a one-line function header that contains 7 lines worth of charaacters is *less* readable than a 7-line header, as long as it's fo

Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

Chris Angelico wrote: if I'd been able to ascertain which functions were pure, or at least side-effect-free, it would have saved me a lot of hassle.) I'm not sure how useful such annotations would be in practice, though. They're only as good as the diligence of the author in using them consiste

Re: [Python-ideas] PEP 8 update on line length

Brendan Barnwell wrote: I use an editor that VISUALLY wraps long lines and maintains the indentation on the wrapped portion, without changing the bytes in the file. I make my lines as long as I want, inserting linebreaks only where they have a semantic reason to be (such as between multiple l

Re: [Python-ideas] PEP 8 update on line length

Christopher Barker wrote: (And did they ever stop to wonder why those old terminals standardized on 80 columns?) Probably because IBM decided on 80 columns for their punched cards. And that probably didn't have anything to do with a readable width for text. Nobody used computers for wo

Re: [Python-ideas] Dict joining using + and +=

Serhiy Storchaka wrote: I do not understand why we discuss a new syntax for dict merging if we already have a syntax for dict merging: {**d1, **d2} (which works with *all* mappings). But that always returns a dict. A '+' operator could be implemented by other mapping types to return a mapping

Re: [Python-ideas] Dict joining using + and +=

Serhiy Storchaka wrote: And this opens a non-easy problem: how to create a mapping of the same type? That's the responsibility of the class implementing the + operator. There doesn't have to be any guarantee that a subclass of it will automatically return an instance of the subclass (many exis

Re: [Python-ideas] Dict joining using + and +=

Rhodri James wrote: I have to go and look in the documentation because I expect the union operator to be '+'. Anyone raised on Pascal is likely to find + and * more natural. Pascal doesn't have bitwise operators, so it re-uses + and * for set operations. I like the economy of this arrangement -

Re: [Python-ideas] PEP: Dict addition and subtraction

Steven D'Aprano wrote: The question is, is [recursive merge] behaviour useful enough and > common enough to be built into dict itself? I think not. It seems like just one possible way of merging values out of many. I think it would be better to provide a merge function or method that lets you s

Re: [Python-ideas] Suggestions: dict.flow_update and dict.__add__

Christopher Barker wrote: That violates an important convention in Python: mutating methods do not return self. We really want to preserve that convention. Smalltalk has an abbreviated way of writing a series of method calls to the same object: x doThis; doThatWith: y; doTheOther. is equiv

Re: [Python-ideas] PEP: Dict addition and subtraction

Ka-Ping Yee wrote: len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the + operator is nonsense. You might as well say that using the + operator on vectors is nonsense, because len(v1 + v2) is not in general equal to len(v1) + len(v2). Yet mathematicians are quite happy to ta

Re: [Python-ideas] Make Python 2.7’s online docs optionally redirect to Python 3 online docs

Steven D'Aprano wrote: I've found that the search engines are getting better at linking to the more recent docs. Likely this is simply due to the fact that Python 3 is being used more than it was, so more of its doc pages are getting linked to. If that's true, then thing should continue to impr

Re: [Python-ideas] PEP: Dict addition and subtraction

Guido van Rossum wrote: I guess this explains the behavior of removing results <= 0; it makes sense as multiset subtraction, since in a multiset a negative count makes little sense. (Though the name Counter certainly doesn't seem to imply multiset.) It doesn't even behave consistently as a mu

Re: [Python-ideas] Attribute-Getter Syntax Proposal

Samuel Li wrote: .attribute -> lambda x: x.attribute .method(*args, **kwargs) -> lambda x: x.method(*args, **kwargs) Leading dots can be hard to spot when reading code. Also, I'm not convinced that use cases for this are frequent enough to warrant new syntax. Something akin to this can alrea

Re: [Python-ideas] Left arrow and right arrow operators

francismb wrote: It is may be how now it is, but means that it needs to be always like this? Yes, as long as you care about not breaking existing code. While you may be in the habit of always leaving a space between '<' and '-', others may have different styles. Do you really want to tell them

Re: [Python-ideas] Preallocated tuples and dicts for function calls

Martin Bammer wrote: what about the idea that the interpreter preallocates and preinitializes the tuples and dicts for function calls where possible when loading a module? This would not be thread-safe. Locking would be needed around uses of the preallocated objects, and that might take away s

Re: [Python-ideas] PEP: Dict addition and subtraction

Guido van Rossum wrote: I guess everybody's high school math(s) class was different. I don't ever recall seeing + and * for boolean OR/AND; we used ∧ and ∨. Boolean algebra was only touched on briefly in my high school years. I can't remember exactly what notation was used, but it definitely wa

Re: [Python-ideas] Attribute-Getter Syntax Proposal

If we were going to add a syntax for abbreviating lambdas, I would rather see something more generally useful, e.g. x -> x.method() as an abbrevation for lambda x: x.method() -- Greg ___ Python-ideas mailing list Python-ideas@python.org https:

Re: [Python-ideas] The @update operator for dictionaries

Jonathan Fine wrote: It not me, but Chris and Steve who want to bind dict.update to an operator, namely '+'. I'm suggested that if you do that, why not call the operator 'update'. One reason would be that '+' is short, whereas 'update' is long. A large part of the reason that common operations

Re: [Python-ideas] Code version evolver

francismb wrote: Yes a source transformer, but to be applied to some 3.x version to move it to the next 3.x+1, and so on ... (instead of '2to3' a kind of 'nowtonext', aka 'python_next') Couldn't that relax the tension on doing 'backward compatibility changes' a bit ? Not really. Having to tran

Re: [Python-ideas] PEP: Dict addition and subtraction

Another random thought about this: Mathematicians use addition as a metaphor for quite a range of different things, but they tend to only use the symbols ∪ and ∩ for actual sets, or things that are very set-like. So maybe that's an argument for using '+' rather than '|' for dict merging. -- Greg

Re: [Python-ideas] Why operators are useful

Rémi Lapeyre wrote: I think this omit a very important property of mathematic equations thought, maths is a very strongly typed language which can be a significant improvement for readability. Python is very strongly typed too, so I don't really see how maths is different. For example, a math

Re: [Python-ideas] Why operators are useful

Richard Damon wrote: Rémi, I believe, is assuming in their example that by defining the field of mathematics being used, there is at least an implicit definition (if not actually explicit as such a statement would typically be preceded by definitions) definition of the types of the variables. I

Re: [Python-ideas] True and False are singletons

Juancarlo Añez wrote: if settings[MY_KEY] is True: ... If I saw code like this, it would take a really good argument to convince me that it shouldn't be just if settings[MY_KEY]: ... -- Greg ___ Python-ideas mailing list Pytho

Re: [Python-ideas] True and False are singletons

Oleg Broytman wrote: Three-way (tri state) checkbox. You have to distinguish False and None if the possible valuse are None, False and True. In that case the conventional way to write it would be if settings[MY_KEY] == True: ... It's not a major issue, but I get nervous when I

Re: [Python-ideas] True and False are singletons

Richard Damon wrote: On 3/18/19 7:27 AM, Greg Ewing wrote: if settings[MY_KEY]: ... > That means something VERY different. Yes, but there needs to be justification for why the difference matters and why this particular way is the best way to deal with it. Whenever you write

Re: [Python-ideas] Why operators are useful

Rémi Lapeyre wrote: You can make "inferences from the way things are used". But the comparison with maths stops here, you don’t make such inferences because your object must be well defined before you start using it. In maths texts it's very common to see things like 'Let y = f(x)...' where it

Re: [Python-ideas] True and False are singletons

Tim Delaney wrote: I would argue the opposite - the use of "is" shows a clear knowledge that True and False are each a singleton and the author explicitly intended to use them that way. I don't think you can infer that. It could equally well be someone who's *not* familiar with Python truth ru

Re: [Python-ideas] Why operators are useful

Antoine Pitrou wrote: You are being idealistic here. MyPy relies on typing hints being available, and sufficiently precise. Yes, but it doesn't require type hints for *everything*. Given enough starting points, it can figure out the rest. Mathematicians rely heavily on their readers being abl

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

Sylvain MARIE via Python-ideas wrote: `my_decorator(foo)` when foo is a callable will always look like `@my_decorator` applied to function foo, because that's how the language is designed. I don't think it's worth doing anything to change that. Everywhere else in the language, there's a very cl

Re: [Python-ideas] New explicit methods to trim strings

Dan Sommers wrote: So what it is "hello" - "world"? If we were to implement the entire group, it would be an element that can't be written in any simpler form. We could do that by representing a string as a sequence of signed substrings, and performing cancellations whereever possible during

Re: [Python-ideas] New explicit methods to trim strings

Dan Sommers wrote: without_prefix without_suffix They're a little longer, but IMO "without" helps reenforce the immutability of the underlying string. We don't seem to worry about that distinction for other string methods, such as lstrip and rstrip. -- Greg __

Re: [Python-ideas] New explicit methods to trim strings

Steven D'Aprano wrote: The best thing is that there will no longer be any confusion as to whether you are looking at a Unicode string or a byte-string: a = a.new_string_trimmed_on_the_left() a = a.new_bytes_trimmed_on_the_left() To keep the RUE happy, instead of a "string" we should c

Re: [Python-ideas] Backward-incompatible changes for Python 4

Paul Moore wrote: now that Python has type inference, it should be possible for users to just type {} and have the interpreter work out which was intended from context. Or have {} return an ambiguous object that turns into a dict or set depending on what is done to it. We could call it a quict

Re: [Python-ideas] Backward-incompatible changes for Python 4

Anders Hovmöller wrote: Please let's all agree that April 1 is the worst day of the year. Agreed. In light of that, I propose that the datetime module in Python 4 be changed so that April 1 does not exist: >>> m31 = date(2019, 3, 31) >>> m31 + timedelta(days = 1) datetime.date(2019, 4, 2) Th

[Python-ideas] Add output() helper function to subprocess module

The check_output() function of the subprocess module raises an exception if the process returns a non-zero exit status. This is inconvenient for commands such as grep that use the return status to indicate something other than success or failure. The check_call() function has a companion call(),

Re: [Python-ideas] Add output() helper function to subprocess module

Nathaniel Smith wrote: On Thu, Apr 4, 2019 at 12:48 AM Greg Ewing wrote: output(args) --> (status, output) Isn't this already available as: run(args, stdout=PIPE)? Yes, but you need to do more than that to get the output as a string. This is the relevant part of the implement

Re: [Python-ideas] Add output() helper function to subprocess module

Chris Angelico wrote: +1 on adding a nice simple function, although I'm not 100% sold on the name "output". The idea is that output/check_output would go together like call/check_call. -- Greg ___ Python-ideas mailing list Python-ideas@python.org htt

Re: [Python-ideas] Syntax for allowing extra keys when unpacking a dict as keyword arguments

Bruce Leban wrote: I think this is a real problem given the frequent convention that you can freely add fields to json objects with the additional fields to be ignored. Unpacking json objects isn't something one does every day, so I don't think it would be worth adding syntax just for this. R

Re: [Python-ideas] Catching the return value of a generator at the end of a for loop

Jan Kaliszewski wrote: I like the idea -- occasionally (when dealing with `yield from`-intensive code...) I wish such a shortcut existed. Can you give a concrete example of a use case? -- Greg ___ Python-ideas mailing list Python-ideas@python.org htt

Re: [Python-ideas] Open parenthesis in REPL completion

Steven D'Aprano wrote: But having the opening bracket auto-added is a small satisfaction, and if you're using the REPL for actual calculations and not just help(), the benefit probably outweighs the annoyance The completer could detect the help( as well and leave out the opening paren in that

Re: [Python-ideas] Using rightarrow "->" for typing annotation of functions

Guido van Rossum wrote: Also, some groups of people would like to see a more concise notation for lambdas, and maybe they'd want to write x = (a, b) -> a + b We probably can't have both, I think we could if we wanted to. In an annotation, -> could be treated as sugar for Callable[], and in o

Re: [Python-ideas] What are the strong use cases for str.rindex()?

Steven D'Aprano wrote: I too often forget that reverse() returns an iterator, That seems like a mistake. Shouldn't it return a view? -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas

Re: [Python-ideas] Adding multiple constructors on one class

Steven D'Aprano wrote: Guido's time machine strikes again -- classes can have any number of constructors, and we've had the ability to do this since at least Python 2.2 if not earlier. Although I think the OP wants all the constructors to have the same name, which is more difficult to achieve

Re: [Python-ideas] More alternate constructors for builtin type

Steven D'Aprano wrote: That suggests a possible pair of constructors: bytes.from_int(n) -> equivalent to b'%d' % n bytes.ord(n) -> equivalent to bytes((n,)) I don't see how bytes.from_int(n) is any clearer about what it does than just bytes(n). If we're going to have named cons

Re: [Python-ideas] shutil.symlink - "avoid constant bool flags"

Tom Hale wrote: It seems far more practicable to have only two functions with sensible boolean defaults, with the split being based on the underlying os module function, namely os.link and os.symlink. Also the os module is designed to follow the C API of the OS as closely as practicable, so th

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Yanghao Hua wrote: I have explained the problem of use descriptors in previous replies, where you cannot have a local signal, e.g. obj.signal = thing # works, but local_signal = thing # doesn't work. Maybe you could do something like: local = Signals() local.signal1 = ... local.signal

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Yanghao Hua wrote: a different assignment behavior in HDL is your assignment does not take effect until a delta cycle of zero virtual time has passed. (did you really looked at the previous postings? :) You need to understand that most of the people reading this are not familiar with the workin

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Yanghao Hua wrote: If I use python to do something and I have to type more chars it doesn't make sense for me. If you shorten it to "n" you get x.n = 4 which is exactly the same number of characters as your "<==" proposal: x <== 4 Getting a bit more creative, you could use the little-kn

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Steven D'Aprano wrote: Yanghao Hua wants to customise the behaviour of assignment. I believe that he wants to emulate the behaviour of some hardware description languages, where the equals sign = doesn't mean assignment (if I have understood correctly, which I may not have), but Something Else.

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Steven D'Aprano wrote: The obvious solution to customising assignment is to use a dotted target: obj.x = value Another problem with this is that we don't want to customise *all* assignments. Sometimes we just want a regular Python assignment. (See my previous post about two different kin

Re: [Python-ideas] Implement POSIX ln via shutil.link and shutil.symlink

On Wed, May 29, 2019 at 10:07:38PM +0700, Tom Hale wrote: If somebody can create a file named link_name between unlink and symlink, he can also remove and create a file named link_name after symlink. I tbink there are some corner cases that can give different results if the sy

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Yanghao Hua wrote: is Python visioned in a way to allow users to define there own operators? No, it's not. Whenever the topic has come up, Guido has always said that he is against having user-defined syntax in Python. -- Greg ___ Python-ideas mailing

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Cody Piersall wrote: As Yanghao mentioned, the likeliest to use would be the in-place matmul operator (@=) but there are use cases where matrix-multiplication of signals would actually be useful too. My question on that is whether matrix multiplication of signals is likely to be used so heavily

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Stephen J. Turnbull wrote: There may be matrices of signals that do want to support multiplication, but that will be a different type, and presumably multiplication of signal matrices will be supported by "*". Then you lose the ability for '*' to represent elementwise multiplication of signal a

Re: [Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

Yanghao Hua wrote: Did Guido say "user defined syntax" or "user defined operator"? > ... for me defining new operator is different To my mind it's not that much different. A reader encountering an unfamiliar operator is pretty much faced with a new piece of syntax to learn. Its spelling gives l

<    1   2   3   4   5   6   7   8   9   >