[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On Tue, 18 Feb 2020 at 23:40, Steven D'Aprano wrote: > > On Tue, Feb 18, 2020 at 09:04:21PM +, Paul Moore wrote: > > > This looks to me like Lua's `items()` function. > > I can't find that function listed anywhere. > > https://www.lua.org/manual/5.3/ > > Are you maybe thinking of `pairs()`? > > https://www.lua.org/manual/5.3/manual.html#pdf-pairs Sorry, yes I was - I should have checked instead of relying on memory. 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/A7ZDOU53G3LDCJKOIB5QR644THDYIOIG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
> Isn’t the point of having a Code of Conduct that we shouldn’t have to have these arguments? Or, if there is an argument about whether a single figurative use as a word qualifies as “excessive swearing” per the CoC, surely an -ideas thread isn’t the place to have it? Yeah, I very much doubt that "shitty wrapper" constitutes as excessive swearing. It'd be one thing if the post contained many or was directed at someone else, but the OP was using it to refer to something they personally wrote. Personally, I think it's a non-issue in that sort of context. On Tue, Feb 18, 2020 at 10:40 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > On Feb 18, 2020, at 17:11, Ethan Furman wrote: > > > > On 02/18/2020 04:26 PM, Steven D'Aprano wrote: > >> On Tue, Feb 18, 2020 at 08:44:07PM +, Rhodri James wrote: > > > >>> Language, sunshine. > >> What about it? > >> Just for the record, I had no issues with Soni's language, but I do > >> object to attempts to shame him for it. > > > > Since when is simply drawing one's attention to something shaming? > > > >> This isn't the Disney Chanel, > >> it's been over 100 years since Victoria was Queen of England, and we're > >> all adults here. > > > > Really? I didn't realize those under the legal age of majority were not > allowed on this list. > > Isn’t the point of having a Code of Conduct that we shouldn’t have to have > these arguments? Or, if there is an argument about whether a single > figurative use as a word qualifies as “excessive swearing” per the CoC, > surely an -ideas thread isn’t the place to have 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/GOKPFN55FTAGLB7WJ6B6MOUJ3FLDWBZ7/ > 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/QFBU42VVYYTC4IHEZ2HVRAB7AYJO2VXD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add __keys__ or __items__ protocol
Serhiy Storchaka wrote: > 1. What special method should be added, `__keys__` or `__items__`? The > former returns keys, it needs to call `__getitem__` repeatedly to get > values. The latter returns key-value pairs, it does not need to call > `__getitem__`, but you should always pay the cost of creating a tuple > even if you do not need values. Between __keys__ and __items__, I find that __keys__ is specifically more unique to mapping types; whereas __items__ can be reasonably applied to any type of container. Also, I personally find that I more frequently have the need to access just all of the keys and some or none of the values, rather than all of the key and value pairs. That being said, if the consensus ends up being to use __items__ instead, I would be okay with that. Serhiy Storchaka wrote: > 2. What type should they return? > * An iterator. +0. > * An iterable which can be iterated only once. Easy to implement in > Python as generator methods. -1. > * An iterable which can be iterated multiple times. +1. > * More complex view object which may support other protocols (for > example support `__or__` and `__and__`). Strong -1. I find that the requirement of an iterable that can be iterated multiple times would be the most reasonable option, as this would be compatible with the existing dict.keys(). A simple iterator seems a bit too generic and similar to __iter__, and requiring it to be an iterable that can be iterated over only once would be incompatible with dict.keys() (which seems rather strange). As for requiring a view object... Steven D'Aprano wrote: > That means that every object wanting to make use of this protocol needs > to create a complex set-like view object, which is neither easy nor > obvious, and may not even be appropriate for some classes. Mainly for the above, I'm -1 on requirement of returning a view; that seems needlessly restrictive and would significantly limit the dunder method's usefulness for any user-created mappings which don't inherit from dict. If it's intended to be used for any mapping object, it should be as (reasonably) simple to implement as possible, IMO. On Tue, Feb 18, 2020 at 7:26 PM Steven D'Aprano wrote: > On Tue, Feb 18, 2020 at 11:47:16AM -0800, Ethan Furman wrote: > > > Whatever `dict.items()` returns, both for consistency and because > > `dict.items()` can become a simple alias for `dict.__items__`. > > That means that every object wanting to make use of this protocol needs > to create a complex set-like view object, which is neither easy nor > obvious, and may not even be appropriate for some classes. > > > > -- > Steven > ___ > 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/YZCK3XLRLV4G65EZGXQB5PU3IBA25TXP/ > 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/UL35QYPRLMJHCBPJPCNIQEUOJR5BBVZ7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 19/02/2020 00:26, Steven D'Aprano wrote: On Tue, Feb 18, 2020 at 08:44:07PM +, Rhodri James wrote: Language, sunshine. What about it? Just for the record, I had no issues with Soni's language, but I do object to attempts to shame him for it. This isn't the Disney Chanel, it's been over 100 years since Victoria was Queen of England, and we're all adults here. Actually we aren't all adults here, I happen to know, but never mind. I still thought Soni's language was inappropriate and just cautioning them was appropriate. If I thought "shitty wrapper" was unacceptable, I wouldn't have bothered cautioning them and just reported the CoC breach. -- Rhodri James *-* Kynesim Ltd ___ 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/VC2ROZN7FOIOBMQJUNZDGVM3GYRR36J2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 2020-02-18 5:33 p.m., Soni L. wrote: Similar to len(). Just a shitty wrapper for __valid_getitem_requests__. Correction: Just a simple wrapper for __valid_getitem_requests__. ___ 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/FGNTAFZ57TA2DLNV3ZSDNKKRUXPDO2V7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 19/02/2020 16:55, Soni L. wrote: On 2020-02-18 5:33 p.m., Soni L. wrote: Similar to len(). Just a shitty wrapper for __valid_getitem_requests__. Correction: Just a simple wrapper for __valid_getitem_requests__. Thank you! :-) -- Rhodri James *-* Kynesim Ltd ___ 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/YDV5Q2M4Q73NCMROHMAPB45QWH3OBSF5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add a __valid_getitem_requests__ protocol
On 02/19/2020 08:55 AM, Soni L. wrote: On 2020-02-18 5:33 p.m., Soni L. wrote: Similar to len(). Just a [crappy] wrapper for __valid_getitem_requests__. Correction: Just a simple wrapper for __valid_getitem_requests__. Hopefully unsurprisingly, those words do not mean the same: simple: little if any extra functionality, possibly just a name redirect crappy: serious performance penalties, weird/incorrect edge cases, different order of parameters, hard to understand code, etc. -- ~Ethan~ ___ 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/CAAUJ2VJK65AJG56T5OHQWDHI37F7EBO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PYTHONLOGGING env variable
Another idea I've had that may be of use: PYTHONLOGGING environment variable. Setting PYTHONLOGGING to any log level or level name will initialize logging.basicConfig() with that appropriate level. Another option would be that -x dev or a different -x logging will initialize basic config. Will be useful mostly for debugging purposes instead of temporarily modifying the code. Kinda surprised it doesn't exist tbh. Bar Harel ___ 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/I74LVJWJLE2LUCCZGOF5A5JDSDHJ6WX2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PYTHONLOGGING env variable
> Setting PYTHONLOGGING to any log level or level name will initialize
logging.basicConfig() with that appropriate level.
This can already be done from the command line through --log=LEVEL, which
sets the logging.loglevel attribute. In the how-to section of the docs,
this is demonstrated in the following example:
# assuming loglevel is bound to the string value obtained from the#
command line argument. Convert to upper case to allow the user to#
specify --log=DEBUG or --log=debugnumeric_level = getattr(logging,
loglevel.upper(), None)if not isinstance(numeric_level, int):
raise ValueError('Invalid log level: %s' %
loglevel)logging.basicConfig(level=numeric_level, ...)
(https://docs.python.org/3/howto/logging.html#logging-to-a-file)
Is there a practical reason why the above doesn't work for you?
Otherwise, I see no reason to add a new environment variable that
effectively does the same thing.
On Wed, Feb 19, 2020 at 8:16 PM Bar Harel wrote:
> Another idea I've had that may be of use:
>
> PYTHONLOGGING environment variable.
>
> Setting PYTHONLOGGING to any log level or level name will initialize
> logging.basicConfig() with that appropriate level.
>
> Another option would be that -x dev or a different -x logging will
> initialize basic config.
>
> Will be useful mostly for debugging purposes instead of temporarily
> modifying the code.
>
> Kinda surprised it doesn't exist tbh.
>
> Bar Harel
> ___
> 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/I74LVJWJLE2LUCCZGOF5A5JDSDHJ6WX2/
> 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/VMT7NWEO7HWBLAJYM4YWJGLM4PK7KA7E/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PYTHONLOGGING env variable
> This can already be done from the command line through --log=LEVEL, which
sets the logging.loglevel attribute. In the how-to section of the docs,
this is demonstrated in the following example:
Note: "loglevel" is an arbitrary name, but this can be implemented
trivially with something like argparse to check for a --log argument.
On Wed, Feb 19, 2020 at 9:19 PM Kyle Stanley wrote:
> > Setting PYTHONLOGGING to any log level or level name will initialize
> logging.basicConfig() with that appropriate level.
>
> This can already be done from the command line through --log=LEVEL, which
> sets the logging.loglevel attribute. In the how-to section of the docs,
> this is demonstrated in the following example:
>
> # assuming loglevel is bound to the string value obtained from the# command
> line argument. Convert to upper case to allow the user to# specify
> --log=DEBUG or --log=debugnumeric_level = getattr(logging, loglevel.upper(),
> None)if not isinstance(numeric_level, int):
> raise ValueError('Invalid log level: %s' %
> loglevel)logging.basicConfig(level=numeric_level, ...)
>
> (https://docs.python.org/3/howto/logging.html#logging-to-a-file)
>
> Is there a practical reason why the above doesn't work for you? Otherwise, I
> see no reason to add a new environment variable that effectively does the
> same thing.
>
>
> On Wed, Feb 19, 2020 at 8:16 PM Bar Harel wrote:
>
>> Another idea I've had that may be of use:
>>
>> PYTHONLOGGING environment variable.
>>
>> Setting PYTHONLOGGING to any log level or level name will initialize
>> logging.basicConfig() with that appropriate level.
>>
>> Another option would be that -x dev or a different -x logging will
>> initialize basic config.
>>
>> Will be useful mostly for debugging purposes instead of temporarily
>> modifying the code.
>>
>> Kinda surprised it doesn't exist tbh.
>>
>> Bar Harel
>> ___
>> 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/I74LVJWJLE2LUCCZGOF5A5JDSDHJ6WX2/
>> 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/CWFNU7ENCH7N25IIIT4NORS2V7K6WENJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PYTHONLOGGING env variable
Thanks Kyle for the feedback :-)
Unfortunately, there is no logging.loglevel attribute.
At the moment, the only way of doing this is modifying the program, parsing
input parameters and setting up the logging system.
If you want it only temporarily for debugging purposes, or permanently for
all scripts in your system, it's not really feasible.
Think of -Wdefault. You can change settings in the warnings module and
modify files each time you wish to enable all warnings. But then again, why
would you?
We have debugging flags for warnings, faulthandlers, asyncio etc... Logging
I would say is the most important and trivial of all, yet we don't have a
flag for it.
On Thu, Feb 20, 2020, 4:24 AM Kyle Stanley wrote:
> > This can already be done from the command line through --log=LEVEL,
> which sets the logging.loglevel attribute. In the how-to section of the
> docs, this is demonstrated in the following example:
>
> Note: "loglevel" is an arbitrary name, but this can be implemented
> trivially with something like argparse to check for a --log argument.
>
> On Wed, Feb 19, 2020 at 9:19 PM Kyle Stanley wrote:
>
>> > Setting PYTHONLOGGING to any log level or level name will initialize
>> logging.basicConfig() with that appropriate level.
>>
>> This can already be done from the command line through --log=LEVEL, which
>> sets the logging.loglevel attribute. In the how-to section of the docs,
>> this is demonstrated in the following example:
>>
>> # assuming loglevel is bound to the string value obtained from the# command
>> line argument. Convert to upper case to allow the user to# specify
>> --log=DEBUG or --log=debugnumeric_level = getattr(logging, loglevel.upper(),
>> None)if not isinstance(numeric_level, int):
>> raise ValueError('Invalid log level: %s' %
>> loglevel)logging.basicConfig(level=numeric_level, ...)
>>
>> (https://docs.python.org/3/howto/logging.html#logging-to-a-file)
>>
>> Is there a practical reason why the above doesn't work for you? Otherwise, I
>> see no reason to add a new environment variable that effectively does the
>> same thing.
>>
>>
>> On Wed, Feb 19, 2020 at 8:16 PM Bar Harel wrote:
>>
>>> Another idea I've had that may be of use:
>>>
>>> PYTHONLOGGING environment variable.
>>>
>>> Setting PYTHONLOGGING to any log level or level name will initialize
>>> logging.basicConfig() with that appropriate level.
>>>
>>> Another option would be that -x dev or a different -x logging will
>>> initialize basic config.
>>>
>>> Will be useful mostly for debugging purposes instead of temporarily
>>> modifying the code.
>>>
>>> Kinda surprised it doesn't exist tbh.
>>>
>>> Bar Harel
>>> ___
>>> 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/I74LVJWJLE2LUCCZGOF5A5JDSDHJ6WX2/
>>> 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/I6SJKDONKSUTATL4QBJMR5Z3YZTKI6TC/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PYTHONLOGGING env variable
[re-sending this since I forgot to CC the list]
> Unfortunately, there is no logging.loglevel attribute.
> At the moment, the only way of doing this is modifying the program,
parsing input parameters and setting up the logging system.
Indeed, that's why I clarified in the follow-up message; sorry it's been a
long day :-).
"loglevel" was simply an arbitrary name chosen for that particular example
and getattr() was used as a way to prefix the module so it would access the
logging level constant instead of the literal name of the level as a string
(which would be invalid to pass to level). You'd likely use argparse or
some other command-line argument parsing utility to get it in the first
place. For example:
parser = argparse.ArgumentParser()
parser.add_argument("--log", dest='logging_level', default='WARNING')
args = parser.parse_args()
numeric_level = getattr(logging, args.logging_level.upper())
logging.basicConfig(level=numeric_level, ...)
(input validation omitted for simplification)
> If you want it only temporarily for debugging purposes, or permanently
for all scripts in your system, it's not really feasible.
Hmm, I'm not sure that I like the idea of overriding the default logging
level being set system-wide, or that there would be an especially strong
use case for it. Instead, it seems more practically common to want to set
it on an individual run of a program temporarily. In such cases, using some
form of command-line parsing utility is a perfectly a viable option.
> We have debugging flags for warnings, faulthandlers, asyncio etc...
Logging I would say is the most important and trivial of all, yet we don't
have a flag for it.
Arguably though, the easier it is to implement on your own, the less of a
need there is to be an environment variable to do it. Also, I think the
logging configuration should be on a per-program basis, rather than
globally (which is what env vars are typically used for).
FWIW I'm not opposed to the principle behind the idea, I'm just not
convinced yet that it would be that much better than the options that are
already available, and would be worthwhile to add an entirely new
environment variable for (or be good usage of an env var for that matter).
Perhaps there are other areas to explore for simplifying the process of
changing the logging level from the command-line though.
Also, although not the same proposal, there was a discussion that brought
up some similar points in a python-ideas thread back in 2014:
https://mail.python.org/archives/list/python-ideas@python.org/thread/7ZLMSQU2C65YZ2KVZKZ6MICPTWVFZVJ3/#GCJZGNJOO27WUWKN2DKUP3D6HLYNLFUI.
I think some of the points made in there are relevant to this discussion.
On Wed, Feb 19, 2020 at 10:26 PM Bar Harel wrote:
> Thanks Kyle for the feedback :-)
>
> Unfortunately, there is no logging.loglevel attribute.
>
> At the moment, the only way of doing this is modifying the program,
> parsing input parameters and setting up the logging system.
>
> If you want it only temporarily for debugging purposes, or permanently for
> all scripts in your system, it's not really feasible.
>
> Think of -Wdefault. You can change settings in the warnings module and
> modify files each time you wish to enable all warnings. But then again, why
> would you?
>
> We have debugging flags for warnings, faulthandlers, asyncio etc...
> Logging I would say is the most important and trivial of all, yet we don't
> have a flag for it.
>
> On Thu, Feb 20, 2020, 4:24 AM Kyle Stanley wrote:
>
>> > This can already be done from the command line through --log=LEVEL,
>> which sets the logging.loglevel attribute. In the how-to section of the
>> docs, this is demonstrated in the following example:
>>
>> Note: "loglevel" is an arbitrary name, but this can be implemented
>> trivially with something like argparse to check for a --log argument.
>>
>> On Wed, Feb 19, 2020 at 9:19 PM Kyle Stanley wrote:
>>
>>> > Setting PYTHONLOGGING to any log level or level name will initialize
>>> logging.basicConfig() with that appropriate level.
>>>
>>> This can already be done from the command line through --log=LEVEL,
>>> which sets the logging.loglevel attribute. In the how-to section of the
>>> docs, this is demonstrated in the following example:
>>>
>>> # assuming loglevel is bound to the string value obtained from the# command
>>> line argument. Convert to upper case to allow the user to# specify
>>> --log=DEBUG or --log=debugnumeric_level = getattr(logging,
>>> loglevel.upper(), None)if not isinstance(numeric_level, int):
>>> raise ValueError('Invalid log level: %s' %
>>> loglevel)logging.basicConfig(level=numeric_level, ...)
>>>
>>> (https://docs.python.org/3/howto/logging.html#logging-to-a-file)
>>>
>>> Is there a practical reason why the above doesn't work for you? Otherwise,
>>> I see no reason to add a new environment variable that effectively does the
>>> same thing.
>>>
>>>
>>> On Wed, Feb 19, 2020 at 8:16 PM Bar Harel wrote:
>>>
Another
