[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

Here is an illustration of what I am talking about: sigdepsem: Signature Dependent Semantics --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler On Mon, Aug 24, 2020 at 2:10 PM

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On 8/24/20 10:39 PM, Adam Hendry wrote: > In the spirit of CHB's recommendation, this is my proposal: > > Would an update/addition/alternative API to the logging module be > considered for inclusion in the stdlib? > >     - Use properties and magic methods instead of getter and setter > methods >  

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

In the spirit of CHB's recommendation, this is my proposal: Would an update/addition/alternative API to the logging module be considered for inclusion in the stdlib? - Use properties and magic methods instead of getter and setter methods - Add flag tfor `sys.excepthook` to choose whether

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

Hello Everyone, Uh-oh, I think you misunderstood me. I was trying to be funny. Raymond always does his "fist-slamming" thing in a funny way, so I was trying to emulate that. I'm not mad. This is my first feature request post. The `logging` module works, so there's nothing that needs to be fixed.

[Python-ideas] Re: Deferred, coalescing, and other very recent reference counting optimization

On 24/08/20 3:24 am, Raihan Rasheed Apurbo wrote: In CPython we have reference counting. My question is can we optimize current RC using strategies like Deferred RC and Coalescing? If no then where would I face problem if I try to implement these sorts of strategies? I gather there have been

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On 2020-08-24 09:25, Christopher Barker wrote: > I agree about the heavy rhetoric, but the OP has a good point. I have often > thought the same thing. Yes, many folks have. I've thought about it a bit myself. The logging package is comprehensive, mature, *very* flexible, and Java-esque. I've

[Python-ideas] Re: Reliable Ordering Of Sets

Well, the other element for me is that I would never want an order GUARANTEE to preclude a later every faster version. I know there are different test scenarios, but I think the first step for it to be remotely reasonable is an ordered implementation that is faster in any reasonable test cases.

[Python-ideas] Re: Reliable Ordering Of Sets

When I quoted 10% as a rough measurement I was referring more to set operations like union, etc, which choosing the larger set may have a very real performance advantage. For membership tests which are false, it may be quicker, as less memory is accessed. The buckets will be smaller (1,2,4, or 8

[Python-ideas] Re: Reliable Ordering Of Sets

The main purpose of sets is FAST membership testing. Everything I've seen in prior discussions convinced me that preserving insertion order would slow that down. If membership testing lost even 10% speed, I would be -1000 on the idea. If someone comes up with actual working code that is no more

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 12:23 PM Jonathan Fine wrote: > Christopher wrote: Why not allow slice syntax as an expression everywhere? > > In reply, Todd wrote: That is a very different discussion, and not > directly related to keyword indexes. Would it be possible to start a new > email thread to

[Python-ideas] Re: Reliable Ordering Of Sets

Tim, thank you for the reference. (if anyone has any tips for quoting emails which were sent before I joined the mailing list, that would be appreciated. I will try to add relevant details in mine) I will try and address some of the points from that discussion and why they aren't satisfying to

[Python-ideas] Re: Adding additionnal common request handlers to http.server

I can't help the feeling that this is much more appropriate for PyPI than for the stdlib. There are just too many different ways to do it. (For example, what if the user isn't familiar with flask?) On Mon, Aug 24, 2020 at 1:45 PM Simon wrote: > > Fair enough. I guess the real question is, how

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On 08/24, Guido van Rossum wrote: > Because all the git history would be lost, and lots of code would break. > That used to be the case but Git has options around that now. ``--ignore-rev`` and ``--ignore-revs-file`` can be used to point at style changing commits that can be excluded from

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On Mon, 24 Aug 2020 at 22:00, Guido van Rossum wrote: > > Well then you can keep wondering. Sorry I don't get your point. I do understand that changing all the method names would have been a major breakage, but I don't see how it would affect git history (sure, I understand that changing all the

[Python-ideas] Re: Reliable Ordering Of Sets

[Cade Brown , suggests ordered sets] FYI, last time this went around was December, with over 100 msgs here: https://mail.python.org/archives/list/python-...@python.org/thread/AEKCBGCKX23S4PMA5YNDHFJRHDL4JMKY/#AEKCBGCKX23S4PMA5YNDHFJRHDL4JMKY ___

[Python-ideas] Re: Adding additionnal common request handlers to http.server

On Mon, Aug 24, 2020, at 12:39, Chris Angelico wrote: > On Tue, Aug 25, 2020 at 2:36 AM Simon wrote: > > In my opinion, REST is the best protocol to make two pieces of software > > communicate with each other, because of its simplicity, yet, the standard > > library lacks in that regard in my

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

Well then you can keep wondering. On Mon, Aug 24, 2020 at 13:59 Stefano Borini wrote: > On Mon, 24 Aug 2020 at 21:54, Guido van Rossum wrote: > > > > > > Because all the git history would be lost, and lots of code would break. > > > > Well, names could have been converted to their snake case

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

On Mon, 24 Aug 2020 at 21:54, Guido van Rossum wrote: > > Because all the git history would be lost, and lots of code would break. Well, names could have been converted to their snake case counterpart, possibly even leaving the old camelcase form as deprecated, and in any case the breakage was

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

Because all the git history would be lost, and lots of code would break. On Mon, Aug 24, 2020 at 13:14 Stefano Borini wrote: > Brings me to a question. Why weren't the logger and unittest module > > "PEP-8"ified in the transition from 2 to 3? > > > > And I agree that both modules are a bit odd.

[Python-ideas] Reliable Ordering Of Sets

Hello all, I have a suggestion/idea for the Python standard (and/or a CPython implementation detail, considering its memory impact): having sets behave similar to dictionaries in that they preserve first-appearance order (i.e. dictionaries are ordered by key which was first inserted). As is said

[Python-ideas] Re: Adding additionnal common request handlers to http.server

> Fair enough. I guess the real question is, how much advantage is > RESTRequestHandler over directly subclassing BaseHTTPRequestHandler? > Maybe it'd be worth it just to simplify that case. > > ChrisA Well, maybe an example would be more telling. Below is a basic usage of the handler I wrote :

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

Brings me to a question. Why weren't the logger and unittest module "PEP-8"ified in the transition from 2 to 3? And I agree that both modules are a bit odd. On Mon, 24 Aug 2020 at 17:31, Christopher Barker wrote: > > I agree about the heavy rhetoric, but the OP has a good point. I have often >

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

On Mon, Aug 24, 2020 at 1:52 PM Christopher Barker wrote: > I’m not at all sure this Idea is possible, > > But even if so, there’s a real trick here. The [] operator is not a > function call, it is a special operator that “takes” a single expression. > > Thing[a, b] is not “getting” two

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

I’m not at all sure this Idea is possible, But even if so, there’s a real trick here. The [] operator is not a function call, it is a special operator that “takes” a single expression. Thing[a, b] is not “getting” two objects, it is getting a single tuple, which is created by the comma. That

[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)

Here is another way forward-- inspired by a conversation off-list with Jonathan Fine. I am calling it "signature dependent semantics". Right now, the semantic meaning of a __setitem__ function like this: # using ambiguous names for the parameters on purpose def __setitem__ (self, a, b): ...

[Python-ideas] Re: Deferred, coalescing, and other very recent reference counting optimization

On 8/24/2020 12:15 PM, Raihan Rasheed Apurbo wrote: I know that but do we need exact reference counting in any other case? what if we find out exact value just before entering GC and rest of the time use deferred value so that we can get rid of some addition subtraction operation during

[Python-ideas] Re: Adding additionnal common request handlers to http.server

On Tue, Aug 25, 2020 at 2:36 AM Simon wrote: > > My idea behind the APIRequestHandler (by the way, RESTRequestHandler might > actually be better) was to provide devs with a simple interface that doesn't > require any setup in order to spin up RESTful APIs for personal projects. > You're

[Python-ideas] Re: Adding additionnal common request handlers to http.server

> > > The standard library module http.server already has 2 request handlers, > with SimpleHTTPRequestHandler and CGIHTTPRequestHandler, the first serves > files from a directory, and the second executes CGI scripts. > > > > Two new handlers could be included in the standard library : > > > > -

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

I agree about the heavy rhetoric, but the OP has a good point. I have often thought the same thing. Isn’t it a bit ironic that the stdlib version of an important module is a poor example of Pythonic style[*] and we have to find a third party package to do something as important as logging? But

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Sun, Aug 23, 2020 at 9:42 PM Todd wrote: > I think it is worth directly discussing the availability of slices in PEP > 472-style keyword indices, since we seem to have mostly converged on a > dunder method signature. This is an issue that has been alluded to > regarding keyword-based

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

Christopher wrote: Why not allow slice syntax as an expression everywhere? In reply, Todd wrote: That is a very different discussion, and not directly related to keyword indexes. Would it be possible to start a new email thread to discuss it? I think they are closely related matters, at least

[Python-ideas] Re: Deferred, coalescing, and other very recent reference counting optimization

I know that but do we need exact reference counting in any other case? what if we find out exact value just before entering GC and rest of the time use deferred value so that we can get rid of some addition subtraction operation during normal byte code execution. Is this possible? If not

[Python-ideas] Re: Enhancement: Adding support for private and name mangled type hints in dataclasses module

While I agree that this is a subset of the idea of having a different attribute name, I think this naming convention is very common, and is even referenced in the python documentation. Which is why I think it would warrant being built in as opposed to using an InitVar. So the way attrs deals

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 12:43 AM Christopher Barker wrote: > Why not allow slice syntax as an expression everywhere? Everywhere I’ve > tried, it’s a syntax error now, but is there any technical reason that it > couldn’t be used pretty much anywhere? > How often do you do this? >>> class Slice:

[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic

There is no need for all that heavy rhetoric. There are many 3rd party modules that provide simpler interfaces to the logging module. Go do some Googling. On Mon, Aug 24, 2020 at 06:03 Adam Hendry wrote: > Dear Python-ideas, > > After looking at the `logging` module, I slammed my fist on my

[Python-ideas] Re: Adding additionnal common request handlers to http.server

On Mon, Aug 24, 2020 at 11:26 PM Simon wrote: > > The standard library module http.server already has 2 request handlers, with > SimpleHTTPRequestHandler and CGIHTTPRequestHandler, the first serves files > from a directory, and the second executes CGI scripts. > > Two new handlers could be

[Python-ideas] Adding additionnal common request handlers to http.server

The standard library module http.server already has 2 request handlers, with SimpleHTTPRequestHandler and CGIHTTPRequestHandler, the first serves files from a directory, and the second executes CGI scripts. Two new handlers could be included in the standard library : - WebhookRequestHandler :

[Python-ideas] FEATURE REQUEST: Make `logging` Module more Pythonic

Dear Python-ideas, After looking at the `logging` module, I slammed my fist on my desk and declared "There has to be a better way!" ( https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 -- Best practices

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020, 00:43 Christopher Barker wrote: > But thus brings up a broader question: > > Why not allow slice syntax as an expression everywhere? Everywhere I’ve > tried, it’s a syntax error now, but is there any technical reason that it > couldn’t be used pretty much anywhere? > That

[Python-ideas] Re: raise TypeError when giving wrong type of argument in functions

Well I wanted a function to check it at run-time. I used to use mypy as pylint of my VS Code but now I've created a decorator for it. But thanks ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to

[Python-ideas] Re: Enhancement: Adding support for private and name mangled type hints in dataclasses module

A couple of thoughts: Does attrs have anything similar? Is this just a subset of a more general-purpose idea to have a different attribute name than the __init__ parameter name? What should repr show? The __init__ parameter name? Or the attribute name? I'd guess the __init__ parameter name.

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, 24 Aug 2020 at 09:59, Alex Hall wrote: > > On Mon, Aug 24, 2020 at 9:54 AM Random832 wrote: >> >> On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote: >> > But thus brings up a broader question: >> > >> > Why not allow slice syntax as an expression everywhere? Everywhere I’ve >> >

[Python-ideas] Re: Improve error message for trying to import itself

It seems like we all agree that getting such a warning would be optimal. The only real question is how we would make sure that it doesn’t slow down imports more than it helps. I’d gladly see your proposed option become a part of the language. With the mentioned restrictions on when it actually

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 9:54 AM Random832 wrote: > On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote: > > But thus brings up a broader question: > > > > Why not allow slice syntax as an expression everywhere? Everywhere I’ve > > tried, it’s a syntax error now, but is there any technical

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 6:27 PM Christopher Barker wrote: > but {a:b:1} is now a syntax error, so we could make only the three-part form > allowable. > But is that a set containing a:b:1, or a dict mapping a to b:1, or a dict mapping a:b to 1? I don't like it. ChrisA

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020 at 12:54 AM Random832 wrote: > > Why not allow slice syntax as an expression everywhere? > > is {a:b} a set containing a slice, or a dict? obviously it's a dict, but > are there any other places that might be affected? should we support {a, b:c} as a set containing a

[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]

On Mon, Aug 24, 2020, at 00:43, Christopher Barker wrote: > But thus brings up a broader question: > > Why not allow slice syntax as an expression everywhere? Everywhere I’ve > tried, it’s a syntax error now, but is there any technical reason that > it couldn’t be used pretty much anywhere? is

[Python-ideas] Re: Improve error message for trying to import itself

On Sat, Aug 22, 2020, at 20:17, Chris Angelico wrote: > A speed drawback on every import would almost certainly be too high a > price to pay. My proposal would only add an extra check 1) on module load [not on import, so you only pay it once per module, and not at all for built-in modules] 2)