Page MenuHome

Add support to numbers like '002.3' in numeric inputs.
AbandonedPublic

Authored by Bastien Montagne (mont29) on Dec 19 2013, 5:58 PM.

Details

Summary

Python does not support '002' and raises syntax error when trying to evaluate it.
Simply remove heading zeros in numbers before trying to evaluate user's expression with py.

Diff Detail

Branch
support_heading_zeros_in_numinput

Event Timeline

Whats the use case for supporting this ability?

This seems unnecessary (who asked for this, if so why?), we dont _have_ to support every kind of input.

To me this seems error prone to attempt to parse input strings which could contain various formatting, including number representations Python adds in the future.

Python can do... 0x123

Should we support... 00x123?

Same for 0b010101, 0o007.
(ok, this is extreme example I know, just to say that Python can do some strange formatting and Im not sure its valuable to attempt to second guess what a valid number is)

Also this patch, afaics fails for valid floats like 0.1e+2 (as in, it won't work for 00.1e+2).

Well, D71 does something similar (but only for smpte-like timecode, so that you can enter things like 00:02:30:00).

Imho, it’s better to handle it on a general basis, though, this can popout randomly (you copy/paste a time value like 05h06m30s and don’t understand why it does not work…). I think current behavior is a bug, there is no reason for entries like '003' to fail to be evaluated (I mean, users will not understand this).

Eeeeh… it does work OK with both 0.1e+2 and 00.1e+2, generating expected '10.0' value?

Just realized that '003.2' is already supported, btw… python is really odd here (I know why, but I don’t think this is something we want to expose/explain to users!).

D71 is different because smpte not only accept, but it also expects leading zeros. So I would say it's probably fine to keep the zero stripping there only

@Bastien Montagne (mont29), hah, I wasnt aware that leading zero's worked for floats but not int's.

Rather not do this for all strings before passing off to Python still.

Now the functionality is very predictable - if it works in Python, it works as button input and Python is flexible enough, if you start to manipulate strings before handing off to Python it means more complex expressions may be broken and since this is a language its really hard to parse it accurately in just a few 100 lines.

If this is needed for time input, Id prefer we have some special handling for time.
Maybe add ".0" onto the end of all numbers to ensure leading zero's wont break (needs to be done carefully too though).

I think this code behaves correctly with usual kind of inputs. Only potential breaking case I can see is rather exotic in this context, and afaik not supported anyway, it would be numbers inside var names, e.g. var001 would get changed to var1

Anyway, see your point. There’s probably no real good solution in this case (except python accepting integers with leading 0, but since this would be against 'common practice' in most languages, I bet this is rather unlikely ;) ), we’ll have to leave with it (and use case-by-case handling when supporting this is mandatory, like with smpte).