Re: [Python-Dev] PEP 558: Defined semantics for locals()

On Sun, May 26, 2019 at 08:04:11PM +1000, Steven D'Aprano wrote: > Richard, your email seems to have introduced a spurious "SPAM" label [...] > edit the subject line to remove the > label? Thanks. I've done so for this response

Re: [Python-Dev] PEP 558: Defined semantics for locals()

olved when you have a trace hook; - make the current CPython behaviour a language behaviour. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/

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

On Sun, May 26, 2019 at 04:03:11PM +0300, Ivan Pozdeev via Python-Dev wrote: > On 24.05.2019 9:55, 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. [...]

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

is simple and understandable. > Consistency across contexts: it's surprising if locals() has acts > differently in module/class scope versus function scope. This argues > for [proxy]. True as far as it goes, but its also true that for the lon

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

asis, I'm equally happy with "do nothing" :-) I don't think "Do Nothing" is a good option, because (as I understand it) the status quo has some weird bugs when you have tracing functions written in Python (but not in C?). So something has to change, one

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

ist comprehension, but the other technique is to subclass list, override ``__eq__`` and give it the behaviour you want. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https:/

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

't help is when the template is dynamically generated. It may be that there will be less new code written using **locals() but I don't think that the **locals() trick will disappear any time before Python 5000. -- Steven ___ Python-Dev

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

: > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > %(web_page_url)slistinfo/%(_internal_name)s > Unsubscribe: %(user_optionsurl)s -- Steven ___ Python-Dev mailing list

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

r permalink form available, like goo.gl, bitly, youtu.be etc use? That would be awesome if we could use them instead. -- Steven Python-Dev mailing list -- python-dev(a)python.org To unsubscribe send an email to python-dev-leave(a)python.org https://mail.python.org/mailman3/lists/python-dev.python.org/

[Python-Dev] Re: Enum and annotations

ts. It doesn't matter there, because its a syntax error. If I wrote more class attributes, I'd probably make this error occassionally too. I think this is going to especially bite beginners, who tend to write more class attributes. (Especially those coming from oth

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

ong past time we bite the bullet and add a pair of methods to strip a prefix and suffix from strings. My preferred bikeshed colour would be strip_prefix and strip_suffix. Will this need a PEP? -- Steven ___ Python-Dev mailing list -- python-d

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

submit a PR for this except, well, see above... -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at htt

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

ript. Clicking hyperlinks is fine, but things like buttons with dropdown menus, the hamburger icon, the Clone/Download button etc do nothing when I click on them. For what it's worth, I'm not using an ad blocker but I am using a moderately old Firefox. -- Steven __

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

for example sys.__stdout__ and friends, since your test for a private name may be overzealous. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman

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

or developers. That cost is why we have the rule "unless explicitly documented public, all imports are private even if not prefixed with an underscore". All these costs strongly suggest to me that we shouldn't try to "fix" the entire std lib. Let

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

ttps://mail.python.org/archives/list/python-id...@python.org -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Messa

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

but I think in the case of views, we should at least fall back on identity of the underlying dicts, even if we decide the more complex tests are not worth the trouble. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubs

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

= b.count(x) for x in a) Given that we cannot rely on the values being hashable or even sortable, I don't know how to make it more efficient in the general case. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe se

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

me a doc update for dict.values() stating that the iterator can't > be compared and a brief mention as to why would be the best solution > for this. We're not talking about comparing iterators. We're talking about comparing views into a dict. That's a difference that m

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

logics usually model the complexities of the real world much better than boolean logic, but the assumption of boolean logic and the law of the excluded middle is too prevalent to mess with in the builtins. http://mathworld.wolfram.com/LawoftheExcludedMiddle.html https://en.wikipedia.org/w

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

k the law of excluded middle, and implement de-facto multi-valued logic (where an exception == Maybe), but we shouldn't have builtins do that. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an ema

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

== b.count(x) for x in a) The .count method could be implemented like this: def count(self, x): n = 0 for a in self: if a == x: n += 1 return n So there are no conceptual problems in defining equality for value views. Putting aside efficiency, this is easy to

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

e suggest it. [1] Again, setting aside the current behaviour inherited from object, and raising an exception. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.pytho

[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

result > of a backslash accident. Maybe even auto-correct them... http://www.catb.org/jargon/html/D/DWIM.html -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://ma

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

orrects (auto-corrupts) filenames for us. I don't want the interpreter trying to guess what I meant and running that instead of what I actually wrote. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe s

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

ode, and to find ways to encourage developers to run with warnings enabled. - In 3.9, we can try making the warnings visible again. - And aim to make it an error in 4.0/3.10. -- Steven ___ Python-Dev mailing list -- python-dev@python.org To unsubscri

[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

eprecation process. We've assumed that library devs will see the warnings long before end users. Since the benefit of this breaking change is quite small, let's delay it long enough to fix the deprecation process. -- Steven ___ Pyt

[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

whatever that object is, rather than what it *actually* is, namely `List[object]`. I dislike code that misleads the reader. > As for choosing the name of the annotation [...] > `TypeGuard` is the term that is used in other languages to describe > this notion, so it seems reasonable to me to ad

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

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