On Wed, 21 Sep 2005 02:55:56 +0200, Greg Ewing
<[EMAIL PROTECTED]> wrote:
> Both of these happen to involve pathnames that exist on
> the currrently available file system, but I can easily
> imagine cases where that would not be so. E.g. I might
> be generating pathames to go into a tar file that
On Tue, 30 Aug 2005 20:55:45 +0200, Tim Peters <[EMAIL PROTECTED]>
wrote:
> [Wolfgang Lipp]
>> reminds me of dict.get()... i think in both cases being explicit::
>>
>> beast = d.setdefault( 666, None )
>> ...
>
> Do you actually do this with
On Tue, 30 Aug 2005 18:14:55 +0200, Tim Peters <[EMAIL PROTECTED]>
wrote:
d = {}
d.setdefault(666)
d
> {666: None}
>
> just doesn't seem useful. In fact, it's so silly that someone calling
> setdefault with just one arg seems far more likely to have a bug in
> their code than to g
On Sat, 27 Aug 2005 16:46:07 +0200, Guido van Rossum
<[EMAIL PROTECTED]> wrote:
> On 8/27/05, Wolfgang Lipp <[EMAIL PROTECTED]> wrote:
>> i never expected .get()
>> to work that way (return an unsolicited None) -- i do consider this
>> behavior harmful and su
kay,
your suggestion makes perfect sense for me, i haven't actually tried
the examples tho. guess there could be a find() or index() or
indices() or iterIndices() ??? function 'f' roughly with these arguments:
def f( x, element, start = 0, stop = None, default = _Misfit, maxcount =
None, rever
On Sat, 27 Aug 2005 13:01:02 +0200, Just van Rossum <[EMAIL PROTECTED]>
wrote:
> Just because you don't read the documentation and guessed wrong d.get()
> needs to be removed?!?
no, not removed... never said that.
> It's a *feature* of d.get(k) to never raise KeyError. If you need an
> excepti
On Sat, 27 Aug 2005 12:35:30 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote:
> P.S. Emphasis mine :-)
no, emphasis all **mine** :-) just to reflect i never expected .get()
to work that way (return an unsolicited None) -- i do consider this
behavior harmful and suggest it be removed.
_wolf
On Sat, 27 Aug 2005 08:54:12 +0200, Martin v. Löwis <[EMAIL PROTECTED]>
wrote:
> with choice 1a): dict.get returns None if the key is not found, even
> though None could also be the value for the key.
that's a bug! i had to *test* it to find out it's true! i've been writing
code for *years* all
i have to revise my last posting -- exporting the new ``str``
pure-python implementation breaks -- of course! -- as soon
as ``isinstance(x,str)`` [sic] is used. right now it breaks
because you can't have a function as the second argument of
``isinstance()``, but even if that could be avoided by ca
just tested the proposed implementation on a unicode-naive module
basically using
import sys
import __builtin__
reload( sys ); sys.setdefaultencoding( 'utf-8' )
__builtin__.__dict__[ 'str' ] = new_str_function
et voilà, str() calls in the module are rewritten, and
print u'düsseldorf' does
neil,
i just intended to worry that returning a unicode object from ``str()``
would break assumptions about the way that 'type definers' like
``str()``, ``int()``, ``float()`` and so on work, but i quickly
realized that e.g. ``int()`` does return a long where appropriate!
since the principle works
11 matches
Mail list logo
