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"后缀?
基础教程推荐
- SQL Server 实例在登录协商期间返回无效或不受支持的协议版本 2021-01-01
- 是否可以执行按位分组功能? 2021-01-01
- SQL 效率:WHERE IN 子查询 vs. JOIN 然后 GROUP 2021-01-01
- 无法解决整理冲突 2021-01-01
- 将 SQL Server DateTime 列迁移到 DateTimeOffset 2021-01-01
- 需要 MySQL 5.1 中的抽象触发器来更新审计日志 2021-01-01
- 如何使用 mysql.connector 禁用查询缓存 2022-01-01
- SQL:使用来自具有相同列名的两个表中的数据... 2021-01-01
- 在 SQL 中连接多个表 2021-01-01
- SSMS 中的权限问题:“对象 'extended_properties'、数据库 'mssqlsystem_resource'、... 错误 229)上的 SELECT 权限被拒绝" 2022-01-01
