Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

09:54:05AM -0700, Steve Dower wrote: > On 23May2019 2355, Steven D'Aprano wrote: > >I don't know if this is a good idea or a terrible idea or somewhere in > >between, so I'm throwing it out to see if anyone likes it. > > > >Let's add a third option t

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Mon, May 27, 2019 at 08:15:01AM -0700, Nathaniel Smith wrote: [...] > I'm not as sure about the locals() parts of the proposal. It might be > fine, but there are some complex trade-offs here that I'm still trying > to wrap my head around. The rest of this document is me thinking out > loud to tr

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Tue, May 28, 2019 at 08:37:17AM +0100, Paul Moore wrote: > Of course, all of this is only if we have decided to formalise the > semantics and change CPython to conform. I've never personally been > affected by any of the edge cases with locals(), so on a purely > personal basis, I'm equally hap

Re: [Python-Dev] Overloading comparison operator for lists

Hi Montana, As Cameron Simpson already pointed out, your query is off-topic for the Python-Dev mailing list and should be taken to the Python-Ideas mailing list, which is for speculative discussion of new designs. Like Cameron, I've CCed Python-Ideas. Please send any follow-ups to that list an

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote: > Armin Rigo wrote: > >You have the occasional big function that benefits a lot from being > >JIT-compiled but which contains ``.format(**locals())``. > > There should be a lot less need for that now that we have f-strings. I think you'r

[Python-Dev] Re: python-ideas and python-dev migrated to Mailman 3/HyperKitty

On Wed, Jun 05, 2019 at 11:08:13AM +0200, Victor Stinner wrote: > Hi, > > Our kind postmasters Mark Sapiro and Abhilash Raj migrated > python-ideas and python-dev mailing lists from Mailman 2 to Mailman 3 > (running on Python 3 ;-))! Great! But email footers are currently broken: > Python-Dev m

[Python-Dev] Re: python-ideas and python-dev migrated to Mailman 3/HyperKitty

On Wed, Jun 05, 2019 at 11:08:13AM +0200, Victor Stinner wrote: > Enhancements: > * More reliable "permalink" URLs to emails This is excellent... but the old pipermail URLs were typically something like 70-80 characters, which means they fit nicely into emails (and comments in source code). H

[Python-Dev] Re: Enum and annotations

On Mon, Jun 10, 2019 at 02:29:56PM -0700, Ethan Furman wrote: > Greetings! > > I saw my first annotation mix-up with regards to Enum today: [...] I don't think this is particular to Enums. I think this is going to be a stumbling block for any class. py> class X: ... a: 1 ... b: 2 ... py

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

On Fri, Jun 28, 2019 at 01:08:45AM +1000, Chris Angelico wrote: > Help on built-in function lstrip: [...] > This does NOT remove a leading substring. It removes a set of characters. This is a re-occurring painpoint and gotcha. I've fallen for it myself. I really think it's long past time we bite

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

On Fri, Jun 28, 2019 at 09:56:26AM -0700, Mariatta wrote: > Hi, > > I've updated PEP 581 yesterday, adding the "Downsides of GitHub" section. > > https://www.python.org/dev/peps/pep-0581/#downsides-of-github You have missed at least one: the minimum technology requirement for using Github is a

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

On Sat, Jun 29, 2019 at 10:26:04AM -0500, Skip Montanaro wrote: > > You have missed at least one: the minimum technology requirement for > > using Github is a lot more stringent than for Roundup. Github's minimum > > system requirements are higher, and it doesn't degrade as well, so > > moving to G

[Python-Dev] Re: What is a public API?

On Sat, Jul 20, 2019 at 06:03:39AM -, Kyle Stanley wrote: > Rather than it being on a case-by-case basis, would it be reasonable > to establish a universal standard across stdlib for defining modules > as public to apply to older modules as well? No, I don't think so. That would require cod

[Python-Dev] Re: What is a public API?

On Mon, Jul 22, 2019 at 10:02:12PM -, Kyle Stanley wrote about renaming non-public names with a leading underscore: > Good point, this would probably have to be a gradual change if it did > happen, rather than being at all once. If it were to happen with a > proper deprecation cycle and cle

[Python-Dev] Re: Replacing 4 underscores with a $ sign, idea for a PEP

Hi Karl, Email should not have a latency of "several hours" unless there is something seriously wrong, perhaps your mail server (your ISP?) is broken. Or possibly you're still being moderated: we recently changed to moderating newcomers, in response to a flurry of spam. As a newcomer to this c

[Python-Dev] Re: Comparing dict.values()

On Tue, Jul 23, 2019 at 08:59:09PM -, Kristian Klette wrote: > Hi! > > During the sprints after EuroPython, I made an attempt at adding support for > comparing the results from `.values()` of two dicts. > > Currently the following works as expected: > > ``` > d = {'a': 1234} > > d.keys() ==

[Python-Dev] Re: Comparing dict.values()

On Tue, Jul 23, 2019 at 10:02:34PM -0400, Terry Reedy wrote: [...] > If one has not learned the default meaning of '==' in Python. Perhaps > this should be given more emphasis in beginner courses. "What does it > mean for two object to be 'equal'?" It is not a trivial question. No, it is not

[Python-Dev] Re: Comparing dict.values()

On Wed, Jul 24, 2019 at 05:30:19PM -, Brett Cannon wrote: > When I saw this I thought, "it should be like `set(d1.values()) == > set(d2.values())`", but has been pointed out there's no guarantee that > all values will be hashable. The hashability requirement for sets is, in a sense, an impl

[Python-Dev] Re: Comparing dict.values()

On Fri, Jul 26, 2019 at 12:57:42AM -0400, Random832 wrote: > On Fri, Jul 26, 2019, at 00:22, Ivan Pozdeev via Python-Dev wrote: > > Since a hash table is an unordered container and keys(), items() and > > values() are iterators over it, *I would expect the results of any of > > the comparisons to

[Python-Dev] Re: Comparing dict.values()

On Wed, Jul 24, 2019 at 08:25:31PM -0400, David Mertz wrote: > Exactly! that was my thought that the exception message could hint at > likely approaches. The NumPy example seems to have a good pattern: > > arr1 == arr2 > > ValueError: The truth value of an array with more than one element is > am

[Python-Dev] Re: Comparing dict.values()

On Thu, Jul 25, 2019 at 05:53:47PM +0200, Antoine Pitrou wrote: > On Wed, 24 Jul 2019 19:09:37 -0400 > David Mertz wrote: > > > > There are various possible behaviors that might make sense, but having > > `d.values() != d.values()` is about the only one I can see no sense in. > > Why? Does the f

[Python-Dev] Re: Comparing dict.values()

On Wed, Jul 24, 2019 at 12:36:29PM +0200, Ronald Oussoren wrote: > > > Op 24 jul. 2019 om 02:27 heeft Steven D'Aprano het > volgende geschreven: > > > But I can suggest at least one useful invariant. If a, b are two dicts: > > > >a.items() == b.item

[Python-Dev] Re: Comparing dict.values()

On Thu, Jul 25, 2019 at 10:15:15AM +1200, Greg Ewing wrote: > What I'm getting from this thread is that there are a variety of > possible behaviours for dict values comparison, any of which could > be considered "correct" depending on what the programmer is trying > to do. Can you elaborate on th

[Python-Dev] Re: Comparing dict.values()

On Fri, Jul 26, 2019 at 08:41:40PM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > The hashability requirement for sets is, in a sense, an implementation > > detail. It might be a requirement for sets in Python the language, > > but its not a r

[Python-Dev] Re: Comparing dict.values()

On Sun, Jul 28, 2019 at 10:18:56PM +0200, Antoine Pitrou wrote: > On Fri, 26 Jul 2019 20:28:05 +1000 > Steven D'Aprano wrote: > > So there are no conceptual problems in defining equality for value > > views. Putting aside efficiency, this is easy to solve. > >

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 07, 2019 at 10:41:25AM +1200, Greg Ewing wrote: > Rob Cliffe via Python-Dev wrote: > > > >Sorry, that won't work. Strings are parsed at compile time, open() is > >executed at run-time. > > It could check for control characters, which are probably the result > of a backslash accident.

[Python-Dev] Re: What to do about invalid escape sequences

On Tue, Aug 06, 2019 at 08:14:35AM +0200, Michael wrote: > For "filenames" you could, perhaps, make an exception in the calls that > use them. e.g., when they are hard-coded in something such as > open("..\training\new_memo.doc"). Functions such as open cannot tell whether their argument was prov

[Python-Dev] Re: What to do about invalid escape sequences

This really is a hairy one. The current behaviour encourages people to use a single backslash when they should be using a double, but that works only sometimes. Should you include an escape or not? Sometimes the backslash stays and sometimes it disappears: py> "abc \d \' xyz" "abc \\d ' xyz"

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 07, 2019 at 10:14:08AM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 10:03 AM Steven D'Aprano wrote: > > - Keep the SyntaxWarning silent by default for 3.8. That gives us > > another year or more to gently pressure third-party libraries to fix > > th

[Python-Dev] Re: What to do about invalid escape sequences

On Tue, Aug 06, 2019 at 07:58:12PM -0700, Nathaniel Smith wrote: > For example, all my projects run tests with deprecation warnings > enabled and warnings turned into errors, but I never saw any of these > warnings. What happens is: the warning is issued when the .py file is > byte-compiled; but a

[Python-Dev] Re: What to do about invalid escape sequences

On Wed, Aug 07, 2019 at 02:33:51PM +1000, Chris Angelico wrote: > On Wed, Aug 7, 2019 at 1:54 PM Steven D'Aprano wrote: > > Don't think of this as a failure. Think of it as an opportunity: we've > > identified a weakness in our deprecation process. Let's f

[Python-Dev] Re: PEP 640: Unused variable syntax.

I can't say that I like the look of pseudo-assignment to question mark: for ? in range(20): ... but I could probably learn to live with it. But one of your rationalisations: > and makes it more obvious that > the actual intent is for the value to be unused -- since it is entirely >

[Python-Dev] Re: Speeding up CPython

A very interesting proposal. A couple of thoughts... Can we have an executive summary of how your proposed approach differs from those of PyPy, Unladen Swallow, and various other attempts? You suggest that payment should be on delivery, or meeting the target, rather than up-front. That's good

[Python-Dev] Re: PEP 640: Unused variable syntax.

On Tue, Oct 20, 2020 at 01:41:02PM +0200, Thomas Wouters wrote: > > a, *?, b = expression > > print(?) # wait this doesn't work; > > > > I'm not sure how this is different than, say, > > a, _, _ = range(3) > print(_) For starters, that will actually print something, not fail wi

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 02:37:02AM +1100, Chris Angelico wrote: > Do you have any details to back this up? You're not just asking for a > proposal to be accepted, you're actually asking for (quite a bit of) > money, and then hoping to find a contractor to do the actual work. Payment is on deliver

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 02:38:25AM +1100, Chris Angelico wrote: > On Wed, Oct 21, 2020 at 12:55 AM Steven D'Aprano wrote: > > A minor point, and I realise that the costs are all in very round > > figures, but they don't quite match up: $2 million split over five > >

[Python-Dev] Re: Speeding up CPython

On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: > What I don't see is where the money's coming from. It's fine to ask, > but will anyone come up with that sort of funding? I don't think Mark is asking for you or I to fund the exercise. He's asking for the PSF to fund it. I think tha

[Python-Dev] Re: Speeding up CPython

On Wed, Oct 21, 2020 at 09:06:58AM +0200, Christian Heimes wrote: > On 21/10/2020 00.14, Steven D'Aprano wrote: > > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote: > > > >> What I don't see is where the money's coming from. It's fine to ask,

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

On Thu, Oct 22, 2020 at 09:48:54AM -0700, Guido van Rossum wrote: > After the pattern matching discussion died out, we discussed it with the > Steering Council. Our discussion ended fairly positive, but there were a > lot of problems with the text. We decided to abandon the old PEP 622 and > break

[Python-Dev] Re: fail keyword like there is pass keyword

On Fri, Oct 23, 2020 at 01:06:36PM -0700, Ethan Furman wrote: > >I think having a *fail* keyword for unit testing > >would be great. > > Luckily, we already have it: > > assert False I take it you don't run your unit tests under -O :-) `raise Exception` works fine for me. -- Steve

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Thank you for the well-written PEP, although I don't agree with it. My response below is quite long. Here is my opinionated TL;DR: (1) Just get over the use of `_` for the wildcard pattern. another identifier. Now that the parser will support soft keywords, we should expect more cases that som

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat, Oct 31, 2020 at 10:22:09PM +1100, Steven D'Aprano wrote: > (1) Just get over the use of `_` for the wildcard pattern. > another identifier. Now that the parser will support soft keywords, we > should expect more cases that something that is an identifier is one >

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Mon, Nov 02, 2020 at 03:31:44PM +0100, Thomas Wouters wrote: > On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano > wrote: > > > > > I really don't get why so many people are hung up over this minuscule > > issue of giving `_` special meaning inside match

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote: > If "_" is a non-binding wildcard, linters will have to allow > "case _, _" otherwise it might as well not be there. And then > if it is later changed to be binding, Why would we want to do that? Apart from the backward incompatibilit

[Python-Dev] Re: review for doctest fix: bpo-35753

For the benefit of others, the problem is that `unittest.mock.call.__wrapped__` generates a new object, which in turn has a dynamic `__wrapped__` attribute, which does the same, thus generating an infinite chain of *distinct* proxies. Being distinct proxy objects defeats the loop detection algo

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

On Tue, Nov 10, 2020 at 03:33:06AM +1100, Chris Angelico wrote: > If that were to happen, what I'd prefer is to cut lots of info out of > the *TUTORIAL* and make a new document called, say, *Python Advanced > Techniques* or something, which could still have the narrative style > but would be aimed

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Thu, Nov 12, 2020 at 09:40:02PM +0300, Paul Sokolovsky wrote: > match foo: > case ("foo", >val1): > ... > case ("bar", >val2): > ... > 1. Much more intuitive for beginners. (If Python adopts it, I see > other "user-friendly" languages adopting the same pattern in the >

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

On Sun, Nov 15, 2020 at 12:48:50PM +0300, Paul Sokolovsky wrote: > Just to give one example, literally at the very beginning, at the > "Pattern Matching and OO" section (3rd heading) it says: If it's the third heading, it's not *literally* at the very beginning. > > Pattern matching is complime

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

On Sun, Nov 15, 2020 at 03:18:29PM +0300, Paul Sokolovsky wrote: > > > amount of work to implement pattern matching is certainly an order > > > of magnitude larger than to introduce constants [...] [Steve] > > Here's a toy proposal, > [] > > The baseline of my version is much simpler: > > # T

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

On Sat, Nov 14, 2020 at 11:11:37PM +1000, Nick Coghlan wrote: > On Fri, 13 Nov 2020 at 09:39, David Mertz wrote: > > > > I have read a great deal of discussion on the pattern matching PEPs and > > less formal discussions. It is possible I have overlooked some post in all > > of that, of course.

[Python-Dev] Re: Words rather than sigils in Structural Pattern Matching

On Tue, Nov 17, 2020 at 08:49:28AM +0100, Marco Sulla wrote: > PS: pattern matching, for a mere mortal like me, seems to be something very > exotical. Have you ever written code that looks like this? if isinstance(obj, tuple) and len(obj) ==3: x, y, z = obj elif isinstance(obj,

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

On Tue, Nov 17, 2020 at 09:55:46AM +, Mark Shannon wrote: > Hi, > > I'm wondering why > ``` > x = "value" > try: > 1/0 > except Exception as x: > pass > ``` > > does not restore "value" to x after > the `except` block. Because try, if, for, while, with etc. don't create a new scope.

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

On Tue, Nov 17, 2020 at 12:36:31PM -0500, Richard Damon wrote: > My main thought on that variable, is I would expect it to have a good > name that implies it is an exception, Something like "e" or "err" then, which are the two most common choices I have seen in exception handling code. > not so

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

On Wed, Nov 18, 2020 at 08:45:10AM +1100, Chris Angelico wrote: > On Wed, Nov 18, 2020 at 8:38 AM Steven D'Aprano wrote: > > To start with, what else are they using "e" for? Surely it would be more > > important to use a better name *there* rather than cha

[Python-Dev] Re: The semantics of pattern matching for Python

On Fri, Nov 20, 2020 at 02:23:45PM +, Mark Shannon wrote: > Why force pattern matching onto library code that was not designed for > pattern matching? It seems risky. Can you give a concrete example of how this will "force" pattern matching onto library code? I don't think that anyone has s

[Python-Dev] Re: Advantages of pattern matching - a simple comparative analysis

On Mon, Nov 23, 2020 at 08:44:21PM +, David Mertz wrote: > Basically, I agree matching/destructuring is a powerful idea. But I also > wonder how much genuinely better it is than a library that does not require > a language change. For example, I could create a library to allow this: > > m =

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

On Sun, Nov 29, 2020 at 12:10:39AM +0300, Paul Sokolovsky wrote: > And we don't speak about some obscure "innovative" idea. Const'ness > aka immutability is well-known and widely used feature in programming > languages. Constantness and immutability are not synonyms. Immutability refers to *obje

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

Paul, You seem to be intent on alienating and driving away as many people as possible. If I may play the amateur psychologist for a moment, I fear that you are unconsciously sabotaging your own proposals. Better to be the genius whose proposals are dragged down by jealous and uncomprehending l

[Python-Dev] Re: unittest of sequence equality

On Tue, Dec 22, 2020 at 06:33:41PM -0500, Alan G. Isaac wrote: > This comment completely misses the point. > This "weird type" qualifies as a Sequence. > (See collections.abc.) It's not weird because of the sequence abc, it's weird because of its treatment of equality, using the `==` operator as

[Python-Dev] Re: unittest of sequence equality

On Sat, Jan 09, 2021 at 07:56:24AM -0500, Alan G. Isaac wrote: > This comment misses the key point, which is: > `assertSequenceEqual` should not rely > on behavior that is not ensured for typing.Sequence, > but it currently does. The failure on a numpy array > simply exposes this problem. You are

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote: > That'd leave open > the option for "foo() if x else foo()" to be optimized down to just > "foo()", although I don't think that particular one is needed. That would be an unsafe optimization. Not all objets are representable as tru

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 08:27:46PM +1100, Chris Angelico wrote: > It's a lot faster for C-implemented functions to require positional > parameters. A number of functions had help text that implied that they > accepted keyword-or-positional args, but if you tried to call them > with keyword args, t

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 02:08:01AM -0800, Emily Bowman wrote: > Even if you define __bool__() as returning a bool, and error/undefined > behavior otherwise, that doesn't eliminate side effects. Is it even > possible to nail down a definition to the point that you can say, "Thou > shalt not mutate

[Python-Dev] Re: 3.10 change (?) for __bool__

On Wed, Jan 13, 2021 at 08:17:26PM +0300, Paul Sokolovsky wrote: > > Besides, we probably don't want to prohibit side-effects in > > `__bool__`. That would prohibit useful tricks such as putting logging > > calls into a method you are trying to debug. > > Surely, if we do that, we wouldn't use Ha

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Mon, Jan 25, 2021 at 06:17:09PM +0100, Victor Stinner wrote: > Hi Bernat, > > "stdlib_module_names" was my first idea but it looks too long, so I > chose "module_names". But someone on Twitter and now you asked me why > not "stdlib_module_names", so I wrote a PR to rename module_names to > sys.

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Tue, Jan 26, 2021 at 12:08:03PM -0800, Brett Cannon wrote: > On Tue, Jan 26, 2021 at 1:26 AM Antoine Pitrou wrote: [...] > > Disagreed. This is niche enough that it warrants a long but explicit > > name, rather than some ambiguous shortcut. > > > > I agree w/ Antoine that a more descriptive

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Tue, Jan 26, 2021 at 11:19:13PM +0100, Victor Stinner wrote: > On Tue, Jan 26, 2021 at 10:04 PM Steve Dower wrote: > > > > On 1/26/2021 8:32 PM, Steve Holden wrote: > > > If the length of the name is any kind of issue, since the stdlib > > > only contains modules (and packages), why not just sy

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Tue, Jan 26, 2021 at 10:56:57AM +0100, Victor Stinner wrote: > On Tue, Jan 26, 2021 at 12:44 AM Steven D'Aprano wrote: [...] > > Your first instinct that it is too long is correct. Just call it > > "stdlib" or "stdlib_names". The fact that it is

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Wed, Jan 27, 2021 at 10:44:00AM +0100, Antoine Pitrou wrote: > Ok, then "stdlib_package_names"? :-) Heh :-) I see your smiley, and I'm not going to argue about the name any further. I have my preference, but if the consensus is stdlib_module_names, so be it. But I think the inconsistency b

[Python-Dev] Re: Concerns about PEP 634

On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote: > On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico wrote: > > How will a __future__ import help here? Are there syntactic or > > behavioural changes that would be worth applying to some modules and > > not others? The entire point of a

[Python-Dev] Re: Concerns about PEP 634

On Sun, Feb 07, 2021 at 09:58:03AM +0300, Paul Sokolovsky wrote: > > A feature doesn't need to be a `__future__` import for you to just > > not use it. > > Right, and the talk is about the opposite - early adopters of > PEP634-style pattern matching should mark the modules in which they > *use* P

[Python-Dev] Re: Concerns about PEP 634

On Sun, Feb 07, 2021 at 12:32:40PM +0300, Paul Sokolovsky wrote: > And nobody says that there will be *incompatible* changes to the > pattern matching, just that previous experience, and discussion of the > PEP622/PEP634 shows that there's a probability of that (higher than > usual). Fine. The ti

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Fri, Feb 12, 2021 at 10:27:01AM +, Mark Shannon wrote: > It impairs readability, because it muddles the return type. > The function in the example returns a bool. > The annotation is also misleading as the annotation is on the return > type, not on the parameter that is narrowed. > > At a

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On Sat, Feb 13, 2021 at 07:48:10PM -, Eric Traut wrote: > I think it's a reasonable criticism that it's not obvious that a > function annotated with a return type of `TypeGuard[x]` should return > a bool. [...] > As Guido said, it's something that a developer can easily > look up if they ar

[Python-Dev] Re: Python 0.9.1

On Tue, Feb 16, 2021 at 05:49:49PM -0600, Skip Montanaro wrote: > If someone knows how to get the original Usenet messages from what Google > published, let me know. I don't have those, but I do have a copy of Python 0.9.1 with unmangled scripts. $ ls -lh Python-0.9.1.tar.gz -rwxr-xr-x 1 steve

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Fri, Feb 26, 2021 at 11:41:56AM +0900, Stephen J. Turnbull wrote: > Mike Miller writes: > > > "sys-admin" is a bit of an overstatement in my phrasing. The core > > is that you need to understand how a PATH works and be able to run > > pip and cd into folders and perhaps run rm/del, etc. Ba

[Python-Dev] Re: Which thing is "Development Mode"

Hi Coyot, and welcome! Can you explain the circumstances where a developer, or an end user, might be confused as to which development mode is meant? "Dev mode" is a very common term: Windows 10 has a development mode. So does the X-Box and the Samsung Galaxy phone. Ruby on Rails also has a dev

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Sat, Feb 27, 2021 at 01:04:08AM +, Oscar Benjamin wrote: > On Fri, 26 Feb 2021 at 23:06, Jim J. Jewett wrote: > > > > I think his point is that most of his students (economics or > > business, rather than comp sci) will never need to use Perl or C or > > Java. Python is friendly enough

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Sat, Feb 27, 2021 at 12:56:17PM +, Oscar Benjamin wrote: > On Sat, 27 Feb 2021 at 11:04, Paul Moore wrote: > > This is 100% true. (At least the part where you say that "it's a > > problem". I'm not sure if "it doesn't need to be like this" is true - > > can you point to a language where th

[Python-Dev] Python history: origin of the arrow annotation

I was curious how and why return annotations use the arrow `->` symbol, so I went spelunking into the depths of the Python-Ideas and Python-Dev mailing lists. Much to my surprise, I couldn't find any discussion or debate about it. Eventually I tracked the discussion back to a mailing list I did

[Python-Dev] Re: Steering Council update for February

On Tue, Mar 09, 2021 at 06:42:24PM -0800, Barry Warsaw wrote: > The Steering Council unanimously believes this is the right thing to do. Diversity is a wonderful thing. We should get some. -- Steve ___ Python-Dev mailing list -- python-dev@python.org

[Python-Dev] Re: Steering Council update for February

On Tue, Mar 09, 2021 at 08:27:19PM +, Pablo Galindo Salgado wrote: >The Steering Council discussed renaming the master branch to main and >the consensus was that we should do that. And about time too. Can we now tackle some of the equally pressing use of offensive terms that are com

[Python-Dev] Re: Steering Council update for February

Evpok, did you think I was joking? I think it is a terrible thing for you to accuse me of being "derogatory" and threaten me with the CoC because I have said we need to do better. It sounds like you are making light of the real pain people are suffering, every bit as real if not more so than th

[Python-Dev] Re: Steering Council update for February

On Wed, Mar 10, 2021 at 02:23:33PM +, David Mertz wrote: > >> It even has a symbol for chains, which is associated even more > >> closely with slavery than "master". > >> > > > All the other examples are also forced and contrived. This is perhaps > worst. I own several chains for purposes ha

[Python-Dev] Re: In what tense should the changelog be written?

On Thu, Apr 29, 2021 at 09:52:14PM -0700, Larry Hastings wrote: > > > D'oh!  I have a second draft already. > >Your NEWS entry should be written in the /present tense,/ and should >start with a verb: Without a subject of the sentence, that's not present tense, it is the imperative mood

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Fri, May 07, 2021 at 06:02:51PM -0700, Chris Jerdonek wrote: > To know what compression methods might be effective, I’m wondering if it > could be useful to see separate histograms of, say, the start column number > and width over the code base. Or for people that really want to dig in, > maybe

[Python-Dev] Re: Speeding up CPython

On Tue, Oct 20, 2020 at 01:53:34PM +0100, Mark Shannon wrote: > Hi everyone, > > CPython is slow. We all know that, yet little is done to fix it. > > I'd like to change that. > I have a plan to speed up CPython by a factor of five over the next few > years. But it needs funding. I've noticed a

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

Hi Chris, On Fri, May 07, 2021 at 07:13:16PM -0700, Chris Jerdonek wrote: > I'm not sure why you're sounding so negative. Pablo asked for ideas in his > first message to the list: I know that Pablo asked for ideas, but that doesn't mean that we are obliged to agree with every idea. This is a di

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Mon, May 10, 2021 at 05:34:12AM -0400, Terry Reedy wrote: > On 5/10/2021 3:28 AM, M.-A. Lemburg wrote: > > >I'm mostly thinking of tracebacks which go >10 levels deep, which is > >rather common in larger applications. For those tracebacks, the top > >entries are mostly noise you never look at w

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote: > The vanilla interpreter could be updated to recognize when it is running > on a similated 35-year-old terminal that implements ansi-vt100 color > codes rather than a similated 40+-year-old black-and-white teletype-like > terminal.

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Thu, May 13, 2021 at 09:18:27AM +0100, Mark Shannon wrote: > Since, faster == less energy for the same amount of work, making CPython > faster will reduce the amount of CO2 produced to do that work and > hopefully make it less of a concern. Work expands to fill the time available: if Python

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Thu, May 13, 2021 at 03:20:31AM -0400, Terry Reedy wrote: > What is the purpose of this PEP? It seems in part to be like a > Standards Track PEP in that it proposes a new (revised) implementation > idea for the CPython bycode interpreter. Do you not intend this to not > constitute approval

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

On Thu, May 13, 2021 at 08:44:04AM -0700, Christopher Barker wrote: > I suggest we keep it really simple, and name the implementation. > > Building on Steve Holden’s suggestion: > > There is broad interest in improving the performance of the cPython > runtime. (Interpreter?) +1 As excellent as

[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

On Thu, May 27, 2021 at 11:18:16AM +1200, Greg Ewing wrote: > >On Wed, May 26, 2021 at 8:55 AM Ammar Askar >> wrote: > > > >most > >recently if your topic mentioned libera.chat, the new freenode owners > >will take it over, ban anyone from chatting in it an

[Python-Dev] Re: Problems with dict subclassing performance

On Thu, Aug 12, 2021 at 08:26:47AM +0200, Marco Sulla wrote: > No ideas? Excuse me for the up. Perhaps you can be more concrete in what you expect from this mailing list. Are you looking for upvotes on StackOverflow (or however it works there)? Or for some core dev to acknowledge that your anal

[Python-Dev] Re: Is anyone relying on new-bugs-announce/python-bugs-list/bugs.python.org summaries

I rely heavily on the new-bugs-announce list, and the email sent by Roundup to people on the Nosy list of a task. I don't care about the weekly summary emails. I don't know what the python-bugs-list is used for. -- Steve ___ Python-Dev mailing list

[Python-Dev] Re: PEP 667: Consistent views of namespaces

On Sat, Aug 21, 2021 at 05:46:52PM -0700, Guido van Rossum wrote: > Hopefully anyone is still reading python-dev. I am :-) [...] > Everything here is about locals() and f_locals in *function scope*. (I use > f_locals to refer to the f_locals field of frame objects as seen from > Python code.) And

[Python-Dev] Re: PEP 667: Consistent views of namespaces

On Fri, Aug 20, 2021 at 04:22:56PM +0100, Mark Shannon wrote: > Hi all, > > I have submitted PEP 667 as an alternative to PEP 558. > https://www.python.org/dev/peps/pep-0667 Specification has a code snippet: def test(): x = 1 l()['x'] = 2 l()['y'] = 4 l()['z'

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote: > I think Nick is on board with bytes.fromint() and no bchr(), and my > sense of the sentiment here is that this would be an acceptable > resolution for most folks. Ethan, can you reconsider? I haven't been completely keeping up wit

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Thu, Sep 09, 2021 at 10:57:26AM +0200, Victor Stinner wrote: > I propose to rename PEP 467 method bytes.fromint(n) to => > bytes.fromchar(n) <= to convert an integer to a single *character*: it > fails if n is not in the [0; 255] range. "char" comes from > "character", as "bchr()" means "bytes

[Python-Dev] Re: PEP 467 feedback from the Steering Council

On Wed, Sep 08, 2021 at 05:06:08PM -, Brandt Bucher wrote: > Steven D'Aprano wrote: > > To me, it sounds like should be the opposite of int.from_bytes. > > >>> int.from_bytes(b'Hello world', 'little') > > 121404708502361365413651784

<    1   2   3   4   5   6   7   8   9   10   >