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

[Christopher Barker]

On Mon, Aug 24, 2020 at 9:26 AM Sebastian Kreft  wrote:

> As I mentioned in another thread, I think the syntax in which the initial
> argument of the slice is missing may be visually confusing, as it is too
> similar to the walrus operator.
>
> d[x=:3] or d[x=:]
>

which I suppose is the point mentioned: "what if we want to use colons for
other things"?

However, the second case will be usually formatted as x = +3, as per PEP 8

>
>
> So unless PEP8 is updated to require/suggest spaces around a keyword index
> (which I'm not proposing), then I am -1 for the suggested feature, at least
> when the initial element is missing.
>

PEP8 can't require, and of course it could be updated -- that seems a non
issue.

As for "why not" not being a motivator -- I agree, I posted it that easy
because this conversation has brought up a number of examples where slice
syntax is nice to use. And David Mertz pointed out, both numpy and pandas
have a utility to make easier slices -- yes, that's an argument for why you
don't need them, but it's also an argument for why there IS a need for
slice objects outside of the square brackets, and if we need slice objects,
then slice syntax is nice.

But rather than suggesting one or two places where we might use sloce
syntax: e.g. function calls:

object.get_subset(x=a:b, y=c:d), or itertools,islice(it, 2:20:2)

Once you allow them anywhere outside  [], then the question does become
"why not?", because having an expression that is only valid in some small
fraction of contexts gets even more confusing.

Of course, as has been pointed out here -- dict displays are one good
reason NOT to support it.

Which is too bad -- I'd really like to see it more broadly available -- I
think it's a very nice syntax.

I am strongly in favor of having slices.  The main motivating factor for
>> me, labelled dimensions in xarray, would be much, much less useful without
>> support for slices.  In fact, as PEP 472 currently mentions, the big
>> benefit of indexing over method calls is that indexing supports slice
>> syntax while method calls don't.
>>
>
so maybe the solution is to have method calls support slices :-)

-CHB



>
>> In a more general sense, I feel not allowing slices would create an
>> artificial distinction between labelled and positional indices that I don't
>> think is justified.  They would work the same, except for slices where
>> labelled indices behave differently.  It would be a strange gotcha.
>>
>> So I think any revision to PEP 472 or new PEP should directly and
>> explicitly support the use of slices.
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/TOABKD7A5X653BTTU3MZICWURNGPMY47/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Sebastian Kreft
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/IQJNOQS2LKHWSSYAJX7KDNWJ5ZFZ25N4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4H5SKCZH6WUPX6SXPSTKOCYLTCSO3SR3/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

On Mon, Aug 24, 2020 at 11:10 AM Ricky Teachey  wrote:

> \The interpreter wouldn't. I'm talking about adding this knowledge of
> signature dependent semantics to `type`.
>
> To implement this, under the hood `type` would detect the signatures with
> different semantics, and choose to wrap the functions with those
> signatures in a closure based on the intended semantic meaning. Then
> everything proceeds as it does today.
>

but it would still not know that:

t = (1,2,3)
something[t]

is the same as:

something[1,2,3]

would it?



> All of this is possible today, of course, using a metaclass, or using a
> regular class and the __init_subclass__ method, or using decorators. But my
> suggestion is to roll it into type.
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
>
>

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/Q6O4JTEHD2S3P5DBHKEET4E5A2NF6YND/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

On Mon, Aug 24, 2020 at 7: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?
>

These look like good ideas to me. And whether or not it would be considered
for the stdlib, a nice package on pypi could be nice. So I encourage you to
work on this :-)

After, of course, looking and seeing what's already out there. (though a
quick search in PyPi turns up, surprisingly, nothing. Lots of packages that
have to do with logging, but nothing that looks like a Pythonic API -- at
least not anything that looks the least bit documented or maintained.

-CHB







> - Use properties and magic methods instead of getter and setter methods
> - Add flag tfor `sys.excepthook` to choose whether to route all
> unhandled exceptions to the root logger
> - PEP8ify to make source code more readable and "pretty"
> - Make module-level `getLogger()` a class singleton, as it's only to
> be used once (warrants further discussion; I don't know if this is
> unnecessary)
> - Provide context managers for loggers to prevent race conditions
> (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants
> further discussion; I don't know if this is unnecessary)
> - Enable iteration over all existing loggers by writing `__len__`s and
> `__getitems__` for logging  (warrants further discussion; I don't know if
> this is unnecessary)
>
> Again, these are just my thoughts. Mike Miller is right in that the
> `logging` module is EXTREMELY intimidating to the new user. This keeps new
> users from logging, which (arguably) should be done as best practice.
>
> On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry 
> wrote:
>
>> 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.
>> Believe me, I'm a content-over-form programmer every day of the week and
>> twice on Sunday. We could make it more Pythonic though.
>>
>> One feature I would like to have added though is a flag I can set to
>> route all unhandled exceptions to the root logger. I need this for my
>> production GUIs, for example, and I have to override `sys.excepthook()` to
>> get this to work right now. Not a huge problem currently, but I think this
>> would be a nice addition to the module.
>>
>> Adam
>>
>>
>>
>> On Mon, Aug 24, 2020 at 4:43 PM Mike Miller 
>> wrote:
>>
>>>
>>> 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 come to appreciate it over the decades.
>>>
>>> My take is that the extensive flexibility was more important in the
>>> past, the
>>> Java-feel only mildly annoying.  In the spirit of batteries-included it
>>> has tons
>>> of baked-in functionality like file rotation, talking to the network,
>>> and the NT
>>> event system.  Though it sometimes made sense in the past, I argue most
>>> of the
>>> functionality is not necessary to have in the stdlib today.  Result:
>>>
>>> - At the low/beginner end, the package and docs are simply overwhelming.
>>> - For the mid-size project, it duplicates functionality like the Unix
>>> logrotate
>>>and syslog programs.
>>> - At the high-end, folks have moved on to "the ELK stack" etc and hosted
>>>services.  Few are using python for *everything* at a larger shop.
>>>
>>>   The "12 factor app" pattern for modern services alludes to the latter
>>> point:
>>>
>>>  https://12factor.net/logs
>>>  A twelve-factor app never concerns itself with routing or storage
>>> of its
>>>  output stream. It should not attempt to write to or manage logfiles.
>>>  Instead, each running process writes its event stream, unbuffered,
>>> to
>>>  stdout. During local development, the developer will view this
>>> stream in
>>>  the foreground of their terminal to observe the app’s behavior.
>>>
>>>
>>> Therefore, a simple way to log to stdout without a lot of reading and
>>> boilerplate might be useful.
>>>
>>> This is what logging.basicConfig() was supposed to be, and it is close
>>> but
>>> doesn't quite hit the mark.  The camelCase name is one small issue, it
>>> being
>>> buried under a mountain of docs is another.  Needing to import constants
>>> is
>>> slightly annoying as well.  It may be able to be improved doc-wise by
>>> putting it
>>> front and center on the first page of the logging docs.  The TOC will
>>> still be
>>> overwhelming to the newcomer however.
>>>
>>> Proposed solution: a trivial pythonic wrapper modu

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

[Ricky Teachey]

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 Ricky Teachey  wrote:

> 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 objects, it is getting a single tuple,
>> which is created by the comma. That is, expression:
>>
>> a,b
>>
>> Has the same value as:
>>
>> (a, b)
>>
>> Or
>>
>> tuple(a,b)
>>
>> Which means:
>>
>> t = tuple(a, b)
>> thing[a, b]
>>
>> Is exactly the same as
>>
>> thing[a,b]
>>
>> And that equivalency needs to be maintained.
>>
>> In practice, two common use cases treat the resulting tuple essentially
>> semantically differently:
>>
>> 1) Using tuples as dict keys i.e. a single value that happens to be a
>> tuple is a common practice.
>>
>> 2) numpy uses the elements of a tuple as separate indices.
>>
>> I don’t think the interpreter would have any way to know which of these
>> is intended.
>>
>> -CHB
>>
>
> The interpreter wouldn't. I'm talking about adding this knowledge of
> signature dependent semantics to `type`.
>
> To implement this, under the hood `type` would detect the signatures with
> different semantics, and choose to wrap the functions with those
> signatures in a closure based on the intended semantic meaning. Then
> everything proceeds as it does today.
>
> All of this is possible today, of course, using a metaclass, or using a
> regular class and the __init_subclass__ method, or using decorators. But my
> suggestion is to roll it into type.
>
> ---
> Ricky.
>
> "I've never met a Kentucky man who wasn't either thinking about going home
> or actually going home." - Happy Chandler
>
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/GORFDMAEXHIB3BFXMNIYBEGZPFWQXMMC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Richard Damon]

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
>     - Add flag tfor `sys.excepthook` to choose whether to route all
> unhandled exceptions to the root logger
>     - PEP8ify to make source code more readable and "pretty"
>     - Make module-level `getLogger()` a class singleton, as it's only
> to be used once (warrants further discussion; I don't know if this is
> unnecessary)
>     - Provide context managers for loggers to prevent race conditions
> (e.g. rather than `getLogger()` have `with logger(__name__)" (warrants
> further discussion; I don't know if this is unnecessary)
>     - Enable iteration over all existing loggers by writing `__len__`s
> and `__getitems__` for logging  (warrants further discussion; I don't
> know if this is unnecessary)
>
> Again, these are just my thoughts. Mike Miller is right in that the
> `logging` module is EXTREMELY intimidating to the new user. This keeps
> new users from logging, which (arguably) should be done as best practice.
>
> On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry
> mailto:adam.grant.hen...@gmail.com>> wrote:
>
> 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. Believe me, I'm a content-over-form programmer every day of
> the week and twice on Sunday. We could make it more Pythonic though.
>
> One feature I would like to have added though is a flag I can set
> to route all unhandled exceptions to the root logger. I need this
> for my production GUIs, for example, and I have to override
> `sys.excepthook()` to get this to work right now. Not a huge
> problem currently, but I think this would be a nice addition to
> the module.
>
> Adam
>
One comment on getLogger(), my understanding is that this is NOT
required to be called just once (but one common code style does), but it
has a promise:

Multiple calls to getLogger() with the same name will always return a
reference to the same Logger object.

Now it does have the slight weirditty that the string given is
effectively a path into a hierarchy using dots. One strategy is to call
it getLogger(__name__) in a file, and if you do that, it is more
efficient to set a module level global to it so you don't need to keep
calling it (but you can)

Following CHB, you might introduce a module object logging.logger that
you can use to access the loggers, but the fact that it isn't a flat
dictionary makes some of the suggestion not quit as appropriate.

-- 
Richard Damon
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HWYMAW4MHDE76ZG5UYX67OJQRYMP7MSV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Adam Hendry]

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 to route all
unhandled exceptions to the root logger
- PEP8ify to make source code more readable and "pretty"
- Make module-level `getLogger()` a class singleton, as it's only to be
used once (warrants further discussion; I don't know if this is unnecessary)
- Provide context managers for loggers to prevent race conditions (e.g.
rather than `getLogger()` have `with logger(__name__)" (warrants further
discussion; I don't know if this is unnecessary)
- Enable iteration over all existing loggers by writing `__len__`s and
`__getitems__` for logging  (warrants further discussion; I don't know if
this is unnecessary)

Again, these are just my thoughts. Mike Miller is right in that the
`logging` module is EXTREMELY intimidating to the new user. This keeps new
users from logging, which (arguably) should be done as best practice.

On Mon, Aug 24, 2020 at 7:23 PM Adam Hendry 
wrote:

> 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.
> Believe me, I'm a content-over-form programmer every day of the week and
> twice on Sunday. We could make it more Pythonic though.
>
> One feature I would like to have added though is a flag I can set to route
> all unhandled exceptions to the root logger. I need this for my production
> GUIs, for example, and I have to override `sys.excepthook()` to get this to
> work right now. Not a huge problem currently, but I think this would be a
> nice addition to the module.
>
> Adam
>
>
>
> On Mon, Aug 24, 2020 at 4:43 PM Mike Miller 
> wrote:
>
>>
>> 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 come to appreciate it over the decades.
>>
>> My take is that the extensive flexibility was more important in the past,
>> the
>> Java-feel only mildly annoying.  In the spirit of batteries-included it
>> has tons
>> of baked-in functionality like file rotation, talking to the network, and
>> the NT
>> event system.  Though it sometimes made sense in the past, I argue most
>> of the
>> functionality is not necessary to have in the stdlib today.  Result:
>>
>> - At the low/beginner end, the package and docs are simply overwhelming.
>> - For the mid-size project, it duplicates functionality like the Unix
>> logrotate
>>and syslog programs.
>> - At the high-end, folks have moved on to "the ELK stack" etc and hosted
>>services.  Few are using python for *everything* at a larger shop.
>>
>>   The "12 factor app" pattern for modern services alludes to the latter
>> point:
>>
>>  https://12factor.net/logs
>>  A twelve-factor app never concerns itself with routing or storage of
>> its
>>  output stream. It should not attempt to write to or manage logfiles.
>>  Instead, each running process writes its event stream, unbuffered, to
>>  stdout. During local development, the developer will view this
>> stream in
>>  the foreground of their terminal to observe the app’s behavior.
>>
>>
>> Therefore, a simple way to log to stdout without a lot of reading and
>> boilerplate might be useful.
>>
>> This is what logging.basicConfig() was supposed to be, and it is close
>> but
>> doesn't quite hit the mark.  The camelCase name is one small issue, it
>> being
>> buried under a mountain of docs is another.  Needing to import constants
>> is
>> slightly annoying as well.  It may be able to be improved doc-wise by
>> putting it
>> front and center on the first page of the logging docs.  The TOC will
>> still be
>> overwhelming to the newcomer however.
>>
>> Proposed solution: a trivial pythonic wrapper module with another name
>> and page
>> in the docs.  It says something like:
>>
>>
>>  log - Logging Quickstart Module
>>  ===
>>
>>  The log module is a simple interface meant to simplify logging for
>>  *applications,* rather than libraries.  This distinction is
>> important.
>>
>>  Libraries should be handled as they always have,
>>  and no changes are necessary to continue to use logging with them::
>>
>>  # hellolib.py
>>  import logging
>>
>>  logger = logging.getLogger(__name__)
>>
>>  def hello_world():
>>  logger.info('hello world!')
>>
>>
>>

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

[Adam Hendry]

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.
Believe me, I'm a content-over-form programmer every day of the week and
twice on Sunday. We could make it more Pythonic though.

One feature I would like to have added though is a flag I can set to route
all unhandled exceptions to the root logger. I need this for my production
GUIs, for example, and I have to override `sys.excepthook()` to get this to
work right now. Not a huge problem currently, but I think this would be a
nice addition to the module.

Adam



On Mon, Aug 24, 2020 at 4:43 PM Mike Miller 
wrote:

>
> 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 come to appreciate it over the decades.
>
> My take is that the extensive flexibility was more important in the past,
> the
> Java-feel only mildly annoying.  In the spirit of batteries-included it
> has tons
> of baked-in functionality like file rotation, talking to the network, and
> the NT
> event system.  Though it sometimes made sense in the past, I argue most of
> the
> functionality is not necessary to have in the stdlib today.  Result:
>
> - At the low/beginner end, the package and docs are simply overwhelming.
> - For the mid-size project, it duplicates functionality like the Unix
> logrotate
>and syslog programs.
> - At the high-end, folks have moved on to "the ELK stack" etc and hosted
>services.  Few are using python for *everything* at a larger shop.
>
>   The "12 factor app" pattern for modern services alludes to the latter
> point:
>
>  https://12factor.net/logs
>  A twelve-factor app never concerns itself with routing or storage of
> its
>  output stream. It should not attempt to write to or manage logfiles.
>  Instead, each running process writes its event stream, unbuffered, to
>  stdout. During local development, the developer will view this stream
> in
>  the foreground of their terminal to observe the app’s behavior.
>
>
> Therefore, a simple way to log to stdout without a lot of reading and
> boilerplate might be useful.
>
> This is what logging.basicConfig() was supposed to be, and it is close but
> doesn't quite hit the mark.  The camelCase name is one small issue, it
> being
> buried under a mountain of docs is another.  Needing to import constants
> is
> slightly annoying as well.  It may be able to be improved doc-wise by
> putting it
> front and center on the first page of the logging docs.  The TOC will
> still be
> overwhelming to the newcomer however.
>
> Proposed solution: a trivial pythonic wrapper module with another name and
> page
> in the docs.  It says something like:
>
>
>  log - Logging Quickstart Module
>  ===
>
>  The log module is a simple interface meant to simplify logging for
>  *applications,* rather than libraries.  This distinction is important.
>
>  Libraries should be handled as they always have,
>  and no changes are necessary to continue to use logging with them::
>
>  # hellolib.py
>  import logging
>
>  logger = logging.getLogger(__name__)
>
>  def hello_world():
>  logger.info('hello world!')
>
>
>  For applications that simply want to log to standard out as would a
> modern
>  service, initialize logging quickly with log::
>
>  # main.py
>  import log
>  import hellolib
>
>  log.configure()  # with good defaults
>
>  hellolib.hello_world()
>
>
>  To configure logging and use it in the main script,
>  a slightly more complex version might look like this::
>
>  # main.py
>  import log
>  import hellolib
>
>  logger = log.configure('debug', format='%(levelname)s
> %(message)s')
>
>  logger.info('About to call hello_world()...')
>  hellolib.hello_world()
>
>
> I've experimented a bit with a module on PyPi named "out," with similar
> ideas,
> though I probably have over-engineered it with ANSI colors and Unicode.
>
> -Mike
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/SOCHCQRUNGZE5JH5CE5X4577TXSS3OOU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing 

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

[Greg Ewing]

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 some experiments along these lines as part
of efforts to remove the GIL. You might like to research them to
find out how much success they've had.

--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/I6T32GL5BVKQ7PALJ4D347M4PBPY2P2P/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mike Miller]

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 come to appreciate it over the decades.


My take is that the extensive flexibility was more important in the past, the 
Java-feel only mildly annoying.  In the spirit of batteries-included it has tons 
of baked-in functionality like file rotation, talking to the network, and the NT 
event system.  Though it sometimes made sense in the past, I argue most of the 
functionality is not necessary to have in the stdlib today.  Result:


- At the low/beginner end, the package and docs are simply overwhelming.
- For the mid-size project, it duplicates functionality like the Unix logrotate
  and syslog programs.
- At the high-end, folks have moved on to "the ELK stack" etc and hosted
  services.  Few are using python for *everything* at a larger shop.

 The "12 factor app" pattern for modern services alludes to the latter point:

https://12factor.net/logs
A twelve-factor app never concerns itself with routing or storage of its
output stream. It should not attempt to write to or manage logfiles.
Instead, each running process writes its event stream, unbuffered, to
stdout. During local development, the developer will view this stream in
the foreground of their terminal to observe the app’s behavior.


Therefore, a simple way to log to stdout without a lot of reading and 
boilerplate might be useful.


This is what logging.basicConfig() was supposed to be, and it is close but 
doesn't quite hit the mark.  The camelCase name is one small issue, it being 
buried under a mountain of docs is another.  Needing to import constants is 
slightly annoying as well.  It may be able to be improved doc-wise by putting it 
front and center on the first page of the logging docs.  The TOC will still be 
overwhelming to the newcomer however.


Proposed solution: a trivial pythonic wrapper module with another name and page 
in the docs.  It says something like:



log - Logging Quickstart Module
===

The log module is a simple interface meant to simplify logging for
*applications,* rather than libraries.  This distinction is important.

Libraries should be handled as they always have,
and no changes are necessary to continue to use logging with them::

# hellolib.py
import logging

logger = logging.getLogger(__name__)

def hello_world():
logger.info('hello world!')


For applications that simply want to log to standard out as would a modern
service, initialize logging quickly with log::

# main.py
import log
import hellolib

log.configure()  # with good defaults

hellolib.hello_world()


To configure logging and use it in the main script,
a slightly more complex version might look like this::

# main.py
import log
import hellolib

logger = log.configure('debug', format='%(levelname)s %(message)s')

logger.info('About to call hello_world()...')
hellolib.hello_world()


I've experimented a bit with a module on PyPi named "out," with similar ideas, 
though I probably have over-engineered it with ANSI colors and Unicode.


-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SOCHCQRUNGZE5JH5CE5X4577TXSS3OOU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reliable Ordering Of Sets

[David Mertz]

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.

For my own uses, I typically use sets with hundreds, maybe thousands of
elements. Often strings. With tens of elements I care about speed less. I
myself rarely work with sets of millions of elements.

On Mon, Aug 24, 2020, 7:25 PM Cade Brown  wrote:

> 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 bytes vs 8 or 16 (32bit
> vs 64bit). But, to compare the entry's hash, an indirection into the
> entries array is required... The hueristics become less clear when
> considering how many collisions there are. It may also change for different
> tuning parameters (i.e. a lower load factor would alleviate the pointer
> dereferences require to compare items, but at the cost of more memory).
>
> It may very well be the case that the target load factor only decreases a
> small amount (so that the ordered implementation still uses less memory),
> but the performance benefits of quick rejections make overall performance
> better. I don't know how 'objective' we can be here without discussing
> specific data sets people may be using.
>
> On Mon, Aug 24, 2020, 7:15 PM David Mertz  wrote:
>
>> 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 than 1%
>> slower, is move to -0.
>>
>> If speed miraculously got faster in such a rewrite (analogous with
>> dictionaries whose order was initially a happy side-effect, but I've seen
>> explanations of why that wouldn't happen) I'd be +1.
>>
>> But in the last case, the entirely of my support would be for the speed
>> up, and exactly none of it would be for the ordering.
>>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K7LSURQ7SCJQTN2NYGK3U5OTIZBXQDCO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reliable Ordering Of Sets

[Cade Brown]

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 bytes vs 8 or 16 (32bit
vs 64bit). But, to compare the entry's hash, an indirection into the
entries array is required... The hueristics become less clear when
considering how many collisions there are. It may also change for different
tuning parameters (i.e. a lower load factor would alleviate the pointer
dereferences require to compare items, but at the cost of more memory).

It may very well be the case that the target load factor only decreases a
small amount (so that the ordered implementation still uses less memory),
but the performance benefits of quick rejections make overall performance
better. I don't know how 'objective' we can be here without discussing
specific data sets people may be using.

On Mon, Aug 24, 2020, 7:15 PM David Mertz  wrote:

> 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 than 1%
> slower, is move to -0.
>
> If speed miraculously got faster in such a rewrite (analogous with
> dictionaries whose order was initially a happy side-effect, but I've seen
> explanations of why that wouldn't happen) I'd be +1.
>
> But in the last case, the entirely of my support would be for the speed
> up, and exactly none of it would be for the ordering.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/65CO4HOUJ3SDZ7TTDXZMJCP66X2LOOEZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reliable Ordering Of Sets

[David Mertz]

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 than 1% slower,
is move to -0.

If speed miraculously got faster in such a rewrite (analogous with
dictionaries whose order was initially a happy side-effect, but I've seen
explanations of why that wouldn't happen) I'd be +1.

But in the last case, the entirely of my support would be for the speed up,
and exactly none of it would be for the ordering.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TJVCREKOW5FWJI6CO5G7SRQBMJDLGZSD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Todd]

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 discuss it?
>
> I think they are closely related matters, at least in terms of
> implementation. For details see rest of this message. I hope this helps our
> understanding, even if it shows difficulties lying ahead.
>
> My non-expert understanding is that if
>>>> d[a=1:2:3]
> is allowed by making a minimal change to Python's abstract grammar, then
>>>> f(a=1:2:3)
> will also be allowed. (Extra work would be required to forbid it.)
>

Why would that be the case?  d[1:3] is allowed but d(1:3) isn't.  The
interpreter replaces "1:3" with "slice(1, 3)" behind-the-scenes.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OZUR6QTUWGP5S6MAABKLW5MEPGL3CU7B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reliable Ordering Of Sets

[Cade Brown]

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 me, and why Python should (still) strive for reliably
ordered sets.

[Tim Peters ]
> "The problem" is that deletions leave _two_ kinds of holes: one in the
hash table, and another in the contiguous vector.
> The latter holes cannot be filled with subsequent new hash+key+value
records because that would break insertion order.
...
> Algorithms doing a lot of mixing of adds and deletes seem a lot more
common for sets than for dicts, and so the ordered dict's basic
implementation _approach_ is a lot less suitable for sets.
...
> Note: the holes left by deletions _wouldn't_ be "a problem" _except_ for
maintaining insertion order.
> If we were only after the memory savings, then on deletion "the last"
record in the contiguous array could be moved into the hole at once,
leaving the array hole-free again. But that also changes the order. IIRC,
that's what the original "compact dict" _did_ do.

When a large operation which is destructive (i.e. computing some difference
of sets), there could be a `set_fill_in_holes()`, called when
`num_entries_including_holes > real_num_entries * FILL_IN_FAC`, that would
rebuild the holes.

Naively, it may take O(N) complexity, but if done alongside an operation
that is already O(N) (i.e. set difference of two sets of similar
cardinality), it may quickly disappear (especially since no 'expensive'
operations like calculating hashes are required) and not affect
performance. Specifically, I bet it would have a small constant factor,
since a simple O(N) for loop and perhaps O(N) scratch space is required, it
would just be shuffling bytes and replacing indices.

The problem may come when user code with repeated additions and
subtractions of individual elements are presented (i.e. the user writes
`for elem in B: A.remove(elem)` instead of `A -= set(B)`). This would cause
a couple of single deletions to be O(N), which may be unacceptable;
however, if this was done with specific ratios (like once the number of
entries including holes reaches twice the amount of real entries), then it
would only run every ~N deletions, which would amortize the operation to
O(1+N/N)=O(1)

> {1, 2} | {3, 4, 5, 6, 7}
> [what should the above] return as ordered sets? Beats me.;
> The imbalance between the operands' cardinalities can be arbitrarily
large, and "first make a copy of the larger one, then loop over the smaller
one" is the obvious way to implement union to minimize the number of
lookups needed.

I must agree that the 'obvious' result (given that we are speaking of
ordered-by-insertion sets) is `{1, 2, 3, 4, 5, 6, 7}`, since they appear in
left-right order on the screen (and Python is specified as
left-right-centric (i.e. lines start on the left, etc).

However, you make good points about performance concerns; big-oh notation
is not what users (and indeed, benchmarks, applications, etc) care about,
it is rather `end_time - start_time`. As long as they are both O(N) union
and O(1) testing, insertion, removal, Python implementations will work fine
and not cause standard algorithms to take preposterous amounts of time
(whereas if testing magically became O(N), it would take many algorithms to
O(N^2), or worse, leaving large problems impossible). Aside from those
travesties that should obviously be avoided, Python must weigh constant
factor performance (i.e. being able to use optimizations as described in
your post) with reliable semantics (with the well-defined result and
iteration order of ordered-by-insertion sets).

This, however, ultimately is an implementation detail, and if other
semantics for 'set' make more sense, and avoid ambiguity (such as order), I
would have to side with removing ambiguity at the loss of, say, 10% of
speed. I know I'm not in the position to make that choice, however, so I
think some tests could be useful to show just how different the performance
is.
I just thought of another pro of using ordered-by-insertion set. Consider
the common idiom to order-by-value, `sorted(myset)`; if no order is
specified, then it very may well be random (in the general case; I know
integers for example will sort the same as their hashes, and will likely be
in some order). If `myset` was constructed with Python enforcing
ordered-by-insertion sets, then special attention could be made to generate
elements of `myset` in sorted or near-sorted order, which may lead to
asymptotic or at least better constant-factor performance under the
`sorted()` function (especially with `timsort`, which will perform well if
I generate `myset` from runs of sorted values. But I'm sure you already
know that ;)).


[Serhiy Storchaka]
> But ordered set implementation is not more compact that the current set
implementation (because

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

[Guido van Rossum]

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 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 :
>
> @RESTRequestHandler.route('/get/', methods=['GET'])
> def get_obj(request, obj_id):
> objs = [
> {'bar': 'baz'},
> {'lorem': 'ipsum'},
> ]
> if obj_id > len(objs):
> raise HTTPStatusException(HTTPStatus.NOT_FOUND)
> return HTTPStatus.OK, objs[obj_id]
> @RESTRequestHandler.errorhandler('*')
> def handle_errors(r, exc):
> return exc.status_code, {'code': exc.status_code, 'message'
> : exc.message}
> with HTTPServer(('localhost', 8080), RESTRequestHandler) as httpd:
> httpd.serve_forever()
> This example demonstrates how such a handler would be used, using a syntax
> that
> flask users should be pretty familiar with. The handler integrates both a
> route and
> an errorhandler decorator, which can be used to add new routes to the API
> that's being
> built. It's not something that's in the standard library either. By the
> way, RESTRequestHandler
> subclasses SimpleHTTPRequestHandler.
>
> Overall the advantage is pretty clear, it provides a much simpler API for
> devs
> who wish to spin up an API, which would be the ultimate goal of this PEP.
> Not to mention,
> the handler I wrote is 184 lines of code, having to reimplement for every
> API is cumbersome.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/DO457OZPWKJZHPYDY54C6TT5K5H44IT7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SG44D2XJDDMR6PNT37C3DLETPQNEMBMO/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Meitham Jamaa]

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 ``blame``.

https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revltrevgt


-- 
Meitham Jamaa

http://meitham.com
GPG Fingerprint: 8C8E3FC7


signature.asc
Description: PGP signature
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/UQ34JJDQUBEG2QWO46TBIQZ5777HA67V/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stefano Borini]

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
tests in the testsuite would throw a wrench in blame, but it would not
be mandatory to do so), nor I understand how providing pep-8 compliant
names as preferred and recommended names while keeping the old ones
for compatibility would be a problem.



> 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 counterpart,
>>
>> possibly even leaving the old camelcase form as deprecated, and in any
>>
>> case the breakage was already being performed for many modules such as
>>
>> e.g. StringIO.StringIO
>>
>>
>>
>>
>>
>> > 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?


-- 
Kind regards,

Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7JNJKUID4IIPZH2ZXIOP4QBQXRGQR45S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Reliable Ordering Of Sets

[Tim Peters]

[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 mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C2GI2HVKMNTEVBV6I57ZTKPALZ3UGGV5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Random832]

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

What about making a stdlib class for building RESTful WSGI applications, which 
could be used with wsgiref for the lightweight-no-external-dependencies use 
case?

basically a "flask light".
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZO7EDEFZM5IVWI7J2X4DC364HIGC6ITE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 counterpart,
>
> possibly even leaving the old camelcase form as deprecated, and in any
>
> case the breakage was already being performed for many modules such as
>
> e.g. StringIO.StringIO
>
>
>
>
>
> > 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.
>
> >>
>
> >>
>
> >>
>
> >> 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 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 the way forward would be to suggest an alternative, rather than
> rant about it :-)
>
> >>
>
> >> >
>
> >>
>
> >> > So the question is: would an update/addition/alternative API to the
> logging module be considered for inclusion in the stdlib?
>
> >>
>
> >> >
>
> >>
>
> >> > -CHB
>
> >>
>
> >> >
>
> >>
>
> >> > [*] Of course, it is not a given that logging IS non-Pythonic, if the
> community likes it as it is, then this, of course, is a non starter.
>
> >>
>
> >> >
>
> >>
>
> >> > PS: unittest is another candidate, though even more integral to core
> Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m
> not the only one that only uses unittest for the stdlib.
>
> >>
>
> >> >
>
> >>
>
> >> > IIUC,  both the logging and unittest design were inspired (if not
> directly ported) from Java. Which explains their out-of-place feeling
> design. As the say, “Python is not Java” — so maybe Python should not log
> and test like java?
>
> >>
>
> >> >
>
> >>
>
> >> > -CHB
>
> >>
>
> >> >
>
> >>
>
> >> >
>
> >>
>
> >> >
>
> >>
>
> >> > On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum 
> wrote:
>
> >>
>
> >> >>
>
> >>
>
> >> >> 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 <
> adam.grant.hen...@gmail.com> wrote:
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> 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 for beautiful intelligible code - PyCon 2015"?
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> Thank you,
>
> >>
>
> >> >>> Adam Hendry
>
> >>
>
> >> >>>
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> ___
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> Python-ideas mailing list -- python-ideas@python.org
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> To unsubscribe send an email to python-ideas-le...@python.org
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/
>
> >>
>
> >> >>>
>
> >>
>
> >> >>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> >>
>
> >> >>>
>
> >>
>
> >> >> --
>
> >>
>
> >> >> --Guido (mobile)
>
> >>
>
> >> >>
>
> >>
>
> >> >>
>
> >>
>
> >> >> ___
>
> >>
>
> >> >>
>
> >>
>
> >> >> Python-ideas mailing list -- python-ideas@python.org
>
> >>
>
> >> >>
>
> >>
>
> >> >> To unsubscribe send an email to python-ideas-le...@python.org
>
> >>
>
> >> >>
>
> >>
>
> >> >> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> >>
>
> >> >>
>
> >>
>
> >> >> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/
>
> >>
>
> >> >>
>
> >>
>
> >> >> Code of Conduct: http://python.org/psf/codeofconduct/
>
> >>
>
> >> >>
>
> >>
>
> >> > --
>
> >>
>
> >> > Christopher Barker, PhD
>
> >>
>
> >> >
>
> >>
>
> >> > Python Language Consulting
>
> >>
>
> >> >   - Teaching
>
> >>
>
> >> >   - Scientific Software Development
>
> >>
>
> >> >   - Desktop GUI and Web Development
>
> >>
>
> >> >   - wxPython, numpy, scipy, Cython
>
> >>
>
> >> > ___
>
> >>
>
> >> > Python-ideas

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

[Stefano Borini]

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 already being performed for many modules such as
e.g. StringIO.StringIO


> 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.
>>
>>
>>
>> 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 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 the way forward would be to suggest an alternative, rather than rant 
>> > about it :-)
>>
>> >
>>
>> > So the question is: would an update/addition/alternative API to the 
>> > logging module be considered for inclusion in the stdlib?
>>
>> >
>>
>> > -CHB
>>
>> >
>>
>> > [*] Of course, it is not a given that logging IS non-Pythonic, if the 
>> > community likes it as it is, then this, of course, is a non starter.
>>
>> >
>>
>> > PS: unittest is another candidate, though even more integral to core 
>> > Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m 
>> > not the only one that only uses unittest for the stdlib.
>>
>> >
>>
>> > IIUC,  both the logging and unittest design were inspired (if not directly 
>> > ported) from Java. Which explains their out-of-place feeling design. As 
>> > the say, “Python is not Java” — so maybe Python should not log and test 
>> > like java?
>>
>> >
>>
>> > -CHB
>>
>> >
>>
>> >
>>
>> >
>>
>> > On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum  wrote:
>>
>> >>
>>
>> >> 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 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 for beautiful intelligible code - PyCon 2015"?
>>
>> >>>
>>
>> >>> Thank you,
>>
>> >>> Adam Hendry
>>
>> >>>
>>
>> >>>
>>
>> >>> ___
>>
>> >>>
>>
>> >>> Python-ideas mailing list -- python-ideas@python.org
>>
>> >>>
>>
>> >>> To unsubscribe send an email to python-ideas-le...@python.org
>>
>> >>>
>>
>> >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>
>> >>>
>>
>> >>> Message archived at 
>> >>> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/
>>
>> >>>
>>
>> >>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>> >>>
>>
>> >> --
>>
>> >> --Guido (mobile)
>>
>> >>
>>
>> >>
>>
>> >> ___
>>
>> >>
>>
>> >> Python-ideas mailing list -- python-ideas@python.org
>>
>> >>
>>
>> >> To unsubscribe send an email to python-ideas-le...@python.org
>>
>> >>
>>
>> >> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>
>> >>
>>
>> >> Message archived at 
>> >> https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/
>>
>> >>
>>
>> >> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>> >>
>>
>> > --
>>
>> > Christopher Barker, PhD
>>
>> >
>>
>> > Python Language Consulting
>>
>> >   - Teaching
>>
>> >   - Scientific Software Development
>>
>> >   - Desktop GUI and Web Development
>>
>> >   - wxPython, numpy, scipy, Cython
>>
>> > ___
>>
>> > Python-ideas mailing list -- python-ideas@python.org
>>
>> > To unsubscribe send an email to python-ideas-le...@python.org
>>
>> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>
>> > Message archived at 
>> > https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/
>>
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Kind regards,
>>
>>
>>
>> Stefano Borini
>>
> --
> --Guido (mobile)



-- 
Kind regards,

Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.pyth

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

[Guido van Rossum]

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.
>
>
>
> 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 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 the way forward would be to suggest an alternative, rather than rant
> about it :-)
>
> >
>
> > So the question is: would an update/addition/alternative API to the
> logging module be considered for inclusion in the stdlib?
>
> >
>
> > -CHB
>
> >
>
> > [*] Of course, it is not a given that logging IS non-Pythonic, if the
> community likes it as it is, then this, of course, is a non starter.
>
> >
>
> > PS: unittest is another candidate, though even more integral to core
> Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m
> not the only one that only uses unittest for the stdlib.
>
> >
>
> > IIUC,  both the logging and unittest design were inspired (if not
> directly ported) from Java. Which explains their out-of-place feeling
> design. As the say, “Python is not Java” — so maybe Python should not log
> and test like java?
>
> >
>
> > -CHB
>
> >
>
> >
>
> >
>
> > On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum 
> wrote:
>
> >>
>
> >> 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 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 for beautiful intelligible code - PyCon 2015"?
>
> >>>
>
> >>> Thank you,
>
> >>> Adam Hendry
>
> >>>
>
> >>>
>
> >>> ___
>
> >>>
>
> >>> Python-ideas mailing list -- python-ideas@python.org
>
> >>>
>
> >>> To unsubscribe send an email to python-ideas-le...@python.org
>
> >>>
>
> >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> >>>
>
> >>> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/
>
> >>>
>
> >>> Code of Conduct: http://python.org/psf/codeofconduct/
>
> >>>
>
> >> --
>
> >> --Guido (mobile)
>
> >>
>
> >>
>
> >> ___
>
> >>
>
> >> Python-ideas mailing list -- python-ideas@python.org
>
> >>
>
> >> To unsubscribe send an email to python-ideas-le...@python.org
>
> >>
>
> >> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> >>
>
> >> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/
>
> >>
>
> >> Code of Conduct: http://python.org/psf/codeofconduct/
>
> >>
>
> > --
>
> > Christopher Barker, PhD
>
> >
>
> > Python Language Consulting
>
> >   - Teaching
>
> >   - Scientific Software Development
>
> >   - Desktop GUI and Web Development
>
> >   - wxPython, numpy, scipy, Cython
>
> > ___
>
> > Python-ideas mailing list -- python-ideas@python.org
>
> > To unsubscribe send an email to python-ideas-le...@python.org
>
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> > Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/
>
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
>
>
>
>
> --
>
> Kind regards,
>
>
>
> Stefano Borini
>
> --
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EL76SY3UR4KDYCPX6GYC5SKKSEZ6AIQX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Reliable Ordering Of Sets

[Cade Brown]

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 in the Python standard, a 'set' is by definition unordered. Yet,
internally they must be stored in some order, and when iterated upon,
converted to string, etc, some ordering must be used. Right now, it is
unspecified, which can lead to interesting results I noticed:

>>> print ({1, 2, 3}, {3, 2, 1})
{1, 2, 3} {1, 2, 3}
>>> print ({1, 5, 9}, {9, 5, 1})
{1, 5, 9} {9, 5, 1}

While, obviously, things like `A == B` are not affected by this, many
algorithms may affect their output if sets are treated as iterables (again,
the argument could be made, as it was for 'dict' as well, that they should
not treat the order as relevant at all). Further, I believe that having a
specification regarding the order and some guarantees could be useful and
important to cohesiveness of Python as a whole.

Despite the obvious non-ordered nature of sets, I still think it is worth
making them behave like `dict` objects (which are also, in some sense,
'unordered' by nature, and yet Python still specifies the order for 3.7+).

I would like to suggests that `set` objects are ordered by insertion, so
that:
  * Sets have a defined, repeatable order for maximum reproducibility
(assuming the code generates the set in a stable way)
  * Tests which are outside of Python can do string comparisons and expect
the same output each time (as with `dict` objects generated in a
predictable way).
  * On a high-level note, Python specifies more exact behavior. It is my
belief (and I'm sure many others share this as well) that
unspecified/implementation-dependent/otherwise-undependable features should
be eliminated and replaced with exact semantics that do not suprise users.

Thoughts?


Thanks,
~
Cade Brown
Working on MAGMA 
http://cade.site
http://chemicaldevelopment.us
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JEMEOMEPR65PDSSCOULKU2K2S7NUIGRL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Simon]

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

@RESTRequestHandler.route('/get/', methods=['GET'])
def get_obj(request, obj_id):
objs = [
{'bar': 'baz'},
{'lorem': 'ipsum'},
]
if obj_id > len(objs):
raise HTTPStatusException(HTTPStatus.NOT_FOUND)
return HTTPStatus.OK, objs[obj_id]
@RESTRequestHandler.errorhandler('*')
def handle_errors(r, exc):
return exc.status_code, {'code': exc.status_code, 'message'
: exc.message}
with HTTPServer(('localhost', 8080), RESTRequestHandler) as httpd:
httpd.serve_forever()
This example demonstrates how such a handler would be used, using a syntax
that
flask users should be pretty familiar with. The handler integrates both a
route and
an errorhandler decorator, which can be used to add new routes to the API
that's being
built. It's not something that's in the standard library either. By the
way, RESTRequestHandler
subclasses SimpleHTTPRequestHandler.

Overall the advantage is pretty clear, it provides a much simpler API for
devs
who wish to spin up an API, which would be the ultimate goal of this PEP.
Not to mention,
the handler I wrote is 184 lines of code, having to reimplement for every
API is cumbersome.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DO457OZPWKJZHPYDY54C6TT5K5H44IT7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Stefano Borini]

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 
> 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 the way forward would be to suggest an alternative, rather than rant 
> about it :-)
>
> So the question is: would an update/addition/alternative API to the logging 
> module be considered for inclusion in the stdlib?
>
> -CHB
>
> [*] Of course, it is not a given that logging IS non-Pythonic, if the 
> community likes it as it is, then this, of course, is a non starter.
>
> PS: unittest is another candidate, though even more integral to core Python. 
> But I’d love to see a “pytest lite” in the stdlib. I suspect I’m not the only 
> one that only uses unittest for the stdlib.
>
> IIUC,  both the logging and unittest design were inspired (if not directly 
> ported) from Java. Which explains their out-of-place feeling design. As the 
> say, “Python is not Java” — so maybe Python should not log and test like java?
>
> -CHB
>
>
>
> On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum  wrote:
>>
>> 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 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 for beautiful intelligible code - PyCon 2015"?
>>>
>>> Thank you,
>>> Adam Hendry
>>>
>>>
>>> ___
>>>
>>> Python-ideas mailing list -- python-ideas@python.org
>>>
>>> To unsubscribe send an email to python-ideas-le...@python.org
>>>
>>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>>
>>> Message archived at 
>>> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/
>>>
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> --
>> --Guido (mobile)
>>
>>
>> ___
>>
>> Python-ideas mailing list -- python-ideas@python.org
>>
>> To unsubscribe send an email to python-ideas-le...@python.org
>>
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>
>> Message archived at 
>> https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/
>>
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Kind regards,

Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/DP4T757D4UHQ2PX7NJ3EZE7763R4Z5QC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ricky Teachey]

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 objects, it is getting a single tuple,
> which is created by the comma. That is, expression:
>
> a,b
>
> Has the same value as:
>
> (a, b)
>
> Or
>
> tuple(a,b)
>
> Which means:
>
> t = tuple(a, b)
> thing[a, b]
>
> Is exactly the same as
>
> thing[a,b]
>
> And that equivalency needs to be maintained.
>
> In practice, two common use cases treat the resulting tuple essentially
> semantically differently:
>
> 1) Using tuples as dict keys i.e. a single value that happens to be a
> tuple is a common practice.
>
> 2) numpy uses the elements of a tuple as separate indices.
>
> I don’t think the interpreter would have any way to know which of these is
> intended.
>
> -CHB
>

The interpreter wouldn't. I'm talking about adding this knowledge of
signature dependent semantics to `type`.

To implement this, under the hood `type` would detect the signatures with
different semantics, and choose to wrap the functions with those
signatures in a closure based on the intended semantic meaning. Then
everything proceeds as it does today.

All of this is possible today, of course, using a metaclass, or using a
regular class and the __init_subclass__ method, or using decorators. But my
suggestion is to roll it into type.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OTEN5EMDBGG5WEO4P6NWIUAYIHSM5MGB/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

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 is, expression:

a,b

Has the same value as:

(a, b)

Or

tuple(a,b)

Which means:

t = tuple(a, b)
thing[a, b]

Is exactly the same as

thing[a,b]

And that equivalency needs to be maintained.

In practice, two common use cases treat the resulting tuple essentially
semantically differently:

1) Using tuples as dict keys i.e. a single value that happens to be a tuple
is a common practice.

2) numpy uses the elements of a tuple as separate indices.

I don’t think the interpreter would have any way to know which of these is
intended.

-CHB



On Mon, Aug 24, 2020 at 10:12 AM Ricky Teachey  wrote:

> 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): ...
>
> ...is currently as follows:
> *Note: below the === is not supposed to be code - I am using it as a way
> to state the semantics on the RHS of the signature on the LHS.*
>
> SIGNATURE === SEMANTICS
> (self, a, b) === (self, key_tuple, value)
>
> In the above, a on the left side, semantically, is the key tuple, and b in
> the value on the RHS.
>
> So right now, line 1 below calls line 2:
>
> [1]: d[1, 2] = foo
> [2]: d.__setitem__(key_tuple, value)
>
> And the call occurs this way:
>
> d.__setitem__((1,2), foo)
>
> So far, all of this is just a description of what currently happens.
>
> The
>
>
>
> signature dependent semantics
>
>
>
> proposal is NOT to change the semantic meaning of the above code in any
> way. These semantics would be maintained.
>
> Signature dependent semantics, as the name suggests, would change the
> semantic meaning of the __setitem__ signature in the case that more than
> two parameters are given in the signature.
>
> In other words, if a signature is provided like this, with 3 or more
> arguments:
>
> def: __setitem__(self, a, b, c): ...
>
> ...then in that case, the language would know there is a different
> semantic meaning intended.
>
> Right now, the above signature would raise a TypeError:
>
> >>> class D:
> ... def __setitem__(self, a, b, c):
> ...   ...
> ...
> >>> d=D()
> >>> d[1,2] = object()
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: __setitem__() missing 1 required positional argument: 'c'
>
> However, using signature dependent semantics, the language would know to
> call using semantics like this instead of raising a TypeError:
>
> d.__setitem__(foo, 1, 2)  # value is first positional argument
>
> In other words, in the case that there are three or more arguments present
> in the __getitem__ signature, the semantics of the signature CHANGES:
>
> SIGNATURE === CURRENT SEMANTICS: where key_tuple on the RHS contains
> (a,b), and value on the RHS is just c
> (self, a, b, c) === (self, key_tuple, value, CURRENTLY_UNUSED_PARAMETER)
>
> SIGNATURE === NEW SEMANTICS: a is value, b is positional argument 1, c is
> positional argument 2
> (self, a, b, c) === (self, value, pos1, pos2)
>
> I'm no cpython expert, but I think signature dependent semantics for
> __setitem__, as well as for __getitem__ and __delitem__, could be
> implemented.
>
> And that change alone could be made INDEPENDENT of supporting kwd args, or
> KeyObjects, or anything else.
>
> Furthermore, after
>
>
>
> signature dependent semantics were implemented (or perhaps at the same
> time), semantics could easily be extended so that code like this:
>
>   d[1, b=2] = foo
>
> ...on a an object with a __setitem__ signature like this:
>
> def __setitem__(self, value, a, b): ...
>
> ...gets called like this:
>
> d.__setitem__(foo, 1, b=2)
>
> BUT, it could also be implemented such that if that same item setting code
> were made against a signature like this:
>
> def __setitem__(self, a, value): ...
>
> You would get a TypeError, because the semantic meaning of the signature
> with just two positional arguments, key_tuple and value, does not support
> kwd arguments.
>
> DOWNSIDE
>
> The biggest downside to this that I see is that it would be confusing to
> the uninitiated, especially in the following case.
>
> If the  signature dependent semantics proposal were to go forward, and one
> wrote a signature with two arguments, the following semantic meaning could
> be mistakenly expected:
>
> # mistaken perception of __setitem__ method semantics
> SIGNATURE === MISTAKEN SEMANTICS
> (self, a, b) === (self, value, atomic_key)
>
> The mistaken belief above stated outright is that the RHS atomic_key is
> NOT a tuple, it is just b from the LHS. But this would not be correct.
>
> The actual semantics,

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

[Ricky Teachey]

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): ...

...is currently as follows:
*Note: below the === is not supposed to be code - I am using it as a way to
state the semantics on the RHS of the signature on the LHS.*

SIGNATURE === SEMANTICS
(self, a, b) === (self, key_tuple, value)

In the above, a on the left side, semantically, is the key tuple, and b in
the value on the RHS.

So right now, line 1 below calls line 2:

[1]: d[1, 2] = foo
[2]: d.__setitem__(key_tuple, value)

And the call occurs this way:

d.__setitem__((1,2), foo)

So far, all of this is just a description of what currently happens.

The signature dependent semantics proposal is NOT to change the semantic
meaning of the above code in any way. These semantics would be maintained.

Signature dependent semantics, as the name suggests, would change the
semantic meaning of the __setitem__ signature in the case that more than
two parameters are given in the signature.

In other words, if a signature is provided like this, with 3 or more
arguments:

def: __setitem__(self, a, b, c): ...

...then in that case, the language would know there is a different semantic
meaning intended.

Right now, the above signature would raise a TypeError:

>>> class D:
... def __setitem__(self, a, b, c):
...   ...
...
>>> d=D()
>>> d[1,2] = object()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __setitem__() missing 1 required positional argument: 'c'

However, using signature dependent semantics, the language would know to
call using semantics like this instead of raising a TypeError:

d.__setitem__(foo, 1, 2)  # value is first positional argument

In other words, in the case that there are three or more arguments present
in the __getitem__ signature, the semantics of the signature CHANGES:

SIGNATURE === CURRENT SEMANTICS: where key_tuple on the RHS contains (a,b),
and value on the RHS is just c
(self, a, b, c) === (self, key_tuple, value, CURRENTLY_UNUSED_PARAMETER)

SIGNATURE === NEW SEMANTICS: a is value, b is positional argument 1, c is
positional argument 2
(self, a, b, c) === (self, value, pos1, pos2)

I'm no cpython expert, but I think signature dependent semantics for
__setitem__, as well as for __getitem__ and __delitem__, could be
implemented.

And that change alone could be made INDEPENDENT of supporting kwd args, or
KeyObjects, or anything else.

Furthermore, after signature dependent semantics were implemented (or
perhaps at the same time), semantics could easily be extended so that code
like this:

  d[1, b=2] = foo

...on a an object with a __setitem__ signature like this:

def __setitem__(self, value, a, b): ...

...gets called like this:

d.__setitem__(foo, 1, b=2)

BUT, it could also be implemented such that if that same item setting code
were made against a signature like this:

def __setitem__(self, a, value): ...

You would get a TypeError, because the semantic meaning of the signature
with just two positional arguments, key_tuple and value, does not support
kwd arguments.

DOWNSIDE

The biggest downside to this that I see is that it would be confusing to
the uninitiated, especially in the following case.

If the  signature dependent semantics proposal were to go forward, and one
wrote a signature with two arguments, the following semantic meaning could
be mistakenly expected:

# mistaken perception of __setitem__ method semantics
SIGNATURE === MISTAKEN SEMANTICS
(self, a, b) === (self, value, atomic_key)

The mistaken belief above stated outright is that the RHS atomic_key is NOT
a tuple, it is just b from the LHS. But this would not be correct.

The actual semantics, in order to maintain backward compatibility, would
not change from what is currently true:

# backward compatible semantics
SIGNATURE === CORRECT, CURRENT SEMANTICS
(self, a, b) === (self, key_tuple, value)

The correct understanding illustrated above is that the RHS key_tuple is a
tuple (containing b from the LHS)  of the form (b,).

That seems like potentially a big downside. But maybe not? I don't know.

---
Ricky.

"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LBLS5OUXSICNKV6ZGDFTBGJNK2YWKNTD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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 normal byte code execution. Is this possible? If not why so?


There are string optimizations that check if the reference count is 
exactly one. One such optimization is +=. See 
https://github.com/python/cpython/blob/master/Objects/unicodeobject.c#L2005 
for the test.


Eric
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/72OUSL22IZZYG7QUGXUCLBIFFHGJ5EZJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 ultimately right, though, in that to scale up, a more robust framework 
> is needed (as I previously mentionned, flask, Django and starlette are much 
> more powerful than a simple class), but they come with their own drawbacks : 
> they are not in the standard library, and they are very heavy.
>
> For a dev that just wants to spin up a very basic API, in order to expose 
> their IoT devices to their network for instance, even flask is overkill. And 
> because of the size of these modules, they are unsuitable for embedded 
> development (on a raspberry pi compute module/zero, or with microPython).
>
> 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 opinion.
>

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
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/E5E3JTVIKX27GQ6USSGBLQ52RESZ3SRP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Simon]

>
> > 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 : Would spin up an HTTP server that one could
> connect webhooks to. Webhooks are really useful when dealing with APIs. So
> far, the third-party package, requests, is used when interacting with Web
> APIs, but there is nothing in the standard library that implements the
> webhook standard.
> >
> > - APIRequestHandler : This can be more controversial, especially with
> third-party packages like Flask, starlette, and django that will be much
> more powerful and secure than this, but this handler would be used to spin
> up a server that would make it easy to serve a simple restful API.
> >
>
> Not really in favour of "API" as a name. If you want a simple RESTful
> API framework, I'd call it something with REST in the name. But I'm
> not sure that that's needed, since you'd quickly outgrow a simple
> class and need to go for Flask/Django/etc.
>
> Webhooks are very tempting. There's a lot to be said for properly
> implementing this protocol in the standard library. It might be a bit
> harder, though, since it basically wants asynchronous or threaded I/O.
> Maybe this would be a good addition to asyncio?
>
> ChrisA


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 ultimately right, though, in that to scale up, a more
robust framework is needed (as I previously mentionned, flask, Django and
starlette are much more powerful than a simple class), but they come with
their own drawbacks : they are not in the standard library, and they are
very heavy.

For a dev that just wants to spin up a very basic API, in order to expose
their IoT devices to their network for instance, even flask is overkill.
And because of the size of these modules, they are unsuitable for embedded
development (on a raspberry pi compute module/zero, or with microPython).

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 opinion.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FQRBP5SMOFR4S7GUDTJKUEUK4F6MJUE5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

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 the way forward would be to suggest an alternative, rather than rant
about it :-)

So the question is: would an update/addition/alternative API to the logging
module be considered for inclusion in the stdlib?

-CHB

[*] Of course, it is not a given that logging IS non-Pythonic, if the
community likes it as it is, then this, of course, is a non starter.

PS: unittest is another candidate, though even more integral to core
Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m
not the only one that only uses unittest for the stdlib.

IIUC,  both the logging and unittest design were inspired (if not directly
ported) from Java. Which explains their out-of-place feeling design. As the
say, “Python is not Java” — so maybe Python should not log and test like
java?

-CHB



On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum  wrote:

> 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 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 for beautiful intelligible code - PyCon 2015"?
>>
>> Thank you,
>> Adam Hendry
>>
>>
>> ___
>>
>> Python-ideas mailing list -- python-ideas@python.org
>>
>> To unsubscribe send an email to python-ideas-le...@python.org
>>
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>>
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/
>>
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>> --
> --Guido (mobile)
>
>
> ___
>
> Python-ideas mailing list -- python-ideas@python.org
>
> To unsubscribe send an email to python-ideas-le...@python.org
>
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/
>
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sebastian Kreft]

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 (labelled) indices but not directly addressed.  The
> basic syntax would be something like d[x=1:3].
>

As I mentioned in another thread, I think the syntax in which the initial
argument of the slice is missing may be visually confusing, as it is too
similar to the walrus operator.

d[x=:3] or d[x=:]

There's precedent for combinations of symbols that have different meanings
when swapped. For example:

x += 3 vs x =+ 3

However, the second case will be usually formatted as x = +3, as per PEP 8


So unless PEP8 is updated to require/suggest spaces around a keyword index
(which I'm not proposing), then I am -1 for the suggested feature, at least
when the initial element is missing.


>
> I am strongly in favor of having slices.  The main motivating factor for
> me, labelled dimensions in xarray, would be much, much less useful without
> support for slices.  In fact, as PEP 472 currently mentions, the big
> benefit of indexing over method calls is that indexing supports slice
> syntax while method calls don't.
>
> In a more general sense, I feel not allowing slices would create an
> artificial distinction between labelled and positional indices that I don't
> think is justified.  They would work the same, except for slices where
> labelled indices behave differently.  It would be a strange gotcha.
>
> So I think any revision to PEP 472 or new PEP should directly and
> explicitly support the use of slices.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/TOABKD7A5X653BTTU3MZICWURNGPMY47/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Sebastian Kreft
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IQJNOQS2LKHWSSYAJX7KDNWJ5ZFZ25N4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jonathan Fine]

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 in terms of
implementation. For details see rest of this message. I hope this helps our
understanding, even if it shows difficulties lying ahead.

My non-expert understanding is that if
   >>> d[a=1:2:3]
is allowed by making a minimal change to Python's abstract grammar, then
   >>> f(a=1:2:3)
will also be allowed. (Extra work would be required to forbid it.)

It is also my non-expert understanding that
>>> {0:1:2:3:4:5}
would then be equivalent to
>>> {slice(0, 1, 2): slice(3, 4, 5)}
and further that
>>> { :: :: : }
would become valid syntax!

My non-expert understanding is based on
https://docs.python.org/3/library/ast.html#abstract-grammar

To me it seems that in for example
   >>> d[::, ::]
the AST is constrained by
slice = Slice(expr? lower, expr? upper, expr? step)
  | ExtSlice(slice* dims)
  | Index(expr value)
while in
   >>> f(x=SOMETHING)
   >>> f[x=SOMETHING]
the SOMETHING is an expr, and the AST is constrained by
expr = BoolOp(boolop op, expr* values)
 | NamedExpr(expr target, expr value)
 | BinOp(expr left, operator op, expr right)
 | UnaryOp(unaryop op, expr operand)
 | Lambda(arguments args, expr body)
 | IfExp(expr test, expr body, expr orelse)
 | Dict(expr* keys, expr* values)
 ...
 | List(expr* elts, expr_context ctx)
 | Tuple(expr* elts, expr_context ctx

If this is correct then adding Slice to the choices for expr would extend
the AST to allow slices in keyword indices. And then the rest follows.
-- 
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EEJM4N6AVT7HZCEZCVQQSFE2XSYXSGZD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Raihan Rasheed Apurbo]

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 why so?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JCEE6F65DU655DPT24LQ6KDL3H5YEBBX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[zachb1996--- via Python-ideas]

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 with private variables is actually even less ideal, 
because it pretends that the convention doesn't even exists since in python the 
variables aren't ever truly private, you can see that 
[here](https://www.attrs.org/en/stable/init.html#private-attributes).

As for repr, I think it may actually be beneficial for these to be excluded, 
because if we're truly emulating private variables, a user shouldn't really 
know what they are without going into the code, although of course since it's 
python they could be fairly easily accessed through inspection and the dict 
attribute. 

Zach
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZF4SM4KWIKBG65ZDQ4SBSXHS3HRIS4TS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[David Mertz]

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:
... def __getitem__(self, o):
... return o
>>> I = Slice()
>>> print(I[1:100:3], I[999:888:-10])
slice(1, 100, 3) slice(999, 888, -10)

 Currently, it takes three extra characters to get a "slice anywhere."

My answer is actually "more than never" since I actually use
pandas.IndexSlice and numpy.s_ occasionally, both of which are the same as
this (but as shown, no need to install/import either to get the
functionality).  But it's not "all the time" either.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5JFEID6MHCHYKHEPO3YILUA3XYYN3TB7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 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 for beautiful intelligible code - PyCon 2015"?
>
> Thank you,
> Adam Hendry
>
>
> ___
>
> Python-ideas mailing list -- python-ideas@python.org
>
> To unsubscribe send an email to python-ideas-le...@python.org
>
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/
>
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 included in the standard library :
>
> - WebhookRequestHandler : Would spin up an HTTP server that one could connect 
> webhooks to. Webhooks are really useful when dealing with APIs. So far, the 
> third-party package, requests, is used when interacting with Web APIs, but 
> there is nothing in the standard library that implements the webhook standard.
>
> - APIRequestHandler : This can be more controversial, especially with 
> third-party packages like Flask, starlette, and django that will be much more 
> powerful and secure than this, but this handler would be used to spin up a 
> server that would make it easy to serve a simple restful API.
>

Not really in favour of "API" as a name. If you want a simple RESTful
API framework, I'd call it something with REST in the name. But I'm
not sure that that's needed, since you'd quickly outgrow a simple
class and need to go for Flask/Django/etc.

Webhooks are very tempting. There's a lot to be said for properly
implementing this protocol in the standard library. It might be a bit
harder, though, since it basically wants asynchronous or threaded I/O.
Maybe this would be a good addition to asyncio?

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OYIOTWMKYXK3YT3Q3GZ7DL57YCUKMZ2F/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Simon]

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 : Would spin up an HTTP server that one could
connect webhooks to. Webhooks are really useful when dealing with APIs. So
far, the third-party package, requests, is used when interacting with Web
APIs, but there is nothing in the standard library that implements the
webhook standard.

- APIRequestHandler : This can be more controversial, especially with
third-party packages like Flask, starlette, and django that will be much
more powerful and secure than this, but this handler would be used to spin
up a server that would make it easy to serve a simple restful API.

I have already implemented both handlers in pure python (without
third-party packages obviously), I'm just wondering if it's a good idea to
make it a PEP, and implement these handlers as part of the python standard
library.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5UMEFDRKU5BXVVZ7HRULMQXVL7CTKX5L/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Adam Hendry]

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 for beautiful intelligible code - PyCon 2015"?

Thank you,
Adam Hendry
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Todd]

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

>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/B36GUN7WKNO2VUNILZG75AUSUPP26UHV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[rawmin . rx]

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-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VFBI5YL6A53PH5EQPVDESTOYBOH4IB7C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

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.


I'm not crazy about adding more uses of runtime type inspection, but I 
guess that ship has sailed with InitVar and ClassVar.


Eric

On 8/23/2020 5:36 PM, zachb1996--- via Python-ideas wrote:

I have a proposal for an addition to the dataclasses module that I think would 
make it
easier to use private and name mangled variables. One of the benefits of the 
dataclass
decorator is that it helps lessen the amount of code when you just need a simple
constructor. A common pattern in python that isn't addressed by the current
implementation is the pattern

```python
class MyClass:

 def __init__(self, a: str, b: str):
 self._a = a
 self.__b = b
```

right now the only straightforward way of doing this with a dataclass is

```python
@dataclass
class MyClass:
 a: InitVar[str]
 b: InitVar[str]

 def __post_init__(self, a, b):
 self._a = a
 self.__b = b
```

My proposal would be to add two types to the dataclasses module, one called 
PrivateVar
  and one called MangledVar. These would add The above pattern (without the 
post_init
  ) using the syntax,

```python
@dataclass
class MyClass:
 a: PrivateVar[str]
 b: MangledVar[str]
```

I've already looked into what would need to be added to dataclasses to implement
  these and it's just a few lines of code since the class implementation would 
be very
   similar to InitVar. Is this something that other see the possibility of 
being added
to python? (Also, I know name mangling isn't super common but I think it
  may as well be added alongside a private variable implementation))
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4JN76TMBGA3YDN5445OR2S7OT32JH2XO/
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5NZOVZQQZMR2B75MKA3P5TLIURYLNP23/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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
>> > tried, it’s a syntax error now, but is there any technical reason that
>> > it couldn’t be used pretty much anywhere?
>>
>> 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? what about other forms of 
>> slices, or if it's not the only element? should we support {a, b:c} as a set 
>> containing a slice? what about {a:b, c}?
>>
>> there may be other places it might be desirable to add new syntax that uses 
>> the colon character, allowing slices anywhere would foreclose that.
>
>
> {a:b} is a dict, {(a:b)} is a set containing one slice.

Isn't the "broader question" actually "what is the justification for
allowing slice syntax as an expression everywhere?" In other words,
what are the use cases?

"Why not do X" is *never* a sufficient reason for a language change -
there is always a cost, and unless there's a corresponding benefit, it
simply isn't going to happen.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4564JBR6TQPASXYKDYCXYCT3TOLFNYIJ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Gustav O]

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 conducts the search, I think the 
benefits would outweigh the costs.

--
Gustav
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/T2B7WHNA4MTOQYIU5WG66KUG2G2WZBOM/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Alex Hall]

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 reason that
> > it couldn’t be used pretty much anywhere?
>
> 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? what about other forms
> of slices, or if it's not the only element? should we support {a, b:c} as a
> set containing a slice? what about {a:b, c}?
>
> there may be other places it might be desirable to add new syntax that
> uses the colon character, allowing slices anywhere would foreclose that.
>

{a:b} is a dict, {(a:b)} is a set containing one slice.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CD7JHBY6JYSE3S53HCND2TGGUF543DV2/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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 mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AUCGQUAAVLCBISLFZTQEU7XSWVUFOPTN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Christopher Barker]

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 slice? what about {a:b, c}?
>

well, slices aren't hashable, so no. though technically hashabily is not a
syntax issue. So if a:b:c was a valid expressson anywhere, then you should
be able to *try* putting in in a set ...

but {a:b:1} is now a syntax error, so we could make only the three-part
form allowable.


> there may be other places it might be desirable to add new syntax that
> uses the colon character, allowing slices anywhere would foreclose that.
>

well, not sure I agree that that's a strong motivator.

I do think the dict display issue is big one though. But maybe we could
expand where slices can be used, like function calls, for instance:

though *maybe* there would be less use for that if.when we get keywords in
the [] operator.

-CHB




> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/CEF2MFP6WA4RKRV4TNWCDTNLAPZ243VD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QCUP73M5KPPBC7YSKPRB4DLWJOOKV2SH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Random832]

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 {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? what about other forms of 
slices, or if it's not the only element? should we support {a, b:c} as a set 
containing a slice? what about {a:b, c}?

there may be other places it might be desirable to add new syntax that uses the 
colon character, allowing slices anywhere would foreclose that.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CEF2MFP6WA4RKRV4TNWCDTNLAPZ243VD/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Random832]

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) only 
for modules loaded from the first entry in sys.path [script directory / current 
directory], so it shouldn't add much overhead at all to imports of stdlib or 
installed packages.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/APNOGQUDRMNJWIKMSR3VZD7BJYL5YISD/
Code of Conduct: http://python.org/psf/codeofconduct/