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

Chris Angelico wrote: That's one of the reasons that a simple solution of "make JSONEncoder respect decimal.Decimal" was rejected - it would require that the json module import decimal, which is extremely costly. I don't follow that -- importing Decimal is a one-time cost, so it's not going to

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

Christopher Barker wrote: I don't think anyone else has come up with, any examples other than Decimal that require this "raw" encoding. It's possible that someone could have their own custom numeric type that they want to encode as a JSON number. But if the base code is enhanced to understand

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

Andrew Barnert wrote: I don’t see why 00.12 vs. 0.12 is a problem ... while 0.12 and 0.012E1 are not a problem at all. I don't think either of them are problems. Or to be more precise, I think that being able to use Decimal objects with JSON would be a good thing, even though it wouldn't

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

Andrew Barnert wrote: No you can’t. Decimal accepts strings that aren’t valid as JSON numbers, like `.3`, That's not a problem as long as it doesn't serialise them that way, which it wouldn't: >>> str(Decimal('.3')) '0.3' > or `nan`, The serialiser could raise an exception in that case.

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

Andrew Barnert wrote: Except that it doesn’t allow that. Using Decimal doesn’t preserve the difference between 1.E+3 and 1000.0, or between +12 and 12. That's true. But it does preserve everything that's important for interpreting it as a numerical value without losing any precision, which

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

Rhodri James wrote: I get what you want -- "this string of digits is the representation I want to use, please don't put quotes around it" -- but I can't help but feel that it will only encourage more unrealistic expectations. I think "consenting adults" applies here. Yes, you could use it to

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

Joao S. O. Bueno wrote: Short of a long term solution, like a __json__ protocol, or at least special support in Python json module for objects of type "numbers.Number", the only way to go, is, as you are asking, being able to insert "raw strings into json". No, that's not the only way. It

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

Paul Moore wrote: So you're proposing a change to the Python language stdlib implementation of that translation. Fine. But you have yet to provide a justification for such a change, I think it can be justified on the grounds that it allows all of the information in the JSON text to be

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

Richard Musil wrote: Even the number 0.64417266845703130 (note the last 0) is different JSON object from 0.6441726684570313 (without the last 0). And Python's Decimal type preserves that distinction: >>> Decimal("0.64417266845703130") Decimal('0.64417266845703130') >>>

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

Stephen J. Turnbull wrote: Richard Musil writes: > After some thinking it seems that the float is only case where this > "loss of a precision" happen. This is true of Unicode normalized forms as well as floats. But it's true in Python, where you have the option to not normalise your

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

Guido van Rossum wrote: I'm not sure I understand the desire to catch every possible exception right where it occurs. I've never felt this need somehow. This is my feeling too. I can't remember having a need for such needle-sharp targeting of exception catching, and if I ever did, it would be

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

Something I don't like about these kinds of proposals is that the except clause is far removed from the code that it covers, hurting readability. By the time you get to the end of a big for-loop or with-statement and see an "except", it's easy to forget that it isn't attached to an ordinary

[Python-ideas] Re: Namespace context managers

This proposal seems to be harking back to the meaning of 'with' in earlier languages, e.g. Pascal, where it makes the fields of a structure temporarily accessible without qualification. Before we got the current version of 'with' in Python, there were periodic proposals to add a similar kind of

[Python-ideas] Re: Cartesian Product on `__mul__`

Andrew Barnert via Python-ideas wrote: The usual set-theoretic definition of tuples is just recursively as ordered pairs: () is 0, (a) is a, (a, b) is , (a, b, c) is <, c>, etc. So, you don’t have to gloss over anything; s1 * s2 * s3 gives you elements ((a, b), c), but those are identical to

[Python-ideas] Re: Cartesian Product on `__mul__`

Batuhan Taskaya wrote: I think it looks very fine when you type {1, 2, 3} * {"a", "b", "c"} and get set(itertools.product({1, 2, 3}, {"a", "b", "c"})). So i am proposing set multiplication implementation as cartesian product. I'm not sure this would be used frequently enough to justify making

[Python-ideas] Re: something like sscanf for Python

Rhodri James wrote: scanf (or rather sscanf) always looks like a brilliant idea right up until I come to use it, at which point I almost always do something else that gives me better control. My experience is similar, but that's largely because error detection and reporting with the C version

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

Steven D'Aprano wrote: The only risk here is if your refactoring does something silly, such as reusing a variable which overrides assignment: What if the variable is bound inside a loop? Does that count as silly? -- Greg ___ Python-ideas mailing

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

Sorry if this has already been answered, but if it has I missed it. From your demo: class HistoricVar: def __getself__(self): return self.var What stops the reference to 'self' here from invoking __getself__ again? -- Greg ___

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

Andrew Barnert wrote: in Lisp, if you replace the setf macro, Okay, maybe Lisp wasn't a good example. In the presence of macros, all bets are off. :-( But at least if you haven't redefined the universe, local bindings in Lisp behave predictably. If you had code involving “x = 2” that stopped

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

Yanghao Hua wrote: this one, on the other hand, is truly generic and universal. The problem is that it's *too* universal. A __getself__ method would be a sorcerer's-apprentice kind of magic that you can't escape when you don't want it. Suppose you want to inspect an object for debugging

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

Yanghao Hua wrote: when you do x.y = z and if y is a descriptor you don't expect x.y is now pointing/binding to z, you have to understand the object behavior anyway. I do not see how this is different in the set/getself() case. The difference is that the special behaviour is associated with

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

Anders Hovmöller wrote: On 26 Jun 2019, at 16:46, Chris Angelico wrote: it violates programmer expectations *across many languages* regarding refactoring. isn't that potentially extremely different in C++ for example? Yes, but it's pretty universal across languages with name-binding

[Python-ideas] Re: `if-unless` expressions in Python

James Lu wrote: I think print("Remember to wear sunscreen!") if hot_outside unless Weather.is_raining() Is more readable than if hot_outside and not Weather.is_raining(): print("Remember to wear sunscreen!") That's very much a matter of opinion -- I find the second version considerably

[Python-ideas] Re: Add «iterate non-blocking» wrapper to prevent blocking loop too long

Gustavo Carneiro wrote: 1. If you don't yield in the for loop body, then you are blocking the main loop for 1 second; 2. If you yield in every iteration, you solved the task switch latency problem, but you make the entire program run much slower. It sounds to me like asyncio is the wrong

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

Stephen J. Turnbull wrote: Note that signal matrices will almost certainly be a completely different type from signals, so as far as the compiler is concerned there's no conflict between "@=" for signal injection and "@=" for signal matrix multiplication. Except that if @= represents signal

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

Kyle Lahnakoski wrote: Here is a half baked idea: class A: def assign(self, other): # whatever this means setattr(A, "<==", A.assign) Some things that would need to be addressed to fully bake this idea: * What determines the precedence of these new operators? * How to

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

Yanghao Hua wrote: You are absolutely right in that writing a new parser might not be a bad idea, but it is just s close for enabling Python to be used as the DSL language. You seem to be arguing for this as an enabler for using Python for DSLs in general, but you're really only talking

[Python-ideas] Re: Assign-in-place operator

Stephen J. Turnbull wrote: L[m:m+k] specifies that a list operation will take place on the k elements starting with m. As a value, it makes a new list of references to those elements. Even that is specific to lists. There's no requirement that a RHS slice has to create new references to

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

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

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

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

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

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

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

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

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 = ...

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

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

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

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

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.

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

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 implementat

[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] 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)

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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]

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

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"

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,

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

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

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

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

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

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

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

<    1   2   3   4   5   6   7   8   9   >