[issue40350] modulefinder chokes on numpy - dereferencing None in spec.loader
Denis Kasak added the comment: Anything still left to do that is stalling this? I just got bitten by it when trying to use modulefinder. -- nosy: +dkasak ___ Python tracker <https://bugs.python.org/issue40350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Enumerating all 3-tuples
On 2018-03-13 23:56, Denis Kasak wrote: On 2018-03-10 02:13, Steven D'Aprano wrote: But I've stared at this for an hour and I can't see how to extend the result to three coordinates. I can lay out a grid in the order I want: 1,1,1 1,1,2 1,1,3 1,1,4 ... 2,1,1 2,1,2 2,1,3 2,1,4 ... 1,2,1 1,2,2 1,2,3 1,2,4 ... 3,1,1 3,1,2 3,1,3 3,1,4 ... 2,2,1 2,2,2 2,2,3 2,2,4 ... ... and applying Cantor's diagonal order will give me what I want, but damned if I can see how to do it in code. [snip] The triples can be viewed as a pair of a pair and a natural number: (1,1),1 (1,1),2 (1,1),3 ... (2,1),1 (2,1),2 (2,1),3 ... (1,2),1 (1,2),2 (1,2),3 ... . . . . . . . . . [snip] def c3(i): """ Inverse of the Cantor pairing function generalization to triples, mapping N → N×N×N. """ n, m = c(i) return c(n) + (m,) In fact, extending this idea further, we can view the grid as a Cartesian product of two sets: the natural numbers and an arbitrary enumerable set. In your intended grid layout, the natural numbers were put (in their usual ordering) on the horizontal axis and the 2-tuples given by the pairing function on the vertical axis. However, diagonalizing this grid allows us to enumerate the Cartesian product itself, which means we can repeat the process by using this enumeration as the new vertical axis. Therefore, this process generalizes naturally to an arbitrary number of dimensions: def cr(i, d=2): """ Inverse of the Cantor pairing function generalization to d-tuples, mapping N → N^d. """ if d == 1: return i elif d == 2: return c(i) else: n, m = c(i) return cr(n, d-1) + (m,) >>> def first_ten(d): ...return [cr(i, d) for i in range(1, 11)] >>> for d in range(2, 5): ... pprint(first_ten(d)) [(1, 1), (2, 1), (1, 2), (3, 1), (2, 2), (1, 3), (4, 1), (3, 2), (2, 3), (1, 4)] [(1, 1, 1), (2, 1, 1), (1, 1, 2), (1, 2, 1), (2, 1, 2), (1, 1, 3), (3, 1, 1), (1, 2, 2), (2, 1, 3), (1, 1, 4)] [(1, 1, 1, 1), (2, 1, 1, 1), (1, 1, 1, 2), (1, 1, 2, 1), (2, 1, 1, 2), (1, 1, 1, 3), (1, 2, 1, 1), (1, 1, 2, 2), (2, 1, 1, 3), (1, 1, 1, 4)] -- Denis Kasak -- https://mail.python.org/mailman/listinfo/python-list
Re: Enumerating all 3-tuples
On 2018-03-10 02:13, Steven D'Aprano wrote: But I've stared at this for an hour and I can't see how to extend the result to three coordinates. I can lay out a grid in the order I want: 1,1,1 1,1,2 1,1,3 1,1,4 ... 2,1,1 2,1,2 2,1,3 2,1,4 ... 1,2,1 1,2,2 1,2,3 1,2,4 ... 3,1,1 3,1,2 3,1,3 3,1,4 ... 2,2,1 2,2,2 2,2,3 2,2,4 ... ... and applying Cantor's diagonal order will give me what I want, but damned if I can see how to do it in code. If you want this exact order, it can be reproduced in the following way. The triples can be viewed as a pair of a pair and a natural number: (1,1),1 (1,1),2 (1,1),3 ... (2,1),1 (2,1),2 (2,1),3 ... (1,2),1 (1,2),2 (1,2),3 ... . . . . . . . . . Decomposing this by the diagonals yields 1: (1,1),1 2: (2,1),1 (1,1),2 3: (1,2),1 (2,1),2 (1,1),3 . . . Notice that the first elements of each pair (i.e. the inner pairs) are given by the (inverse of the) original Cantor pairing function, in decreasing order. The second elements are just the natural numbers. Naming the inverse c, we can rewrite the above like this: 1: c(1),1 2: c(2),1 c(1),2 3: c(3),1 c(2),2 c(1),3 . . . Rewriting this to spell out the mapping between the natural numbers and the pairs, we get 1 -> c(1),1 2 -> c(2),1 3 -> c(1),2 4 -> c(3),1 5 -> c(2),2 6 -> c(1),3 . . . Squinting a bit, this might seem familiar. This is exactly the same as the original pairing function, except for an additional application of c to the first element of the pair! 1 -> 1,1 2 -> 2,1 3 -> 1,2 4 -> 3,1 5 -> 2,2 6 -> 1,3 This leads fairly naturally to the implementation. from itertools import accumulate, count def c(i): """ Inverse of the Cantor pairing function, mapping N → N×N. """ assert i >= 1 # partial sums of the series 1 + 2 + 3 + ... sums = accumulate(count(1)) n = 0 while True: m = next(sums) if m < i: n += 1 else: r = m - i break return r + 1, n - r + 1 def c3(i): """ Inverse of the Cantor pairing function generalization to triples, mapping N → N×N×N. """ n, m = c(i) return c(n) + (m,) Applying c3 to the natural numbers gives the sequence you wanted: s = map(c3, count(1)) pprint([next(s) for _ in range(10)]) [(1, 1, 1), (2, 1, 1), (1, 1, 2), (1, 2, 1), (2, 1, 2), (1, 1, 3), (3, 1, 1), (1, 2, 2), (2, 1, 3), (1, 1, 4)] -- Denis Kasak -- https://mail.python.org/mailman/listinfo/python-list
Re: Attribute error-- but I'm innocent(?)
On Tue, Mar 3, 2009 at 6:13 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
On Mon, 2 Mar 2009 16:56:58 -0800 (PST), Nick Mellor
nick.mellor.gro...@pobox.com declaimed the following in
def __init(self):
self.forename = RandomName(h:\\Testing\\NameDb\
\Forenames.csv, namefield = Forename)
Where is RandomName defined? Python is case sensitive, and the
method further down is randomName.
You could ask the same for dictfile(), which is also not shown, though
you could probably deduce from the filename (and the fact that it
works now) that it is defined elsewhere in the same file.
Furthermore, given the indentation you show, randomName is a method
of RandomPerson... If that is true, you'll need to do
target = self.randomName(...)
self.surname = RandomName(h:\\Testing\\NameDb\\Surnames.csv,
namefield = Surname)
self.randomAddress = dictfile(h:\\Testing\\NameDb\
\Addresses.csv).cycleShuffled() it should be obvious
[...]
def randomName(self):
As the OP said, RandomName is a class and, judging by the
capitalization, he is instantiating objects of the said class and not
the method of RandomPerson.
Up above you are pass two arguments (besides the self with my
noted change would supply), but here you do not have anything to accept
them... Where is that file name and that keyword argument supposed to be
received?
def randomName(self, fileid, namefield):
#have to use namefield as you used a keyword passing mechanism
return {Forename : self.forename.randomByWeight(),
Surname : self.surname.randomByWeight()}
This will return a dictionary containing both forename and
surname... Assuming you have forename and surname OBJECTS with contain a
randomByWeight method.
In all probability, forename and surname *are* instances of RandomName
and contain the randomByWeight() method.
--
Denis Kasak
--
http://mail.python.org/mailman/listinfo/python-list
Re: Reference or Value?
On Mon, Feb 23, 2009 at 8:41 PM, Christian Heimes li...@cheimes.de wrote: Denis Kasak wrote You could, however, argue that the swap function doesn't work as expected (e.g. from a Pascal or a C++ POV) simply because the underlying objects aren't mutable. The objects *do* get passed by reference; We are getting down the same road every couple of months. Please don't explain Python's calling system with terms like call by reference. It's plain simple wrong. The correct term is call by sharing or call by object reference although I myself don't use the latter term because it sounds too much like call by reference. Every time somebody tries to explain Python with call by reference, the person is confusing himself and others. I assure you I am not confused about Python's object model / calling system. I was arguing, from a purely theoretical standpoint, that the same system Python uses could be described in terms of call-by-reference with some additional constraints. I am by no means arguing that this is a good way of explaining it or trying to explain it to someone in terms of call-by-reference. I just don't think it's plain simple wrong, just confusing and suboptimal. -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: Reference or Value?
On Mon, Feb 23, 2009 at 9:12 PM, Steve Holden st...@holdenweb.com wrote: Denis Kasak wrote: I assure you I am not confused about Python's object model / calling system. I was arguing, from a purely theoretical standpoint, that the same system Python uses could be described in terms of call-by-reference with some additional constraints. I am by no means arguing that this is a good way of explaining it or trying to explain it to someone in terms of call-by-reference. I just don't think it's plain simple wrong, just confusing and suboptimal. Well, what's the benefit of discussing such a description, then? Regulars on c.l.py see this subject arising so regularly it's a bit like there's nothing new under the sun. Honestly, it's been discussed /ad nauseam/ lately. Someone said upthread that Andrew Cooke was completely wrong and I contested that. :-) I apologise for not being current with the latest discussions. -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: Reference or Value?
On Mon, Feb 23, 2009 at 5:09 AM, Steven D'Aprano ste...@remove.this.cybersource.com.au wrote: On Sun, 22 Feb 2009 13:37:27 -0300, andrew cooke wrote: as far as i understand things, the best model is: 1 - everything is an object 2 - everything is passed by reference Except that is wrong. If it were true, you could do this: def swap(x, y): y, x = x, y a = 1 b = 2 swap(a, b) assert a == 2 and b == 1 but you can't, it does not work. Ergo, parameter passing in Python does not have the same semantics as languages that use pass-by-reference, such as Pascal and Basic. That means that even if you can justify the claim Python is pass-by-reference by some technical argument (and I don't believe you can), it is misleading to make that claim without further qualifications. You could, however, argue that the swap function doesn't work as expected (e.g. from a Pascal or a C++ POV) simply because the underlying objects aren't mutable. The objects *do* get passed by reference; the function doesn't receive a new copy of the object and it can examine the original object's ID. The actual culprit is not the way objects are passed but the assignment operator, since it works by rebinding names (as Andrew Koenig explained) and not by changing the object itself. If the swap() function could somehow access the underlying integer object and modify it, swapping of values would indeed occur because the function *did* get references to the objects passed to it. That said, it's a rather convoluted way of explaining what happens and calling it pass-by-object feels much better. :-) -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: To unicode or not to unicode
On Sun, Feb 22, 2009 at 1:39 AM, Ross Ridge rri...@csclub.uwaterloo.ca wrote:
Ross Ridge (Sat, 21 Feb 2009 18:06:35 -0500)
I understand what Unicode and MIME are for and why they exist. Neither
their merits nor your insults change the fact that the only current
standard governing the content of Usenet posts doesn't require their
use.
Thorsten Kampe thors...@thorstenkampe.de wrote:
That's right. As long as you use pure ASCII you can skip this nasty step
of informing other people which charset you are using. If you do use non
ASCII then you have to do that. That's the way virtually all newsreaders
work. It has nothing to do with some 21+ year old RFC. Even your Google
Groups newsreader does that ('content=text/html; charset=UTF-8').
No, the original post demonstrates you don't have include MIME headers for
ISO 8859-1 text to be properly displayed by many newsreaders. The fact
that your obscure newsreader didn't display it properly doesn't mean
that original poster's newsreader is broken.
And how is this kind of assuming better than clearly stating the used
encoding? Does the fact that the last official Usenet RFC doesn't
mandate content-type headers mean that all bets are off and that we
should rely on guesswork to determine the correct encoding of a
message? No, it means the RFC is outdated and no longer suitable for
current needs.
Being explicit about your encoding is 99% of the whole Unicode magic in
Python and in any communication across the Internet (may it be NNTP,
SMTP or HTTP).
HTTP requires the assumption of ISO 8859-1 in the absense of any
specified encoding.
Which is, of course, completely irrelevant for this discussion. Or are
you saying that this fact should somehow obliterate the need for
specifying encodings?
Your Google Groups simply uses heuristics to guess the
encoding the OP probably used. Windows newsreaders simply use the locale
of the local host. That's guessing. You can call it assuming but it's
still guessing. There is no way you can be sure without any declaration.
Newsreaders assuming ISO 8859-1 instead of ASCII doesn't make it a guess.
It's just a different assumption, nor does making an assumption, ASCII
or ISO 8850-1, give you any certainty.
Assuming is another way of saying I don't know, so I'm using this
arbitrary default, which is not that different from a completely wild
guess. :-)
And it's unpythonic. Python assumes ASCII and if the decodes/encoded
text doesn't fit that encoding it refuses to guess.
Which is reasonable given that Python is programming language where it's
better to have more conservative assumption about encodings so errors
can be more quickly diagnosed. A newsreader however is a different
beast, where it's better to make a less conservative assumption that's
more likely to display messages correctly to the user. Assuming ISO
8859-1 in the absense of any specified encoding allows the message to be
correctly displayed if the character set is either ISO 8859-1 or ASCII.
Doing things the pythonic way and assuming ASCII only allows such
messages to be displayed if ASCII is used.
Reading this paragraph, I've began thinking that we've misunderstood
each other. I agree that assuming ISO 8859-1 in the absence of
specification is a better guess than most (since it's more likely to
display the message correctly). However, not specifying the encoding
of a message is just asking for trouble and assuming anything is just
an attempt of cleaning someone's mess. Unfortunately, it is impossible
to detect the encoding scheme just by heuristics and with hundreds of
encodings in existence today, the only real solution to the problem is
clearly stating your content-type. Since MIME is the most accepted way
of doing this, it should be the preferred way, RFC'ed or not.
--
Denis Kasak
--
http://mail.python.org/mailman/listinfo/python-list
Re: What encoding does u'...' syntax use?
On Sat, Feb 21, 2009 at 7:24 PM, Thorsten Kampe thors...@thorstenkampe.de wrote: I'm pretty much sure it is UCS-2 or UCS-4. (Yes, I know there is only a slight difference to UTF-16/UTF-32). I wouldn't call the difference that slight, especially between UTF-16 and UCS-2, since the former can encode all Unicode code points, while the latter can only encode those in the BMP. -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: What encoding does u'...' syntax use?
On Sat, Feb 21, 2009 at 9:10 PM, Martin v. Löwis mar...@v.loewis.de wrote: I'm pretty much sure it is UCS-2 or UCS-4. (Yes, I know there is only a slight difference to UTF-16/UTF-32). I wouldn't call the difference that slight, especially between UTF-16 and UCS-2, since the former can encode all Unicode code points, while the latter can only encode those in the BMP. Indeed. As Python *can* encode all characters even in 2-byte mode (since PEP 261), it seems clear that Python's Unicode representation is *not* strictly UCS-2 anymore. Since we're already discussing this, I'm curious - why was UCS-2 chosen over plain UTF-16 or UTF-8 in the first place for Python's internal storage? -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: What encoding does u'...' syntax use?
On Sat, Feb 21, 2009 at 9:45 PM, Martin v. Löwis mar...@v.loewis.de wrote: Indeed. As Python *can* encode all characters even in 2-byte mode (since PEP 261), it seems clear that Python's Unicode representation is *not* strictly UCS-2 anymore. Since we're already discussing this, I'm curious - why was UCS-2 chosen over plain UTF-16 or UTF-8 in the first place for Python's internal storage? You mean, originally? Originally, the choice was only between UCS-2 and UCS-4; choice was in favor of UCS-2 because of size concerns. UTF-8 was ruled out easily because it doesn't allow constant-size indexing; UTF-16 essentially for the same reason (plus there was no point to UTF-16, since there were no assigned characters outside the BMP). Yes, I failed to realise how long ago the unicode data type was implemented originally. :-) Thanks for the explanation. -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: time.strptime() and time.strftime() reciprocity
On Mon, Feb 16, 2009 at 11:57 PM, Greg Krohn inva...@example.invalid wrote: snip ActivePython 2.6.1.1 (ActiveState Software Inc.) based on Python 2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import time fmt = %m/%d/%y %I:%M %p print time.strptime(fmt, time.strftime(fmt)) Traceback (most recent call last): File stdin, line 1, in module File C:\Python26\lib\_strptime.py, line 454, in _strptime_time return _strptime(data_string, format)[0] File C:\Python26\lib\_strptime.py, line 325, in _strptime (data_string, format)) ValueError: time data '%m/%d/%y %I:%M %p' does not match format '02/16/09 04:52 PM' So, yeah, that seems weird to me. Does anyone get similar results, know why this is happening, and/or how to fix it? It's actually pretty trivial to fix, which you would have also known if you had read the message of the exception more carefully. :P You passed the arguments for strptime() the wrong way around. Just pass them in reverse and your problem will be fixed. -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading text file with wierd file extension?
On Mon, Feb 2, 2009 at 10:43 PM, Lionel lionel.ke...@gmail.com wrote: snip ResourcefilePath 'C:\\C8Example1.slc.rsc' snip C:\C8Example1.slc.src The extension you used in the interactive shell differs from the one you used in the class code (i.e. rsc vs src). -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: unable to print Unicode characters in Python 3
On Tue, Jan 27, 2009 at 1:52 PM, Giampaolo Rodola' gne...@gmail.com wrote:
I have this same issue on Windows.
Note that on Python 2.6 it works:
Python 2.6.1 (r261:67517, Dec 4 2008, 16:51:00) [MSC v.1500 32 bit
(Intel)] on
win32
Type help, copyright, credits or license for more information.
print unicode('\u20ac')
\u20ac
Shouldn't this be
print unicode(u'\u20ac')
on 2.6? Without the 'u' prefix, 2.6 will just encode it as a normal
(byte) string and escape the backslash. In Python 3.0 you don't need
to do this because all strings are unicode to start with. I suspect
you will see the same error with 2.6 on Windows once you correct this.
(note to Giampaolo: sorry, resending this because I accidentally
selected reply instead of reply to all)
--
Denis Kasak
--
http://mail.python.org/mailman/listinfo/python-list
Re: unable to print Unicode characters in Python 3
On Tue, Jan 27, 2009 at 7:08 PM, Thorsten Kampe
thors...@thorstenkampe.de wrote:
* Denis Kasak (Tue, 27 Jan 2009 14:22:32 +0100)
On Tue, Jan 27, 2009 at 1:52 PM, Giampaolo Rodola' gne...@gmail.com
wrote:
snip
print unicode('\u20ac')
\u20ac
Shouldn't this be
print unicode(u'\u20ac')
You are trying to create a Unicode object from a Unicode object. Doesn't
make any sense.
Of course it doesn't. :-)
Giampaolo's example was wrong because he was creating a str object
with a non-escaped backslash inside it (which automatically got
escaped) and then converting it to a unicode object. In other words,
he was doing:
print unicode('\\u20ac')
so the Unicode escape sequence didn't get interpreted the way he
intended it to. I then modified that by adding the extra 'u' but
forgot to delete the extraneous unicode().
You are confusing encoding and decoding. unicode(str) = str.decode. To
print it you have to encode it again to a character set that the
terminal understands and that contains the desired character.
I agree (except for the first sentence :-) ). As I said, I simply
forgot to delete the call to the unicode builtin.
--
Denis Kasak
--
http://mail.python.org/mailman/listinfo/python-list
Re: palindrome function
Peter Otten wrote: Denis Kasak wrote: Basically, it reverses the list in place, so it modifies the list which called it. It does not return a /new/ list which is a reversed version of the original, as you expected it to. Since it doesn't return anything explicitly, Python makes it return None. Hence, the comparison you are doing is between the original list and a None, which is False, naturally. Try this: spam = ['a', 'n', 'n', 'a'] eggs = spam[:] if spam.reverse() == eggs: print Palindrome Your explanation is correct, but your example code compares None to ['a', 'n', 'n', 'a'] and therefore won't print Palindrome, either. Of course. Thank you for the correction. I guess you know your caffeine has started to wear off when you start making the same mistakes you were trying to fix. :-) -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: palindrome function
On Sat, Jul 12, 2008 at 12:22 AM, kdt [EMAIL PROTECTED] wrote: Hi all, Can someone please explain to me why the following evaluates as false? list=['a','n','n','a'] list==list.reverse() False I'm stumped :s Read the documentation on list.reverse(). Basically, it reverses the list in place, so it modifies the list which called it. It does not return a /new/ list which is a reversed version of the original, as you expected it to. Since it doesn't return anything explicitly, Python makes it return None. Hence, the comparison you are doing is between the original list and a None, which is False, naturally. Try this: spam = ['a', 'n', 'n', 'a'] eggs = spam[:] if spam.reverse() == eggs: print Palindrome Also, 'list' is a really bad name for a list, since this is the name of the builtin type object for the list type. -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting a set of lambda functions
On Sun, May 25, 2008 at 1:43 PM, Martin Manns [EMAIL PROTECTED] wrote:
Hi,
I try to get a set of lambda functions that allows me executing each
function code exactly once. Therefore, I would like to modify the set
function to compare the func_code properties (or the lambda
functions to use this property for comparison).
(The reason is that the real function list is quite large ( 1E5), there
are only few functions with non-equal code and the order of execution
is not important.)
How can I achieve this?
func_strings=['x', 'x+1', 'x+2', 'x']
funclist = [eval('lambda x:' + func) for func in func_strings]
len(funclist)
4
len(set(funclist))
4
funclist[0].func_code == funclist[3].func_code
True
funclist[0] == funclist[3]
False
Isn't this a bug? Shouldn't it be possible to create a set of
different lambda functions via a loop? At first I thought it was just
a quirk of list comprehensions, but the following example also yields
incorrect (or at least unintuitive) results:
spam = []
for i in range(10):
... spam.append(lambda: i)
spam[0]()
9
spam[1]()
9
Manually creating the lambdas and appending them to a list works as
expected, naturally; I don't see a good reason why it wouldn't work
with a loop. Am I missing something?
--
Denis Kasak
--
http://mail.python.org/mailman/listinfo/python-list
Re: Getting a set of lambda functions
On Sun, May 25, 2008 at 1:43 PM, Martin Manns [EMAIL PROTECTED] wrote:
Hi,
I try to get a set of lambda functions that allows me executing each
function code exactly once. Therefore, I would like to modify the set
function to compare the func_code properties (or the lambda
functions to use this property for comparison).
(The reason is that the real function list is quite large ( 1E5), there
are only few functions with non-equal code and the order of execution
is not important.)
How can I achieve this?
func_strings=['x', 'x+1', 'x+2', 'x']
funclist = [eval('lambda x:' + func) for func in func_strings]
len(funclist)
4
len(set(funclist))
4
funclist[0].func_code == funclist[3].func_code
True
funclist[0] == funclist[3]
False
Isn't this a bug? Shouldn't it be possible to create a set of
different lambda functions via a loop? At first I thought it was just
a quirk of list comprehensions, but the following example also yields
incorrect (or at least unintuitive) results:
spam = []
for i in range(10):
... spam.append(lambda: i)
spam[0]()
9
spam[1]()
9
Manually creating the lambdas and appending them to a list works as
expected, naturally; I don't see a good reason why it wouldn't work
with a loop. Am I missing something?
--
Denis Kasak
--
http://mail.python.org/mailman/listinfo/python-list
Re: Getting a set of lambda functions
Scott David Daniels wrote: Denis Kasak wrote: ... spam = [] for i in range(10): ... spam.append(lambda: i) spam[0]() 9 spam[1]() 9 Manually creating the lambdas and appending them to a list works as expected, naturally; I don't see a good reason why it wouldn't work with a loop. Am I missing something? Yes, you are missing something: binding time. your anonymous function returns the value of i in the enclosing scope _at_the_time_of_ _the function's_execution_. If you follow your previous example with 'del i' and then execute any of your spam functions, you'll get an NameError: global name 'i' is not defined. Ah, the problem was in the subtle misunderstanding of the semantics of lambda functions on my part. It's much clearer now. Thanks. There are a couple of ways to slve your problem: (1) use default args to do the binding at the function definition time. for i in range(10): spam.append(lambda arg=i: arg) The lambda expression is normally spelled lambda i=i: i), but if you don't know the idiom, I find the i=i part confuses people. Indeed. It hasn't occured to me that lambdas could bind the variables inside them by name. I guess my lambdas are still a little shaky. :-) -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: type classobj not defined?
Wesley Brooks wrote: Dear Users, I'm in the process of adding assert statements to a large piece of code to aid with bug hunting and came across the following issue; Using python in a terminal window you can do the following: type(False) == bool True I would like to check that an object is a class, here's an example: class b: def __init__(self): self.c = 1 def d(self): print self.c type(b) type 'classobj' But the following fails: type(b) == classobj Traceback (most recent call last): File stdin, line 1, in ? NameError: name 'classobj' is not defined You can compare it against the ClassType object located in the types module. import types class b: def __init__(self): self.c = 1 def d(self): print self.c type(b) == types.ClassType True -- Denis Kasak -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
Mike Schilling wrote: Threaded mail-readers too, screen-based editors , spell-checkers, all useless frills. Interestingly enough, I have explained my opinion in the part of the post you have trimmed. On the other hand, things you mentioned are far from being useless. They introduce no intrinsical slowdown due to increased bandwidth consumation, nor potential security problems. They have no downsides I can possibly think of and have many advantages. They are useful. HTML on Usenet is not. -- Denis -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
John Bokma wrote: You can't be sure: errors in the handling of threads can cause a buffer overflow, same for spelling checking :-D Yes, they can, provided they are not properly coded. However, those things only interact locally with the user and have none or very limited interaction with the user on the other side of the line. As such, they can hardly be exploitable. Some people never use them, and hence they use memory and add risks. On a good newsreader the memory use difference should be irrelevantly small, even if one does not use the features. I would call that a nitpicky argument. Also, the risk in question is not comparable because of the reasons stated above. The kind of risk you are talking about happens with /any/ software. To stay away from that we shouldn't have newsreaders (or any other software, for that matter) in the first place. Of course can HTML be useful on Usenet. The problem is that it will be much more often abused instead of used. No, you missed the point. I am arguing that HTML is completely and utterly /useless/ on Usenet. Time spent for writing HTML in Usenet posts is comparable to that spent on arguing about coding style or writing followups to Xah Lee. It adds no further insight on a particular subject, but _does_ add further delays, spam, bandwidth consumation, exploits, and is generally a pain in the arse. It's redundant. -- Denis -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
John Bokma wrote: Ulrich Hobelmann [EMAIL PROTECTED] wrote: John Bokma wrote: http://www.phpbb.com/mods/ Great. How can I, the user, choose, how to use a mod on a given web server? Ask the admin? And that is, in your opinion, completely comparable to running your own, private client? Is the admin obliged to install the mod? Is the admin even reachable? What if the web server runs another board than PHPBB? Check if there is a mod, and ask the admin. See above. Does the user want this? And with a user stylesheet you can change it quite radically :-) The look, not the feel. Wild guess: (signed) javascript and iframes? on your local computer? Otherwise: fetch HTML, parse it, restructure it, and have the application run a local webserver. Python, Perl, piece of cake. You seem to be forgetting that we are mainly talking about end users here who most probably will not have the sufficient expertise to do all that. And even if they do, it's still time consuming. -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
John Bokma wrote: so use Lynx :-) One forum I visit is about scorpions. And really, it talks a bit easier about scorpions if you have an image to look at :-D. In short: Usenet = Usenet, and www = www. Why some people want to move people from www to Usenet or vice versa is beyond me. If 80% of the current Usenet users stop posting, Usenet is not going to die :-D Agreed. This is actually your first post with which content I agree totally. From your other posts I got the impression that you are one of those people that are trying to make Usenet and WWW more similar to one another. -- Denis -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
T Beck wrote: Wasn't the point... I never said they were. HTML is at version 4.0(I think?) now, AND we've added extra layers of stuff you can use alongside of it. The internet is a free-flowing evolving place... to try to protect one little segment like usenet from ever evolving is just ensuring it's slow death, IMHO. That's all... HTML is at version 4.01 to be precise, but that is precisely off-topic. This discussion has being going on for long enough. It is held in a large crosspost to newsgroups that have nothing to do with HTML or the evolution of Usenet. The bottom line is that most Usenet users like it the way it is now, and it certainly serves it's purpose. The Web and Usenet should not mix as they are two distinct entities and merging them would lose some of their distinctive qualities, making the Internet a poorer place. I suggest letting the matter rest or taking it to a more appropriate newsgroup. -- Denis -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
CBFalconer wrote: Mike Schilling wrote: Mike Meyer [EMAIL PROTECTED] wrote in message Mike Schilling [EMAIL PROTECTED] writes: l v [EMAIL PROTECTED] wrote in message Xah Lee wrote: (circa 1996), and email should be text only (anti-MIME, circa 1995), I think e-mail should be text only. I have both my email and news readers set to display in plain text only. It prevents the marketeers and spammers from obtaining feedback that my email address is valid. A surprising amount of information can be obtained from your computer by allowing HTML and all of it's baggage when executing on your computer. Phishing comes to my mind first and it works because people click the link without looking to see where the link really takes them. A formatting-only subset of HTML would be useful for both e-mail and Usenet posts. Used to be people who wanted to send formatted text via email would use rich text. It never really caught on. But given that most of the people sending around formatted text are using point-n-click GUIs to create the stuff, the main advantage of HTML - that it's easy to write by hand - isn't needed. But the other advantage, that it's an existing and popular standard, remains. However, for both e-mail and news, it is totally useless. It also interferes with the use of AsciiArt, while opening the recipient to the dangers above. And HTML has the tendency to make e-mail and Usenet posts unnecessarily bigger, which will continue to be a bugger until broadband links become common enough. -- Denis -- http://mail.python.org/mailman/listinfo/python-list
Re: Jargons of Info Tech industry
Mike Schilling wrote: I see a difference between X would be useful for A, B, and C and Y will always be the only proper way. Don't you? Y would not be useful because of the bandwidth it consumes, the malware it would introduce, the additional time spent focusing on the format rather than quality of the content and, frankly, because it's useless. As Rich already said, if one wants to look at neatly formatted content, one can always visit the web. Usenet is meant to be an information-sharing facility, and I cannot see *any* reason why it should be exposed to all the disadvantages stated in numerous places in thread to gain a pale advantage such as flashy content. We already have a World Wide Web, no need to make Usenet it's clone. -- Denis -- http://mail.python.org/mailman/listinfo/python-list
