[issue1153] help(pickle) fails: unorderable types: type() type()
New submission from Marcin 'Qrczak' Kowalczyk: Python 3.0a1 (py3k, Sep 8 2007, 15:57:56) [GCC 4.2.1 20070719 (release) (PLD-Linux)] on linux2 Type help, copyright, credits or license for more information. import pickle help(pickle) Traceback (most recent call last): File stdin, line 1, in module File /usr/local/lib/python3.0/site.py, line 350, in __call__ return pydoc.help(*args, **kwds) File /usr/local/lib/python3.0/pydoc.py, line 1685, in __call__ self.help(request) File /usr/local/lib/python3.0/pydoc.py, line 1729, in help else: doc(request, 'Help on %s:') File /usr/local/lib/python3.0/pydoc.py, line 1512, in doc pager(render_doc(thing, title, forceload)) File /usr/local/lib/python3.0/pydoc.py, line 1490, in render_doc return title % desc + '\n\n' + text.document(object, name) File /usr/local/lib/python3.0/pydoc.py, line 319, in document if inspect.ismodule(object): return self.docmodule(*args) File /usr/local/lib/python3.0/pydoc.py, line 1076, in docmodule contents.append(self.document(value, key, name)) File /usr/local/lib/python3.0/pydoc.py, line 320, in document if inspect.isclass(object): return self.docclass(*args) File /usr/local/lib/python3.0/pydoc.py, line 1210, in docclass lambda t: t[1] == 'data') File /usr/local/lib/python3.0/pydoc.py, line 1173, in spilldata name, mod, maxlen=70, doc=doc) + '\n') File /usr/local/lib/python3.0/pydoc.py, line 1295, in docother repr = self.repr(object) File /usr/local/lib/python3.0/repr.py, line 24, in repr return self.repr1(x, self.maxlevel) File /usr/local/lib/python3.0/pydoc.py, line 954, in repr1 return getattr(self, methodname)(x, level) File /usr/local/lib/python3.0/repr.py, line 78, in repr_dict for key in islice(sorted(x), self.maxdict): TypeError: unorderable types: type() type() -- components: Library (Lib) messages: 55839 nosy: Qrczak severity: normal status: open title: help(pickle) fails: unorderable types: type() type() type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1153 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What is a type error?
Chris Smith [EMAIL PROTECTED] writes:
No what happens if right here you code
b := 16;
Does that again change the type of b? Or is that an illegal
instruction, because b has the local type of (18..22)?
It arranges that the expression b after that line (barring further
changes) has type int{16..16}, which would make the later call to
signContract illegal.
The assignment might be performed in a function called there, so it's
not visible locally.
Propagating constraints from conditionals is not applicable to mutable
variables, at least not easily.
I think that constant bounds are not very useful at all. Most ranges
are not known statically, e.g. a variable can span the size of an
array.
--
__( Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
--
http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Ken Tilton [EMAIL PROTECTED] writes: I think the point is that, with the variable actually being just a string and with dedicated new explicit functions required as accessors, well, you could hack that up in any language with dictionaries. It is the beginnings of an interpreter, not Python itself even feigning special behavior. If the semantics and the global structure of the code is right, only you don't like the local concrete syntax, then the complaint is at most as justified as complaints against Lisp parentheses. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Alexander Schmolck [EMAIL PROTECTED] writes: I'd like to see a demonstration that using the same binding syntax for special and lexical variables buys you something apart from bugs. There are 3 fundamental operations related to plain mutable variables: A1. Making a new mutable variable with an initial value. A2. Getting the current value. A3. Setting the new value. and 4 operations related to dynamically scoped variables: B1. Making a new dynamic variable with an initial value. B2. Getting the current value. B3. Setting the new value. B4. Local rebinding with a new initial value. If you don't ever use B4, dynamic variables behave exactly like plain variables. For this reason I see no point in distinguishing A2 from B2, or A3 from B3. Dynamic variables are a pure extension of plain variables by providing an additional operation. Distinguishing the syntax of A1 and B1 is natural: somehow it must be indicated what kind of variable is created. Mutability is orthogonal to dynamic scoping. It makes sense to have a variable which is like a plain variable but without A3, and a variable which is like a dynamic variable but without B3, although it doesn't provide anything new, only allows to express more constraints with a potential for optimization. I won't consider them here. Common Lisp does something weird: it uses the same syntax for A1 and B4, where the meaning is distinguished by a special declaration. Here is its syntax: Directly named plain variables: A1. (let ((name value)) body) and other forms A2. name A3. (setq name value), (setf name value) First-class dynamic variables: B1. (gensym) B2. (symbol-value variable) B3. (set variable value), (setf (symbol-value variable) value) B4. (progv `(variable) `(value) body) Directly named dynamic variables: B1. (defvar name value), (defparameter name value) B2. name B3. (setq name value), (setf name value) B4. (let ((name value)) body) and other forms Dynamic variables in Lisp come in two flavors: first-class variables and directly named variables. Directly named variables are always global. You can convert a direct name to a first-class variable by (quote name). Plain variables have only the directly named flavor and they are always local. You can emulate the first-class flavor by wrapping a variable in a pair of closures or a closure with dual getting/setting interface (needs a helper macro in order to be convenient). You can emulate a global plain variable by wrapping a dynamic variable in a symbol macro, ignoring its potential for local rebinding. You can emulate creation of a new first-class variable by using a dynamic variable and ignoring its potential for local rebinding, but this can't be used to refer to an existing directly named plain variable. In order to create a plain variable, you must be sure that its name is not already used by a dynamic variable in the same scope. So any essential functionality is possible to obtain, but the syntax is very irregular. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
Followup-To: comp.lang.lisp Bill Atkins [EMAIL PROTECTED] writes: The cool thing about ITERATE is that it lets you express looping concepts in a language designed explicitly for such a purpose, e.g. (iter (for x in '(1 3 3)) (summing x)) = 7 (iter (for x in '(1 -3 2)) (finding x maximizing (abs x))) = -3 (iter (for x in '(a b c 1 d 3 e)) (when (symbolp x) (collect x))) = (a b c d e) While such macros indeed allow to generate efficient code, I don't find these examples convincing in terms of readability. The same examples in my language where iteration is based on higher order functions are shorter and also clear: Sum [1 3 3] = 7 [1 (-3) 2]-MaximumBy Abs = -3 [#a #b #c 1 #d 3 #e]-Select (_ %Is SYMBOL) = [#a #b #c #d #e] -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Programming challenge: wildcard exclusion in cartesian products
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: The python code below generates a cartesian product subject to any logical combination of wildcard exclusions. For example, suppose I want to generate a cartesian product S^n, n=3, of [a,b,c,d] that excludes '*a*b*' and '*c*d*a*'. See below for details. I'm afraid that different programs in this thread has understood the asterisk differently: that it matches any single element, or that it matches any sequence of elements. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Perl-Python-a-Day: Sorting
Abdulaziz Ghuloum [EMAIL PROTECTED] writes: Python FAQs contain an entry to the schwartzian transform. http://www.python.org/doc/faq/programming.html#i-want-to-do-a-complicated-sort-can-you-do-a-schwartzian-transform-in-python This entry is obsolete: it should mention the 'key' option of the standard sort method. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Perl-Python-a-Day: Sorting
Followup-To: comp.lang.scheme Xah Lee [EMAIL PROTECTED] writes: Since this is frequently used, Python provides a somewhat shorter syntax for it, by specifying the column used as the ordering “key”. [...] Because Python's implementation is not very refined , this specialized syntax is actually much speedier than the general form “lambda x, y: cmp(x[1],y[1])”. It is a burden on the programer to always use the “key” syntax idiosyncrasy if he is sorting a large matrix. It's not only clearer for a human, but also faster in all good implementations of all languages which support that, except when the ordering function is very simple. It's called Schwartzian transform and I wish more language designers and programmers knew about it. http://en.wikipedia.org/wiki/Schwartzian_transform I urge future SRFI authors to include it. The withdrawn SRFI-32 for sorting didn't do that, and I can't find any other SRFI which deals with sorting. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Carl Banks [EMAIL PROTECTED] writes: BTW, the fact that a closure refers to a variable itself rather to its current value can be used to check the true attitude of languages with respect to functional programming, by observing how they understand their basic loops :-) Closing on a value rather than a variable would have been a lot easier to implement. To be clear: closing on the variable is the only sane choice. Closing on its current value would be inconsistent with global variables and no language does this. The issue is about the semantics of loops: whether they introduce a new variable for each iteration, or change the value of a single variable. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
[EMAIL PROTECTED] (Thomas A. Russ) writes: (defun addn (n) #'(lambda (x) (+ x n))) The same as def addn(n): def fn(x): return n + x return fn Is this really equivalent? What happens if you call addn more than once with different parameters. Will you get different functions that you can use simultaneously? Yes. It also behaves correctly when a variable it refers to is later mutated. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
[EMAIL PROTECTED] (Thomas A. Russ) writes:
(defun addn (n)
#'(lambda (x)
(+ x n)))
The same as
def addn(n):
def fn(x):
return n + x
return fn
Is this really equivalent?
What happens if you call addn more than once with different
parameters. Will you get different functions that you can
use simultaneously?
Yes.
It also behaves correctly when a variable it refers to is later
mutated.
BTW, the fact that a closure refers to a variable itself rather to its
current value can be used to check the true attitude of languages with
respect to functional programming, by observing how they understand
their basic loops :-)
Python loses:
closures = []
for i in range(10):
...def add(x):
... return x + i
...closures.append(add)
...
closures[5](1000)
1009
as does Ruby:
$ ruby -e '
closures = []
for i in 0..9 do
closures.push(proc {|x| x + i})
end
puts closures[5][1000]'
1009
but Lisp loses too:
(let ((closures (make-array 10)))
(do ((i 0 (+ i 1)))
((= i 10))
(setf (svref closures i) #'(lambda (x) (+ x i
(funcall (svref closures 5) 1000))
1010
Scheme wins:
(let ((closures (make-vector 10)))
(do ((i 0 (+ i 1)))
((= i 10))
(vector-set! closures i (lambda (x) (+ x i
((vector-ref closures 5) 1000))
1005
and what is perhaps surprising, Perl wins:
$ perl -e '
foreach my $i (0..9) {
push @closures, sub {$_[0] + $i}
}
print $closures[5](1000), \n'
1005
If you think it's unlikely that one would want to keep a closure
referring to a loop control variable longer than the loop iteration
which has created it, think about the loop body spawning a thread.
--
__( Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
--
http://mail.python.org/mailman/listinfo/python-list
