In article ,
Ned Batchelder wrote:
> This idea that the repr can reconstruct the object always fell flat with
> me since the vast majority of classes don't have a repr that works that
> way. I look at it a little differently: the repr is meant to be as
> unambiguous as possible to a develope
On 10/12/13 2:20 AM, Ian Kelly wrote:
On Fri, Oct 11, 2013 at 7:31 AM, Stephen Tucker wrote:
On the original question, well, I accept Ned's answer (at 10.22). I also
like the idea of a helper function given by Peter Otten at 09.51. It still
seems like a crutch to help poor old Python 2.X to do
On Fri, Oct 11, 2013 at 7:31 AM, Stephen Tucker wrote:
> On the original question, well, I accept Ned's answer (at 10.22). I also
> like the idea of a helper function given by Peter Otten at 09.51. It still
> seems like a crutch to help poor old Python 2.X to do what any programmer
> (or, at least
On 10/11/2013 9:31 AM, Stephen Tucker wrote:
to be able to by itself. The distinction between the "geekiness" of a
tuple compared with the "non-geekiness" of a string is, itself, far too
geeky for my liking. The distinction seems to be an utterly spurious -
even artificial or arbitrary one to me
Stephen Tucker writes:
> ESRI compound the problem, actually, by making all the strings that the
> ArcGIS Python interface
> delivers (from MS SQLServer) Unicode! (I suppose, on reflection, they have no
> choice.) So I am
> stuck with the worst of both worlds - a generation of Python (2.X) that
ually *deliberately *the case (which I, at the
> moment, am finding difficult to accept), what is the neatest (that is,
> the most Pythonic) way to get non-ASCII characters in unicode objects in
> tuples displayed correctly?
I'd go with something like this helper function:
d
gt; displays non-ASCII characters in the unicode objects as escape sequences
> (as repr() does)?
>
> 2. Given that this is actually *deliberately *the case (which I, at the
> moment, am finding difficult to accept), what is the neatest (that is, the
> most Pythonic) way to get non-ASCI
ters
sent to the file correctly, whereas, unicode objects in tuples get
their characters sent to the file as escape sequences. Why is this the
case?
4. As for question 1 above, I ask here also: What is the neatest way
to get round this?
Stephen Tucker.
Although Python 3 is better than P
have also found that, even though I use write to send the text to the
> file, unicode objects not in tuples get their non-ASCII characters sent to
> the file correctly, whereas, unicode objects in tuples get their
> characters sent to the file as escape sequences. Why is this the cas
ch I, at
> the moment, am finding difficult to accept)
I'm pretty sure it is not, since this is corrected in Python 3.
> what is the neatest (that is, the most Pythonic) way to get non-ASCII
> characters in unicode objects in tuples displayed correctly?
Switch to Python 3 :-)
--
as escape sequences
(as repr() does)?
2. Given that this is actually *deliberately *the case (which I, at the
moment, am finding difficult to accept), what is the neatest (that is, the
most Pythonic) way to get non-ASCII characters in unicode objects in tuples
displayed correctly?
3. A similar
11 matches
Mail list logo
