First some definitions.  I looked over what google and 
http://en.wikipedia.org/wiki/GUID had to offer and came up with this:

guid: Globally unique identifier. A 16-byte identifier.  Guids are most 
commonly 
written in text as a sequence of hexadecimal digits with some dashes.

uniqueidentifier: ms sql column data type, uses 16 bytes.  nice place to store 
a 
guid.  for the rest of this discussion, consider it synonymous with guid.

In VFP and MsSql tools (EM, Profiler, Query Analyzer) guids are always treated 
like a 36 char string.  I am not sure where (server, client, odbc, vfp, etc) 
the 
translation takes place between 16 bytes and 36 chars.  my guess from 
observations: it is not the server,

The reason I bring this up:

Save Failed:
internal error: None
SQL: update Counters set Counters.nCounter = 5 where 
Counters.kCounters_pk='15?'ÒC²ÕñܾS¤¤'

I think the framework should take care of translating that into it's hex 
representation, complete with dashes, per the wikipedia description.

Now the kicker: python has nice support for human readable versions of things 
that are not human readable.

"The str() function is meant to return representations of values which are 
fairly human-readable, while repr() is meant to generate representations which 
can be read by the interpreter (or will force a SyntaxError if there is not 
equivalent syntax). For objects which don't have a particular representation 
for 
human consumption, str() will return the same value as repr()."  - 
http://docs.python.org/tut/node9.html

And because it is related:
"The pprint module provides a capability to ``pretty-print'' arbitrary Python 
data structures in a form which can be used as input to the interpreter. If the 
formatted structures include objects which are not fundamental Python types, 
the 
representation may not be loadable." 
http://docs.python.org/lib/module-pprint.html

So, I can see a case for leaving the internal value of a guid as a 16 byte 
number, and hook into __str__ and __repr__ for display purposes.

This may be worth considering in regards to support for images.  It would be 
nice to display the header info:

[EMAIL PROTECTED]:~/dabo/trunk/dabo/dabo/icons$ identify daboIcon096.png
daboIcon096.png PNG 128x128 128x128+0+0 PseudoClass 256c 6kb

Images is pretty far off of the guid subject, but I think worth considering as 
part of the guid display problem.

So, given all this fluff, what seems to be in line with the dabo way?

I am sure someone will say "why not use the guid module" and give the the URL I 
couldn't find.

Carl K

_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev

Reply via email to