# What is 0L in the NonSerializingDataset?

**URL:** <https://forum.inductiveautomation.com/t/what-is-0l-in-the-nonserializingdataset/31251>\
**Category:** Ignition\
**Tags:** ignition80\
**Created:** [January 13, 2020, 3:12pm UTC](https://forum.inductiveautomation.com/t/what-is-0l-in-the-nonserializingdataset/31251 "2020-01-13T15:12:14Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\
**Post date:** [January 13, 2020, 4:29pm UTC](https://forum.inductiveautomation.com/t/what-is-0l-in-the-nonserializingdataset/31251/2 "2020-01-13T16:29:08Z")

</div>

Java has separate types for long vs short integers (64 vs 32 bit), while Python abstracts this away from your. Jython makes this a bit more complicated, because it’s backed by the JVM, but it also attempts to abstract this away. We generally try to fix things on our own for presentation, also, but sometimes all that magic just breaks down, and you’ll get an actual ‘long’ type in Python code - which is differentiated by the L after the value.

They’re numerically equivalent, and every Python operation you’ll do between them should work, as you’ve noticed, so it’s not going to cause any problems. If you want to get rid of them, the builtin `int()` function should convert them to “real” Python integers.

---

_[View the full topic](https://forum.inductiveautomation.com/t/what-is-0l-in-the-nonserializingdataset/31251)._