You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was wondering if there is any interest in implementing a "fallback" list line parser.
Currently, any callable passed as parse_list_line_custom will take precedence over parse_list_line_unix and parse_list_line_windows. However, for client code dealing with the "occasional" odd server that requires a custom parser, I much rather define a "fallback" parser used in last resort than ALWAYS overriding the built in parsers.
Here is an implementation of this, but alternatively maybe a 'last'/'first' argument could be used to tell the Client in what order to use the custom parser.
The text was updated successfully, but these errors were encountered:
I got your point, but is there something wrong with just raising a ValueError if your custom parser don't understand the line and want to try unix and windows parsers instead?
the problem is that oftentimes the custom parser WILL understand the line, but I would prefer to use self.parse_list_line_unix or self.parse_list_line_windows when they work.
somewhat related to issues 104 and 144
I was wondering if there is any interest in implementing a "fallback" list line parser.
Currently, any callable passed as
parse_list_line_custom
will take precedence overparse_list_line_unix
andparse_list_line_windows
. However, for client code dealing with the "occasional" odd server that requires a custom parser, I much rather define a "fallback" parser used in last resort than ALWAYS overriding the built in parsers.Here is an implementation of this, but alternatively maybe a
'last'/'first'
argument could be used to tell theClient
in what order to use the custom parser.The text was updated successfully, but these errors were encountered: