Support encode int as string

[msyyc]

fix #2703

pending on Azure/cadl-ranch#656

[msyyc]

skip eslint failure caused by deprecation of urlencode:

After #2775 merged, we could revert this change.

[iscai-msft]

i don't think we have to modify model_base.py, we can pass in a deserialization function into the rest_field and have it serialize and deserialize as a string

[msyyc]

autorest.python/packages/typespec-python/generator/pygen/codegen/templates/model_base.py.jinja2

Lines 829 to 840 in 8480487

	class _RestField:
	def __init__(
	self,
	*,
	name: typing.Optional[str] = None,
	type: typing.Optional[typing.Callable] = None, # pylint: disable=redefined-builtin
	is_discriminator: bool = False,
	visibility: typing.Optional[typing.List[str]] = None,
	default: typing.Any = _UNSET,
	format: typing.Optional[str] = None,
	is_multipart_file_input: bool = False,
	):

Appreciate if you could explain more how to pass in deserialization function? It seems that RestField has no parameter to pass it.

[iscai-msft]

you pass it through the type kwarg. For example, in this test, we've typed the prop as being a sequence, but in terms of serislizstion / deserialization, we want it to be a set, so we pass in a callback. We should be able to do the same thing here, where we type it as an int, but we pass in type=lambda x: str(x) / write a callback that does that instead

[tadelesh]

for datetime/bytes encoding, we put the logic in model_base.py. shall we keep consistent for all the encoding things? another thing is if use callback, how to deal with serialization?

[msyyc]

@iscai-msft I think it is better not handle this feature with call_back so that we could keep consistent for all encoding things. But your comment hint me that we could confirm the deserialize and serialize function for model property when generate code so that we could save time for model initialization and I have created #2797 to track it.

[iscai-msft]

Since the model is vendored we can def change things, so I think we can have the rest field take in serialization and deserialization as callbacks. As @msyyc said we've already thought of passing explicit callbacks into rest field for perf improvements, so I think what we should do is do a slight redesign where we have serialization and deserialization callback inputs. When we're generating, we can generate with explicit callback inputs so we don't have to use perf time to determine which serialize / deserialize function we should use

[msyyc]

Exactly. And the change of redesign for serialization/deserialization will be a little huge so I would like to do it in another PR.

[iscai-msft]

Ok I've added a separate issue for the serialization and deserialization, #2801

[iscai-msft]

why do we have this code here> we should already be doing this in the regenreate.ts file, and this is also for the autorest generation. Whatever functinoality we need from this should be moved into the scripts instead of being in yml for the scripts

[iscai-msft]

the one thing i'm not sure about is serialization. If we can't edo serialization here, we should instead add similar functionality but for serialization (and we can rename type to deserialization) instead of adding extra logic through the msrest way

[msyyc]

• there is condition to make sure it only works for typespec-python: https://github.com/Azure/autorest.python/blob/8e20f2136af3ae2e1939533a36c980b7c9bbe572/eng/pipelines/ci-template.yml#L121C12-L121C117
• If we add it in regenerate.ts, when regenreate fails, the local repo will be in a mess since all the generated folders are already deleted.

[iscai-msft]

you pass it through the type kwarg. For example, in this test, we've typed the prop as being a sequence, but in terms of serislizstion / deserialization, we want it to be a set, so we pass in a callback. We should be able to do the same thing here, where we type it as an int, but we pass in type=lambda x: str(x) / write a callback that does that instead