On Thu, Feb 14, 2008 at 6:04 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Now can you come up with a syntax for positional-only
> > arguments? So far everybody has failed at that, and there are some use
> > cases where it's useful too.
>
> def foo(*(a, b,c)):
>...
Raymond Hettinger wrote:
> When you run reversed(s), the s argument
> can be any Sequence (either mutable or immutable) and the
> return value is an iterator that doesn't copy the whole
> dataset.
If reversed() became a *view* (a mutable one) rather than
an iterator, there might be more of a case
[EMAIL PROTECTED] wrote:
> How about being able to reopen() an open file object, e.g.:
>
> print(..., file=sys.stdout.reopen(encoding="utf-8")
But reopening implies a lot more than just changing the
encoding.
--
Greg Ewing, Computer Science Dept, +--+
Un
Raymond Hettinger wrote:
> Would it be worthwhile to leave reversed(s) and s[::-1]
> as the two obvious ways to do it?
But that would leave us without an efficient way of
reversing in-place.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury
Guido van Rossum wrote:
> Now can you come up with a syntax for positional-only
> arguments? So far everybody has failed at that, and there are some use
> cases where it's useful too.
def foo(*(a, b,c)):
...
i.e. catch them in a * arg which is unpacked in-place.
--
Greg Ewing, Computer Scien
Guido> You can hack around this for now by doing (before printing
Guido> anything)
Guido> sys.stdout._encoding = 'utf-8'
Guido> but that ought to be a temporary hack until we've figured out the
Guido> right way to set it.
How about being able to reopen() an open file object
[Skip]
> If s.reverse() is dumped shouldn't s.sort() be as well?
I don't think so. When you run reversed(s), the s argument
can be any Sequence (either mutable or immutable) and the
return value is an iterator that doesn't copy the whole
dataset.
In contrast, sorted() takes any iterable and make
>> But .reverse() is in-place, while the other two create new sequences,
no?
Raymond> reversed(s) creates an iterator and s[::-1] creates a new list.
Raymond> They are not the same as s.reverse() but the use cases overlap
Raymond> quite a bit.
If s.reverse() is dumped shouldn't
[Steven]
> But .reverse() is in-place, while the other two create new sequences, no?
reversed(s) creates an iterator and s[::-1] creates a new list. They are not
the same as s.reverse() but the use cases overlap quite a bit.
Raymond
___
Python-3000
On Thu, Feb 14, 2008 at 5:52 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Would it be worthwhile to leave reversed(s) and s[::-1] as the two obvious
> ways to do it (ways that work with any Sequence, not just lists)?
But .reverse() is in-place, while the other two create new sequences, no?
Would it be worthwhile to leave reversed(s) and s[::-1] as the two obvious ways
to do it (ways that work with any Sequence, not just lists)?
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Guido van Rossum writes:
> The code that guesses the default stdout encoding isn't very good,
> especially not on OSX. Suggestions are welcome.
FWIW XEmacs 21.5 (still unreleased) was changed to set all system
codecs (path, stdin, and stdout) to UTF-8 at startup if it's running
on Mac OS (a bui
On Thu, Feb 14, 2008 at 2:59 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Maybe a decent rule of thumb would be:
> >
> > - if LANG is set, use the encoding it specifies; if there's no
> > encoding in it, assume it's ASCII.
> >
> > - if LANG is *not* set, default to UTF-8 instead of to
On Thu, Feb 14, 2008 at 2:48 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I've been exercising the new keyword-only arguments syntax. It is absolutely
> wonderful. I'm amazed at how many long standing problems it solves elegantly.
Agreed. Now can you come up with a syntax for positional-o
> Maybe a decent rule of thumb would be:
>
> - if LANG is set, use the encoding it specifies; if there's no
> encoding in it, assume it's ASCII.
>
> - if LANG is *not* set, default to UTF-8 instead of to US-ASCII; UTF-8
> is much more likely to be correct and useful for 10.4 and before.
You mean
I've been exercising the new keyword-only arguments syntax. It is absolutely
wonderful. I'm amazed at how many long standing problems it solves elegantly.
Thanks Talin!
Raymond
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.o
In Leopard (OSX 10.5), it looks like LANG is set to convey this: it
has the value en_US.UTF-8 for me, and I haven't done anything to
change it. The Preferences dialog is completely changed from 10.4 and
there's a checkbox (on by default AFAIK) to set the LANG variable.
(However I've noticed that it
> The code that guesses the default stdout encoding isn't very good,
> especially not on OSX. Suggestions are welcome.
Unfortunately, Apple isn't very cooperative here. There is no way
of determining the encoding of a Terminal.app window, AFAIK
(it's normally UTF-8, unless the user has changed it)
The encoding is a file property, not a print parameter.
The code that guesses the default stdout encoding isn't very good,
especially not on OSX. Suggestions are welcome.
You can hack around this for now by doing (before printing anything)
sys.stdout._encoding = 'utf-8'
but that ought to be a
A thread on the Python Mac sig got me to wondering if there is any magic in
Python 3's print function for printing Unicode. Nope, no magic:
>>> print("\xef")
Traceback (most recent call last):
File "", line 1, in
File "/Users/skip/local/lib/python3.0/io.py", line 1246, in wri
Daniel Stutzbach wrote:
> Okay, but turn it around for a minute. Which types should have a
> .copy() method and why?
I would argue that it's not about mappings, it's about mutability. I
always thought the .copy method on dicts was to allow functions to work
on a passed-in dict without causing
21 matches
Mail list logo
