Re: [Python-Dev] [poll] New name for __builtins__
Oleg Broytmann <[EMAIL PROTECTED]> writes: > On Fri, Nov 30, 2007 at 11:22:03AM +1300, Greg Ewing wrote: >> The next step up from global would be __galactic__. > >Let me skip __universe[al]__ and go directly to The Ultimate >Questions: So maybe it should be called __42__? Bernhard ___ 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] Backporting PEP 3127 to trunk
Greg Ewing <[EMAIL PROTECTED]> writes: > I don't know about oct(), but I found hex() to be quite useful > the other day when I was using the interactive interpreter to > to some hex calculations. It would have been quite tedious > having to say "%x".format(_) or some such all the time to > see the results in hex. > > An alternative might be to have some variable that can be > set to control the format of numbers printed by the interactive > shell. Something like this? >>> import sys >>> import __builtin__ >>> def myhook(o): ... if isinstance(o, int): ... print hex(o) ... else: ... print repr(o) ... __builtin__._ = o ... >>> sys.displayhook = myhook >>> 123 0x7b Bernhard ___ 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] PEP 310 and exceptions
Nick Coghlan <[EMAIL PROTECTED]> writes: > holger krekel wrote: >> Moreover, i think that there are more than the "transactional" >> use cases mentioned in the PEP. For example, a handler may want to >> log exceptions to some tracing utility or it may want to swallow >> certain exceptions when >> its block does IO operations that are ok to fail. > > With the current PEP 310 definition, these can be manually handled using > sys.exc_info() in the __exit__ method. With the proposed implementation of PEP 310 rev. 1.5 it wouldn't work. sys.exc_info returns a tuple of Nones unless an except: clause has been entered. Either sys.exc_info() would have to be changed to always return exception information after an exception has been raised or the implementation would have to be changed to do the equivalent of e.g. if hasattr(var, "__enter__"): var.__enter__() try: try: suite except: pass finally: var.__exit__() An empty except: suite suffices. In C that's equivalent to a call to PyErr_NormalizeException AFAICT. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ ___ 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] Please comment on PEP 357 -- adding nb_index slot to PyNumberMethods
"Travis E. Oliphant" <[EMAIL PROTECTED]> writes: > 2) The __index__ special method will have the signature > >def __index__(self): >return obj > >Where obj must be either an int or a long or another object >that has the __index__ special method (but not self). So int objects will not have an __index__ method (assuming that ints won't return a different but equal int object). However: > 4) A new operator.index(obj) function will be added that calls >equivalent of obj.__index__() and raises an error if obj does not >implement the special method. So operator.index(1) will raise an exception. I would expect operator.index to be implemented using PyNumber_index. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ ___ 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] Proposal: defaultdict
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> If the __getattr__()-like operation that supplies and inserts a
> dynamic default was a separate method, we wouldn't have this problem.
Why implement it in the dictionary type at all? If, for intance, the
default value functionality were provided as a decorator, it could be
used with all kinds of mappings. I.e. you could have something along
these lines:
class defaultwrapper(object):
def __init__(self, base, factory):
self.__base = base
self.__factory = factory
def __getitem__(self, key):
try:
return self.__base[key]
except KeyError:
value = self.__factory()
self.__base[key] = value
return value
def __getattr__(self, attr):
return getattr(self.__base, attr)
def test():
dd = defaultwrapper({}, list)
dd["abc"].append(1)
dd["abc"].append(2)
dd["def"].append(1)
assert sorted(dd.keys()) == ["abc", "def"]
assert sorted(dd.values()) == [[1], [1, 2]]
assert sorted(dd.items()) == [("abc", [1, 2]), ("def", [1])]
assert dd.has_key("abc")
assert not dd.has_key("xyz")
The precise semantics would have to be determined yet, of course.
> OTOH most reviewers here seem to appreciate on_missing() as a way to
> do various other ways of alterning a dict's __getitem__() behavior
> behind a caller's back -- perhaps it could even be (ab)used to
> implement case-insensitive lookup.
case-insensitive lookup could be implemented with another
wrapper/decorator. If you need both case-insitivity and a default
value, you can easily stack the decorators.
Bernhard
--
Intevation GmbH http://intevation.de/
Skencil http://skencil.org/
Thuban http://thuban.intevation.org/
___
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] Dropping __init__.py requirement for subpackages
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes: > Now the problem. Suppose you have the source package python-foo-bar, > which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This > would make a module called "foo.bar" available. Likewise, you can have the > source package python-foo-zbr, which installs $pythondir/foo/__init__.py and > $pythondir/foo/zbr.py. This would make a module called "foo.zbr" available. > > The two packages above install the file $pythondir/foo/__init__.py. If > one of them adds some content to __init__.py, the other one will overwrite > it. Packaging these two packages for e.g. debian would be extremely > difficult, because no two .deb packages are allowed to intall the same file. > > One solution is to generate the __init__.py file with post-install hooks > and shell scripts. Another solution would be for example to have only > python-foo-bar install the __init__.py file, but then python-foo-zbr would > have to depend on python-foo-bar, while they're not really related. Yet another solution would be to put foo/__init__.py into a third package, e.g. python-foo, on which both python-foo-bar and python-foo-zbr depend. Bernhard -- Intevation GmbH http://intevation.de/ Skencil http://skencil.org/ Thuban http://thuban.intevation.org/ ___ 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
