Fred Drake wrote:
On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote:
Fred asked for a --prefix flag (which is what I was voting on). I don't
really care what you do by default as long as you give me a way to do it
differently.
What's most interesting (to me) is that no one's commented on my
On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote:
Fred asked for a --prefix flag (which is what I was voting on). I
don't
really care what you do by default as long as you give me a way to
do it
differently.
What's most interesting (to me) is that no one's commented on my note
that my
On Sat, May 03, 2008 at 10:57:06PM +0200, "Martin v. L?wis" wrote:
> > there is a chance .encode() after repr() will escape or unescape the result
> > in a wrong way.
>
> No, there is no such chance.
Ok, then. Probbaly I was wrong.
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/
def repr_ascii(obj):
return str(repr(obj).encode("ASCII", "backslashreplace"), "ASCII")
>>>It is hard to apply the function for repr(container).
>>> repr(container).encode("unicode_escape") is the only way (at least I don't
>>> see any other way).
>> I think Atsuo envisioned you t
On Sat, May 03, 2008 at 10:20:43PM +0200, "Martin v. L?wis" wrote:
> > On Sat, May 03, 2008 at 09:54:24AM +0900, Atsuo Ishimoto wrote:
> >> If requirement for ASCII-repr is popular enough, we can provide a
> >> built-in function like this:
> >>
> >> def repr_ascii(obj):
> >> return str(repr(obj
> On Sat, May 03, 2008 at 09:54:24AM +0900, Atsuo Ishimoto wrote:
>> If requirement for ASCII-repr is popular enough, we can provide a
>> built-in function like this:
>>
>> def repr_ascii(obj):
>> return str(repr(obj).encode("ASCII", "backslashreplace"), "ASCII")
>
>It is hard to apply the
On Sat, May 03, 2008 at 09:54:24AM +0900, Atsuo Ishimoto wrote:
> If requirement for ASCII-repr is popular enough, we can provide a
> built-in function like this:
>
> def repr_ascii(obj):
> return str(repr(obj).encode("ASCII", "backslashreplace"), "ASCII")
It is hard to apply the function
Barry Warsaw wrote:
On May 3, 2008, at 5:05 AM, Nick Coghlan wrote:
- for experienced users (Barry, skip, etc) that want ~/.local to be
more easily accessible, creating a visible ~/local symlink is an
utterly trivial exercise.
Hey Nick, I agree with everything above, except that I'd probably
Stephen J. Turnbull wrote:
Nick Coghlan writes:
> Martin v. Löwis wrote:
> >> Is new built-in function desirable, or just document is good enough?
> >
> > Traditionally, I take the position that new built-in functions are
> > rarely desirable; this one is no exception.
>
> I agree with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On May 3, 2008, at 5:05 AM, Nick Coghlan wrote:
The major reasons why I think staying out of people's way by default
is important:
- for people like me (glyph, Georg, etc), it allows us to keep our
home directory organised the way we like it. As
Nick Coghlan writes:
> Martin v. Löwis wrote:
> >> Is new built-in function desirable, or just document is good enough?
> >
> > Traditionally, I take the position that new built-in functions are
> > rarely desirable; this one is no exception.
>
> I agree with that, but string.repr_ascii ma
>> - for experienced users (Barry, skip, etc) that want ~/.local to be
>> more easily accessible, creating a visible ~/local symlink is an
>> utterly trivial exercise.
Barry> Hey Nick, I agree with everything above, except that I'd probably
Barry> put myself more in Glyph'
Nick> [EMAIL PROTECTED] wrote:
Fred> If user-local package installs went to ~/ by default ... with a
Fred> way to set an alternate "prefix" instead of ~/ using a distutils
Fred> configuration setting, I'd be happy enough.
Skip> +1 from me.
Nick> But then we clutter up peo
I'd much rather stick with a single style guide; PEP 8 can be revised
as needed. I suggest that we preface the 2.x-specific things with
words like "in Python 2, ..." but by and large focus the style guide
on Py3k. We could even migrate the rules that are only relevant to 2.x
to an Appendix-like cha
Bill Janssen wrote:
I slightly prefer ~/.local/ over other suggestions
but I'm also open to ~/.python.d/
Guido's point about it not being necessarily "local" is a good one. I
use lots of computers; they all automount my home directory (~) from a
network file server. Nothing under that directo
[EMAIL PROTECTED] wrote:
Fred> If user-local package installs went to ~/ by default ... with a
Fred> way to set an alternate "prefix" instead of ~/ using a distutils
Fred> configuration setting, I'd be happy enough.
+1 from me.
But then we clutter up people's (read *my*) home direc
Martin v. Löwis wrote:
Is new built-in function desirable, or just document is good enough?
Traditionally, I take the position that new built-in functions are
rarely desirable; this one is no exception.
I agree with that, but string.repr_ascii may be a reasonable thing to add.
Cheers,
Nick.
> Is new built-in function desirable, or just document is good enough?
Traditionally, I take the position that new built-in functions are
rarely desirable; this one is no exception.
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
htt
18 matches
Mail list logo
