byte types

[ichabod801]

__len__() for existing types/classses does not give that (so len() does not, either).

That's why wavic said to create a custom class, not use one of the existing types. Then you can define __len__ to handle all of that stuff, and then len() will handle it for you.

[wavic]

It depends on you how the interpretation of the data is going to happen. An archiving program has different ways to handle the different archives for example. There is no such a thing "one to rule them all".

[Skaperen]

__len__() for existing types/classses does not give that (so len() does not, either).

That's why wavic said to create a custom class, not use one of the existing types. Then you can define __len__ to handle all of that stuff, and then len() will handle it for you.

the whole point about clen() is that any type (that could contain utf-8) which might be provided to a function (that needs to know how many utf-8 characters are in it) that calls clen() so clen() needs to be a single name that handles many types (all types that make sense for it ... all types that can contain utf-8).

it's just like len() except that len() gets to have a method (__len()__) in each type it can handle.

so basically, to implement clen() as versatile as len(), which is a reasonable goal, you need to add it to python itself (e.g. to existing types).

advise to create a custom type misses the mark by a kilometer.

post #1 is about how to work better at check types in a way that visibly suggests it is supporting multiple types. i believe this thread has degraded because of the agenda against handling multiple types. but i am wondering where this agenda originates. i suspect it is from python having the weakness of being unable to allow "user code" supporting dynamic typing the same way python itself can do, which can be solved by allowing "user code" to add methods to existing types (syntactically easy enough by setting attributes on types).

[Gribouillis]

i suspect it is from python having the weakness of being unable to allow "user code" supporting dynamic typing the same way python itself can do

What does it mean? I don't see where Python is unable to support dynamic typing. By the way, using a generic function, you can implement a clen() function that behaves exactly the way len() does including using a __clen__() attribute for user defined types. I would implement it but I still don't understand the result that you expect from a call to clen(). Also note that officially, we should not implement new dunder methods by ourselves, just in case the python devs decide to have a __clen__ attribute someday in the future.

[Skaperen]

you say "user defined types" and that is the big catch, and the limitation of python that prevents full utilization of dynamic types. in summary not all types can be fully used dynamically; only "user defined types" can. this is the limitation that prevents making a function (named whatever you want to name it) do as i described (or any similar generic facility like this) with any type, dynamically. and the saddest part is that this would not be hard to add, conceptually (although i have no idea what limitations a specific implementation might impose). just the ability to (retroactively) add methods to a builtin (any existing) class is enough to achieve it.

[Gribouillis]

this is the limitation that prevents making a function (named whatever you want to name it) do as i described

I didn't say that. I say that the clen() function can behave the way you want for ALL types, but that this behavior can be based on a __clen__ attribute only for user defined types because one can not add members to builtin types.

It is a limitation that we cannot add members to builtin types BUT it doesn't prevent us from implementing a dynamic clen() function by the means of functools.singledipatch.

[Skaperen]

yeah, you're right, we can implement clen() that way. but, why do so as it would be an incomplete implementation. and clen() is just an example, anyway.