Re: [Python-Dev] Proposal to revert r54204 (splitext change)

2007-03-19 Thread Taro

delurk
On Windows it's correct that splitext(.txt)[1] == splitext(foo.txt)[1]
and an implementation in which this is not true would be considered buggy.
On *ix it's correct that splitext(.txt)[1] != splitext(foo.txt)[1] and
the current behaviour is considered buggy. Since programmer expectations are
platform-specific, regardless of whether keywords are used or not, why not
make the default behaviour platform-specific and document that it's so?

Alternatively, if a new path implementation ever gets up, a more neutral
solution might be to have a platform-specific Path.filetype, which could
handle Mac resources..
/delurk

Cheers, -T
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-3000] Iterators for dict keys , values, and items == annoying :)

2006-03-31 Thread Taro Ogawa
Taro Ogawa taroso at gmail.com writes: 
 Nick Coghlan ncoghlan at gmail.com writes:
  There are three big use cases:
  ...
 delurk
 ...
Apologies - this was posted via gmane and the post I responded to appeared in
the gmane.comp.python.devel.3000 tree...  I'll repost there (and check gmane a
little more carefully in future).

-T.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] [Python-3000] Iterators for dict keys, values, and items == annoying :)

2006-03-30 Thread Taro Ogawa
Nick Coghlan ncoghlan at gmail.com writes:
 There are three big use cases:
dict.keys
dict.values
dict.items
 Currently these all return lists, which may be expensive in terms of copying.
 They all have iter* variants which while memory efficient, are far less 
 convenient to work with.
delurk
Is there any reason why they can't be view objects - a dictionary has keys, 
has values, has items - rather than methods returning view objects:
for k in mydict.keys:
...
for v in mydict.values:
...
for k, v in mydict.items:
...
For backward compatibility with Py2.x, calling them would raise a 
DeprecationWarning and return a list.  This could even be introduced in 2.x 
(with a PendingDeprecationWarning instead?).

Cheers, -T.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com