Mailman 3 January 2001 - Python-Dev

(no subject)
by Tim Peters 25 Jan '01

25 Jan '01

[Skip] > Why not have a special REGISTRY token you can place in the BROWSER > path to tell it when to consult the registry? On non-Windows > platforms it can simply be ignored: > > BROWSER=netscape:REGISTRY:explorer Because non-Windows platforms shouldn't be bothered with Windows silliness any more than Windows users should be bothered with Unix silliness. BROWSER isn't of any use on Windows, and REGISTRY isn't of any use on Unix. Eric may still *think* BROWSER is of use on Windows, but if so that's not really a technical problem <wink>.

2 1

Re: test___all__ failing; Windows
by Tim Peters 24 Jan '01

24 Jan '01

> In that case, the __all__ attribute in the module has to be calculated > dynamically. Say, adding code like > > try: > LC_MESSAGES > except NameError: > pass > else: > __all__.append('LC_MESSAGES') > > Ditto for anything else. > > Should I check in a patch? SourceForge CVS doesn't appear to be broken, so I can only conclude everyone decided this was a bad to stop taking drugs <0.9 wink>.

1 0

Tkinter documentation (Was: What does "batteries are included" mean?)
by Martin v. Loewis 24 Jan '01

24 Jan '01

> It's already a blot on Python that the standard documentation set > doesn't cover Tkinter. Just point your friendly web browser to Ping's HTML generator and ask for Tkinter, or invoke "pydoc.py Tkinter". [I wouldn't have brought this up if it hadn't been the contribution of my friend Nils Fischbeck:-] Regards, Martin

1 0

BROWSER status
by Eric S. Raymond 24 Jan '01

24 Jan '01

I spent the morning writing and testing patches to make urlview and GNU Emacs BROWSER-aware, and have sent them off to the relevant maintainers. I've also sent a patch to Andries Brouwer for the environ(5) man page. Those of you interested in my latest bit of social engineering can take a look at http://www.tuxedo.org/~esr/BROWSER/ A bow in Guido's direction -- if he hadn't been grouchy about this I probably wouldn't have gotten to shipping those patches for a while. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> A right is not what someone gives you; it's what no one can take from you. -- Ramsey Clark

1 0

Re: [Python-checkins] CVS: python/dist/src/Lib/test test___all__.py,1.3,1.4
by Skip Montanaro 24 Jan '01

24 Jan '01

Guido> - Use "exec ... in dict" to avoid having to walk on eggshells; Guido> locals no don't have to start with underscore. Thanks. I have just been incredibly short on time lately. Guido> - Only test dbhash if bsddb can be imported. (Wonder if there Guido> are more like this?) Alpha testing should pick those up, yes? ;-) Guido> ! try: Guido> ! import bsddb Guido> ! except ImportError: Guido> ! if verbose: Guido> ! print "can't import bsddb, so skipping dbhash" Guido> ! else: Guido> ! check_all("dbhash") Instead of having to know that dbhash includes bsddb, shouldn't dbhash be the module that's imported here? Skip

2 3

re: sets
by Greg Wilson 24 Jan '01

24 Jan '01

1. I did a poll overnight by email of 22 friends and colleagues, none of whom are regular Python users (yet). My question was, "Would you expect the interface of a set class to be like the interface of a vector or list, or like the interface of a map or hash?" 15 people have replied; all 15 have said, "map or hash". Several respondents are Perl hackers, so I'm sure the answer is influenced by previous exposure to the set-as-valueless-hash idiom. Still, I think 15-0 is a pretty convincing score... Four, unprompted, said that they thought the STL's hierarchy of containers was as good as it gets, and that other languages should mirror it. (One of those added that this makes teaching much simpler --- students can transfer instincts from one language to another.) 2. Is there enough interest in sets for a BOF at IPC9? Please reply to me point-to-point if you're interested; I'll summarize and post the result. I volunteer to bring the donuts... > > Ka-Ping Yee: > > The only change that needs to be made to support sets of immutable > > elements is to provide "in" on dictionaries. The rest is then all > > quite natural: > > dict[key] = 1 > > if key in dict: ... > > for key in dict: ... > > various: > > [but what about 'value in dict' or '(key, value) in dict'?] > Fredrik Lundh: > let's just say that "in" is the same thing as "has_key", > and be done with it. > Guido van Rossum: > You know, I've long resisted this, but I agree now -- this is the > right thing. Greg Wilson: Woo hoo! Now, on a related note, what is the status of the 'indices()' proposal, as in: for i in indices(someList): instead of: for i in range(len(someList)): Would 'indices(dict)' be the same as 'dict.keys()', to allow uniform iteration? Or would it be more economical to introduce a 'keys()' method on lists and tuples, so that: for i in collection.keys(): would work on dicts, lists, and tuples? I know that 'keys()' is the wrong name for lists and tuples, but dicts are already using it, and it's completely unambiguous... Thanks, Greg

1 0

Is X a (sequence|mapping)?
by Martin v. Loewis 24 Jan '01

24 Jan '01

> i don't see an easy way to test if something supports one of these > abstract interfaces in Python. Why do you want to test for that? If you have an algorithm that only operates on integer-indexed things, what can you do if the test fails? So it is always better to just use the object in the algorithm, and let it break with an exception if somebody passes a bad object. Regards, Martin

4 4

Sets: elt in dict, lst.include
by Ka-Ping Yee 24 Jan '01

24 Jan '01

On Tue, 23 Jan 2001, Jeremy Hylton wrote: > For my applications, the dictionary-based approach is faster and > offers a natural interface. The only change that needs to be made to support sets of immutable elements is to provide "in" on dictionaries. The rest is then all quite natural: dict[key] = 1 if key in dict: ... for key in dict: ... (Then we can also get rid of the ugly has_key method.) For those that need mutable set elements badly enough to sacrifice a little speed, we can add two methods to lists: lst.include(elt) # same as - if elt not in lst: lst.append(elt) lst.exclude(elt) # same as - while elt in lst: lst.remove(elt) (These are generally useful methods to have anyway.) This proposal has the following advantages: 1. You still get to choose which implementation best suits your needs. 2. No new types are introduced; lists and dicts are well understood. 3. Both features are extremely simple to understand and explain. 4. Both features are useful in their own right, and could stand as independent proposals to improve lists and dicts respectively. (For instance, i spotted about 10 places in the std library where the 'include' method could be used, and i know i would use it myself -- certainly more often than pop or reverse!) 5. In all cases this is faster than a new Python class. (For instance, Jeremy's implementation even contained a commented-out optimization that stored self.elts.has_key as self.has_elt to speed things up a bit. Using straight dicts would see this optimization and raise it one, with no effort at all.) 6. Either feature can be independently approved or rejected without affecting the other. -- ?!ng

8 13

getting rid of ucnhash
by Fredrik Lundh 24 Jan '01

24 Jan '01

It's probably just me, but the names of the two unicode modules tend to irritate me: > ls u*.pyd ucnhash.pyd unicodedata.pyd (the former contains names, the latter data) I've been meaning to rename the former, but I just realized that it might be better to get rid of it completely, and move its functionality into the unicodedata module. The result is a single 200k unicodedata module, which con- tains the name database as well as two new functions: name(character [, default]) => map unicode character to name. if the name doesn't exist, return the default object, or raise ValueError. lookup(name) => unicode character (or raise KeyError if it doesn't exist) Should I check it in now, change the names/semantics and check it in, or post it to sourceforge? Cheers /F

3 3

Re: [Python-checkins] CVS: python/dist/src/Objects object.c,2.114,2.115
by Guido van Rossum 24 Jan '01

24 Jan '01

> A few miscellaneous helpers. > > PyObject_Dump(): New function that is useful when debugging Python's C > runtime. In something like gdb it can be a pain to get some useful > information out of PyObject*'s. This function prints the str() of the > object to stderr, along with the object's refcount and hex address. > > PyGC_Dump(): Similar to PyObject_Dump() but knows how to cast from the > garbage collector prefix back to the PyObject* structure. > > [See Misc/gdbinit for some useful gdb hooks] > > none_dealloc(): Rather than SEGV if we accidentally decref None out of > existance, we assign None's and NotImplemented's destructor slot to > this function, which just calls abort(). Barry, since these are only gdb helpers, would it perhaps be better if their names started with "_Py" to indicate that they aren't part of the regular API? They violate an important rule: you shouldn't write to stderr directly, but always to sys.stderr. (There's a helper routines to write to stderr: PySys_WriteStderr().) I understand that for the gdb helper it's important to use the real stderr, and I don't object to having these functions present at all times (they're so small), but I do think that we should make it clear (by a _Py name, and also by a comment) that they should not be called! --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1