Python-Dev February 2000

python-dev@python.org

41 participants
73 discussions

by Moshe Zadka

I'll refer you all to the copy of random.py you have on your hard-disks, to line 68, where a function new_generator(a=None) is defined, merely returning generator(a=None). I wonder who put it there, and why. At least to simplify the weirdness, we could change it to # for backwards compatability new_generator = generator Which would work for all but the most obscure hacks. -- Moshe Zadka <mzadka(a)geocities.com>. INTERNET: Learn what you know. Share what you don't.

21 years, 2 months

Python 1.6 timing

by Guido van Rossum

Andrew let me repost this mail of his to this list. It's worth a discussion here (if not in a larger forum). My responses are at the bottom. ------- Forwarded Message Date: Wed, 19 Jan 2000 20:17:55 -0500 From: "A.M. Kuchling" <amk1(a)erols.com> To: guido(a)python.org Subject: Python 1.6 timing I thought a bit more about the release schedule for 1.6, and like the idea of delaying it less and less. Another bad effect of delaying it is that not having Unicode in the core handicaps developing XML tools; we can continue working with wstrop, or integrate MAL's code into the XML-SIG's CVS tree, but it might mean abandoning the XML processing field to Perl & Tcl because the tools can't be made fully standard compliant in time. Options I can think of: 1) Delegating some control to a pumpkin holder [...]. 2) Releasing the Unicode+sre modules as separate add-ons to 1.5. (But would that impose annoying backward-compatibility constraints when they get integrated into 1.6?) 3) Add Unicode, sre, Distutils, plus other minor things and call it 1.5.5, meaning it's not as big a revision as a 1.6 release, but it's bigger than just another patchlevel of bugfixes. I don't remember what other features were planned for 1.6; was there anything major, if static typing is left for 2.0? - -- A.M. Kuchling http://starship.python.net/crew/amk/ Life's too short for chess. -- H.J. Byron ------- End of Forwarded Message There are several other things I can think of now that were planned for 1.6: revamped import, rich comparisons, revised coercions, parallel for loop (for i in L; j in M: ...), extended slicing for all sequences. I've also been thinking about making classes be types (not as huge a change as you think, if you don't allow subclassing built-in types), and adding a built-in array type suitable for use by NumPy. I've also received a conservative GC patch that seems to be fairly easy to apply and has some of Tim Peters' blessing. For 1.5.5 (what happened to 1.5.3 and 1.5.4?), we can have a more conservative agenda, as suggested by Andrew: Unicode and distutils are probably the most important things to integrate. (The import utilities are not ready for prime time in my opinion; there are too many issues.) Anybody care to be the pumpkin? That would cut the discussion short; otherwise the problem remains that I can't spend too much time on the next release unless I get funded for it; what little money I've received for CP4E I had better spend on getting some CP4E-related results ASAP, because the next installment of this funding is very much at stake... --Guido van Rossum (home page: http://www.python.org/~guido/) Life's better without braces. -- Bruce Eckel

21 years, 2 months

re: Programming Paradigms paper

by gvwilson＠nevex.com

I've put a copy of a paper by Marian Petre on the Software Carpentry web site at: http://www.software-carpentry.com/extern/petre_paradigms.html I hope it will be of interest to people on this list. From the introduction: ...language designers everywhere aspire to a Kuhnian ideal that paradigms are absolute: complete and exclusive, dominating and defining every aspect of an approach... This paper presents an alternative view of programming paradigms based on studies of expert programmer behaviour: a view of paradigms as selectable reference models...that evolve from expert practice and are shaped within a programming culture. From that vantage, it considers the implications of programming paradigms for teaching programming. The author is with the Open University in the United Kingdom; her email is in the paper, and she would be grateful if you could let her know if you cite or reference the paper. Greg

21 years, 2 months

Re: [Py-Consortium] Unicode snapshot available

by Fredrik Lundh

Guido wrote: > There's one thing missing (but not for long!): Fredrik Lundh's sre > module, which implements re-compatible-but-faster regular expressions > for 8-bit characters and Unicode, hasn't been integrated yet. We're > waiting for Fredrik, who's just back from the conference -- it > shouldn't be long now. a snapshot will be posted real soon now (should have appeared yesterday, but some business stuff got into the way, and now I've had too much champagne for my own good ;-). anyway, to grab it, take the last part of MAL's URL (just the filename), and append it to: http://w1.132.telia.com/~u13208596/ (nothing there right now) if you have questions, use the effbot(a)telia.com address (until further notice, at least -- might reorganize my mail accounts in a near future). </F>

21 years, 2 months

Set data type

by Ka-Ping Yee

Okay, so i was going to wait until i had an implementation before bringing this up here, but it seems the other discussion has come round to sets already so this might be a good time. After Eric asked about sets at dinner (e.g. having 'x in dict' do 'dict.has_key(x)') i wondered about what it would take to support sets. Guido's response to 'x in dict' was that it was inconsistent since 'x in list' searches the values of the list, while the proposed 'x in dict' would search the keys. A friend (Mark Miller, designer of E -- see www.erights.org) and i had chatted about this before, and one idea that was suggested was to have the mapping map each member of the set to itself. Then 'in' would give the expected behaviour. E also manages to overload | and & so that they do useful things with mappings-used- as-dictionaries as well as union and intersection for mappings- used-as-sets. I expect, however, that & will be rarely used on mappings-used-as-dictionaries; more common is the desire for |, which Python has solved nicely with dict.update() (also better because it is clearly non-commutative). So i think the clearest thing to do is to make sets a separate built-in type. Here's the interface i was thinking of: >>> s = {1, 5, 7} # no colons means a set >>> type(s) <type 'set'> >>> s # sets are printed in hashed order {7, 1, 5} >>> {1: 4, 5, 7} # mixing pairs and singletons is an error File "<stdin>", line 1 {1: 4, 5, 7} ^ SyntaxError: invalid syntax >>> {3, 4: 5, 7} # mixing pairs and singletons is an error File "<stdin>", line 1 {3, 4: 5, 7} ^ SyntaxError: invalid syntax >>> 5 in s # membership 1 >>> 6 in s 0 >>> t = s # sets are mutable, so this is an alias >>> t.append(2) # like list.append(), accepts one new member >>> s {7, 5, 2, 1} >>> u = s.copy() # make a copy >>> u.append(9) >>> u.append([3]) # set members must be hashable Traceback (innermost last): File "<stdin>", line 1, in ? TypeError: unhashable type >>> u {7, 5, 9, 2, 1} >>> u.extend(range(5)) # like list.extend(), accepts a sequence or set >>> u {9, 7, 5, 4, 3, 2, 1, 0} >>> u.remove(7) # like list.remove() >>> s {7, 5, 2, 1} >>> s | {3, 5} # union {7, 5, 3, 2, 1} >>> s & {1, 2, 3} # intersection {2, 1} >>> s <= u # subset 1 >>> s >= s 1 >>> u <= s 0 >>> for i in s: print i # iterate in hashed order 7 5 2 1 >>> l = list(s) >>> l.sort() >>> for i in l: print i # iterate in sorted order 1 2 5 7 >>> s.clear() # for completeness, i suppose >>> s >>> s[3] # probably best not to permit subscripting Traceback (innermost last): File "<stdin>", line 1, in ? TypeError: unsubscriptable object >>> s[5:7] Traceback (innermost last): File "<stdin>", line 1, in ? TypeError: unsliceable object In short, sets get append, extend, remove # from lists clear, copy # from dictionaries and the operators &, |, in, <=, >=, <, >, == They could be implemented like dicts with just keys and no values. Two open issues: 1. How to spell the empty set? Possibilities include {,} or {-} or a constant in __builtins__. __builtins__ would probably get a conversion function 'set' (soon to be a type-object/constructor like int, list, etc.), so you could just say 'set()'. 2. How do sets sort? We could insert them somewhere in the hierarchy of types next to lists and tuples. Currently () > [] > {}, so we could have () > [] > {,} > {} for example. More tricky is the question of what to do with the partial ordering created by >, >=, etc. a. The answer is the same as whatever answer we get when Python supports rich comparisons and instances can have partial orderings too. b. We can make >, >= behave like dictionary >, >= so that there is a defined sort order, and put the subset/superset functionality in a method. Option a. would be nicest since there are other good uses for rich comparisons, and in b. we get comparison operators that don't really do anything useful. (Side note: Do we achieve a. just by divorcing __cmp__ from >, >=, etc.? sorting would use __cmp__, while > and < would look for __gt__, __lt__, etc., and if not found, fall back on __cmp__. __cmp__ contracts to be stable [a.__cmp__(b) always has the same outcome for a given a and b], reflexive [if a == b, then a.__cmp__(b) == 0], consistent [if a.__cmp__(c) == 0 and b.__cmp__(d) == 0, then a.__cmp__(b) == c.__cmp__(d)], symmetric [a.__cmp__(b) + b.__cmp__(a) == 0 for all a, b], and transitive [if a.__cmp__(b) > 0 and b.__cmp__(c) > 0, then a.__cmp__(c) > 0; if a.__cmp__(b) == 0 and b.__cmp__(c) == 0, then a.__cmp__(c) == 0], but __gt__, __lt__ need make no such promises. Side side note: which of these promises, if any, should we ask __gt__ et al to make? Stability, at least?) ((Side side side note: in E, Mark Miller also ran into the problem of spelling different kinds of "equals"es. For object identity we have "is", for content comparison we have "==". If we need a new operator for magnitude equality i suggest "<=>", as used in E.)) Well, it may be a lot of words, but it's not much good unless you are going to use it in practice. I think i would have good use for it, but i would like to hear your opinions. Would you use such a thing? -- ?!ng

21 years, 2 months

re: syntax issues / LANL

by gvwilson＠nevex.com

Given current discussions of ternary conditionals, namespaces, etc., would people like me to write up my notes on syntactic/semantic issues that came up during the courses I taught at Los Alamos National Laboratory? I could send 'em directly to interested parties, or post to this list. Greg

21 years, 2 months

RE: [Python-Dev] Set data type

by Asbahr, Jason

>Okay, so i was going to wait until i had an implementation before >bringing this up here, but it seems the other discussion has come >round to sets already so this might be a good time. I like your set proposal, Ping. The lack of a set datatype something that has come up in my organization as new people are exposed to the language, especially those familiar with the STL. It's not a show stopper or anything... Jason Asbahr Origin Systems, Inc. jasbahr(a)origin.ea.com

21 years, 2 months

__contains__ hook

by Moshe Zadka

Here's a very preliminary, very hackish version of a hook for the "in" operator. Basically, use like: class spam: def __contains__(self, o): return 1 6 in spam() (answers 1) I must say I was horrified by the current way the operator was handled: very non-OO-ish. I'd much rather there'd be a slot in the sequence interface for this method. This is why there's still no way to use the hook with regular C extension types. Have fun! (BTW: I've tested it only minimally, so it might break your Python. Use with caution). PS. Eric, you can implement sets the *right* way this time. -- Moshe Zadka <mzadka(a)geocities.com>. INTERNET: Learn what you know. Share what you don't. *** ../../../python/dist/src/Objects/abstract.c Fri Oct 15 14:09:02 1999 --- Objects/abstract.c Tue Feb 1 10:34:34 2000 *************** *** 1110,1115 **** --- 1110,1140 ---- } return 0; } + /* special case for instances. Basically emulating Python code, + but optimizations will come later */ + if (PyInstance_Check(w)) { + PyObject *py__contains__, *py_ret, *py_args; + int ret; + + py__contains__ = PyObject_GetAttrString(w, "__contains__"); + if(py__contains__ == NULL) + return -1; + py_args = PyTuple_New(1); + if(py_args == NULL) { + Py_DECREF(py__contains__); + return -1; + } + Py_INCREF(v); + PyTuple_SET_ITEM(py_args, 0, v); + py_ret = PyObject_CallObject(py__contains__, py_args); + Py_DECREF(py__contains__); + Py_DECREF(py_args); + if(py_ret == NULL) + return -1; + ret = PyObject_IsTrue(py_ret); + Py_DECREF(py_args); + return ret; + } sq = w->ob_type->tp_as_sequence; if (sq == NULL || sq->sq_item == NULL) {

21 years, 2 months

zipfile.py, file system abstractions

by Fred L. Drake, Jr.

At one point we discussed file system abstractions on this list. Do we want to pursue the idea? I have an implementation that's been tested on Unix: a Filesystem instance refers to either the entire "native" filesystem, or a subset of a filesystem (either a filesystem object or the native filesystem), based on a "root" that's a directory within the parent filesystem. There'd need to be some work done to make sure it works properly on Windows and the Mac, but I don't think that would be a lot of work. I think this should be available as an abstraction in Python. Implementing this on top of a ZIP/JAR file is also useful. If Jim A.'s zipfile.py will be added to the standard library in 1.6, I'd like to add a Filesystem class that operates on a zipfile object. Any thoughts? If you want this, someone needs to check in and document zipfile.py. ;) I'll add filesys.py & it's documentation. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

21 years, 2 months

Revised proposal (and preliminary implementation): Registry access module for Python on Windows

by Thomas Heller

Ok, at least the first proposal did start the discussion. Here is a revised one: A preliminary implementation is available at http://starship.python.net/crew/theller/ ---------------------------------------------------------------------- winreg - windows registry access module Exception: error - raised when a function fails. Will contain a windows error code and a textual description. Objects: regnode object - represents a open key in the registry. Functions: OpenKey (name) -> regnode object Opens an existing key with the specified access rights and returns a regnode object. name is specified like "HKLM\Software\Python" or "HKEY_LOCAL_MACHINE\Software\Python" CreateKey (name) -> regnode object Creates a new key or opens an existing one and returns a regnode object. For the name format see OpenKey regnode object methods: Values () -> dict Returns a dictionary mapping names to values. The <default> or unnamed value has the key ''. The values are either strings or integers, depending on the REG_* type. GetValue ([name]) -> integer or string Returns a value specified by name or the default value. SetValue ([name,] value) Set a named or the <default> value. Named values must be integers or string (which are stored as REG_DWORD or REG_SZ). Should an optional third parameter be used, allowing to store in other REG_* typecodes? I dont think so. DeleteValue ([name]) Deletes a named or the <default> value. SubKeys () -> sequence Returns a sequence containing the names of all subkeys. DeleteKey (name [,recursive=0]) If recursive is 0, deletes the named key if no subkeys exist. If there are subkeys an error is raised. If recursive is not 0, the named key is deleted including subkeys. OpenKey (name) -> regnode object Openes an existing subkey and returns a regnode object pointing to it. CreateKey (name) -> regnode object Creates a new or openes an existing subkey and returns a regnode object pointing to it. regnode objects have the following properties: name - the name of the RegistryKey, something like "HKLM\Software\Python" hkey - the integer keyhandle ---------------------------------------------------------------------- Thomas Heller

21 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev February 2000