-
Notifications
You must be signed in to change notification settings - Fork 126
Warning and error handling in _bytesify_input is too inflexible #166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The proposal looks reaonable. I hope to fully get to it next week. (initial nitpick: let's use I'm also thinking about doing this as 3.1. I feel the betas aren't useful any more; AFAIK there's only you trying them out. |
Do you want to address the issue for 3.0 or shall we get 3.0.0 out now and implement this for 3.1? I'm fine with getting 3.0 out now. But we should make |
I played around with the idea. See the d984f34 for a (test-less) implementation. |
How do you plan to encode |
Argh. I misread the most important part of the issue, didn't I. About deprecating |
Well, you skipped the most important part for my use case. :) What do you want to use instead of |
`bytes_warnings`, as in your proposal, sounds good. With string values,
preferably.
…On Jan 15, 2018 6:07 PM, "Christian Heimes" ***@***.***> wrote:
Well, you skipped the most important part for my use case. :)
What do you want to use instead of bytes_mode_hardfail?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#166 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AASfSj6nZ2_uk9CncfPeUhRCMlaLwvErks5tK4XRgaJpZM4RcLTG>
.
|
It's very unlikely that I will have time to develop and test a patch before Feb 6th. I'm busy with DevConf CZ preparations and will have a week of meetings and travel after DevConf. Proposition
|
Renaming |
The way how
_bytesify_input
handles errors and warnings is too inflexible:python-ldap/Lib/ldap/ldapobject.py
Lines 125 to 158 in ad46c11
bytes_mode=None
(default), the function emits a bytes warning when the input is text, then encodes it as UTF-8 bytes. Warnings are slow and can cause performance regressions (see Possible performance regression with LDAPBytesWarning #133). The warnings are always emitted, even when warnings are disabled and not shown to the user. The warnings module does not allow early opt-out.bytes_mode=False
(strictly future-compatible) there is no warnings mode at all. When the function is called with bytes as input, it always fails withTypeError
. TypeErrors make it really, really hard to port an existing application to future compatible API. There should be a mode that emits just warnings.Proposal
I suggest that we introduce a
bytes_warning
flag:bytes_warning=BYTES_WARNINGS_SILENT
emits no warnings and doesn't raise TypeError forbytes_mode
None, True, and False.bytes_warning=BYTES_WARNINGS_WARN
emits a warning when input is text forbytes_mode=None
/bytes_mode=True
or input is bytes forbytes_mode=False
.bytes_warning=BYTES_WARNINGS_ERROR
raises a TypeError when input is text forbytes_mode=None
/bytes_mode=True
or input is bytes forbytes_mode=False
.bytes_warning=None
(default) depends onbytes_mode
:bytes_mode=None
->BYTES_WARNINGS_WARN
bytes_mode=True
->BYTES_WARNINGS_ERROR
bytes_mode=False
->BYTES_WARNINGS_ERROR
The flags are defined as:
The text was updated successfully, but these errors were encountered: