What is 0L in the NonSerializingDataset?

I have a form where I feed the current data on screen as a dictionary to function to handle update/inserts.

I’m now trying to implement the old data/retrieved data from when the form is first opened, as occasionally I will need to do other database operations based on changes in certain columns.

When I turn the NonSerializingDataset that is the custom property on my root container that has all the original data to populate the form, I try to turn it into a dictionary like this -

def nonSerializingDatasetToDictionary(dataset):
	"""
	Takes a dataset with columns and one row and returns a dictionary where the key = column name
	and value is tuple of row values in order
	Args:
		dataset:NonSerializingDatasetdataset, dataset you want to turn into a dictionary
	Returns:
		dictionary: dict, dictionary of the dataset 
	"""

	import system.dataset
	dict = {}
	for row in range(dataset.getRowCount()):
		for column in range(dataset.getColumnCount()):
			columnName =  str(dataset.getColumnName(column))
			value = dataset.getValueAt(row, columnName)
			dict[columnName] = value
	return dict

Now when I make the dictionary, it’s just grabbing the appropriate value property from the components on screen and I get something like this -
{'sentToContact': True, 'sentToAcctNotNeeded': True, 'sentToAccounting': True, 'state': 0, 'sentToContNotNeeded': True, 'receivedConfirmation': False}

while my non serializing dataset turns into this
{'sentToContact': 0, 'sentToAcctNotNeeded': 0, 'sentToAccounting': 0, 'state': 0L, 'receivedConfirmation': 0, 'sentToContNotNeeded': 0}

I’ve tested it and all my comparisons work fine as 0 is interpreted as False and 1 as True. But why does my state column, which has an integer value, turn to 0L. It works, I’ve tried comparing it with 0 and it’s fine, but I was just wonderign why it says 0L instead of just 0.

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.

1 Like

Thanks. Yea didn’t cause any issues I just wanted to learn more about how things work under the hood so to speak.

1 Like

Just note that python/jython will preserve a long as a long through the int() function if it doesn’t fit in a signed 32-bit register. Also, python will only print the ‘L’ on longs if repr() is used instead of str().