Raymond Hettinger wrote:
> Like "autodict" could mean anything.
Everything is meaningless until you know something
about it. If you'd never seen Python before,
would you know what 'dict' meant?
If I were seeing "defaultdict" for the first time,
I would need to look up the docs before I was
confi
Josiah Carlson wrote:
> In this particular example, there is no net reduction in line use. The
> execution speed of your algorithm would be reduced due to function
> calling overhead.
If there were more uses of the function, the line count
reduction would be greater.
In any case, line count and
On 2/21/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>
> I agree with this, but don't know a clean way to do 2 builds. I
> modified buildbot to:
>
> - Stop doing the second "without deleting .py[co]" run.
> - Do one run with a debug build.
> - Use -uall -r for both.
I screwed it up, so now it d
Greg Ewing wrote:
> Raymond Hettinger wrote:
>
>
>>Like "autodict" could mean anything.
>
>
> Everything is meaningless until you know something
> about it. If you'd never seen Python before,
> would you know what 'dict' meant?
>
> If I were seeing "defaultdict" for the first time,
> I would n
Steve Holden wrote:
> Given that the default entries behind the non-existent keys don't
> actually exist, something like "virtual_dict" might be appropriate.
No, that would suggest to me something like
a wrapper object that delegates most of the
mapping protocol to something else. That's
even le
Greg Ewing wrote:
Fuzzyman wrote:
I've had problems in code that needs to treat strings, lists and
dictionaries differently (assigning values to a container where all
three need different handling) and telling the difference but allowing
duck typing is *problematic*.
Yo
Raymond Hettinger wrote:
> Like "autodict" could mean anything.
fwiw, the first google hit for "autodict" appears to be part of someone's
link farm
At this website we have assistance with autodict. In addition to
information for autodict we also have the best web sites concerning
dic
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Stephen J. Turnbull wrote:
>> What I advocate for Python is to require that the standard
>> base64 codec be defined only on bytes, and always produce
>> bytes.
Greg> I don't understand that. It seems quite clear to
Fuzzyman wrote:
> cfg = ConfigObj(newfilename)
> cfg['key'] = 'value'
> cfg['key2'] = ['value1', 'value2', 'value3']
> cfg['section'] = {'key': 'value', 'key2': ['value1', 'value2', 'value3']}
If the main purpose is to support this kind of notational
convenience, then I'd be inclined to require a
On 2/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Mark Russell wrote:
>
> > PEP 227 mentions using := as a rebinding operator, but rejects the
> > idea as it would encourage the use of closures.
>
> Well, anything that facilitates rebinding in outer scopes
> is going to encourage the use of closu
Greg Ewing wrote:
Fuzzyman wrote:
cfg = ConfigObj(newfilename)
cfg['key'] = 'value'
cfg['key2'] = ['value1', 'value2', 'value3']
cfg['section'] = {'key': 'value', 'key2': ['value1', 'value2', 'value3']}
If the main purpose is to support this kind of notational
convenien
Hello all,
Feel free to shoot this down, but a suggestion.
The operator module defines two functions :
isMappingType
isSquenceType
These return a guesstimation as to whether an object passed in supports
the mapping and sequence protocols.
These protocols are loosely defined. Any obje
I'm concerned that the on_missing() part of the
proposal is gratuitous. The main use cases for defaultdict have a simple
factory that supplies a zero, empty list, or empty set. The on_missing()
hook is only there to support the rarer case of needing a key to
compute a default value. The h
Stephen J. Turnbull wrote:
> Base64 is a (family of) wire protocol(s). It's not clear to me that
> it makes sense to say that the alphabets used by "baseNN" encodings
> are composed of characters,
Take a look at
http://en.wikipedia.org/wiki/Base64
where it says
...base64 is a binary to
Raymond Hettinger wrote:
> Aside: Why on_missing() is an oddball among dict methods. When
> teaching dicts to beginner, all the methods are easily explainable ex-
> cept this one. You don't call this method directly, you only use it
> when subclassing, you have to override it to do anything use
Raymond Hettinger wrote:
> I'm concerned that the on_missing() part of the proposal is gratuitous.
I second all that. A clear case of YAGNI.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
> >>> from operator import isSequenceType, isMappingType
> >>> class anything(object):
> ... def __getitem__(self, index):
> ... pass
> ...
> >>> something = anything()
> >>> isMappingType(something)
> True
> >>> isSequenceType(something)
> True
>
> I suggest we either deprecate these f
Fuzzyman wrote:
> Hello all,
>
> Feel free to shoot this down, but a suggestion.
>
> The operator module defines two functions :
>
> isMappingType
> isSquenceType
>
>
> These return a guesstimation as to whether an object passed in supports
> the mapping and sequence protocols.
>
> T
Raymond Hettinger wrote:
>> >>> from operator import isSequenceType, isMappingType
>> >>> class anything(object):
>> ... def __getitem__(self, index):
>> ... pass
>> ...
>> >>> something = anything()
>> >>> isMappingType(something)
>> True
>> >>> isSequenceType(something)
>> True
>>
>>
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Tim Peters wrote:
>> Speaking of which, a number of test failures over the past few weeks
>> were provoked here only under -r (run tests in random order) or under
>> a debug build, and didn't look like those were specific to Windows.
>> Adding -r to
[Alex]
> I'd love to remove setdefault in 3.0 -- but I don't think it can be done
> before that: default_factory won't cover the occasional use cases where
> setdefault is called with different defaults at different locations, and,
> rare as those cases may be, any 2.* should not break any e
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Please submit your patch to SourceForge.I've submitted the zlib patch as patch #1435422. I added some test cases to test_zlib.py and documented the new methods. I'd like to test my gzip / tarfile changes more before creating a patch for it,
On Feb 22, 2006, at 7:21 AM, Raymond Hettinger wrote:
...
> I'm somewhat happy with the patch as it stands now. The only part
> that needs serious rethinking is putting on_missing() in regular
> dicts. See my other email on that subject.
What if we named it _on_missing? Hook methods int
On 2/22/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I'm concerned that the on_missing() part of the proposal is gratuitous. The
> main use cases for defaultdict have a simple factory that supplies a zero,
> empty list, or empty set. The on_missing() hook is only there to support
> the rare
On Feb 22, 2006, at 6:35 AM, Greg Ewing wrote:
> I'm thinking of convenience, too. Keep in mind that in Py3k,
> 'unicode' will be called 'str' (or something equally neutral
> like 'text') and you will rarely have to deal explicitly with
> unicode codings, this being done mostly for you by the I/O
[Guido van Rossum"]
> If we removed on_missing() from dict, we'd have to override
> __getitem__ in defaultdict (regardless of whether we give
>defaultdict an on_missing() hook or in-line it).
You have another option. Keep your current modifications to
dict.__getitem__ but do not include dict.on_m
On Feb 22, 2006, at 4:18 AM, Fuzzyman wrote:
> Raymond Hettinger wrote:
>> from operator import isSequenceType, isMappingType
>> class anything(object):
>>> ... def __getitem__(self, index):
>>> ... pass
>>> ...
>> something = anything()
>> isMappingType(something)
>>>
Raymond Hettinger wrote:
>from operator import isSequenceType, isMappingType
>class anything(object):
>>
>>... def __getitem__(self, index):
>>... pass
>>...
>>
>something = anything()
>isMappingType(something)
>>
>>True
>>
>isSequenceType(something)
>>
>>True
>>
>>I
On 2/22/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum"]
> > If we removed on_missing() from dict, we'd have to override
> > __getitem__ in defaultdict (regardless of whether we give
> >defaultdict an on_missing() hook or in-line it).
>
> You have another option. Keep your cu
On 2/20/06, Mark Mc Mahon <[EMAIL PROTECTED]> wrote:
It seems that the Path module as currently defined leaves equalitytesting up to the underlying string comparison. My guess is that thisis fine for Unix (maybe not even) but it is a bit lacking for Windows.
Should the path class implement an __eq_
At 06:14 AM 2/22/2006 -0500, Jeremy Hylton wrote:
>On 2/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Mark Russell wrote:
> >
> > > PEP 227 mentions using := as a rebinding operator, but rejects the
> > > idea as it would encourage the use of closures.
> >
> > Well, anything that facilitates reb
"Almann T. Goo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> IMO, Having properly nested scopes in Python in a sense made having
> closures a natural idiom to the language and part of its "user
> interface." By not allowing the name re-binding it almost seems like
> that "user i
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Efficiency is an implementation concern.
It is also a user concern, especially if inefficiency overruns memory
limits.
> In Py3k, strings
> which contain only ascii or latin-1 might be stored as
> 1 byte per character,
On 2/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Here's a crazy idea, that AFAIK has not been suggested before and could
> work for both globals and closures: using a leading dot, ala the new
> relative import feature. e.g.:
>
> def incrementer(val):
> def inc():
>
[Ian Bicking]
> They seem terribly pointless to me.
FWIW, here is the script that had I used while updating and improving the two
functions (can't remember whether it was for Py2.3 or Py2.4). It lists
comparative results for many different types of inputs. Since perfection was
not possible, t
Guido van Rossen wrote:
> I think the pattern hasn't been commonly known; people have been
> struggling with setdefault() all these years.
I use setdefault _only_ to speed up the following code pattern:
if akey not in somedict:
somedict[akey] = list()
somedict[akey].append(avalue)
These lin
Terry Reedy wrote:
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
>
>> Which is why I think that only *unicode* codings should be
>> available through the .encode and .decode interface. Or
>> alternatively there should be something more explicit like
>> .unicode_encode and .unicode_decode th
Raymond Hettinger wrote:
> [Ian Bicking]
>> They seem terribly pointless to me.
>
> FWIW, here is the script that had I used while updating and improving
> the two functions (can't remember whether it was for Py2.3 or Py2.4).
> It lists comparative results for many different types of inputs.
>
A minor related point about on_missing():
Haven't we learned from regrets over the .next() method of iterators
that all "magically" invoked methods should be named using the __xxx__
pattern? Shouldn't it be named __on_missing__() instead?
-- Michael Chermside
> But given :
>
> True True Instance w getitem
> True True NewStyle Instance w getitem
> True True []
> True True {}
>
> (Last one is UserDict)
>
> I can't conceive of circumstances where this is useful without duck
> typing *as well*.
Yawn. Give it up. For user defined instances, these fun
Almann T. Goo wrote:
>>As far as I remember, Guido wasn't particularly opposed
>>to the idea, but the discussion fizzled out after having
>>failed to reach a consensus on an obviously right way
>>to go about it.
>
>
> My apologies for bringing this debated topic again to the
> front-lines--that s
First off, thanks to Neil for writing this all down. The whole thread
of discussion on the bytes type was rather long and thus hard to
follow. Nice to finally have it written down in a PEP.
Anyway, a few comments on the PEP. One, should the hex() method
instead be an attribute, implemented as a
Greg Ewing wrote:
> Jeremy Hylton wrote:
>
>
>>The names of naming statements are quite hard to get right, I fear.
>
>
> My vote goes for 'outer'.
>
> And if this gets accepted, remove 'global' in 3.0.
>
In 3.0 we could remove 'global' even without 'outer',
and make module global scopes read
On Thu, Feb 16, 2006 at 12:47:22PM -0800, Guido van Rossum wrote:
> BTW, for folks who want to experiment, it's quite simple to create a
> working bytes implementation by inheriting from array.array. Here's a
> quick draft (which only takes str instance arguments):
Here's a more complete prototype
On Sunday 12 February 2006 21:51, Thomas Wouters wrote:
> Well, in the past, features -- even syntax changes -- have gone in
> between the last beta and the final release (but reminding Guido
> might bring him to tears of regret. ;) Features have also gone into
> what would have been 'bugfix releas
On Feb 22, 2006, at 1:22 PM, Brett Cannon wrote:
> First off, thanks to Neil for writing this all down. The whole thread
> of discussion on the bytes type was rather long and thus hard to
> follow. Nice to finally have it written down in a PEP.
>
> Anyway, a few comments on the PEP. One, shoul
However the definition of "feature" vs. "bugfix" isn't always crystal clear.
Some things that went into 2.4 recently felt like small features to
me; but others may disagree:
- fixing chunk.py to allow chunk size to be > 2GB
- supporting Unicode filenames in fileinput.py
Are these features or bug
SourceForge.net wrote:
> Status: Closed
> Resolution: Accepted
And here I was, thinking I might actually work on this and submit a
patch on the weekend ...
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/lis
On Thursday 23 February 2006 09:19, Guido van Rossum wrote:
> However the definition of "feature" vs. "bugfix" isn't always
> crystal clear.
>
> Some things that went into 2.4 recently felt like small features to
> me; but others may disagree:
>
> - fixing chunk.py to allow chunk size to be > 2GB
>
Raymond Hettinger wrote:
> Your example simply highlights the consequences of one of Python's
> most basic, original design choices (using getitem for both sequences
> and mappings). That choice is now so fundamental to the language
> that it cannot possibly change.
Hmm - just a thought ...
Si
It took 2 hours, but I caught up on Python-dev email. Hoorah.
So, couple of things - the trunk has test failures for me, right now.
test test_email failed -- Traceback (most recent call last):
File
"/home/anthony/src/py/pytrunk/python/Lib/email/test/test_email.py",
line 2111, in test_parsedat
On 21-Feb-06, at 11:21 AM, Almann T. Goo" <[EMAIL PROTECTED]> wrote:Why not just use a class?def incgen(start=0, inc=1) : class incrementer(object): a = start - inc def __call__(self): self.a += inc return self.a return incrementer()a = incgen(7, 5)for n in range(10)
[Neal Norwitz]
> ...
> I also think I know how to do the "double builds" (one release and one
> debug). But it's too late for me to change it tonight without
> screwing it up.
I'm not mad :-). The debug build is more fruitful than the release
build for finding problems, so doing two debug-build
Josiah Carlson wrote:
> However, I believe global was and is necessary for the
> same reasons for globals in any other language.
Oddly, in Python, 'global' isn't actually necessary,
since the module can always import itself and use
attribute access.
Clearly, though, Guido must have thought at the
Fredrik Lundh wrote:
> fwiw, the first google hit for "autodict" appears to be part of someone's
> link farm
>
> At this website we have assistance with autodict. In addition to
> information for autodict we also have the best web sites concerning
> dictionary, non profit and new york
> Oddly, in Python, 'global' isn't actually necessary,
> since the module can always import itself and use
> attribute access.
>
> Clearly, though, Guido must have thought at the time
> that it was worth providing an alternative way.
I believe that use cases for rebinding globals (module attribute
Terry Reedy wrote:
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
>
>>Efficiency is an implementation concern.
>
> It is also a user concern, especially if inefficiency overruns memory
> limits.
Sure, but what I mean is that it's better to find what's
conceptually right and then look for an
On 22-Feb-06, at 9:28 PM, [EMAIL PROTECTED] wrote:On 21-Feb-06, at 11:21 AM, Almann T. Goo" <[EMAIL PROTECTED]> wrote:Why not just use a class?def incgen(start=0, inc=1) : class incrementer(object): a = start - inc def __call__(self): self.a += inc return self.a retu
Steven Bethard wrote:
> And, as you mention, it's consistent
> with the relative import feature.
Only rather vaguely -- it's really somewhat different.
With imports, .foo is an abbreviation for myself.foo,
where myself is the absolute name for the current module,
and you could replace all instan
Ron Adam wrote:
> While I prefer constructors with an explicit encode argument, and use a
> recode() method for 'like to like' coding. Then the whole encode/decode
> confusion goes away.
I'd be happy with that, too.
--
Greg Ewing, Computer Science Dept, +-
At 03:49 PM 2/23/2006 +1300, Greg Ewing wrote:
>Steven Bethard wrote:
> > And, as you mention, it's consistent
> > with the relative import feature.
>
>Only rather vaguely -- it's really somewhat different.
>
>With imports, .foo is an abbreviation for myself.foo,
>where myself is the absolute name
Guido's on_missing() proposal is pretty good for what it is, but it is
not a replacement for set_default(). The use cases for a derivable,
definition or instantiation time framework is different than the
call-site based decision being made with setdefault(). The difference
is that in the former c
Steven Bethard wrote:
> And, as you mention, it's consistent with the relative import feature.
Greg Ewing wrote:
> With imports, .foo is an abbreviation for myself.foo,
> where myself is the absolute name for the current module,
> and you could replace all instances of .foo with that.
Phillip J.
Steven Bethard wrote:
> Phillip J. Eby wrote:
>
>>Actually, "import .foo" is an abbreviation for "import myparent.foo", not
>>"import myparent.myself.foo".
Oops, sorry, you're right.
s/myself/myparent/g
--
Greg Ewing, Computer Science Dept, +--+
University
Anthony Baxter wrote:
> Who's the person who hands out buildbot username/password pairs?
That's me.
> I
> have an Ubuntu x86 box here that can become one (I think the only
> linux, currently, is Gentoo...)
How different are the Linuxes, though? How many of them do we need?
Regards,
Martin
___
James Y Knight wrote:
> Some MIME sections
> might have a base64 Content-Transfer-Encoding, others might be 8bit
> encoded, others might be 7bit encoded, others might be quoted- printable
> encoded.
I stand corrected -- in that situation you would have to encode
the characters before combini
Samuele Pedroni wrote:
> If you are looking for rough edges about nested scopes in Python
> this is probably worse:
>
> >>> x = []
> >>> for i in range(10):
> ... x.append(lambda : i)
> ...
> >>> [y() for y in x]
> [9, 9, 9, 9, 9, 9, 9, 9, 9, 9]
As an aside, is there any chance that this co
Delaney, Timothy (Tim) wrote:
> Since we're adding the __index__ magic method, why not have a
> __getindexed__ method for sequences.
I don't think this is a good idea, since it would be
re-introducing all the confusion that the existence of
two C-level indexing slots has led to, this time for
use
Almann T. Goo wrote:
> (although rebinding a name in the global scope from a
> local scope is really just a specific case of that).
That's what rankles people about this, I think -- there
doesn't seem to be a good reason for treating the global
scope so specially, given that all scopes could be
Mark Mc Mahon wrote:
> Should the path class implement an __eq__ method that might do some of
> the following things:
> - Get the absolute path of both self and the other path
I don't think that any path operations should implicitly
touch the file system like this. The paths may not
represent re
Fuzzyman wrote:
> The operator module defines two functions :
>
> isMappingType
> isSquenceType
>
> These protocols are loosely defined. Any object which has a
> ``__getitem__`` method defined could support either protocol.
These functions are actually testing for the presence
of two
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Stephen J. Turnbull wrote:
>> Base64 is a (family of) wire protocol(s). It's not clear to me
>> that it makes sense to say that the alphabets used by "baseNN"
>> encodings are composed of characters,
Greg> Take a l
On 2/21/06, Robert Brewer <[EMAIL PROTECTED]> wrote:
> 1. Allow trace hooks to receive c_call, c_return, and c_exception events
> (like profile does).
I can easily make this modification. You can also register the same
bound method for trace and profile, which sortof eliminates this
problem.
> 2
> "Ron" == Ron Adam <[EMAIL PROTECTED]> writes:
Ron> Terry Reedy wrote:
>> I prefer the shorter names and using recode, for instance, for
>> bytes to bytes.
Ron> While I prefer constructors with an explicit encode argument,
Ron> and use a recode() method for 'like to like
> If we wanted to be fully consistent with the relative import
> mechanism, we would require as many dots as nested scopes.
At first I was a bit taken a back with the syntax, but after reading
PEP 328 (re: Relative Import) I think I can stomach the syntax a bit
better ; ).
That said, -1 because I
Stephen J. Turnbull wrote:
>> "Ron" == Ron Adam <[EMAIL PROTECTED]> writes:
>
> Ron> Terry Reedy wrote:
>
> >> I prefer the shorter names and using recode, for instance, for
> >> bytes to bytes.
>
> Ron> While I prefer constructors with an explicit encode argument,
> Ron>
Title: RE: [Python-Dev] Unifying trace and profile
I, Robert, wrote:
> 1. Allow trace hooks to receive c_call, c_return,
> and c_exception events (like profile does).
and Nicholas Bastin replied:
> I can easily make this modification. You can also
> register the same bound method for trace
77 matches
Mail list logo
