Giters

wyfo / apischema

JSON (de)serialization, GraphQL and JSON schema generation using Python typing.

Home Page:https://wyfo.github.io/apischema/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`to_snake_case` bug

thomascobb opened this issue · comments

commented 
>>> from apischema.utils import to_snake_case, to_camel_case
>>> to_camel_case("a_long_string_with_123_numbers")
'aLongStringWith123Numbers'
>>> to_camel_case("a_long_string_with123_numbers")
'aLongStringWith123Numbers'
>>> to_snake_case('aLongStringWith123Numbers')
'_lon_strin_with12_numbers'

I'm happy to submit a PR to fix, but what should the output of to_snake_case('aLongStringWith123Numbers') be?

  1. a_long_string_with123_numbers
  2. a_long_string_with_123_numbers
commented

Indeed, to_snake_case is broken. Its presence in the library is an accident, it was supposed to be used, but finally it was not, and it was not removed. Moreover, its neither documented, nor tested (as documentation examples are a large part of the tests).

In fact, apischema is not supposed to be a case conversion library like https://github.com/okunishinishi/python-stringcase. camelCase (as well as PascalCase) aliasing is only implemented as a convenient shortcut, but is not documented either and should not be used for now outside of apischema code.

By the way, to_snake_case bug has been fixed because it's now used with the cythonisation refactoring. But as you mentioned, snake_case is not a trivial thing, for example about number handling. apischema internal to_snake_case implementation just does what apischema need and should not be intended to answer specifical user need in my opinion.

commented

Currently, all the features that are part of the public interface are written in a __all__ list (not necessarily in the same module).

commented

Sounds reasonable, it's good not to bloat libraries beyond their purpose. I can put the one conversion function I need into my code, so this doesn't need to be in apischema...