Why do integers in database row tuple have an #39;L#39; suffix?(为什么数据库行元组中的整数具有“L后缀?)
问题描述
My question is why do a MySQL row's integer values have an 'L' suffix? Here are the details:
The following dictionary -- artificially formatted here for ease of display --
{'estimated': '',
'suffix': '',
'typeofread': 'g',
'acct_no': 901001000L,
'counter': 0,
'time_billed': datetime.datetime(2012, 5, 1, 9, 5, 33),
'date_read': datetime.datetime(2012, 3, 13, 23, 19, 45),
'reading': 3018L,
'meter_num': '26174200'}
is comprised of a MySQL database table's columns zipped with the result of reading once from the table.
I can remove the 'L' by passing these values into int(), so if that dictionary were in a variable named snapped_read, I could do this:
int(snapped_read['reading']) and 3018L would change to 3018.
I'm just curious as to why integers show up this way.
Because in versions of Python before Python 3, long integer literals were indicated with an l or L suffix. In Python 3, ints and longs have been merged into just int, which functions pretty much like long used to.
Do note that, technically, Python( 2)'s int was equivalent to C's long, while Python's long was more like a BigNumber-type thing with unlimited precision (which is now the case for Python 3's int type.)
http://docs.python.org/library/stdtypes.html#numeric-types-int-float-long-complex
这篇关于为什么数据库行元组中的整数具有“L"后缀?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:为什么数据库行元组中的整数具有“L"后缀?
基础教程推荐
- MySQL 5.7参照时间戳生成日期列 2022-01-01
- while 在触发器内循环以遍历 sql 中表的所有列 2022-01-01
- 使用 VBS 和注册表来确定安装了哪个版本和 32 位 2021-01-01
- 从字符串 TSQL 中获取数字 2021-01-01
- CHECKSUM 和 CHECKSUM_AGG:算法是什么? 2021-01-01
- MySQL根据从其他列分组的值,对两列之间的值进行求和 2022-01-01
- 如何在 CakePHP 3 中实现 INSERT ON DUPLICATE KEY UPDATE aka upsert? 2021-01-01
- ORA-01830:日期格式图片在转换整个输入字符串之前结束/选择日期查询的总和 2021-01-01
- 带更新的 sqlite CTE 2022-01-01
- 带有WHERE子句的LAG()函数 2022-01-01
