>> and the C standard says that sizeof(char) == 1 byte.
>
> Does it actually use the word byte, or does it just say the
> "smallest addressable unit of memory" or something?
>
> Seems to me it can't have it both ways, without also trying
> to define the meaning of "byte", which I don't think it h
2008/4/15 Guido van Rossum <[EMAIL PROTECTED]>:
> On Tue, Apr 15, 2008 at 6:10 PM, Michael Urman <[EMAIL PROTECTED]> wrote:
> >The third use, to represent strings unambiguously, is not a major point,
>
> This is very much dependent on who is looking.
>
> > Similarly it's more useful to have '日本
On Tue, Apr 15, 2008 at 6:10 PM, Michael Urman <[EMAIL PROTECTED]> wrote:
> I agree with that this is enoguh. I see two main uses for repr when it
> comes to strings: to put quotes around the contents, and to replace
> control characters with safe representations the interpreter
> understands.
Paul Moore wrote:
> If you don't
> want to change your code, write
>
> from my_repr import my_repr as repr
But repr() itself doesn't do anything -- it just
invokes the __repr__ method of its argument. So
you can't actually accomplish anything by replacing
it, unless your replacement does a lo
Terry Reedy wrote:
> import unirep
> print(*map(unirep.russian, objects))
That's okay if the objects are strings, but what about
non-string objects that contain strings?
We'd need another protocol, such as __unirep__.
--
Greg
___
Python-3000 mailing l
Nick Coghlan wrote:
> and the C standard says that sizeof(char) == 1 byte.
Does it actually use the word byte, or does it just say the
"smallest addressable unit of memory" or something?
Seems to me it can't have it both ways, without also trying
to define the meaning of "byte", which I don't th
On Tue, Apr 15, 2008 at 7:06 PM, atsuo ishimoto <[EMAIL PROTECTED]> wrote:
> For debugging, I think patch http://bugs.python.org/issue2630 is
> practical enough if error handler of sys.stdout is 'backslashescape'.
>
> If you are Russian and you want to print list of Cyrillic string, you
> can print
On Tue, Apr 15, 2008 at 5:34 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I thought I had a reasonable proposal: deprecate in 3.1, remove in
> > 3.3. Adding a PendingDeprecationWarning in 3.0 would be fine. Doing
> > anything in 2.6 would not be fine, except perhaps mak
Guido van Rossum wrote:
> I thought I had a reasonable proposal: deprecate in 3.1, remove in
> 3.3. Adding a PendingDeprecationWarning in 3.0 would be fine. Doing
> anything in 2.6 would not be fine, except perhaps making it a
> PendingDeprecationWarning whan -3 is given.
How do you feel if I clos
2008/4/16, Terry Reedy <[EMAIL PROTECTED]>:
> I suspect the real solution has to be language-community (and even
> programmer) specific, since I expect most people would like the chars they
> know and expect to be unescaped and others left escaped. So, perhaps there
> should be a unirep module
2008/4/16, Guido van Rossum <[EMAIL PROTECTED]>:
>
> So it sounds like we're doomed if we do, and damned if we don't. Or do
> I misunderstand you? Do you have a practical suggestion?
>
For debugging, I think patch http://bugs.python.org/issue2630 is
practical enough if error handler of sys.stdout
On 15/04/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
> | So it sounds like we're doomed if we do, and damned if we don't. Or do
> | I misunderstand you? Do you have a practical suggestion?
>
> You understood the same as me.
That's how
On Tue, Apr 15, 2008 at 6:06 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Input and output are often wildly asymmetric anyway. It's easy to make
> int() and float() accept more input types. But making them return a
> different output type is different. I find the existing work-arounds
> good
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Tue, Apr 15, 2008 at 10:29 AM, Stephen J. Turnbull
| <[EMAIL PROTECTED]> wrote:
| > Guido van Rossum writes:
| > > In Py3k we may be able to do something else though -- instead of
| > > insisting on ASCII we c
On Tue, Apr 15, 2008 at 2:56 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 15, 2008 at 2:37 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> > Agreed. Otherwise the common ascii based network protocol task of reading
> some bytes in and converting them to the integer that they rep
On Tue, Apr 15, 2008 at 2:37 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
> Agreed. Otherwise the common ascii based network protocol task of reading
> some bytes in and converting them to the integer that they represent in
> ascii would require an additional unicode decoding step.
>
This use
Agreed. Otherwise the common ascii based network protocol task of reading
some bytes in and converting them to the integer that they represent in
ascii would require an additional unicode decoding step.
On Tue, Apr 15, 2008 at 7:18 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Yeah, practica
On Tue, Apr 15, 2008 at 10:29 AM, Stephen J. Turnbull
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum writes:
> > In Py3k we may be able to do something else though -- instead of
> > insisting on ASCII we could allow a much larger set of characters to
> > be unescaped.
>
> Yes. The implicatio
Neal Norwitz wrote:
>
> Yeah, I'm sure we should have more documentation. You could really
> help the situation by documenting all the things you learn. That way
> everyone else will be able to learn from you.
>
>> So I would like to make sure that some people is willing to help me
>> wheneve
Guido van Rossum writes:
> A complaint about this would carry more weight when it came from
> someone who actually has to deal with the issue than coming from a
> purely theoretical perspective (unless I'm wrong and you actually read
> Japanese).
This *is* a problem. In my experience a lot o
Yeah, practicalibty beat purity on that one. I'd say let it beat
purity on int() and float() as well.
On Tue, Apr 15, 2008 at 2:42 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mark Dickinson wrote:
> > On the other hand, there's at least some sense in which bytes already
> > acts as a sort of p
Trent Nelson wrote:
>> Mark Dickinson gmail.com> writes:
>>> Fair enough. My twisted mind was trying to find ways that size_t
>>> might be something other than long or long long, but that seems
>>> unlikely...
>> There has been a report where sizeof(size_t) < sizeof(long).
>> It breaks things in
> Mark Dickinson gmail.com> writes:
> > Fair enough. My twisted mind was trying to find ways that size_t
> > might be something other than long or long long, but that seems
> > unlikely...
>
> There has been a report where sizeof(size_t) < sizeof(long).
> It breaks things in the dict implementat
Mark Dickinson wrote:
> On the other hand, there's at least some sense in which bytes already
> acts as a sort of poor-man's string: witness bytes.lower and friends.
> Maybe practicality beats purity here?
From PEP 358 (describing what is now bytearray):
"""Note the conspicuous absence of .isupp
Mark Dickinson gmail.com> writes:
> Fair enough. My twisted mind was trying to find ways that size_t
> might be something other than long or long long, but that
> seems unlikely...
There has been a report where sizeof(size_t) < sizeof(long). It breaks things in
the dict implementation:
http://bu
Thanks. Perhaps it is a false alarm. I will test again.
Regards
On Tue, Apr 15, 2008 at 2:25 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
>
> Anand Balachandran Pillai wrote:
>
> > Hi list,
> >
> > After updating py3k trunk to the most recent svn version
> > (62349) and building Python, I am gettin
Anand Balachandran Pillai wrote:
> Hi list,
>
> After updating py3k trunk to the most recent svn version
> (62349) and building Python, I am getting the following
> error while trying to start the interpreter.
>
> [EMAIL PROTECTED] ~]$ /usr/local/bin/python
> Fatal Python error: Py_Initialize: c
When I said "trunk" I meant the py3k branch i.e
http://svn.python.org/projects/python/branches/py3k .
Thanks
On Tue, Apr 15, 2008 at 2:13 PM, Anand Balachandran Pillai
<[EMAIL PROTECTED]> wrote:
> Hi list,
>
> After updating py3k trunk to the most recent svn version
> (62349) and building Pyth
Hi list,
After updating py3k trunk to the most recent svn version
(62349) and building Python, I am getting the following
error while trying to start the interpreter.
[EMAIL PROTECTED] ~]$ /usr/local/bin/python
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (m
Good to see this. Thanks!
On Sun, Apr 13, 2008 at 2:37 AM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> If you're interested, I've implemented equality for range in issue 2603.
>
>
> --
> Cheers,
> Benjamin Peterson
>
--
-Anand
___
Python-3000 m
30 matches
Mail list logo
