Re: [Python-Dev] Failing tests: marshal, warnings
Greg Ward [EMAIL PROTECTED] writes: On 06 March 2005, I said: I'll check this in and merge to the trunk once I see all tests passing. Checked in on 2.4 branch. Not merged to trunk since Raymond hasn't merged his stuff to the trunk yet. I don't think that code is going onto HEAD. Cheers, mwh -- Our lecture theatre has just crashed. It will currently only silently display an unexplained line-drawing of a large dog accompanied by spookily flickering lights. -- Dan Sheppard, ucam.chat (from Owen Dunn's summary of the year) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal returning NotImplemented (or not)
Greg Ewing wrote: Is there some reason why Context couldn't invoke the binary operator methods using binary operators, rather than calling their methods directly? I had a similar idea, but then I remembered that the whole point of invoking the methods through a specific Context is to override the default context that the binary operators pick up. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
On Sun, 2005-03-06 at 14:16, Martin v. Löwis wrote: I don't know whether anybody has done this before, but I just tried to run cvs2svn on the Python repository. The conversion took 7 hours, and the result is now available at http://www.dcl.hpi.uni-potsdam.de/python/branches/ Because of the load that the conversion produces on the machine, I cannot run the entire conversion every day. Reportedly, cvs2svn is able to run in incremental mode, but I haven't tried this out yet. I personally have had no success doing this, but the last time I tried was with a fairly old version of svn. BTW, it looks like you just pulled in python/dist right? Did you pull in the trunk? What about nondist, or as Greg mentioned, distutils which is a sibling of the top-level python directory. - It has imported the CVSROOT directory as well. I don't know whether this is deliberate/useful. Almost certainly not useful. Even the diff checkin messages are generated with a much simpler script (owing largely to svn being designed to make this kind of thing possible without disgusting hacks). Anyway, this repository is now online for anonymous read-only access. Anybody interested in playing with it is welcome to do so. For those interested in server side issues: the repository is an 1.1.1 fsfs repository. The CVS repository consumes 368MiB; the SVN repository 797MiB. Just curious - why did you choose fsfs instead of the BerkeleyDB backend? Thanks for doing this Martin. I've heard that SF may be offering svn as early as May or June and I would love to see us convert when that's available. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
Barry Warsaw wrote: I personally have had no success doing this, but the last time I tried was with a fairly old version of svn. It gives an error message when you try. You then need to interpret the error message, retry, and it gives you another error message. You do this three times, and end up with the command line cvs2svn -q --fs-type=fsfs --encoding=latin1 --exclude=r16b1|cnri-16-start|descr-branch|release152p1-patches|after-call-reorg|r22a1|before-call-reorg|release16|r161|r161-branch|r16a2|release152p2 -s py.svn.new python BTW, it looks like you just pulled in python/dist right? Did you pull in the trunk? What about nondist, or as Greg mentioned, distutils which is a sibling of the top-level python directory. I posted the wrong URL. The right one is http://www.dcl.hpi.uni-potsdam.de/python/ It has distutils right in http://www.dcl.hpi.uni-potsdam.de/python/trunk/distutils/ Just curious - why did you choose fsfs instead of the BerkeleyDB backend? I had hoped that it would consume less disk space - but I really should try with bdb again. In our operational repositories, I have now migrated everything to fsfs because it is so much more friendly to backups. You can backup the on-disk state, and trust that is consistent. With bdb, you need to use hot-backup.py or some such, and this gives you an entire copy which then goes into all incremental backups. With fsfs, the incremental backups really pickup new commits only. (for the Python svn, it doesn't matter much, since that is excluded from backup, anyway) Thanks for doing this Martin. I've heard that SF may be offering svn as early as May or June and I would love to see us convert when that's available. So do I. However, I now believe that it is unlikely that SF will provide automatic conversion (or the automatic conversion will be useless/fail); instead, we likely need to provide our hand-tuned conversion. I'll keep collecting issues/complaints about this specific conversion, and try to integrate them if I can. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
Greg Ward wrote: Presumably for Python's repository, this would work: cvs2svn -s /home/svn/python /home/cvs/python/python ...except, umm, isn't distutils a separate top-level directory in the Python repository or something? Ok. Removing the CVSROOT before the conversion (from CVS) or after the conversion (from svn) would probably work. OTOH, I wonder whether the distutils CVS needs to be converted at all, or whether it would be sufficient to only migrate the python module (in which case your approach would be sufficient). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Urllib code or the docs appear wrong
It seems to me that either urllib's docs are wrong or its code is wrong
w.r.t. how the User-agent header is handled. In part, the docs say:
By default, the URLopener class sends a User-Agent: header of
urllib/VVV, where VVV is the urllib version number. Applications can
define their own User-Agent: header by subclassing URLopener or
FancyURLopener and setting the instance attribute version to an
appropriate string value before the open() method is called.
Looking at the code it seems to me that the User-agent header is fixed at
instantiation time:
version = Python-urllib/%s % __version__
# Constructor
def __init__(self, proxies=None, **x509):
...
self.addheaders = [('User-agent', self.version)]
...
and that when open_http() is called, it simply calls putheader() for each
element of addheaders. Setting the version instance attribute will have no
effect. If I managed to add another User-agent header before open_http()
was called, the request would wind up with two copies which is probably not
desirable either.
I can see a couple ways around this:
* Just change the docs to match the current implementation. Users
wishing to override the User-agent header would then have to subclass
FancyURLopener and set the version class attribute.
* Defer decisions about the value of the User-agent until open_http() is
called.
It appears the OpenerDirector class in urllib2 has a similar early binding
problem.
I don't particularly care how this is solved, but it appears to need
solving.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Documentation for __new__
Greg Ward wrote: On 05 March 2005, Nick Coghlan said: Steven Bethard has put together some text to add __new__ to the list of Basic Customisation methods in the language reference. Would one of the documentation folks care to take a look at it? I've tried to tighten up the text there and hopefully make it a smidgeon clearer and more accurate. Here's my best effort: __new__(cls[, ...]) Called to create a new instance of class 'cls'. __new__() is a static method (special-cased so you need not declare it as such) that takes the class to create an instance of as the first argument. The remaining arguments are those passed to the object constructor expression. The return value of __new__() should be the new object instance. Just to offer alternatives: __new__(cls[, ...]) __new__() is a static method (special-cased so you need not declare it as such) whose fist argumen is the class of which a new instance is required. The remaining arguments are those passed to the object constructor expression (the call to the class). The return value of __new__() should be the new instance object, which is not constrained to be of type 'cls'. Typical usage is to create a new instance of the class by invoking the superclass's __new__() method using super(currentclass, cls).__new__([...]) with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of 'cls', its __init__() will be invoked like __init__(self[, ...]), where the extra arguments are the same as were passed to __new__(). Typical usage creates a new instance of the required class by invoking the superclass's __new__() method using super(currentclass, cls).__new__(...) with appropriate argumnents and then modifying the newly- created instance as necessary before returning it. If __new__() returns an instance of 'cls' then the new instance's __init__() method will be called with the instance itself as the first argument and the remaining arguments being the second and subsequent arguments to __new__(). You do need not to return an instance of 'cls', but if you do not, the new instance's __init__() method will not be invoked. If __new__() does not return an instance of 'cls' then the new instance's __init__() method will not be invoked. __new__() is intended mainly to allow subclasses of immutable types (like int, str, or tuple) to customize instance creation. Feedback welcome. Has anyone volunteered to render this in LaTeX yet? If not, I might. Greg I decided some time ago that documenting Python in LaTex wasn't my forte ... regards Steve ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Documentation for __new__
On 07 March 2005, Steve Holden said: Just to offer alternatives: Cool, I liked some of your changes. I'm happy with this doc change. Will checkin Doc/ref/ref3.tex on 2.4 branch and merge to trunk shortly. Greg -- Greg Ward [EMAIL PROTECTED] http://www.gerg.ca/ What do you mean -- a European or an African swallow? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36
On 07 March 2005, Anthony Baxter said: Um, unless I misread this, you added new attributes to the ossaudiodev objects in the 2.4 branch. Please don't do this - this is a new feature, and suddenly people who want to use those new attributes have to either test for version = 2.4.1, or else do a hasattr test. Please see the bugfix PEP for more rationale on this... D'ohhh -- busted! My only excuse is that the lack of these attributes was originally filed as a bug report, and I suddenly realized oops! new attributes == feature request just as I was checking the change in on 2.4. I'll revert the change on 2.4 if you (or anyone) really wants me to. Otherwise, I'd rather leave it as-is and go fix more bugs. Greg -- Greg Ward [EMAIL PROTECTED] http://www.gerg.ca/ I don't believe there really IS a GAS SHORTAGE.. I think it's all just a BIG HOAX on the part of the plastic sign salesmen -- to sell more numbers!! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Migrating to subversion
On 07 March 2005, Martin v. Löwis said: OTOH, I wonder whether the distutils CVS needs to be converted at all, or whether it would be sufficient to only migrate the python module (in which case your approach would be sufficient). The last time I looked (late 2000), there was useful content in /distutils that was not in /python/dist/src/Lib/distutils. Greg -- Greg Ward [EMAIL PROTECTED] http://www.gerg.ca/ I can never remember how to spell mnemonic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Useful thread project for 2.5?
On 06 March 2005, Fazal Majid said: Since I started this, I might as well finish it. I do have some Python developer experience (hey, I even voted for comp.lang.python back when...) but not in the core interpreter itself. What would be *really* spiffy is to provide a way for externally-triggered thread dumps. This is one of my top two Java features [1]. The way this works in Java is a bit awkward -- kill -QUIT the Java process and it writes a traceback for every running thread to stdout -- but it works. Something similar ought to be possible for Python, although optional (because Python apps can handle signals themselves, unlike Java apps). It could be as simple as this: calling sys.enablethreaddump(signal=signal.SIGQUIT) from the program enables externally-triggered thread dumps via the specified signal. Greg [1] The other is compiler recognition of @deprecated in doc comments. -- Greg Ward [EMAIL PROTECTED] http://www.gerg.ca/ Think honk if you're a telepath. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36
On Mon, Mar 07, 2005, Greg Ward wrote: D'ohhh -- busted! My only excuse is that the lack of these attributes was originally filed as a bug report, and I suddenly realized oops! new attributes == feature request just as I was checking the change in on 2.4. I'll revert the change on 2.4 if you (or anyone) really wants me to. Otherwise, I'd rather leave it as-is and go fix more bugs. Please revert. I've spent more time than I'd like dealing with the introduction of booleans in Python 2.2, and helping other people avoid similar problems seems like a Good Thing to me. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Useful thread project for 2.5?
At 08:23 PM 3/7/05 -0500, Greg Ward wrote: On 06 March 2005, Fazal Majid said: Since I started this, I might as well finish it. I do have some Python developer experience (hey, I even voted for comp.lang.python back when...) but not in the core interpreter itself. What would be *really* spiffy is to provide a way for externally-triggered thread dumps. This is one of my top two Java features [1]. The way this works in Java is a bit awkward -- kill -QUIT the Java process and it writes a traceback for every running thread to stdout -- but it works. Something similar ought to be possible for Python, although optional (because Python apps can handle signals themselves, unlike Java apps). It could be as simple as this: calling sys.enablethreaddump(signal=signal.SIGQUIT) from the program enables externally-triggered thread dumps via the specified signal. Couldn't this just be done with traceback.print_stack(), given the _current_frames() facility? About the only real problem with it is that the other threads can keep running while you're trying to print the stack dumps. I suppose you could set the check interval really high and then restore it afterwards as a sneaky way of creating a critical section. Unfortunately, there's no getcheckinterval(). Which reminds me, btw, it would be nice while we're adding more execution control functions to have a way to get the current trace hook and profiling hook, not to mention ways to set them on non-current threads. You can do these things from C of course; I mean accessible as part of the Python API. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: Useful thread project for 2.5?
[Greg Ward] What would be *really* spiffy is to provide a way for externally-triggered thread dumps. This is one of my top two Java features [1]. The way this works in Java is a bit awkward -- kill -QUIT the Java process and it writes a traceback for every running thread to stdout -- but it works. Something similar ought to be possible for Python, although optional (because Python apps can handle signals themselves, unlike Java apps). It could be as simple as this: calling sys.enablethreaddump(signal=signal.SIGQUIT) from the program enables externally-triggered thread dumps via the specified signal. See the link in my original post to Florent's Zope deadlock debugger. Things like the above are easy enough to create _given_ a bit of C code in the core to build on. [Phillip J. Eby] Couldn't this just be done with traceback.print_stack(), given the _current_frames() facility? Right. About the only real problem with it is that the other threads can keep running while you're trying to print the stack dumps. I don't know that it matters. If you're debugging a deadlocked thread, its stack isn't going to change. If you're trying to find out where unexpected time is getting swallowed, statements in the offending loop(s) are still going to show up in the stack trace. I suppose you could set the check interval really high and then restore it afterwards as a sneaky way of creating a critical section. Unfortunately, there's no getcheckinterval(). sys.getcheckinterval() was added in Python 2.3. Which reminds me, btw, it would be nice while we're adding more execution control functions to have a way to get the current trace hook and profiling hook, not to mention ways to set them on non-current threads. You can do these things from C of course; I mean accessible as part of the Python API. Huh. It didn't remind me of those at all wink. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Modules ossaudiodev.c, 1.35, 1.36
On Tuesday 08 March 2005 12:14, Greg Ward wrote: D'ohhh -- busted! My only excuse is that the lack of these attributes was originally filed as a bug report, and I suddenly realized oops! new attributes == feature request just as I was checking the change in on 2.4. I'll revert the change on 2.4 if you (or anyone) really wants me to. Otherwise, I'd rather leave it as-is and go fix more bugs. I really would like to see it reverted, please. Thanks, Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
