[issue13697] python RLock implementation unsafe with signals
Mike Meyer m...@mired.org added the comment:
I just ran into this issue in the logging module using 2.7. Here's the TB in
case it sheds any light on the issue
Traceback (most recent call last):
File ./crawler.py, line 531, in module
main(argv[1:]1:)
File ./crawler.py, line 522, in main
MCP(config).run()
File ./crawler.py, line 332, in run
self.reaper()
File ./crawler.py, line 359, in reaper
logging.debug('MCP process alive: %s', state)
File /usr/local/lib/python2.7/logging/__init__.py, line 1600, in debug
root.debug(msg, *args, **kwargs)
File /usr/local/lib/python2.7/logging/__init__.py, line 1120, in debug
self._log(DEBUG, msg, args, **kwargs)
File /usr/local/lib/python2.7/logging/__init__.py, line 1250, in _log
self.handle(record)
File /usr/local/lib/python2.7/logging/__init__.py, line 1260, in handle
self.callHandlers(record)
File /usr/local/lib/python2.7/logging/__init__.py, line 1300, in
callHandlers
hdlr.handle(record)
File /usr/local/lib/python2.7/logging/__init__.py, line 746, in handle
self.release()
File /usr/local/lib/python2.7/logging/__init__.py, line 700, in release
self.lock.release()
File /usr/local/lib/python2.7/threading.py, line 147, in release
self.__block.release()
thread.error: release unlocked lock
Since I'm not using threads, getting thread errors was a little bit of
a surprise. I guess trying to make the logging module thread safe
added a potential bug.
--
nosy: +Mike.Meyer
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13697
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Mike Meyer m...@mired.org added the comment: I've just verified that this patch also fixes 13824 and 11839. The attached patchfile adds a test to verify that using a non-existent default file fails if you don't specify the argument, and succeeds if you do. Could someone please apply it? -- nosy: +Mike.Meyer Added file: http://bugs.python.org/file25438/fopatch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Mike Meyer m...@mired.org added the comment: Sorry - got ahead of myself. It doesn't fix 13824. A deeper reading reveals that the problem wasn't quite what I thought it on first glance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11839] argparse: unexpected behavior of default for FileType('w')
Mike Meyer m...@mired.org added the comment: Steven - 12776 indeed fixes this issue. I applied the patch from it to a build of todays checkout, verified that my simple test script worked, then wrote some test cases for test_argparse. I've uploaded the patch for that test to both issues. I can't close this as a duplicate, though. -- nosy: +Mike.Meyer Added file: http://bugs.python.org/file25439/fopatch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5370] unpickling vs. __getattr__
Mike Meyer m...@users.sourceforge.net added the comment: True. But hat's why it was a QAD hack - all I did was make sure it didn't blow up on the test code, and that it passed the provided unit tests. It really needs to walk the class tree. So something like hasattr(inst.__class__, '__setstate__') is more likely to be correct. And yes, the pickle unit tests apparently don't test the __*state__ routines, but that's a different bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5370] unpickling vs. __getattr__
Mike Meyer m...@users.sourceforge.net added the comment: I don't believe in documenting bugs instead of fixing them. If this bug is going to stay in the code, I can either fix my install of Python to have non-broken Pickle modules, or I can fix every third-party libraries objects I use whose authors didn't worry about pickling them enough to find this. The fornmer is almost certainly easier, given a little time. Probably even easier than agreeing on proper document wording. The __init__ case is different - there isn't a common use case (this one comes from the standard library) for __init__ that breaks pickling, and the problems tend to manifest in the resulting pickles, not in the unpickling process. -- message_count: 4.0 - 5.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5370] unpickling vs. __getattr__
Mike Meyer m...@users.sourceforge.net added the comment: QAD patch for 2.6 pickle.py to fix this bug. Passes the 2.6 pickle unit tests. -- message_count: 5.0 - 6.0 Added file: http://bugs.python.org/file13290/pp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5370] unpickling vs. __getattr__
Mike Meyer m...@users.sourceforge.net added the comment: The args attribute gets created by __init__ and nothing in the class removes it. I don't think it's unreasonable for the class to expect the attribute to not vanish on it. Possibly it should be spelled __args (or declared private :-), but neither of those would make a difference in this case. Any feature access can be made more robust by checking for it in __dict__ first, but such a practice is neither practical nor pragmatic. It may be different for __getargs__, in which case the bug is in the documentation for __getargs__, which should mention this issue. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5370] unpickling vs. __getattr__
New submission from Mike Meyer m...@users.sourceforge.net: The attached short file causes all of python 2.5, 2.6 and 3.0 to drop into infinite recursion trying to unpickle the created object, but the 2.5 version has the cleanest The problem appears to be that the unpickle code (C in 3.0; Python in 2.5 - I assume the others are similar) uses getattr to try and get the __setstate__ method (if any) of the opject being built before it's dictionary is populated. This causes the invocation of the __getattr__ method, which tries to use the non-existent attrs attribute, thus starting the recursion. A simple workaround is to provide this: def __setstate__(self, data): self.__dict__.update(data) but methinks that either 1) the interpreter shouldn't be falling into the infinite loop in this case, or 2) the pickle code should be using hasattr to check for the attribute (which won't trigger this problem) before trying getattr on it. -- files: pickletest.py messages: 82721 nosy: mwm severity: normal status: open title: unpickling vs. __getattr__ type: behavior versions: Python 2.5, Python 2.6, Python 3.0 Added file: http://bugs.python.org/file13179/pickletest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Import and execfile()
On Fri, 11 Jan 2008 20:55:07 -0800 (PST) George Sakkis [EMAIL PROTECTED] wrote: On Jan 11, 5:24 pm, Mike Meyer [EMAIL PROTECTED] wrote: On Fri, 11 Jan 2008 14:05:11 -0800 (PST) George Sakkis [EMAIL PROTECTED] wrote: I maintain a few configuration files in Python syntax (mainly nested dicts of ints and strings) and use execfile() to read them back to Python. This has been working great; it combines the convenience of pickle with the readability of Python. So far each configuration is contained in a single standalone file; different configurations are completely separate files. You can make the syntax cleaner by using classes to hold the values instead of nested dicts, etc. That way you don't have to quote the names of the values: class Foo: bar = 1 baz = 2 Actually I am using the dict() constructor instead of literals so it's as clean as with classes; IMO for nested options it's cleaner than nested classes: Yup, that does that. Wasn't available last time I did this, so... I understand why this fails but I'm not sure how to tell execfile() to set the path accordingly. Any ideas ? Manipulate sys.path yourself? That's what Mitko suggested too, and indeed it works: However this doesn't look very clean to me. Also it's not thread-safe; I don't know that there is a clean solutions. As for not being thread-safe, I'd suggest that you should have all your configuration information loaded *before* you start any threads. This makes shutting down in case you decide there's something wrong in it easier, and in some cases may prevent inadvertently doing things that shouldn't oughta be done. In the case where you config files are parsed by the python interpreter, this goes double because a busted config file could lead to exceptions, leaving your application in an unknown state. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: where do my python files go in linux?
On Sat, 12 Jan 2008 16:13:08 +0100 Jorgen Bodde [EMAIL PROTECTED] wrote: Normally you'd split up the bulk of the code into a module which gets installed into site-packages and a piece of stand-alone front-end code which imports the module and executes whatever you need to do and gets installed into a typical PATH directory. I would agree but it is not a site package I am trying to distribute, but a wxPython application. I would not think my app belongs in the python site packages dir. I suspect that's because your app is simple, in that it only has one command. Many apps have multiple commands that share the same set of libraries. So putting a package for that app in site-packages makes a lot of sense. If your app-specific library is properly designed and documented, users may be able to build further commands for the system as well. On the issue of .pyc files - don't distribute them. Instead, arrange for the install package to run the compileall.py script (in the standard library) on your libraries. .pyc files are *not* guaranteed to be platform independent (even though the latest rpm tools seem to claim otherwise), so if you build them for your platform, they may well be unusable after being installed. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: super, decorators and gettattribute
On Sat, 12 Jan 2008 10:45:25 -0800 (PST) Richard Szopa [EMAIL PROTECTED]
wrote:
Hello all,
I am playing around w/ Python's object system and decorators and I
decided to write (as an exercise) a decorator that (if applied to a
method) would call the superclass' method of the same name before
doing anything (initially I wanted to do something like CLOS
[1] :before and :end methods, but that turned out to be too
difficult).
However, I cannot get it right (specially, get rid of the eval). I
suspect that I may be misunderstanding something happening between
super objects and __getattribute__ methods.
Here's my code:
def endmethod(fun):
Decorator to call a superclass' fun first.
If the classes child and parent are defined as below, it should
work like:
x = child()
x.foo()
I am parent's foo
I am child's foo.
name = fun.__name__
def decorated(self, *args, **kwargs):
try:
super_object = super(self.__class__, self)
There's an apparently common bug here: you don't want to pass super
self.__class__, but the class that the method is bound to. The two
aren't the same, as an instance of a subclass will have the subclass
as self.__class__, and not the current class. So super will return the
current class or a subclass of it, meaning (since you invoked this
method from self) you'll wind up invoking this method recursively.
All of which means your decorator is probably going to have to take
the class as an argument.
# now I want to achieve something equivalent to calling
# parent.foo(*args, **kwargs)
# if I wanted to limit it only to this example
# this doesn't work: in the example, it calls child's foo,
# entering in an eternal loop (instead of calling parent's
# foo, as I would expect).
# super_object.__getattribute__(name)(*args, **kwargs)
# this does work, but I feel it's ugly
eval('super_object.%s(*args, **kwargs)' % name)
except AttributeError:
pass # if parent doesn't implement fun, we don't care
# about it
return fun(self, *args, **kwargs) # hopefully none
decorated.__name__ = name
return decorated
class parent(object):
def foo(self):
print 'I am parent\'s foo'
class child(parent):
@endmethod
def foo(self):
print I am foo\'s foo.
if __name__=='__main__':
x = child()
x.foo()
Can anybody tell me how to call a superclass method knowing its name?
The same way you call any object's methods if you know it's name:
getattr(super_object, name)(*args, **kwargs)
The code seems to work the way you want:
x.foo()
I am parent's foo
I am foo's foo.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to POST call and retrieve result page
On Fri, 11 Jan 2008 14:44:19 +0530 suyash jape [EMAIL PROTECTED] wrote:
Hi all
i want to access a web page through python script, fillup the necessary
fields,
and press submit button (which does POST call) and retrieve the result page
and retrieve some values from it.
Here is the script i have written till now.
import urllib2
# create array of name/value pairs
self.params = urllib.urlencode({'seqname': 'BioSequence', 'sequence':
'ATACATTATCCAAACATAGCATGGCTT'})
# send http-post
request = urllib.urlopen(http://www.hydrazome.metazome.net/search.php;,
params)
# read back each line of reply
line = request.read()
print line
This script fills up the correct values in the search.php page.But i am not
sure if it is doing the POST (submit call).
Beacause in 'line' varialble, i am getting the search.php page.Not the
result page which is blast_results.php.
How to retrieve the result page?
Sounds like you're not POSTing to the right page.
The form on .../search.php lets you fill in values, but those values
are not necessarily POSTed to search.php. In particular, the form element
has an action attribute that has a URL to which the values on the page
should be posted. If that points to .../blast_results.php, then that's
the page you need to pass to urlopen with your data.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Learning Python via a little word frequency program
On 11 Jan 2008 03:50:53 -0800 Paul Rubin http://phr.cx@NOSPAM.invalid wrote: rent [EMAIL PROTECTED] writes: keys = freq.keys() keys.sort(key = freq.get, reverse = True) for k in keys: print %-10s: %d % (k, freq[k]) I prefer (untested): def snd((x,y)): return y # I wish this was built-in What's wrong with operator.itemgetter? sorted_freq = sorted(freq.iteritems(), key=snd, reverse=True) (still untested) from operator import itemgetter sorted_freq = sorted(freq.iteritems(), key=itemgetter(2), reverse=True) mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Magic function
On Fri, 11 Jan 2008 08:29:18 -0800 (PST) [EMAIL PROTECTED] wrote: Hi all, I'm part of a small team writing a Python package for a scientific computing project. The idea is to make it easy to use for relatively inexperienced programmers. As part of that aim, we're using what we're calling 'magic functions', and I'm a little bit concerned that they are dangerous code. I'm looking for advice on what the risks are (e.g. possibility of introducing subtle bugs, code won't be compatible with future versions of Python, etc.). Quick background: Part of the way our package works is that you create a lot of objects, and then you create a new object which collects together these objects and operates on them. We originally were writing things like: obj1 = Obj(params1) obj2 = Obj(params2) ... bigobj = Bigobj(objects=[obj1,obj2]) bigobj.run() This is fine, but we decided that for clarity of these programs, and to make it easier for inexperienced programmers, we would like to be able to write something like: obj1 = Obj(params1) obj2 = Obj(params2) ... run() The idea is that the run() function inspects the stack, and looks for object which are instances of class Obj, creates a Bigobj with those objects and calls its run() method. So, any comments on that approach? The basic idea is ok, but looking at the stack makes me a bit nervous. That makes the code complicated, and probably fragile in the face of changing python versions. The unittest module does much the same thing - you run unittest.main, and it runs all the tests in any TestCase subclass in your module (assuming you didn't do something to limit it). However, it does it by examining the module, not the stack. The real difference is that your magic classes have to be global to your module. On the other hand, it provides some nice tools to let you partition things, so you can easily run subsets of the classes from the command line. It's probably worth a look. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Frontend/GUI for C Program
On Fri, 11 Jan 2008 08:12:48 -0800 (PST) [EMAIL PROTECTED] wrote: I have a C program that works very well. However, being C it has no GUI. What does C have to do with it not having a GUI? I've written more C programs with a GUI than Python ones - and the C experience was generally better. Of course, I was using Intuition, not X. I have experience using wxPython from within Python apps and I like it a lot for its cross-platform capabilities. I was hoping to use wxPython for this as well. Sure, the GUI can be disconnected from the application. In fact, that's the right way to do it - it allows you to change the GUI as times move forward. I've done this in three different ways. Diez pegged them two of them. When the underlying C code is poorly organized, use subprocess to run the the C application, build what you're going to send to it's standard in, and watch what it writes to standard output. If the C code is well-organized - structures with routines that manipulate them, so you can identify objects - and command handling on standard in is basically parse the arguments, then invoke the the right function with those values, then you can wrap the structures as object - with the appropriate functions as methods, and use it in two ways. One is to expose things via a shared library, and the use ctypes to talk to it. The other is to embed a python into your application, and have it launch the script that's going to provide the GUI. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: improving performance of python webserver running python scripts in cgi-bin
On Thu, 10 Jan 2008 23:17:28 -0800 (PST) Dale [EMAIL PROTECTED] wrote:
I am using a simple python webserver (see code below) to serve up
python scripts located in my cgi-bin directory.
import BaseHTTPServer
import CGIHTTPServer
class Handler(CGIHTTPServer.CGIHTTPRequestHandler):
cgi_directories = ['/cgi-bin']
httpd = BaseHTTPServer.HTTPServer(('',8000), Handler)
httpd.serve_forever()
This works fine, but now I would like to combine the python scripts
into the server program to eliminate starting the python interpreter
on each script call. I am new to python, and was wondering if there
is a better techique that will be faster.
You can use BaseHTTPRequestHandler and override do_GET to handle the
actual request.
Also, can someone reccommend an alternative approach to
httpd.serve_forever(). I would like to perform other python functions
(read a serial port, write to an Ethernet port, write to a file, etc.)
inside the web server program above. Is there an example of how to
modify the code for an event loop style of operation where the program
mostly performs my python I/O functions until an HTTP request comes
in, and then it breaks out of the I/O operations to handle the HTTP
request.
Use poll/select/whatever to check if httpd.socket has data available,
and then invoke httpd.handle_request() when it does. Nothing else will
happen while the request is being handled.
The suggestion to check the various frameworks for doing async work is
a good one as well.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: for loop without variable
On Fri, 11 Jan 2008 22:18:22 GMT Neil Hodgson [EMAIL PROTECTED] wrote: Marty: I recently faced a similar issue doing something like this: data_out = [] for i in range(len(data_in)): data_out.append([]) Another way to write this is data_out = [[]] * len(data_in) Not quite. All the other variants give you 23 empty lists. That one gives you 23 references to one list: x = [[] for _ in range(23)] x[1].append(23) x [[], [23], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], []] x = [[]] * 23 x[1].append(23) x [[23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23], [23]] mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Import and execfile()
On Fri, 11 Jan 2008 14:05:11 -0800 (PST) George Sakkis [EMAIL PROTECTED]
wrote:
I maintain a few configuration files in Python syntax (mainly nested
dicts of ints and strings) and use execfile() to read them back to
Python. This has been working great; it combines the convenience of
pickle with the readability of Python. So far each configuration is
contained in a single standalone file; different configurations are
completely separate files.
You know, I've been there before. It's kinda neat, but not something
you really want to put in the hands of most users.
You can make the syntax cleaner by using classes to hold the values
instead of nested dicts, etc. That way you don't have to quote the
names of the values:
class Foo:
bar = 1
baz = 2
The really slick part was that if the config classes line up with the
implementation classes, you can create an instance of the config class
for the implementation object, and it can then change those values to
change it's behavior without changing the defaults other instances
see.
Now I'd like to factor out the commonalities of the different
configurations in a master config and specify only the necessary
modifications and additions in each concrete config file. I tried the
simplest thing that could possibly work:
With classes you factor out the commonality by factoring it into a
base class that the others inherit from.
==
# some_config.py
# master_config.py is in the same directory as some_config.py
from master_config import *
# override non-default options
foo['bar']['baz] = 1
...
==
# trying to set the configuration:
CFG = {}
execfile('path/to/some_config.py', CFG)
Traceback (most recent call last):
...
ImportError: No module named master_config
I understand why this fails but I'm not sure how to tell execfile() to
set the path accordingly. Any ideas ?
Manipulate sys.path yourself?
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney [EMAIL PROTECTED] wrote: Paul Sijben [EMAIL PROTECTED] writes: I know that I can not stop a dedicated hacker deconstructing my code. A direct consequence of this is that you can not stop *anyone* from deconstructing your code if it's in their possession. It takes only one dedicated, skilled person to crack your obfuscation system and distribute an automated process for doing so to anyone interested. Except that's not what he's trying to do. However I can not imagine that I would be the first one planning to do this. So is there a solution like this available somewhere? Trying to make bits uncopyable and unmodifiable is like trying to make water not wet. And again, that's not what he's trying to do. He wants to arrange things so that he doesn't have to support unmodified versions of his code, by making it impossible to import modified modules. While that's still impossible, once you decide how difficult you want to make it for people to do that, you can *probably* make it that difficult - but the process gets progressively more difficult and expensive as you make it harder. I think he's contemplating only the simplest, least expensive step: adding an import hook that only allows imports of digitally signed modules. If planning to deploy on Windows, where he has to bundle a python with his application, he may well implement the hook in the interpreter instead of in python, so it's harder to find. If you wanted to go to the expense, you could probably arrange things so that the digital signatures are the more vulnerable attack vectors, but I'd expect to spend millions of dollars doing so. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Q: modifying SQL statements
On Fri, 11 Jan 2008 18:11:41 -0500 Faber J. Fedor [EMAIL PROTECTED] wrote:
On 10/01/08 22:53 -0500, Mike Meyer wrote:
Personally, I think it would be more pythonic to not try and use two
different APIs to walk the list of jobs (... One Way To Do it):
def __call__(self, where=None):
q = select * from %s % (self.name,) + ( if not where else ( where
%s % where))
Does this '( if not where...' syntax actually work? I couldn't get it to
compile and I couldn't find any examples of such syntax (but you can't
expect googling for 'if not' to be too successful).
Yes.
def test(name, where):
... return select * from %s % (name,) + ( if not where else ( where %s %
where))
...
test('mine', 'x = 3')
'select * from mine where x = 3'
test('mine', None)
'select * from mine'
test('yours', 'barfle is not NULL')
'select * from yours where barfle is not NULL'
It is a 2.5 feature, though. I converted all my clients to 2.5.1,
shortly after it was available, and haven't used anything older
since. Sorry 'bout that.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is lambda x=x : ... ?
On Thu, 10 Jan 2008 10:25:27 -0800 (PST) [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm reading this page: http://www.ps.uni-sb.de/~duchier/python/continuations.html and I've found a strange usage of lambda: Now, CPS would transform the baz function above into: def baz(x,y,c): mul(2,x,lambda v,y=y,c=c: add(v,y,c)) ### What does y=y and c=c mean in the lambda function? Older versions of python didn't make variables in an outer scope visible in the inner scope. This was the standard idiom to work around that. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is lambda x=x : ... ?
On Thu, 10 Jan 2008 19:59:23 +0100 Fredrik Lundh [EMAIL PROTECTED] wrote: Mike Meyer wrote: What does y=y and c=c mean in the lambda function? Older versions of python didn't make variables in an outer scope visible in the inner scope. This was the standard idiom to work around that. lexically scoped free variables and object binding are two different things, and have different semantics. the former does not always replace the latter. And? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: for loop without variable
On Thu, 10 Jan 2008 08:42:16 +0100 Hrvoje Niksic [EMAIL PROTECTED] wrote: Mike Meyer [EMAIL PROTECTED] writes: It sounds to me like your counter variable actually has meaning, It depends how the code is written. In the example such as: for meaningless_variable in xrange(number_of_attempts): ... the loop variable really has no meaning. Rewriting this code only to appease pylint is exactly that, it has nothing with making the code more readable. Except in this case, the variable *has* a meaning. You've just chosen to obfuscate it. you've hidden that meaning by giving it the meaningless name i. If you give it a meaningful name, then there's an obvious way to do it (which you listed yourself): while retries_left: [...] This loop contains more code and hence more opportunities for introducing bugs. For example, if you use continue anywhere in the loop, you will do one retry too much. All correct - and I'm a big fan of minimizing code, as code you don't write has no bugs in it. But you can still show the meaning of this meaningless variable: for number_of_attempts in xrange(maximum_attempts): Of course, the OP's request is a better solution: since he doesn't actually need the variable, removing it completely means there's one less variable, which is one less thing you can set to the wrong value. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: XML+Logs to Latex. XSLT?
On Thu, 10 Jan 2008 22:32:50 +0100 Fredrik Lundh [EMAIL PROTECTED] wrote: Yes. For sure. I though XSLT was something like XML not other language and that Python will have any library that uses XSLT to do transformation... XSLT is definitely a language (it's turing complete, after all), but that there are of course several Python bindings to XSLT libraries; here's one: XSLT is definitely something like XML - because an XSLT file is an XML file. But it represents a program, and hence is a programming language. It is unlike most other programming languages you will have encountered. XSLT may well be the most popular thing like XSLT, but Prolog is probably the language you've heard of that's closest to it. If you want to transform your XML into different-shaped XML or flat text, XSLT should be high on the list of tools to check out. http://codespeak.net/lxml/ Very much recommended. But please don't use SAX if you can avoid it; it's hard to work with, and not very efficient. I'd recommend ElementTree, which is a light- weight DOM library, that's part of the standard library: http://effbot.org/zone/element-index.htm While I love the ElementTree API, the standard library implementation is missing tools that I find invaluable in working with XML. No schema support, for instance. The effort of maintaining a schema is repaid multiple times if you take advantage of it. If your application validates the XML on input, you *know* that when you translate a required attribute value to an the, the attribute will be there, and the it's value will repersent an int. And using a schema-aware editor is pretty much the only sane way for a human being to edit XML. The XPath implementation is also limited. Having written a little XSLT, not having pretty much all of XPath available for pulling values is painful. And of course, XSLT support, as there are things that XSLT is good for. Others I'm not so sure about. External entities seem to be unsupported by ElementTree. XInclude? More? Is this the way you will do it? As the author of ElementTree, I'm a bit biased, but I'd definitely do it in Python ;-) Ditto - well, except I'm not the author of ElementTree. If all you want to do is read the XML into a tree of python strings, then the ElementTree implementation is an excellent API for doing so, and being in the standard library means you should already have it. If you want to leverage XML to make your job as easy as possible, then I'd recommend using the aforementioned lxml instead. It provides the same ElementTree API on top of the popular libxml2 and libxslt libraries (your Unix-like system probably comes with them pre-installed), and hence gives you access to all the XML tools they provide - like the ones I mentioned above. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Detecting OS platform in Python
On Thu, 10 Jan 2008 18:37:59 -0800 (PST) Devraj [EMAIL PROTECTED] wrote:
Hi everyone,
My Python program needs reliably detect which Operating System its
being run on, infact it even needs to know which distribution of say
Linux its running on. The reason being its a GTK application that
needs to adapt itself to be a Hildon application if run on devices
like the N800.
I don't think it can be done. For most Unix system, os.uname() will give
you the information you want:
os.uname()
('FreeBSD', 'bhuda.mired.org', '6.2-STABLE', 'FreeBSD 6.2-STABLE #6: Sun Jun 3
04:17:59 EDT 2007 [EMAIL PROTECTED]:/usr/src/sys/amd64/compile/BHUDA',
'amd64')
(let's see - OS name, the system name, the release level, complete
build information, down to the configuration file for the build and
build number for that configuration, and the hardware type it was
built for).
For GNU/Linux systems, it won't, because it's a kernel facility, and
kernels don't know what distribution they're part of:
Linux student.mired.org 2.6.12-9-386 #1 Mon Oct 10 13:14:36 BST 2005 i686
GNU/Linux
(kernel name, system name, kernel version and build information,
platform, and operating system).
GNU/Linux distributions are collections of lots of people software, so
each has it's own way to state what distribution it is. I believe
there's some sort of standard - except not everybody follows it. So
you wind up using a series of heuristics to chase this information
down.
I have been searching around for an answer to this, and did find some
messages on a lists that suggested the use of sys.platform to detect
platform, with counter posts saying that it didn't work on Windows
etc.
Oh, you want it to work on Windows? Hmmm. [snotty comment about
Windows deleted].
Does the underlying platform claim to be POSIX.2 compliant? If so,
then os.uname() should work on it, but as indicated, that may well not
be complete.
On the other hand, trying to figure out what features you have
available by guessing based on the platform type is generally the
wrong way to approach this kind of problem - only in part because you
wind up reduced to a series of heuristics to figure out the
platform. And once you've done that, you could wind up being wrong.
Generally, you're better of probing the platform to find out if it has
the facilities you're looking for. For python, that generally means
trying to import the modules you need, and catching failures; or
possibly looking for attributes on modules if they adopt to the
environment around them.
I'm not a GTK programmer, and have never even heard of Hildon. Is
there some associated module you could try and import that doesn't
exist on the N800? I.e.:
try:
import gtk
mygui = 'gtk'
except ImportError:
import Hildon
mygui = 'Hildon'
or maybe something like:
import gtk
mygui = 'gtk' if not hasattr(gtk, 'Hildon') else 'Hildon'
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie Q: modifying SQL statements
On Thu, 10 Jan 2008 20:32:06 -0500 Faber J. Fedor [EMAIL PROTECTED] wrote: Hi all, I'm in the process of learning Python by writing a job queue program. Nothing fancy, mind you, just read from a table, shell out to a program, write back to the table. I'm working off of the tutorial listed here (amongst many places): http://www.devx.com/dbzone/Article/22093 In my Jobs class I have: def __iter__(self): creates a data set, and returns an iterator (self) q = select * from %s % (self.name) self._query(q) return self # an Iterator is an object # with a next() method def next(self): returns the next item in the data set, or tells Python to stop r = self.dbc.fetchone() if not r: raise StopIteration return r which works well, but what if I want to modify the __iter__ query? I want to be able to do something like this (and I know this is not the right syntax but you'll get my drift): for job in jobs: print job # which the above code does for job in jobs(status = running): print job for job in jobs(jobid = 4): print job What's the pythonic way of doing this? Part of evaluating a for loop is that the expression in the for loop is evaluated, and it's __iter__ method is called. In your first line, the initial evaluation returns the jobs object, whose __iter__ method is then called, giving you the effect you want. For the second and third lines, the first evaluation tries to call the jobs object with the query as an argument. This fails, unless your jobs object is callable. If that returns the jobs object, __iter__ will be called - and thus use the query you want to avoid. So you need to have a __call__ method that leaves a token for __iter__ so it uses the proper query. This will do that, but I'm not sure I'd call it pythonic: _where = def __iter__(self): if not self._working: q = select * from %s % (self.name + where,) self._query(q) return self def __call__(self, where): self._where = where %s % (where,) return self def next(self): ... self._where = self.__class__._where # Put back class default raise StopIteration return r Personally, I think it would be more pythonic to not try and use two different APIs to walk the list of jobs (... One Way To Do it): def __call__(self, where=None): q = select * from %s % (self.name,) + ( if not where else ( where %s % where)) self._query(q) for r in self.dbc.iterresults() # I assume it has something like this yield r This should cause your first line to fail (possibly, depends on the exact nature of the class); it needs to be for job in jobs(): print job. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: for loop without variable
On Thu, 10 Jan 2008 22:36:56 -0500 Marty [EMAIL PROTECTED] wrote: I recently faced a similar issue doing something like this: data_out = [] for i in range(len(data_in)): data_out.append([]) More succinctly: data_out = [] for _ in data_in: data_out.append([]) Or, as has already been pointed out: data_out = [[] for _ in data_in] This caused me to wonder why Python does not have a foreach statement (and also why has it not come up in this thread)? I realize the topic has probably been beaten to death in earlier thread(s), but does anyone have the short answer? But I'm curious - what's the difference between the foreach you have in mind and the standard python for? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: for loop without variable
On Fri, 11 Jan 2008 01:48:43 -0500 Marty [EMAIL PROTECTED] wrote: Mike Meyer wrote: This caused me to wonder why Python does not have a foreach statement (and also why has it not come up in this thread)? I realize the topic has probably been beaten to death in earlier thread(s), but does anyone have the short answer? But I'm curious - what's the difference between the foreach you have in mind and the standard python for? For example, I thought the python equivalent of perl's foreach might be: No, python's equivalent of Perl's foreach is for. I.e. foreach $var (@list) does the same thing as Python's for var in list (except Perl gets the scoping right). Maybe you're thinking of Perls default variable feature (I don't know what else to call it), which implicitly uses $_ as a variable in any number of places if you fail to provide a variable? So that you can say: foreach (@list) and apparently not have to use a variable, except it implicitly uses $_. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Another dumb scope question for a closure.
On Wed, 9 Jan 2008 13:47:30 -0500 (EST) Steven W. Orr [EMAIL PROTECTED] wrote: So sorry because I know I'm doing something wrong. 574 cat c2.py #! /usr/local/bin/python2.4 def inc(jj): def dummy(): jj = jj + 1 return jj return dummy h = inc(33) print 'h() = ', h() 575 c2.py h() = Traceback (most recent call last): File ./c2.py, line 10, in ? print 'h() = ', h() File ./c2.py, line 5, in dummy jj = jj + 1 UnboundLocalError: local variable 'jj' referenced before assignment I could have sworn I was allowed to do this. How do I fix it? Nope. This is one of the things that makes lisper's complain that Python doesn't have real closures: you can't rebind names outside your own scope (except via global, which won't work here). Using a class is the canonical way to hold state. However, any of the standard hacks for working around binding issues work. For instance: def inc(jj): ... def dummy(): ... box[0] = box[0] + 1 ... return box[0] ... box = [jj] ... return dummy ... h = inc(33) h() 34 mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: problem of converting a list to dict
On Wed, 9 Jan 2008 14:34:26 -0600 Reedick, Andrew [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:python-
[EMAIL PROTECTED] On Behalf Of John Machin
Sent: Wednesday, January 09, 2008 3:02 PM
To: python-list@python.org
Subject: Re: problem of converting a list to dict
On Jan 10, 6:52 am, Reedick, Andrew [EMAIL PROTECTED] wrote:
A bigger hint:
a=i.split('=')
print '%s' splits into % (i), a
consider:
(1) using %r instead of '%s'
Eh, personal preference depending on how sure you are of the
data's type.
(2) omitting the redundant space after 'into'
Some of us coming in from other languages and still aren't used
to the comma adding an unwanted space after everything. I've been
tempted to root around in Python's source code to fix the problem.
(3) losing the redundant () around i
For me, the () is there for readability. Python's sprintf
syntax is odd to begin with, and something like
print '%s' splits into % i, a, b, c
means either
1) you really do want to append b and c after the
sprintf, or
print '%s' splits into % (a), b, c
2) that the formatting string is missing a few things
print '%s' splits into % (a, b, c) ## Ooops!
forgot to change it to %s %5.2d %6.3f
In that case, I'd suggest making the right operand a tuple:
print '%s' splits into % (i,), a, b, c
which some will argue is good style in any case. Or if you just want
to aide readers not used to python, use the redundant parens to
enforce the default parsing:
print ('%s' splits into % i), a, b, c
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python too slow?
On Wed, 9 Jan 2008 15:45:41 -0800 (PST) [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Okay I profiled the code and here is the output: http://heightened.files.wordpress.com/2008/01/output.txt It seems that the function it spends the longest on is the red_points function that he uses to find the points. Ok, so what's that look like? Python - used properly - can be quite fast. We process 1.5 billion rows a day through our python-based ETL system. The trick is to arrange things so that the cpu-intensive work gets done by C code. Preferably by tightly coded C written by very sharp people and extensively tweaked to make it go fast. In our case, the T part of our ETL system is handled by a custom C library that's been around - and being debugged and tweaked - for quite some time. Other examples include much of the code for python's builtins, and things like the Numpy extension library. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: for loop without variable
On Wed, 9 Jan 2008 18:49:36 -0800 (PST) erik gartz [EMAIL PROTECTED] wrote: The loop performs some actions with web services. The particular iteration I'm on isn't important to me. It is only important that I attempt the web services that number of times. If I succeed I obviously break out of the loop and the containing function (the function which has the loop in it) returns True. If all attempts fail the containing loop returns False. It sounds to me like your counter variable actually has meaning, but you've hidden that meaning by giving it the meaningless name i. If you give it a meaningful name, then there's an obvious way to do it (which you listed yourself): while retries_left: if this_succeeds(): return True retries_left -= 1 return False mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: urllib2.urlopen broken?
In [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED] typed:
In 2.5.1 (and 2.[45], but not 2.3):
Sigh. Sorry 'bout that. Since I started it, the breakage is:
Python 2.5.1 (r251:54863, May 15 2007, 15:31:37)
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6
Type help, copyright, credits or license for more information.
import urllib2
u = urllib2.urlopen('http://www.mired.org/')
u.fileno()
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/opt/lib/python2.5/socket.py, line 252, in fileno
return self._sock.fileno()
AttributeError: HTTPResponse instance has no attribute 'fileno'
The problem is that urlib2 was changed to wrap an HTTPResponse object
in a socket._fileobject to get a few more file methods. Except (as
reported above) HTTPResponse doesn't have a fileno() method, so when
_fileobject tries to use it, it blows up.
Adding an appropriate method to HTTPResponse:
def fileno(self):
return self.fp.fileno()
fixes the problem, but may not be the best solution. If no one
suggests a better one, I'll file the appropriate bug report.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
urllib2.urlopen broken?
In 2.5.1 (and 2.[45], but not 2.3): -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 14 Jan 2006 23:21:14 -0500, Mike Meyer wrote: So those properties of object() are all identical because they're really properties of object. If you define an object() by those properties, you have to conclude that object is itself an instance of object(). In this specific case, object instances get their properties from the class, but your conclusion doesn't follow. The easiest way to tell this is to ask, can we distinguish the object class (type) from an object instance? The answer is, yes we can: object type 'object' object() object object at 0xf705d3b8 Yes, but you're not looking at properties of the object, but rather of the type of the object. And for what it's worth, object is an instance of object. isinstance(object, object) True mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 14 Jan 2006 23:26:40 -0500, Mike Meyer wrote: I have no problem with that. Some objects are mutable and can change their value If the object *is* the value, how can it change to be a different value without also changing to be a diffent object? Because that's what they do. Think of it this way: objects are the memory location, the value is the particular pattern of bits at that memory location. Just because you flip a couple of bits at location N, changing the value, the location doesn't change. Ok. So when you say the object is the value, you're *really* saying the memory location is the pattern of bits it holds. Except that a memory location is an address, which is a pattern of bits. In general, this won't be the same pattern of bits as the memory location holds. So you're actually claiming that an object is two different patterns of bits at the same time. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: On Sun, 15 Jan 2006 03:11:27 -0500, Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 14 Jan 2006 23:26:40 -0500, Mike Meyer wrote: I have no problem with that. Some objects are mutable and can change their value If the object *is* the value, how can it change to be a different value without also changing to be a diffent object? Because that's what they do. Think of it this way: objects are the memory location, the value is the particular pattern of bits at that memory location. Just because you flip a couple of bits at location N, changing the value, the location doesn't change. Ok. So when you say the object is the value, you're *really* saying the memory location is the pattern of bits it holds. No. You seem to have trouble with analogies. My apologies for not making it clearer: I should have said, by analogy, the relationship between mutable objects and their value is equivalent to the relationship between a memory location and the bit pattern at that location. No, I don't have any trouble with analogies. I'm just carrying it to make the point that *I* want to make, rather than stopping at the point that you want to make. It isn't common for programming data to have multiple values simultaneously, but it does happen: a certain value can be a pointer to a memory location and an integer, or a numeric value and a character. Yup, and they're all represented by the same bit pattern. I've got no problem with that. It's perfectly correct to say that that bit pattern *is* all those things. On the other hand, it's not correct so say that the memory location - or the object - that those bit patterns reside in *is* those those. It isn't - it just holds them. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson writes: The Python manual's claim there is solidly grounded. The logic of 'types' is reasonably well-defined in the discipline. Each instance of a type takes exactly one element from the type's set of values (at least at a particular time). References? Are not hard to find. Well, Google didn't turn anything up. On the other hand, object and value are pretty poor terms to google with. Maybe you can suggest better ones? Didn't I? Type, or data type or datatype, plus abstract data[optional-space]type. You mentioned those in close connection with Wickipedia, so I only checked there. In retrospect, those probably don't work well, as we've already established that datatypes don't necessarily have to have values. In Niklaus Wirth's /Algorithms + Data Structures = Programs, the first section after introduction The concept of data type. It's been a few decades since I read that, but I don't recall anything that prohibited a valueless instance. The term data type implies instances have data; is it clear enough that a datum is a value? Actually, what data type implies to me is that data have a type. But skip that for now - what's the data that goes along with an instance of object? Wikipedia has reasonable articles on datatype and abstract datatype. That an instance takes a value is too obvious to state, but clearly implied by discussion of an object's value. I obviously disagree that it's too obvious to state. Just because most instances of objects have a value doesn't necessarily mean that every instance of an object has a value. The fact that general principles and results depend on each object having a value implies they must. *What* general principles? *What* results? The discussion on these wikipedia pages don't say anything that would imply that an object must have a value. If you're familiar with other programming languages, you can to those. There are no values of C's 'void' type, and consequently there are never any objects of type void. But we're not talking about C, we're talking about Python. You seemed to disagree when I said the logic of 'types' is reasonably well-defined in the discipline. If you're just talking about Python, then the Python Language Reference is right simply by status. That my repeated requests for a definition of type (or object) have never been answered suggest very strongly to me that the logic of types is not well-defined. And I'm trying to find out if there is any justification for the statement made in the Python Programing language. If there's some good reason that valueless objects can't (or shouldn't) exist in general, that will do. If there's some reason they can't (or shouldn't) exist in Python, that will do - though I'm also interested in the general question. What I'm *not* interested in is examples from other programming languages. That they fail to let you have objects without values no more proves that objects can't have values than Python not letting you take the address of a variable provesd that variables can't have addresses. [...] Ok, so the objects identity is not it's value. Right. Otherwise, the claim the type object has only one value would be false. I'm still not sure that there's only one value for objects of type 'object'. Well, if you can identify the set the values are drawn from, that would go a long way towards settling that issue. The concept of a valueless object is inconsistent with a great deal material. Another completely unsupported pronouncement. *What* material? Come on, give me *explicit* references. My textbooks are in storage too, but you'll find plenty if you look. Remember learning about call by value? Did they have to deal with objects without a value to pass? No. But in Python, call by reference has to deal with objects without a reference to pass. So what? Discussion involving an object's value would have to be rewritten to cover the case of objects that don't have one. Is a valueless object mutable or immutable? Let's see; the Reference says: Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. Your valueless objects break the definitions. The Ref says An object's mutability is determined by its type so it must have some mutability status to determine. Want to re-work the literature to cover your special case? So you're claiming that all objects have values is a convenience, like x raised to the power 0 is 1? Got any references yourself? Where's the literature on typed objects that don't have values? Ain't got none. On the other hand, I'm not trying to prove that such objects exist. I'm trying to find out if there's any justification for claiming that they don't exist. At the very least
Re: how do real python programmers work?
Roy Smith [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] wrote: we need a term for development environment built out of Unix tools We already have one. The term is emacs. So people using a development environment built around vim's pyhon mode are using emacs? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do real python programmers work?
Tom Anderson [EMAIL PROTECTED] writes: On Thu, 12 Jan 2006, Mike Meyer wrote: well, we need a term for development environment built out of Unix tools Disintegrated development environment? Differentiated development environment? How about just a development environment? I'd like the term to distinguish it from a standalone integrated development environment, which lets out the last one. How about interconnected development enviroment so we can reasonably suggest it whenever someone asks for an IDE? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: If you want to argue that the builtin sets should do that, you can - but that's unrelated to the question of how the comparison operators behave for the rest of the bulitin types. What I argue is that there is no single order for a specific type. I think that depends on your definition of type, but let it go. There can be an order that is most usefull in general but which order is usefull at a specific point depends on the context. Yes. So what? Does this fact suggest some change to Python that would improve it? If so, you need to mention it. If not, why bring it up at all? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Freezing
[EMAIL PROTECTED] writes: Mike Meyer: Actually, I like the len model, which would be a new builtin that uses the __freeze__ method. Well, I presume this is a matter of personal tastes and consistency too. This time I appreciate the freeze() too, but probably some people can think that adding .len, .copy(), .del(), .freeze() methods to most objects is more regular: len(l) l.len copy.copy(l) l.copy() |l| freeze(l) l.freeze() del ll.del() One problem is that it suggests a structure that isn't there. While other languages will have an abstract sequence type that has a len that, for example, iterates through the elements to count them, Python doesn't have such a thing. Adding a len method would require adding the method to all the types, even if only to add the default behavior. A len function, on the other hand, can check for __len__, and implement the default behavior if it doesn't find that (n.b. - I'm not saying that this is what len does; I'm just providing an example!). A freeze function could do the same thing: check for __freeze__ and use that if it exists, otherwise implement a default behavior. In Py3K you might be able to put the default behavior on object, but only if everything really inherits from object. I'm not sure the other builtin types will do that. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: PDA Implementations
gregarican [EMAIL PROTECTED] writes: I am in the process of creating an app that runs on various PDA platforms. Currently I have it running on ARM Linux (Sharp Zaurus) and am starting to port it over to ARM Windows Mobile (Dell Axim). Using Python has made the task particularly easier and (dare I say it?) kind of fun. On an unrelated topic, you might take a look at Symbian devices. They've released a version of Python 2.3 for it. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Marshal Obj is String or Binary?
Giovanni Bajo [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Try...
for i in bytes: print ord(i)
or
len(bytes)
What you see isn't always what you have. Your database is capable of
storing \ x 0 0 characters, but your string contains a single byte of
value zero. When Python displays the string representation to you, it
escapes the values so they can be displayed.
He can still store the repr of the string into the database, and then
reconstruct it with eval:
repr and eval are overkill for this, and as as result create a
security hole. Using encode('string-escape') and
decode('string-escape') will do the same job without the security
hole:
bytes = '\x00\x01\x02'
bytes
'\x00\x01\x02'
ord(bytes[0])
0
rb = bytes.encode('string-escape')
rb
'\\x00\\x01\\x02'
len(rb)
12
rb[0]
'\\'
bytes2 = rb.decode('string-escape')
bytes == bytes2
True
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Noam Raphael [EMAIL PROTECTED] writes: Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Sorry, I wasn't clear enough. In treating I meant how containers treat the objects they contain. For example, you can't easily map a value to a specific instance of a list - dict only lets you map a value to a specific *value* of a list. Wrong. All you have to do is create a list type that uses identity instead of value for equality testing. This is easier than mapping an exception to false. Another example - you can't search for a specific list object in another list. Your proposed == behavior doesn't change that at all. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. Here they are: * Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that decimals should not be compared to floats, instead of returning False). While I agree that Decimal(3.0) == 3.0 returning false doesn't make sense, having it raise an exception doesn't make any more sense. This should be fixed, but changing == doesn't fix it. * You won't be able to use objects as keys, expecting them to be compared by value, and causing a bug when they don't. I recently wrote a sort-of OCR program, which contains a mapping from a numarray array of bits to a character (the array is the pixel-image of the char). Everything seemed to work, but the program didn't recognize any characters. I discovered that the reason was that arrays are hashed according to their identity, which is a thing I had to guess. If default == operator were not defined, I would simply get a TypeError immediately. This isn't a use case. You don't get correct code with either version of '=='. While there is some merit to doing things that make errors easier to find, Python in general rejects the idea of adding boilerplate to do so. Your proposal would generate lots of boilerplate for many practical situations. * It is more forward compatible - when it is discovered that two types can sensibly be compared, the comparison can be defined, without changing an existing behaviour which doesn't raise an exception. Sorry, but that doesn't fly. If you have code that relies on the exception being raised when two types are compared, changing it to suddenly return a boolean will break that code. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson writes: [EMAIL PROTECTED] wrote: The reason is that I am still trying to figure out what a value is myself. Do all objects have values? Yes. Can you justify this, other than by quoting the manual whose problems caused this question to be raised in the first place? The Python manual's claim there is solidly grounded. The logic of 'types' is reasonably well-defined in the discipline. Each instance of a type takes exactly one element from the type's set of values (at least at a particular time). References? What the value of object()? A few weeks ago I turned to that page for enlightenment, with the results I reported. I think type 'object' has only one value, so that's it. In that case, they should all be equal, right? object() == object() False Looks like they have different values to me. Whether the '==' operation conforms to your idea of what equality means is unclear. Care to say what it does mean, then? Maybe I was wrong, and the object's identity is part of its abstract state. Is abstract state always part of the value? Or maybe an object is valueless, in spite of what the manual says. We know that's not true. You claim it's not true, but didn't provide anything to back up those claims, or even alternatives to explain the apparent discrepancy in behavior. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 14 Jan 2006 04:22:53 +, Donn Cave wrote: | 2. What is the value of object()? [ I assume you mean, the object returned by object(). ] It doesn't really have a value. I can't think of any kind of computation that could use this object directly. Here is one: obj_inst = object() def computation(data): global obj_inst if data is obj_inst: print FirstOneThousandPrimes() else: print TextOfWarAndPeace() It isn't a particularly useful computation, but it is a computation. And it doesn't use the value of the object instance, it uses it's identity. Any type that doesn't have hacks to share instances with the same value could be used in this way. Let's try not to be too deep here, okay? Before asking what is the value of foo?, we have to agree on what we mean by value. It is easy to tie yourself into knots here. I think you want to settle what we mean by type first. Or maybe in parallel. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Donn Cave [EMAIL PROTECTED] writes: | 3. If two objects are equal with ==, does that | mean their values are the same? Yes. | 3.0 == 3 | True Evidently the value of 3.0 is the same as the value of 3. And they do. They are two different representations of the same value. More in another thread. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
On Numbers
In the discussion of equality, the issue that decimal('3.0') == 3.0 is
False came up as a reason for changing the behavior of ==. The problem
with this is that the proposed change doesn't really fix anything, it
just gives different wrong behavior. The correct fix would seem to be
fixing python's handling of numbers.
It's not clear from the PEP why test for equality always fails. While
the PEP says that interactions with floats are disallowed as to
tricky, comparisons seem to be an exception. In particular, equality
comparisons seem to always return false, whereas checking for
magnitude seems to work.
What appears to be missing in Python is a coherent model for all
numberic types. Other languages have this, so there's no obvious
reason that Python can't. Or maybe Python does, and I've overlooked
it. In that case, pointers to documentation would be appreciated.
If it doesn't exist, then I think this is something that should be
addressed for Py3K.
I'd like to work on that. The idea would be that all the numeric types
are representations of reals with different properties that make them
appropriate for different uses. The goal would be a model for a
numeric type that captures those properties in a way that allows them
to be combined to give sane behavior without being to tricky.
To get started on that, I want to consider how other languages with
rich numeric type systems model them. I'm going to look at a couple of
languages in the LISP family. I'd like to solicit the community for
the names of languages (and pointers to references, if possible!) with
a coherent view of a rich set of numeric types.
Thanks,
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Paul Rubin http://[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Whether the '==' operation conforms to your idea of what equality means is unclear. Care to say what it does mean, then? I'd say a==b doesn't necessarily mean a and b have the same value. Care to say what it does mean (as opposed to what it doesn't mean), then? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 14 Jan 2006 14:14:01 +, Antoon Pardon wrote: On 2006-01-14, Steven D'Aprano [EMAIL PROTECTED] wrote: On Thu, 12 Jan 2006 16:11:53 -0800, rurpy wrote: It would help if you or someone would answer these five questions (with something more than yes or no :-) 1. Do all objects have values? All objects ARE values. Some values themselves are complex objects which in turn contain other values, e.g. if I execute: I don't agree with this wording. If a mutable object mutates it is still the same object but is's value has changed. [...] So I would agree with: objects have values. I don't believe this is a useful distinction to make. If two objects ARE the same value, then they should be the same object. If two objects HAVE the same value, then they may or may not be the same object. In particular, if the value is mutable, and you change one object that is some value you change the value, but the any other objects that are that value are still the old value of the value (um, I hope you know what I mena). This problem - and the vocabulary problem I just illustrated - both go away if objects have values instead of are values. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: object instances are like electrons (note for pedants: in classical physics, not QED): they are all exactly the same, distinguishable only by their position in time and space (or memory location). Except all electrons aren't exactly the same - because they have a value over and above their location. If you want to be pedantic, you can claim that electrons with a positive charge aren't really electrons. In either case, what's the object's equivalent for electric charge? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python.org website ?
Martin Maney [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] wrote: http://beta.python.org In particular, creating a good-looking design that remains readable in all possible browser configurations is impossible. Getting one that is readable in all reasonable browser configurations is hard, unless you make your definition of reasonable very narrow. Nah, it's very simple, if you can let go of the wrong-headed notion that the web is just like print media. Never had it. Gave up trying to drive it out of peoples heads over a decade ago. Of course that means you're unlikely to win any design awards, or even get a lot of commecnts about how spiffy your web site looks, because all the design geeks will judge you by the inapproriate standards of print media. Well, if you lower the defintion of good-looking design far enough, it's simple. Those design awards don't go to sites that I consider good-looking, though. Their standards seem to be driven by advertising concerns, and not readability or usability. If you ignore the designed-for-advertising goals, there's a lot of good information about design to be had from the print media. While some of it is totally inappropriate on the WWW (like ratios of page dimensions), a lot of it is still applicable (like choosing coherent font sets). If you look, you'll even find advice on how to pick fonts for low-resolution output devices. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: distance_in_feet = 5 weight_in_milligrams = 5 distance_in_feet == weight_in_milligrams True Since when is a distance comparable to a weight, let alone equal? The latest (and most impressive to date) to fix this is frink: URL: http://futureboy.homeip.net/frinkdocs/ The examples section is particularly amusing. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Noam Raphael [EMAIL PROTECTED] writes: Mike Meyer wrote: Noam Raphael [EMAIL PROTECTED] writes: Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Sorry, I wasn't clear enough. In treating I meant how containers treat the objects they contain. For example, you can't easily map a value to a specific instance of a list - dict only lets you map a value to a specific *value* of a list. Wrong. All you have to do is create a list type that uses identity instead of value for equality testing. This is easier than mapping an exception to false. You're suggesting a workaround, which requires me to subclass everything that I want to lookup by identity (and don't think it's simple - I will have to wrap a lot of methods that return a list to return a list with a modified == operator). No, I'm suggesting a general solution that works for *every* case where you want something other than the standard equality case. I'm suggesting the use of another container class: iddict instead of dict. That's all. You're suggesting adding a new builtin type to the language that deals with one special case. Is this special case really that common? I don't recall seeing anyone else ask for it in the last 10 years or so. I don't think that mapping an exception to false is so hard (certainly simpler than subclassing a list in that way), and the average user won't have to do it, anyway - it's the list implementation that will do it. I disagree with both your assessments. Subclassing is trivial. And every user who wants to compare elements in a container that might include heterogenous types has to deal with this issue. That's more than just lists, even if you only pay atttention to builtin types. Nuts - you have to deal with it when you're adding elements to a dictionary. Another example - you can't search for a specific list object in another list. Your proposed == behavior doesn't change that at all. It does - *use idlist*. You're mixing two proposals into the same thread. You'll forgive me for referring to the original proposal. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. Here they are: * Things like Decimal(3.0) == 3.0 will make more sense (raise an exception which explains that decimals should not be compared to floats, instead of returning False). While I agree that Decimal(3.0) == 3.0 returning false doesn't make sense, having it raise an exception doesn't make any more sense. This should be fixed, but changing == doesn't fix it. No, it can't be fixed your way. It was decided on purpose that Decimal shouldn't be comparable to float, to prevent precision errors. I'm saying that raising an exception will make it clearer. So how come I can compare decimals to floats? type(d) class 'decimal.Decimal' d 2.0 True d 0.0 False Are you proposing we should break this, which currently functions correctly? You're correct that this can't be fixed by fixing decimal alone. It requires more work than that. It may not be possible to fix this properly before Py3K. But your proposal can't be done until then anyway. I've already started the process of proposing a proper fix. * You won't be able to use objects as keys, expecting them to be compared by value, and causing a bug when they don't. I recently wrote a sort-of OCR program, which contains a mapping from a numarray array of bits to a character (the array is the pixel-image of the char). Everything seemed to work, but the program didn't recognize any characters. I discovered that the reason was that arrays are hashed according to their identity, which is a thing I had to guess. If default == operator were not defined, I would simply get a TypeError immediately. This isn't a use case. You don't get correct code with either version of '=='. While there is some merit to doing things that make errors easier to find, Python in general rejects the idea of adding boilerplate to do so. Your proposal would generate lots of boilerplate for many practical situations. I would say that there's a lot of merit to doing things that make errors easier to find. That's what exceptions are for. Exceptions are for finding *programming errors*? That's a rather unusual view of exceptions. Please say what those practical situations are - that what I want. (I understand. You think that added containers and a try...except fro time to time aren't worth it. I think they are. Do you have any other practical situations?) That try...except is the boilerplate I'm talking about. You are right that I'm suggesting a try...except when testing if a list contains an object, but a case when you have a list with floats and Decimals, and you rely on Decimal(3.0) in list1 to find only Decimals seems to me a little bit far-fetched. If you have another example, please say it. But you're suggesting
Re: Is 'everything' a refrence or isn't it?
Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson [EMAIL PROTECTED] writes: Mike Meyer wrote: Bryan Olson writes: [EMAIL PROTECTED] wrote: The reason is that I am still trying to figure out what a value is myself. Do all objects have values? Yes. Can you justify this, other than by quoting the manual whose problems caused this question to be raised in the first place? The Python manual's claim there is solidly grounded. The logic of 'types' is reasonably well-defined in the discipline. Each instance of a type takes exactly one element from the type's set of values (at least at a particular time). References? Are not hard to find. Well, Google didn't turn anything up. On the other hand, object and value are pretty poor terms to google with. Maybe you can suggest better ones? In Niklaus Wirth's /Algorithms + Data Structures = Programs, the first section after introduction The concept of data type. It's been a few decades since I read that, but I don't recall anything that prohibited a valueless instance. My copy is in storage, so I can't really double check it. Care to quote the relevant segment that says that objects have to have a value? Wikipedia has reasonable articles on datatype and abstract datatype. That an instance takes a value is too obvious to state, but clearly implied by discussion of an object's value. I obviously disagree that it's too obvious to state. Just because most instances of objects have a value doesn't necessarily mean that every instance of an object has a value. The discussion on these wikipedia pages don't say anything that would imply that an object must have a value. If you're familiar with other programming languages, you can to those. There are no values of C's 'void' type, and consequently there are never any objects of type void. But we're not talking about C, we're talking about Python. What the value of object()? A few weeks ago I turned to that page for enlightenment, with the results I reported. I think type 'object' has only one value, so that's it. In that case, they should all be equal, right? object() == object() False Looks like they have different values to me. Whether the '==' operation conforms to your idea of what equality means is unclear. Care to say what it does mean, then? I think that's now been answered a few times. In this case, it means comparison of object identity. Ok, so the objects identity is not it's value. Otherwise, the claim the type object has only one value would be false. Maybe I was wrong, and the object's identity is part of its abstract state. Is abstract state always part of the value? The abstract state, sometimes called the logical state, is the value the object represents. So are you now claiming that all instances of object have different values, as they all have different identities? The concept of a valueless object is inconsistent with a great deal material. Another completely unsupported pronouncement. *What* material? Come on, give me *explicit* references. At the very least, provide or point to a definition of type that makes it clear that a type for which you can have instances *has* to have values. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: Likewise instances of object() have a rich, object-oriented structure -- dir(object()) returns a list with twelve items -- but every instance is identical. That's because all the things in dir(object()) are also in dir(object): dir(object) == dir(object()) True So those properties of object() are all identical because they're really properties of object. If you define an object() by those properties, you have to conclude that object is itself an instance of object(). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 14 Jan 2006 18:26:41 -0500, Mike Meyer wrote: If two objects ARE the same value, then they should be the same object. You are assuming that values are unique, and that therefore is X is (in the English sense, not the Python sense) some value, then no other thing Y can also be the same value. I would say that's a valid definition of value. I have no problem with that. Some objects are mutable and can change their value If the object *is* the value, how can it change to be a different value without also changing to be a diffent object? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: More than you ever wanted to know about objects
[EMAIL PROTECTED] (Alex Martelli) writes:
Steve Holden [EMAIL PROTECTED] wrote:
...
3. If two objects are equal with ==, does that
mean their values are the same?
Almost universally, yes, although if you know enough about how the
interpreter works under the hood you can define the response of
instances of your own classes to the == operator (by defining their
__eq__ method), and even define a class whose instances aren't equal to
anything, even to themselves!
Hmmm... now this may be just be, but I'm quite vary of saying that,
since 1 == 1.0 == 1.0+0j, those three objects's values are the same.
For even more fun, consider 1.0 == 1 == decimal.Decimal('1.0').
Are equal, sure. But I intuitively see being the same as a stronger
condition than being equal.
When you say being the same, I think identity. But that's not
right either.
In mathematics, 1 is not the same as 1.0 -- there exists a natural
morphism of integers into reals that _maps_ 1 to 1.0, but they're still
NOT the same thing.
But what makes them different isn't attached to *them* - it comes with
the group/field they are part of. If I give you a mathematical 1 in
isolation, you can't tell if it's a real, an integer, a counting
number, or a member of Z-sub-n.
((I don't think this violates the introduce no complexity that doesn't
help understanding rule -- I think the 1==1.0 case is important!))
I do too. But I also think that Python's number types are somewhat
dodgy, and we might be better off if we ignore them for now. After we
get things straightened out for the other types, we can worry about
numbers.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: More than you ever wanted to know about objects
Steve Holden [EMAIL PROTECTED] writes: I just wish Mike Meyer and Steven D'Aprano were close enough that you could bang their heads together. We might be. But the results would probably be catastrophic for the surrounding area. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is 'everything' a refrence or isn't it?
Bryan Olson [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: The reason is that I am still trying to figure out what a value is myself. Do all objects have values? Yes. Can you justify this, other than by quoting the manual whose problems caused this question to be raised in the first place? What the value of object()? A few weeks ago I turned to that page for enlightenment, with the results I reported. I think type 'object' has only one value, so that's it. In that case, they should all be equal, right? object() == object() False Looks like they have different values to me. Or maybe an object is valueless, in spite of what the manual says. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: how do real python programmers work?
bblais [EMAIL PROTECTED] writes: In Python, there seems to be a couple ways of doing things. I could write it in one window, and from a Unix shell call python myscript.py and be like C++, but then I lose the interactiveness which makes prototyping easier. If I use the python shell, I can use import (and reload), or execfile perhaps. How do experienced python programmers usually do it? I do it both ways - and at least one other. If I'm working on code that's largely independent of the module, I'll use python-mode's execute commands to send the code to the Python interpreter. If the code needs the rest of the module, I'll use reload in the interactive interpreter. In the final stages of module development, I'll have a test at the end of the module, and switch to the shell to run the module as a script for testing. Of course, a lot of what I do is web apps, so the later stages of testing involve activating a browser and hitting reload. Is there a usually about it, or is it up to personal taste? Are there any convenient ways of doing these things? I think you've found some of the most convenient ones already. Maybe some of the people who IDEs (instead of - well, we need a term for development environment built out of Unix tools) will let us know what they do. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with super()
David Hirschfield [EMAIL PROTECTED] writes: I'm having trouble with the new descriptor-based mechanisms like super() and property() stemming, most likely, from my lack of knowledge about how they work. Here's an example that's giving me trouble, I know it won't work, but it illustrates what I want to do: class A(object): _v = [1,2,3] def _getv(self): if self.__class__ == A: return self._v return super(self.__class__,self).v + self._v v = property(_getv) class B(A): _v = [4,5,6] b = B() print b.v What I want is for b.v to give me back [1,2,3,4,5,6], but this example gets into a recursive infinite loop, since super(B,self).v is still B._getv(), not A._getv(). Is there a way to get what I'm after using super()? Yes. Call super with A as the first argument, not self.__class__. That's twice in the last little bit I've seen someone incorrectly use self.__class__ instead of using the class name. Is there bogus documentation somewhere that's recommending this? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading from input file.
Sheldon [EMAIL PROTECTED] writes: So Mike if you can do better then do it then! There are many ways do solve a problem, perhaps you have not learned that yet. At first this guy didn't know what to do, so he had to begin somewhere. Now you can take him much further, I am sure but the journey might not be so pleasant. Your attitude really needs major adjustment but then again, I have to consider the source. Let's double check: I didn't insult you. I didn't insult the original poster. I didn't say the code was bad, or ugly, or otherwise intolerable. All I did was point out that - with a modern Python - there's a shorter, easier to read way to write it. Pretty typical c.l.python behavior: demonstrating how posted code can be improved in some way. Personally, I encourage this behavior, because it helps everybody write better code. In return, I get insulted, told I need an attitude adjustment, and insulted a second time. If seeing people improve your code ticks you off so badly, you should think *very* hard before you post it to c.l.python. Writing code that can't be improved is nearly impossible, so it's very likely that any code posted here - by anyone - someone will know how to improve. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading from input file.
Sheldon [EMAIL PROTECTED] writes:
after you have read the file then split it like this:
file = open('inputfile.txt', 'r').read()
import string
file = string.split(file,'\n')
You're doing things the hard way - at least if you have a modern
Python. The above can be done as:
file = open('inputfile.txt', 'r').read().split('\n')
Or even better
file = open('inputfile.txt', 'r').readlines()
will all give you the same result.
BTW, it's a bad habit to leave open files laying around. It's also a
bad habit to use the name of builtins (like file) as variable names.
now if you print file[0] you should only get the first line.
Be careful and examine the file for non-continuous sections where a
line is empty. That is to say where file[x] = ' '. You should remove
these lines from the txt files before you read it with python. It maybe
so that python reads the entire file, empty spaces and all, and then
you have to remove them after the split with a WHERE statement. This is
a much easier way so lets hope that this is so.
Huh? What in the OP makes you think this is even necesary?
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, I would like some consistency. Either all comparisons between objects of different types throw an exception by default or none does. That's a very silly thing to ask for. It presumes that all types are the same. They aren't. It doesn't presume anything like that. Yes it does. It presumes that all operators of all types either always make sense, or there are always situations where they don't It also presumes that all comparisons are the same. They aren't. It doesn't presume that either. Yes it does. It presumes that all operators either always make sesne, or there are always situations where they don't. To use an overworked analogy, you might as well ask that you either have to peel all fruit, or that you never have to peel a fruit. Bad analogy since a fruit is not a relationship. I suggest you look up the meaning of the word analogy. In any case, the proposeed behavior *is* consistent. The behavior for all builtin types will be that comparisons that don't make sense will throw exceptions. It is only consistent if you start from an inconsistent view and then check for how consistently this view is followed. There is nothing consistent in telling that 1 == (1,3) makes sense and 1 (1,3) doesn't make sense. Set theoretically both 1 and (1,3) are sets. Of course there are types for which the given behaviors don't make sense. However, we're not talking about user-defined relations on user-defined types with syntax that isn't supported by the language. We're talking about the builtin relationships defined on the builtin types. There is a use case for things like 1 (1,3) making sense and denoting a total order. When you have a hetergenous list, having a total order makes it possible to sort the list which will make it easier to weed out duplicates. So why don't you demand a use case for the new behaviour to counter this use case? Yes, there is. And you are perfectly free to implement a type that behaves that way if you want to. I don't need a use case to counter this one; I just need to show that this use case can be reasonably covered by the proposed mechanism. IMO it would be better if it was possible to associate some kind of order function with the container. Because the order most usefull for comparing between two instances doesn't need to be the most usefull order in finding an element from a container. No, it wouldn't. Order relationships are a property of the type, not the container. The order relationships are right where they belong - attached to the type. That notwithstanding, it's often practical to be able to override the order function for some specific method (and would be even if the order function were associated with the container instead of the type), so some of the methods that use order allow you to provide a function to use for them. If you really want a container type that has an order function associated with it, you can write one. If you want it made part of the language, you'll have to provide a use case. I could impose a total order on sets, so that I can use a bisection algorithm on a container of them, but such an order is in general less usefull than the superset ordering when you are manipulating sets. And you're free to implement a subclass of sets that does that. If you want to argue that the builtin sets should do that, you can - but that's unrelated to the question of how the comparison operators behave for the rest of the bulitin types. At least, it doesn't matter unless you try and force all the types and operators to be the same. Since we're talking about Py3K here, there is no default behavior. User-defined classes all inherit from builtin types, and will get the behavior of their comparison operators from those types. In particular, those that inherit from object will get objects behavior, which means they'll get equality as identity. But if this makes any behaviour defined on objects consistent by definition, because the only criteria you seem to have for consistency is the inherited behaviour from object. If object would use a random function to decide that would be consistent too, because it would be the behaviour inherited by other classes. I don't find this a usefull way to measure consistency. But you can use a random
Re: How can I create a dict that sets a flag if it's been modified
here's one attempt. (I'm no expert, so wait for better :-) class ModFlagDict(dict): def __init__(self, *args, **kwargs): super(ModFlagDict, self).__init__(*args, **kwargs) self.modified = False def __setitem__(self, key, value): self.modified = True super(ModFlagDict, self).__setitem__(key, value) You also need to catch __delitem__. You may need to catch pop, update, clear and setdefault, depending on whether or not they call the __setitem__/__delitem__. Personally, I'd catch them all and make sure the flag got set appropriately, because whether or not they use those methods is an implementation detail that may change in the future. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python.org website ?
Tim Parkin [EMAIL PROTECTED] writes: Mike Meyer wrote: Of course, this is typical on the web: Works in IE really means works in IE in the configurations we tested it for, and usually means works in our favorite configuration. Actually the site has been tested on every browser listed on http://www.browsercam.com/Features.aspx and a few extras... Sorry. I didn't mean to imply that this was the attitude taken for the new python site. I was grousing about the state of the web in general. The new python site is still in testing, and I know such misbehaviors may be because of that rather than your attitude. A depressing percentage of web sites go into production with such problems intact, though. Nice to see that Python.org isn't going to be one of them. Whilst it doesn't work on ie4 (although it is readable) it does work on netscape 4.x (albeit with a much simpler css layout dedicated for just this browser) and it has also been optimised to work in lynx/links and has been partially tested in some speech readers.. However, since this testing there has been some changes made and instead of continually testing across all configurations, we're planning on running another browser check soon. Which answered my next question - which was about testing with things like JavaScript disabled, major CSS hackery, ignoring author fonts/colors, and in text-only browsers. I'm still dissapointed that the FreeBSD site loses Beastie if your browser is set to ignore authors colors (or should, anyway). In particular, creating a good-looking design that remains readable in all possible browser configurations is impossible. Getting one that is readable in all reasonable browser configurations is hard, unless you make your definition of reasonable very narrow. Not quite impossible but I agree it's pretty hard, especially using css for layout and trying to follow w3c guidelines (e.g. the relative font sizing thing)... However our aim is to make the site readable in all browsers in the majority of normal configurations. Well, all possible browser configurations include things like browser windows that are only 10s of pixels wide along with fonts sizes measured in the hundreds. I think you're justified in ignoring those, though. Thanks, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Link List in Python
sri2097 [EMAIL PROTECTED] writes: Hi all, I have written a Link list implementation in Python (Although it's not needed with Lists and Dictionaries present. I tried it just for the kicks !). Anyway here is the code - Generally very nice. # Creating a class comprising of node in Link List. class linklist: def __init__(self, data=None,link=None): self.data = data self.link = link def __str__(self): return str(self.data) def printing(node): print -*80 print ([data][link] --- [data][link] and so on till the end) print -*80 while 1: if node.link: print node.data, node.link,---, node = node.link else: # Printing the last node and exiting. print node.data, node.link print (All nodes printed) break Doubt - Now, Here I needed only 4 nodes. But what if I need more nodes. Is there any way to create the number of nodes at runtime. Since I plan to 'import' this module later. I wouldn't know how many nodes I need even before executing it. So, my doubt is - Is there any way to create 'n' number of object (here nodes) at runtime ? Sure: node = None for i in range(n): node = linklist(i, node) # Node now points to a linked list of n nodes, counting down as you traverse # the list. Any general criticisms about the code are also welcome... Well, your __str__ on linklist makes printing node.data, node.link equivalent to printing node.data, node.link.data, which is confusing. Maybe you want to make the __str__ method different? Also, the while loop in printing can be shortened a bit. The canonical loop scanner looks like: while node: process(node) node = node.link You have a slightly different process for the last node, which requires a conditional in the loop. By re-arranging things so the difference happens on the first node, you process the first node outside the loop, and drop the conditional in the loop: def printing2(node): print node.data, node.link, node = node.link while node: print --, node.data, node.link, node = node.link print \nAll nodes printed Ok, part of the difference was printing the trailing newline. I moved that to the final print statement to make it work right. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Freezing
Xavier Morel [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Dicts and sets require immutable keys, like tuples or frozensets, but to me they look like a duplication. So the idea is to remove tuples and frozensets (and replace the few other uses of tuples with lists, like the % interpolation), and to add a freeze operation, to freeze lists, sets and dicts (etc), so they can be used as keys. This has been suggested before. How about just providing a freeze method on `object` (since everything will inherit from object) that can freeze the object? Well, the OP suggested this is for 3.0, but it doesn't have to be unless you use his syntax. But Python generally prefers words to magic characters, so a freeze builtin would be preferable, meaning it could be done in 2.x. In fact the freeze protocol could provide 2 methods: freeze and frozen, the former would freeze the object in place (e.g. freeze the object it's applied to) while the later would return a frozen copy of the object it's applied to. Freezing in place is problematical. For this to work as intended, all the values in the container have to be frozen as well. All yours and the OPs examples used immutable values, so this wasn't obvious. But consider: d = dict() l = [d] l.freeze() for l to be usable as a dictionary key etc. after the freeze invocation, d must also be frozen. Doing that in place would be unfortunate. Creating a frozen copy of d to put in the frozen version of l might work, but still seems strange. Furthermore: One could even dream of a melt/molten method pair that'd behave at the opposite of the freeze/frozen pair (to have the ability to unfreeze an object if needed) You can't do unmelt in place: l.freeze() d.melt() would leave l not really frozen. You probably want the freeze and melt to be symmetric, which lets out freezing in place. No new keyword, no new token, no new structure, no new builtin, same functionalities. Actually, I like the len model, which would be a new builtin that uses the __freeze__ method. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to remove subset from a file efficiently?
fynali [EMAIL PROTECTED] writes:
Hi all,
I have two files:
Others have pointed out the Python solution - use a set instead of a
list for membership testing. I want to point out a better Unix
solution ('cause I probably wouldn't have written a Python program to
do this):
Objective: to remove the numbers present in barred-list from the
PSPfile.
$ ls -lh PSP320.dat CBR319.dat
... 56M Dec 28 19:41 PSP320.dat
... 8.6M Dec 28 19:40 CBR319.dat
$ wc -l PSP320.dat CBR319.dat
4,462,603 PSP320.dat
693,585 CBR319.dat
I wrote the following in bash to do the same:
#!/bin/bash
ARGS=2
if [ $# -ne $ARGS ] # takes two arguments
then
echo; echo Usage: `basename $0` {PSPfile} {CBRfile}
echo; echo eg.: `basename $0` PSP320.dat
CBR319.dat; echo;
echo NOTE: first argument: PSP file, second: CBR file;
echo this script _does_ no_ input validation!
exit 1
fi;
# fix prefix; cost: 12.587 secs
cat $1 | sed -e 's/^0*/966/' $1.good
cat $2 | sed -e 's/^0*/966/' $2.good
# sort/save files; for the 4,462,603 lines, cost: 36.589 secs
sort $1.good $1.sorted
sort $2.good $2.sorted
# diff -y {PSP} {CBR}, grab the ones in PSPfile; cost: 31.817 secs
diff -y $1.sorted $2.sorted | grep $1.filtered
# remove trailing junk [spaces ]; cost: 1 min 3 secs
cat $1.filtered | sed -e 's/\([0-9]*\) */\1/' $1.cleaned
# remove intermediate files, good, sorted, filtered
rm -f *.good *.sorted *.filtered
#:~
...but strangely though, there's a discrepancy, the reason for which I
can't figure out!
The above script can be shortened quite a bit:
#!/bin/sh
comm -23 (sed 's/^0*/966/' $1 | sort) (sed 's/^0*/966/ $2 | sort)
Will output only lines that occur in $1. It also runs the seds and
sorts in parallel, which can make a significant difference in the
clock time it takes to get the job done.
The Python version is probably faster, since it doesn't sort the
data.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Conditionals stored as text to translate to real compares
Randall Parker [EMAIL PROTECTED] writes:
if OperatorType == :
# then do a greater than compare here.
BoolVal = TestVal TargetVal
elif OperatorType == =:
# then do a greater or equal to here.
BoolVal = TestVal = TargetVal
and so on.
It would seem a lot easier to do:
BoolVal = TargetVal EvalStrToOper() MyInnerList(2)
where EvalStrToOper creates an immediate sign that then allows that
line to get evaluated by the interpreter.
How about:
BoolVal = EvalStrToOper[](TargetVal, MyInnerList(2)) ?
EvalStrOper = {'': operator.gt, '=': operator.ge,
'': operator.lt, '=': operator.le,
...
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why is there no post-pre increment operator in python
[EMAIL PROTECTED] writes: Anyone has any idea on why is there no post/pre increment operators in python ? For lots of good reasons. Although the statement: ++j works but does nothing So does --j. They both parse as a value with two unary operators applied to it in succession: +(+(j)) and -(-(j)). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Spelling mistakes!
Dennis Lee Bieber [EMAIL PROTECTED] writes: On Wed, 11 Jan 2006 06:57:06 +, Steve Holden [EMAIL PROTECTED] declaimed the following in comp.lang.python: I suppose most readers aren't old enough to remember the punch card days, when you would hand your work in on coding sheets to the punch room and it would be punched onto cards using huge machines (anyone remember the 026 and 029 punches?). FORTRAN and COBOL on 029s -- and had to submit the school ID card to check-out a drum; coding a drum card was actually taught in the COBOL class. Pretty much everything on the 029. Like you, I had to punch things myself. And had a drum card with one track for FORTRAN and a second for ALGOL. Of course, I was employed to work with them. At one point, I actually helped someone do data processing with the card sorter. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, and won't provide examples to show why you want things to behave whatever way you want, I can't really say much else about it. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Restart process with SIGHUP
[EMAIL PROTECTED] writes: I'm trying to restart a process with the os.kill command. My Problem is that if the command gets executed, my python script stops working. I want to SIGHUP a process with the following command: os.kill(pid, signal.SIGHUP). That looks right. Can anyone give me a hint in solving this? Not without knowing what the problem really is. Show us code. Show us a traceback (best) or otherwise provide details about what stops working means. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: how to improve this simple block of code
py [EMAIL PROTECTED] writes: Say I have... x = 132.00 but I'd like to display it to be 132 ...dropping the trailing zeros...I currently try this The two-strip solution is cleaner, but: if x.endswith(0): x = x[:len(x)-1] x = x[:-1] or del x[-1] both improve that one statement. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: New Python.org website ?
Stefan Rank [EMAIL PROTECTED] writes: on 11.01.2006 11:44 Steve Holden said the following: http://beta.python.org Very nice! Just wanted to note that the content area and the menu area overlap (leaving some content unreadable) in Opera 8.51 / WinXP Ditto for Opera 8.51 / OSX, and for Safari. It's a problem with not handling users who need large fonts. I recreated it in Mozilla by changing the minimum font size setting from None to 20 (just a value I chose at random). I use Opera and Safari on a day-to-day basis, and probably configured them appropriately for my aging eyes. Of course, this is typical on the web: Works in IE really means works in IE in the configurations we tested it for, and usually means works in our favorite configuration. In particular, creating a good-looking design that remains readable in all possible browser configurations is impossible. Getting one that is readable in all reasonable browser configurations is hard, unless you make your definition of reasonable very narrow. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-11, Mike Meyer schreef [EMAIL PROTECTED]: Antoon Pardon [EMAIL PROTECTED] writes: Op 2006-01-10, Mike Meyer schreef [EMAIL PROTECTED]: Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? I'm not going to bother with that. Since you're being vague about what you want, I would like some consistency. Either all comparisons between objects of different types throw an exception by default or none does. That's a very silly thing to ask for. It presumes that all types are the same. They aren't. It also presumes that all comparisons are the same. They aren't. To use an overworked analogy, you might as well ask that you either have to peel all fruit, or that you never have to peel a fruit. In any case, the proposeed behavior *is* consistent. The behavior for all builtin types will be that comparisons that don't make sense will throw exceptions. Since we're talking about Py3K here, there is no default behavior. User-defined classes all inherit from builtin types, and will get the behavior of their comparison operators from those types. In particular, those that inherit from object will get objects behavior, which means they'll get equality as identity. and won't provide examples to show why you want things to behave whatever way you want, I can't really say much else about it. Did you see examples that show why Guido wants things to behave whatever Guido's idea is a change from current behaviour. Each time I saw some argue a change here, people seem to expect a use case from that person. So why ask a use case of me and just accepy Guido's idea. For one thing, Guido has a long history of doing excellent Python design work. For another, this issue was thrashout out at length in comp.lang.python some years ago. What Guido proposed is inline with the conclusions of those discussions. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Scripts to logon to websites
BartlebyScrivener [EMAIL PROTECTED] writes: New to Python and Programming. Trying to make scripts that will open sites and automatically log me on. A common enough things to want to do. The following example is from the urllib2 module. What are realm and host in this example. Host is a domain name that can be mapped to a ip address. Realm is from HTTP authentication schemes. When the server asks for authentication, it gives out a realm name as well, so that different parts of the host can use different authentication systems. Does anyone have a simple example of a script that opens, say, gmail or some other commonly accessed site that requires a username and password so that I can see how one is made? Yes, but its not clear how much good it'll do you. As Peter indicated, not everyone uses HTTP based authentication. In fact, pretty much anyone who wants to control how the authentication boxes look (which seems to be 99% of the people writing web apps, never mind that they can't really do that) use something other than HTTP-based authentication. How you go about dealing with such sites depends on where they put the user name/login information,and how they encode the fact that you've authenticated as user . So I could show you my script for accessing yahoo. However, it probably won't work on another site without changes to accomodate the other site. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Scripts to logon to websites
Peter Hansen [EMAIL PROTECTED] writes: By the way, note that neither basic auth nor digest auth provide any real security, and in fact with basic auth the userid and password are sent *in cleartext*. For any serious production site these techniques should probably not be used without additional security measures in place, such as HTTPS encryption. To be clear, the HTTP authentication schemes don't provide any security for the *content* that gets passed back and forth, and they don't claim to. If someone can intercept that content, they can read it. For some applications, this is really important. For others, it doesn't matter at all. Basic auth doesn't (quite) pass the user name and password in cleartext. It uses rot-13. For all the protection it provides, it might as well be cleartext. Digest passes around md5 sums of varous bits and pieces. While md5 has been compromised, I don't believe that's happened in a way that compromises the security of digest auth. The password and username that pass over the wire are about as secure as they're going to get without noticably heavier mechanisms than digest auth requires. On the downside, the server has to have the clear text password available. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Steven Bethard [EMAIL PROTECTED] writes: Mike Meyer wrote: Steven Bethard writes: Not to advocate one way or the other, but how often do you use heterogeneous containers? Pretty much everything I do has heterogenous containers of some sort or another. Sorry, I should have been a little more specific. I meant heterogeneous containers where you've used the in operator. Fair enough. But the problem occurs with more than just the in operator. Anytime you want to do comparisons on objects in a heterogenous container, you have to deal with this. This includes other methods on the container, like list index and remove moethods. It also means that application-level code that does these kinds of things have to deal with the possible exceptions as non-exceptional occurences. Yeah, there's an easy fix. But it's ugly. SQL queries made to DP API compliant modules return homogenous lists of heterogenous containers. The cgi module turns the request string into a dictionary-like container of objects with values of different types. Are the keys of different types too? Because if the keys are all the same types, then using the in operator here wouldn't raise an exception. Unless, of course, you used the in operator on the .values() of the dictionary... Nope, not different keys. The canonical example of that would be the many memoize decorators. Note that *inserting* something into such a dictionary can cause problems, as if two objects hash to the same value, they get compared for equality. The last thing I did that was both more than a script and didn't use either a database or a web front end was (IIRC) a media player for multiple media types. It revolved around lists of things to play, and the things in question could be any playable object - video or audio files, track on a CD, or a DVD, or even a playlist. That seems pretty reasonable. Your code used the in operator with these lists? I don't really recall - it's been a while. I know I provided searching facillities, but don't recall if it did a search by doing object comparisons or not. Come to think of it, recursive data structures of this type - a container that contains a heterogenous list of things, possibly including instances of the container type itself - are pretty common. Sure. I have a number of tree-like containers, and in at least a few implementations, BranchNode and LeafNode are different classes. But I haven't needed the in operator with these. With the raise-exceptions-between-objects-of-different-types proposal, it would probably raise an exception if you tried, but I can't decide whether that's a good or a bad thing... Ugh. That's *ugly*. That means you have to do a complete pass over the data to figure out if two objects are different types or not so you can decide to raise the exception. Whether you want to make a seperate check the type pass or try doing equality tests at the same time will depend on the data. If you're checking a set of 10-million element lists, you *don't* want to check them all if you can avoid it. Either that, or make the results of the in operator (and related methods, etc.) depend on the comparison order. That might be acceptable for lists, but it's really not for sets or dictionaries. Actually, that's not sufficient to make the results reliable. If some objects are allowed to *not* throw exceptions and do equality-based-on-identity, then the results of a == b won't be the same as the results of b == a, so looking for a in a container that has b in it will give different results than looking for b in a container that has a in it. The other proposal - if I have it right - would not change the behavior of equality comparisons between objects of the same class, but would make comparisons between objects of different classes raise an exception instead of returning false by default. Perhaps, given duck-typing, a better proposal would be to raise an exception if the objects have different interfaces. Of course, at the moment, I can't think of any even vaguely efficient way of checking that. ;-) Yup. This *really* looks like trying to enforce static typing in a language that doesn't do anything like it now. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Scripts to logon to websites
Peter Hansen [EMAIL PROTECTED] writes: Mike Meyer wrote: Peter Hansen [EMAIL PROTECTED] writes: By the way, note that neither basic auth nor digest auth provide any real security, and in fact with basic auth the userid and password are sent *in cleartext*. For any serious production site these techniques should probably not be used without additional security measures in place, such as HTTPS encryption. To be clear, the HTTP authentication schemes don't provide any security for the *content* that gets passed back and forth, and they don't claim to. If someone can intercept that content, they can read it. For some applications, this is really important. For others, it doesn't matter at all. If someone can see the content, they can also see the userid and password. Only if the userid and password are part of the content. If you're doing the usual form-based authentication, then they are. If you're doing an HTTP-based authentication, then they aren't - the authentication information is in the headers, and can be protected however the protocol designers want it to be. Most people on the web are simply too ignorant of security issues for those of us building systems that require passwords to ignore this issue. To do so is to endanger the security and privacy of the very people you are hoping to have as users and customers, which is lazy and careless (and perhaps in some countries even criminal these days). Most of the people building systems that require passwords on the web are too ignorant of security issues for me to trust anything crucial to them. I don't bank online, because the banking systems I've looked at don't meet *my* minimal requirements for security. Digest passes around md5 sums of varous bits and pieces. While md5 has been compromised, I don't believe that's happened in a way that compromises the security of digest auth. The password and username that pass over the wire are about as secure as they're going to get without noticably heavier mechanisms than digest auth requires. On the downside, the server has to have the clear text password available. My information about digest was either obsolete or simply wrong, as I didn't realize it had all the nonce and anti-replay support it appears to have. (I may have been remembering articles about how much of that wasn't supported widely at some time in the past, meaning replays were still quite possible in most cases. No longer sure.) Thanks for the correction. Back when I was dealing with this on a regular basis, the major browser and server vendors were all pushing encrypted session mechanisms of various kinds. Given that, a secure authentication mechanism is a waste of time, and would provide competition for their product in some application domains. So those vendors typically didn't implement digest authentication. This sucked if you were exchanging content that didn't need security, but wanted to authenticate identity. In my own opinion, however, requiring that passwords be stored in clear text on the server is still quite a bad thing to do. I don't think even system administrators should ever have access to user passwords. But many people don't seem to agree (or at least, are more than happy to be lazy rather than diligent in protecting their users' privacy). Paul Rubin indicates that this isn't required - so my information is out of date as well. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to create a script that list itself ?
Tim Roberts [EMAIL PROTECTED] writes: It was pointed out to me that the shortest Python program which produces itself on stdout is: -- Which, oddly enough, is also the shortest shell program that produces itself on stdout. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. Maybe that is just a wrong implementation of the in operator. That's what I said just below: You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? But that is already a problem. Remember the thread about the Enum class which originally raised an exception when comparing values from different Enums. This would already cause such a problem. Yes, I remember. I also remember that it was eventually agreed that that Enum behavior was broken. There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Antoon Pardon [EMAIL PROTECTED] writes: There is no way in python now to throw an exception when you think comparing your object to some very different object is just meaningless and using such an object in a container that can be searched via the in operator. I claim that comparing for equality is *never* meaningless. Either two objects are equal, or they aren't. It may be that they are of different types - like the enum example above - in which case they will never compare equal. Note that this is different from an ordering. It's possible to have a pair of objects - maybe even of the same type - that can't be ordered in anyway. In this case, raising an exception when you try that comarison makes sense. IMO you have the choice between taking the mathematical route or the practical route. The behavior proposed for Py3k *is* the practical route. It gives a reasonable behavior, and one that leads to simple implemenations for container operations. Now you can take the practical option and decide that programmatically it make no sense to compare a specific couple of values and throw an exception in this case, but it doesn't matter much which test you are conducting at that point. Can you provide a case where having a test for equality throw an exception is actually useful? BTW, the case you're arguing for is *different* from the case the OP proposed. By my reading, he wanted equality testing to throw an exception for two objects unless a comparison was explicitly coded. So that even a == a could cause an exception. Maybe python should adopt both approaches and introduce a new family of comparators. Then one family will always succeed and the other family can throw an exception. Comparators - including equality comparators - can already throw exceptions. The enum case proved that. Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. But there are certainly circumstances that I would prefer 1 == (1,2) to throw an exception instead of simply turning up False. So what are they? Again - give us real use cases. I would say some more thinking is needed in this area. Now we can have weird circumstances where A == B and B == C but A != C. Nothing wierd about that at all. Anyone who's dealt with floats at all should be used to it. With floats that is entirely a problem of precision. When you are working with discrete types such circumstances remain weird. Floats *are* a discrete type. The equality *relationship* is what's fuzzy. There are lots of non-transitive relationships around. I don't find them wierd at all. I think such cases can be troublesome too for containers and the in operator. I don't. Can you provide an example of where it is? Well not with the in operator but with the index method of lists which seems related enough. The index method of list is already a bit fuzzy. If the in operator returns true one can use index to find out an element in the container that compares equal. Now normally it wouldn't make a difference whether you would make further comparisons against the original object or against the object in the list. But in this case it can make a difference and it isn't obvious what one should do. That's because in this case there's no on right answer. What you should do will depend on what you are trying to accomplish. That's the normal state of affairs when programming. IMO some more thinking about this is needed before deciding this would be a good idea or not. Actually, what's need are examples of usages where breaking equality into two (or more - most LISPs have three different definitions of equality) different relations is usefull. I think it is usefull because when I am looking for 1 in a list, I'm not necessarily happy when I find 1.0 or decimal(1). That's an argument for a more *precise* equality operator. That's certainly worth considering, but has nothing to do with whether or not it makes sense for an equality comparison to throw an exception. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
[EMAIL PROTECTED] writes: It seems to me that both Mike's and Fuzzyman's objections were that sometimes you want the current behaviour, of saying that two objects are equal if they are: 1. the same object or 2. have the same value (when it's meaningful). In both cases this can be accomplished pretty easily: You can do it with a try..except block, and you can write the try...except block inside the __contains__ method. (It's really pretty simple: try: return a == b except TypeError: return a is b ) This isn't easy. It's an ugly hack you have to use everytime you want to iterate through a heterogenous set doing equality tests. You're replacing false with an emphathetic false, that *all* containers to change for the worse to deal with it. Also, Mike said that you'll need an idlist object too - and I think he's right and that there's nothing wrong with it. Except that we now need four versions of internal data structures, instead of two: list, tuple, idlist, idtuple; set, idset, frozenset, frozenidset, and so on. What's wrong with this is that it's ugly. Note that while you can easily define the current == behaviour using the proposed behaviour, you can't define the proposed behaviour using the current behaviour. Yes you can, and it's even easy. All you have to do is use custom classes that raise an exception if they don't Also note that using the current behaviour, you can't easily treat objects that do define a meaningful value comparison, by identity. Yes you can. Just use the is operator. Note that this behavior also has the *highly* pecular behavior that a doesn't necessarily equal a by default. I will point out why your example usages aren't really usefull if you'll repeat your post with newlines. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
Steven Bethard [EMAIL PROTECTED] writes: Not to advocate one way or the other, but how often do you use heterogeneous containers? Pretty much everything I do has heterogenous containers of some sort or another. SQL queries made to DP API compliant modules return homogenous lists of heterogenous containers. The cgi module turns the request string into a dictionary-like container of objects with values of different types. Higher-level web interfaces go even further in this direction. The last thing I did that was both more than a script and didn't use either a database or a web front end was (IIRC) a media player for multiple media types. It revolved around lists of things to play, and the things in question could be any playable object - video or audio files, track on a CD, or a DVD, or even a playlist. Come to think of it, recursive data structures of this type - a container that contains a heterogenous list of things, possibly including instances of the container type itself - are pretty common. Pretty much every GUI package has something like it. All processors of SGML-based markup languages I've ever dealt with included something like it. MIME-encoded email does this. Page layout programs do this. Block-structured programming languages do this. And probably lots of others. These are things that in a language that used classes for carrying (and enforcing) type, all of these cases would be heterogenous lists of objects that were subtypes of some type, so maybe they would really be heterogenous. But then you're stuck with the interesting question: What's the type relationship between two objects a and b that allows them to be compared. This question is still interesting with duck typing. If anything, it's even more interesting. We have *at least two* different proposals for a different typing system in hand. For one, the answer is obvious. The OP proposed that equality only be allowed when the types explicitly allow it, instead of defaulting to typing by identity. In that one the answer is that all the types on the list have to boilerplate so they play together. Phrasing it that way makes it seem contrary to the spirit of Python, as not needing boilerplat is an oft-touted strength of Python. The other proposal - if I have it right - would not change the behavior of equality comparisons between objects of the same class, but would make comparisons between objects of different classes raise an exception instead of returning false by default. Since I didn't raise this proposal, I'll leave it up to someone else to explain under what conditions two objects that are both instances of some class are the same type or not. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: config errors on Freebsd and python 2.3
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Safeer Tabassum wrote: why you are not installing it from ports? The port distribution doesn't build to support Tkinter. Looks like they changed that recently - because it used to build it by default. Tkinter is now installed by x11-toolkits/py-tkinter. That's why I started building python from source. And since I'm building from source I can be more up-to-date then the ports distribution, and include pil, pmw, etc in the build. The current ports Python is 2.4.2. Do you have a newer version of Python? And pil/pmw and a lot of other things are already in the ports tree as separate ports. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newline at EOF Removal
Alex N [EMAIL PROTECTED] writes:
Peter gave me a good clue here
w.write(f.read().rstrip('\n') + '\n')
However the 2nd \n puts that empty line at the end of the file so I
No, it doesn't. Well, maybe it doesn't, depending on how your
applications treats newlines. Normally, a newline terminates a line,
so a file ending in ...some-alpha-text\n ends in a complete
line. Python agrees with this, as file.readlines won't return a list
with a final empty string in it if fed a file whose last character is
a newline.
tried it with just
w.write(f.read().rstrip('\n'))
and it works great!
This one ends in ...some-alpha-text. I'd say it ended in an
incomplete line, because the last line doesn't have a trailing
newline. My editor would agree - it warns me if I try and save a file
with an incomplete final line.
From what you've said, PHP apparently treats newlines as line
*separators*, not terminators. So a file that ends in a final newline
ends with a final blank line.
I suspect that part of your problem is trying to deal with the two
different views of what a newline does.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Spelling mistakes!
[EMAIL PROTECTED] writes: Terry But not faster than use a dict server! Why not just use (e.g.) Terry kdict? Maybe because not everybody has it? Sybren Lame excuse. If you don't have something but you do want to use Sybren it, you get it. I don't think I want it badly enough to figure out how to get it to work on my Mac. (I'm assuming the k prefix implies it's part of KDE.) I'm happy to continue googling for words I want defined. On the Mac, use Butler. I *can't* say enough good things about Butler on the Mac - it actually makes the UI bearable. For this case, I can search any of Google, Wikipedia or Websters online (both the dictionary and the thesarus) by typing the appropriate hotkey, the word, and the enter key. So not only does this make using google for spelling checking faster, it makes it equally easy to check an online dictionary. Butler comes preconfigured for either Webster or Dictionary.com, as well as Wikipedia and some specialty dictionaries, and it's trivial to add a search on any search engine that does a GET query. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Help with dynamic attributes.
Mr.Rech [EMAIL PROTECTED] writes: Hi all, I was writing a simple class when I get a strange error message that I can't understand. Hopefully someone could help me here. My class's init method takes a list of lists as input argument and I'd like to create several attributes each one referencing one item of the passed list. Why? You save all of two characters per reference over doing a simple self.x = list(self.lol) mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: testing units in a specific order?
Tim Peters [EMAIL PROTECTED] writes: They're run in alphabetical order, sorting on the test methods' names. For that reason some people name test methods like 'test_001', 'test_002', ..., although unit tests really shouldn't case which order they get run in. This seems sort of hard to do with good OO design. I.e. - I have some object foo with the requirement that foo.setup be run before foo.process. I typically do unit tests to run foo.setup first, and the test for foo.process assumes that foo.setup has been run. The alternative would have the setup for foo.process run foo.setup as part of the prep. But that assumes that foo.setup worked properly. To make sure of that, I still need the unit test for foo.setup to run before the test for foo.process. I supposed the test would be better if the test of foo.process didn't expect foo.setup to be run first. But in that case, if foo.setup fails, running foo.process is only moderatly interesting - a failure may be a cascade from the failure of setup, and passing the test may not mean it'll pass if setup actually finishes properly. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why keep identity-based equality comparison?
[EMAIL PROTECTED] writes: My question is, what reasons are left for leaving the current default equality operator for Py3K, not counting backwards-compatibility? (assume that you have idset and iddict, so explicitness' cost is only two characters, in Guido's example) Yes. Searching for items in heterogenous containers. With your change in place, the in operator becomes pretty much worthless on containers of heterogenous objects. Ditto for container methods that do searches for equal members. Whenever you compare two objects that don't have the same type, you'll get an exception and terminate the search. If the object your searching for would have been found later, you lose - you'll get the wrong answer. You could fix this by patching all the appropriate methods. But then how do you describe their behavior, without making some people expect that it will raise an exception if they pass it incomparable types? Also, every container type now has this split between identity and equality has to be dealt with for *every* container class. If you want identity comparisons on objects, you have to store them in an idlist for the in operator and index methods to work properly. I also think your basic idea is wrong. The expression x == y is intuitively False if x and y aren't comparable. I'd say breaking that is a bad thing. But if you don't break that, then having x == y raise an exception for user classes seems wrong. The comparison should be False unless they are the same object - which is exactly what equality based on id gives us. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Try Python update
[EMAIL PROTECTED] (Alex Martelli) writes: Mike Meyer [EMAIL PROTECTED] wrote: For some reason, I couldn't see the links at the end of the page; now I can, though they look sort of ragged, but, OK. Probably the fonts I chose. I'm in no way a good visual designer. I'm hoping someone who is will step up to help with this. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Returning Values from Bash Scripts
Jorgen Grahn [EMAIL PROTECTED] writes: On Sun, 08 Jan 2006 08:57:01 GMT, Tim Roberts [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: How to execute bash scripts from python (other than using os.popen) and get the values that those bash scripts return. Why would you eliminate os.popen? It is precisely the right way to do this. That's the same interface bash itself uses to execute scripts. That is, assuming by values you mean the stdout from the script. If you really mean the numerical return code, you can use os.system. And that's just one value, of course. And not a very useful one, either -- it's a non-negative integer, with a pretty low max value -- 255 on my machine. Unless you count the crash return codes. Further, os.system (and os.popen) pass the command through a shell, and actually gives you the return value from the shell instead of the command in question. Normally, these are the same thing. But if the shell fails to execute the command, they aren't - and there's no easy way to tell that that's what happened. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie with some doubts.
Jorgen Grahn [EMAIL PROTECTED] writes: On Sat, 07 Jan 2006 18:47:20 -0500, Mike Meyer [EMAIL PROTECTED] wrote: ... As far as I'm concerned, the definitive work in this area is Meyer's Object Oriented Software Construction. He covers pretty much all the uses of OO language features, using a language that was designed specifically to support those uses. Bjarne Stroustrup recommends it, but notes Tends to confuse Eiffel with universal principles. He does tend to write like the Eiffel way of doing OO is the only valid way of doing OO. Be warned that after reading it, you're liable to come back to Python and wonder Why doesn't Python do X. Meyer is too much of a fundamentalist for me, so much of the book just pisses me off. I expect that many Python programmers would feel the same way, Python being the way it is. I should note that Python isn't Eiffel is often a good answer to the questions Why doesn't Python do X that arise from that book. The design goals of Eiffel are different from the design goals of Python. I like the design goals of both languages, so I like both languages. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Try Python update
[EMAIL PROTECTED] (Alex Martelli) writes: I'm finding it hard to arrange my own experiments with Safari (I'm using a loaner machine since my normal one[s] are all having problems and under repair) but I'm told the solution for cursor positioning is to set the caretPos attribute of the textarea, like for example at http://www.codingforums.com/showthread.php?t=43245 ... caretPos is apparently an MS extension; it's not supported by Safari or the Gecko browsers. setSelectionRange is the standards-compliant version. It's not supported by Safari either :-(. Thanks, mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newline at EOF Removal
Alex Nordhus [EMAIL PROTECTED] writes: I am looking for a way to strip the blank line and the empty newline at the end of the text file. I can get the blank lines removed from the file but it always leaves the end line (which is blank) as a newline. My code is here and it works but leaves the newline at the end of the file. This really isn't a very clear description of the problem. Does your file end with two newlines in row? That would be what you'd get if it ended with the newline for the last line. If it ends with just one newline, then you're not getting the a blank last line, you're simply getting a last line that ends with a newline. How do I get rid of it? import re f = open(oldfile.txt) w = open(newfile.txt, wt) for line in f.readlines(): line = re.sub(r'^\s+$', '', line) w.write(line) This is an abuse of regular expressions (see http://www.mired.org/home/mwm/spare/ ); simple string methods can do this job for you. Try: for line in f: if line.strip(): w.write(line) mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
