Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2000-June/005029.html below:

[Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)

• Previous message: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
• Next message: [Python-Dev] id() on Win64
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

[Greg Stein]
> Regardless: yes, it can certainly break some code. IMO, if any code out
> there makes any kinds of assumptions about id(), then they deserve to be
> broken :-)

[Trent Mick]
> Amen.

Guys, it's almost never that simple, and developers are the last ones to
think of the reasonable cases that may break.  In this case, e.g., code may
be doing something as harmless as printing an id() via a "... %d ..." format
in a log, and-- BOOM! --that blows up with an OverflowError if you feed it a
Python long larger than a C long.

I'd rather fix %d formats than leave id() broken, though!  id() has to
return a unique value.

but-i'll-sympathize-with-the-users-even-in-public<wink>-ly y'rs  - tim

• Previous message: [Python-Dev] id() on Win64 (was: CVS: python/dist/src/Python bltinmodule.c,2.162,2.163)
• Next message: [Python-Dev] id() on Win64
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4