Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Tony Arcieri
    @tarcieri
    The spec doesn't specifically address nullability, but as you say it's used commonly enough the entire type system probably needs to be treated as nullable everywhere. Nullability is a little different from heterogenous types though, or at least a special case
    re: arrays of disparate types, I proposed typing them as tuples: tjson/tjson-spec#38
    anupsv
    @anupsv
    Hi @tarcieri
    im new here but been following tjson for a while now :)
    Tony Arcieri
    @tarcieri
    Hi there @anupsv
    Tony Arcieri
    @tarcieri
    Saw your Python implementation. Awesome
    anupsv
    @anupsv
    Thanks a lot Tony
    Tony Arcieri
    @tarcieri
    I should probably send an email to the Google Group about the remaining open issues, although I'm not sure how many people actually signed up
    anupsv
    @anupsv
    😀, although it works I'm gonna improve it more with immutable classes....
    Tony Arcieri
    @tarcieri
    looks like two people :worried:
    apparently this is a better place to discuss stuff
    anupsv
    @anupsv
    Hehe
    I'll join the Google group soon
    Tony Arcieri
    @tarcieri
    I'd say the major remaining issues are:
    Floating point syntax: tjson/tjson-spec#43
    Boolean syntax: tjson/tjson-spec#44
    Nullability: tjson/tjson-spec#42
    Full type signatures for objects: tjson/tjson-spec#41
    Nice-to-haves are:
    Tuples: tjson/tjson-spec#38
    Sets: tjson/tjson-spec#22
    anupsv
    @anupsv
    Hmmm.....tuples and sets seem nice to have... But issues first
    Ill look at floating point tomorrow
    see the best methods to go bout this
    Tony Arcieri
    @tarcieri
    I'm not finished specing it yet, but it's pretty much guaranteed to be f for 32-bit single-precision floats, d for 64-bit double-precision floats stored in strings, both as specified in IEEE754-2008
    there's an open question as to whether f should be stored in a string or as a JSON floating point literal (or both)
    anupsv
    @anupsv
    a json floating point may have different behaviors
    a string would be logically more likely , but then again, need ways to distinguish
    Tony Arcieri
    @tarcieri
    RFC 7159 is unfortunately a bit vague on all of this :worried:
    This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision.
    i.e. precision is an implementation detail
    anupsv
    @anupsv
    huh
    Tony Arcieri
    @tarcieri
    I think it's reasonable to expect single-precision 32-bit floats to be ubiquitously supported
    as a native type
    anupsv
    @anupsv
    yep
    anupsv
    @anupsv
    So boolean will have "v"
    Tony Arcieri
    @tarcieri
    As presently proposed, yes
    anupsv
    @anupsv
    seems fine, shouldnt be complicated
    Nullability needs more thought
    Tony Arcieri
    @tarcieri
    yes
    I am a fan of making TJSON non-nullable for now
    anupsv
    @anupsv
    yep, that should work and may be with the next major version, we could add the alternative
    Tony Arcieri
    @tarcieri
    :thumbsup:
    Justin Fay
    @justinfay
    Hi @anupsv I forked your repo to https://github.com/justinfay/tjson-python/ and added the test suite, I had to make some small tweaks to get the test suite to run and there are still a few failures on py2/py3
    I also think you could do without the python-dateutil dependency as timezones should always be UTC
    anupsv
    @anupsv
    I'll look into it, i've not yet made it compatible to py3
    anupsv
    @anupsv
    Should'nt be that hard, will look into it this weekend
    Tony Arcieri
    @tarcieri
    For anyone curious about JavaScript: TC39 is discussing adding 64-bit signed and unsigned integers to JavaScript
    which should be supported by transpilers soon
    Tony Arcieri
    @tarcieri
    I am going to hold off on implementing the JavaScript version until that's available