Re: [Python-Dev] Extension to dl module to allow passing strings from native function
On 8/13/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Are you aware of the ctypes module? > > http://starship.python.net/crew/theller/ctypes/ I didn't know about ctypes, thanks for the pointer. It definitely has much more functionality (although it's more complex and a whole new module) than my little hack ;-) Regards, Senko -- Senko Rasic ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
[EMAIL PROTECTED] writes: > You don't need something like a buggy SWIG to put non-strings in dir(). > class C: pass > ... C.__dict__[3] = "bad wolf" dir(C) > [3, '__doc__', '__module__'] > > This is likely to happen "legitimately", for instance in a class that allows > x.y and x['y'] to mean the same thing. (if the user assigns to x[3]) I wonder if dir() should strip non-strings? Cheers, mwh -- A VoIP server "powered entirely by stabbing, that I made out of this gun I had"-- from Twisted.Quotes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Tim Peters <[EMAIL PROTECTED]> writes: > [Martin v. Löwis] >> I have placed a new version of the PEP on >> >> http://www.python.org/peps/pep-0347.html > > ... > > +1 from me. But, I don't think my vote should count much, and (sorry) > Guido's even less: what do the people who frequently check in want? > That means people like you (Martin), Michael, Raymond, Walter, Fred. > ... plus the release manager(s). I want svn, I think. I'm open to more sophisticated approaches but am not sure that any of them are really mature enough yet. Probably will be soon, but not soon enough to void the effort of moving to svn (IMHO). I'm not really a release manager these days, but if I was, I'd wand svn for that reason too. The third set of people who count are pydotorg admins. I'm not really one of those either at the moment. While SF's CVS setup has it's problems (occasional outages; it's only CVS) it's hard to beat what it costs us in sysadmin time: zero. > It would be best if svn:eol-style were set to native during initial > conversion from CVS, on all files not marked binary in CVS. Yes. Cheers, mwh -- I recompiled XFree 4.2 with gcc 3.2-beta-from-cvs with -O42 and -march-pentium4-800Mhz and I am sure that the MOUSE CURSOR is moving 5 % FASTER! -- from Twisted.Quotes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
On Tuesday 16 August 2005 21:42, Michael Hudson wrote: > I want svn, I think. I'm open to more sophisticated approaches but am > not sure that any of them are really mature enough yet. Probably will > be soon, but not soon enough to void the effort of moving to svn > (IMHO). > > I'm not really a release manager these days, but if I was, I'd wand > svn for that reason too. I _am_ a release manager these days, and I'm in favour of svn. I really want to be off CVS, and I would love to be able to go with something more sophisticated than svn. Unfortunately, I really don't think any of the alternatives are appropriate. While Perforce is definitely capable, the Bitkeeper disaster strongly influence me against relying on the generosity of a commercial software vendor who could change their mind at any time. The more radical (and powerful) tools such as baz/bzr, darcs, monotone and the like really aren't there yet. I have no doubt that they will get there, but right now, I want something better than CVS, and I don't want to have to fight bugs or limitations in the revision control system. By the way - if you're intending on suggesting alternates to svn, please don't just post a link saying "check out this system". Post an explanation of _why_ we should look at this particular system. What's it's strengths? Why should we invest the time to download it and play with it? Speaking for myself, I don't have the time or energy to spend trying the countless numbers of revision control systems that are out there. Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
On Tue, 2005-08-16 at 07:42, Michael Hudson wrote: > The third set of people who count are pydotorg admins. I'm not really > one of those either at the moment. While SF's CVS setup has it's > problems (occasional outages; it's only CVS) it's hard to beat what it > costs us in sysadmin time: zero. True, although because of the peculiarities of cvs, there have definitely been times I wish we had direct access to the repository. svn should make most of those reasons moot. As for sysadmin time with the changes proposed by the pep -- clearly they won't be zero, but I think the overhead for svn itself will be nearly so. With the fsfs backend, there's almost no continuous care and feeding needed, including for backups (which XS4ALL takes care of). The overhead for the admins will be in user management. I really don't think it will be that much more effort for new developers to badger the admins into adding them to some config file than it currently is to get one of us to click a few links to add you to the SF project. ;) (Okay, yeah we'll have to manage credentials now.) The alternatives to svn all sound very enticing, however my own feeling is that while the workflows they make possible might be good for Python in the long run, it's not clear how all that will evolve. We know that we can treat svn as "a better cvs" and the current workflow seems to serve us well enough. I'd be happy to switch to svn now, while continuing to experiment and follow the better scm systems for the future. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Barry Warsaw <[EMAIL PROTECTED]> writes: > On Tue, 2005-08-16 at 07:42, Michael Hudson wrote: > >> The third set of people who count are pydotorg admins. I'm not really >> one of those either at the moment. While SF's CVS setup has it's >> problems (occasional outages; it's only CVS) it's hard to beat what it >> costs us in sysadmin time: zero. > > True, although because of the peculiarities of cvs, there have > definitely been times I wish we had direct access to the repository. > svn should make most of those reasons moot. > > As for sysadmin time with the changes proposed by the pep -- clearly > they won't be zero, but I think the overhead for svn itself will be > nearly so. OK, that's more or less what I thought. [...] > I'd be happy to switch to svn now, while continuing to experiment > and follow the better scm systems for the future. I suppose another question is: when? Between 2.4.2 and 2.5a1 seems like a good opportunity. I guess the biggest job is collection of keys and associated admin? Cheers, mwh -- well, take it from an old hand: the only reason it would be easier to program in C is that you can't easily express complex problems in C, so you don't. -- Erik Naggum, comp.lang.lisp ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
On Tue, Aug 16, 2005 at 10:08:26PM +1000, Anthony Baxter wrote: > On Tuesday 16 August 2005 21:42, Michael Hudson wrote: > > I want svn, I think. I'm open to more sophisticated approaches but am > > not sure that any of them are really mature enough yet. Probably will > > be soon, but not soon enough to void the effort of moving to svn > > (IMHO). > > > > I'm not really a release manager these days, but if I was, I'd wand > > svn for that reason too. > > I _am_ a release manager these days, and I'm in favour of svn. I really > want to be off CVS, and I would love to be able to go with something > more sophisticated than svn. Unfortunately, I really don't think any of > the alternatives are appropriate. As a non-committer I can say _anything_ is preferable to the current situation and svn is good enough. bzr might make it even easier but svn is familiar and it will work right now. I haven't submitted a patch in ages partly because using anonymous SF cvs plain doesn't work. aside, at work we switched from cvs to svn and it the transition was easy for developers, svn lives up to its billing as a fixed cvs. -jack ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] implementation of copy standard lib
Hi, After profiling a small python script I found that approximately 50% of the runtime of my script was consumed by one line: "import copy". Another 15% was the startup of the interpreter, but that is OK for an interpreted language. The copy library is used by another library I am using for my scripts. Importing copy takes 5-10 times more time that import os, string and re together! I noticed that this lib is implemented in python, not in C. As I can imagine that *a lot* of libs/scripts use the copy library, I think it worthwhile to implement this lib in C. Unfortunately I cannot do this myself: I am relatively inexperienced with python and do not know C. What are your opinions? Martijn Brouwer -- __ I have a new e-mail adress. If you are still using [EMAIL PROTECTED], please change to [EMAIL PROTECTED] __ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] implementation of copy standard lib
On 8/14/05, Martijn Brouwer <[EMAIL PROTECTED]> wrote: > I noticed that this lib is implemented in python, not in C. As I can > imagine that *a lot* of libs/scripts use the copy library, I think it > worthwhile to implement this lib in C. > Unfortunately I cannot do this myself: I am relatively inexperienced > with python and do not know C. > > What are your opinions? I'll reply to this over on c.l.py, where it belongs. -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
On Aug 16, 2005, at 2:52 AM, Martin v. Löwis wrote: > Tim Peters wrote: > >> It would be best if svn:eol-style were set to native during initial >> conversion from CVS, on all files not marked binary in CVS. >> > > Ok, I'll add that to the PEP. Not sure how to implement it, yet... cvs2svn does that by default (now). James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] dev listinfo page (was: Re: Python + Ping)
On Friday 12 August 2005 05:05, David Wilson wrote: > Would it perhaps be an idea, given the number of users posting to the > dev list, to put a rather obvious warning on the listinfo page: Well, not exactly the style you suggested, but I've made it fairly close. It's certainly more noticable now. :-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
Michael Hudson wrote: > [EMAIL PROTECTED] writes: > >> You don't need something like a buggy SWIG to put non-strings in dir(). >> > class C: pass >> ... > C.__dict__[3] = "bad wolf" > dir(C) >> [3, '__doc__', '__module__'] >> >> This is likely to happen "legitimately", for instance in a class that allows >> x.y and x['y'] to mean the same thing. (if the user assigns to x[3]) > > I wonder if dir() should strip non-strings? Me too. And it would be a good idea, I think, to specify explicitly in the dir() docs this behavior. Right now at least rlcompleter and ipython's completer can break due to this, there may be other tools out there with similar problems. If it's a stated design goal that dir() can return non-strings, that's fine. I can filter them out in my completion code. I'd just like to know what the official stance on dir()'s return values is. Cheers, f ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
Guido van Rossum wrote: > (3) I think a better patch is to use str(word)[:n] instead of word[:n]. Mmh, I'm not so sure that's a good idea, as it leads to this: In [1]: class f: pass ...: In [2]: a=f() In [3]: a.__dict__[1] = 8 In [4]: a.x = 0 In [5]: a. a.1 a.x In [5]: a.1 File "", line 1 a.1 ^ SyntaxError: invalid syntax In general, foo.x named attribute access is only valid for strings to begin with (what about unicode in there?). Instead, this is what I've actually implemented in ipython: words = [w for w in dir(object) if isinstance(w, basestring)] That does allow unicode, I'm not sure if that's a good thing to do. Cheers, f ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
James Y Knight wrote: > cvs2svn does that by default (now). Ah, ok. Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Michael Hudson wrote: > I suppose another question is: when? Between 2.4.2 and 2.5a1 seems > like a good opportunity. I guess the biggest job is collection of > keys and associated admin? I would agree. However, there still is the debate of hosting the repository elsehwere. Some people (Anthony, Guido, Tim) would prefer to pay for it, instead of hosting it on svn.python.org. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
On Tue, Aug 16, 2005 at 08:31:20PM +0200, "Martin v. Löwis" wrote: > I would agree. However, there still is the debate of hosting the > repository elsehwere. Some people (Anthony, Guido, Tim) would prefer > to pay for it, instead of hosting it on svn.python.org. Another option would be to pay someone to maintain the SVN setup on python.org. Unfortunately, I guess that would require someone else to first create a detailed description of the maintenance work required and to process bids. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
On Tue, 2005-08-16 at 15:18, Neil Schemenauer wrote: > Another option would be to pay someone to maintain the SVN setup on > python.org. Unfortunately, I guess that would require someone else > to first create a detailed description of the maintenance work > required and to process bids. Again, it's not clear to me that there's much more we need to have done that we either don't want to do ourselves or that XS4ALL isn't doing for us. IOW, we get backups for free and mostly the repo just swims along nicely. We have to do user management, but I think we want to do that ourselves anyway. There may be occasional infrastructural work that needs to happen (e.g. we still owe Martin a login for tunneling), but those tasks seem to me to be better handled either by volunteers or by short-term paid piece work. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
[Michael Hudson] >> I suppose another question is: when? Between 2.4.2 and 2.5a1 seems >> like a good opportunity. I guess the biggest job is collection of >> keys and associated admin? [Martin v. Löwis] > I would agree. However, there still is the debate of hosting the > repository elsehwere. Some people (Anthony, Guido, Tim) would prefer > to pay for it, instead of hosting it on svn.python.org. Not this Tim. I _asked_ whether we had sufficient volunteer resource to host it on python.org, because I didn't know. Barry has since made sufficiently reassuring gurgles on that point, in particular that ongoing maintenance (after initial conversion) for filesystem-flavor SVN is likely in-the-noise level work. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Tim Peters wrote: > Not this Tim. I _asked_ whether we had sufficient volunteer resource > to host it on python.org, because I didn't know. Barry has since made > sufficiently reassuring gurgles on that point, in particular that > ongoing maintenance (after initial conversion) for filesystem-flavor > SVN is likely in-the-noise level work. Ah, ok. Of course, Barry can only speak about the current availability of volunteers, which is quite good (especially since amk took over coordinating them), nobody can predict the future (the time machine apparently only works one-way). So I guess the concern stays, and, more objectively, this is a risk for the project (but so is any specific commercial offering). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
[Tim] > +1 from me. But, I don't think my vote should count much, and (sorry) > Guido's even less: what do the people who frequently check in want? > That means people like you (Martin), Michael, Raymond, Walter, Fred. > ... plus the release manager(s). +1 from me. CVS is meeting my needs but I would definitely benefit from fast diffs and atomic commits. My experiences with SVN to-date have all been positive and it was easy to learn. Also, I think it is a nice plus that our choosing SVN means that others can choose SVK and get the benefits of a distributed rcs without us having to do anything extra to support it. James Knight's thoughts on the subject seem on target. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Neil Schemenauer wrote: > Another option would be to pay someone to maintain the SVN setup on > python.org. Unfortunately, I guess that would require someone else > to first create a detailed description of the maintenance work > required and to process bids. I think this would be difficult. I could imagine services like tummy.com, where you can hire somebody on an hours-per-week basis; these people maintain multiple servers, and just need to do the proper accounting. However, they also (naturally) tend to desire an organization that meets their needs also, e.g. by providing the machine and network (this is apparently how tummy.com operates). If you are suggesting that the PSF hires a specific individual for that maintenance, the risk of getting somebody unexperienced/uncooperative would be much higher: if we were unhappy with the tummy.com guy looking after our hardware, we could complain to his boss; if that is the boss, we would just take our data and cancel the contract. Also, hiring somebody would be somewhat unfair to people who do similar tasks as volunteers, and I guess the board might not agree to such expenses. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
[Martin v. Löwis] > Ah, ok. Of course, Barry can only speak about the current availability > of volunteers, which is quite good (especially since amk took over > coordinating them), nobody can predict the future (the time machine > apparently only works one-way). So I guess the concern stays, and, > more objectively, this is a risk for the project (but so is any > specific commercial offering). I'm not really worried about it. Sounds like ongoing pain is pretty much limited to keeping committer accounts/credentials up to date, and that normal good backup procedures will deal with filesystem-SVN state as a matter of course. If there's one thing sysadmins love to do, it's fiddling with user accounts and credentials -- if _anyone_ volunteers to work on python.org, they'll be eager to lord this power over us . If not, that's fine too. The PSF has the funds and the mission to pay for infrastructure support; I'd just _rather_ spend PSF funds on "more glamorous" stuff (like grants and conferences). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
[Raymond Hettinger] > +1 from me. CVS is meeting my needs but I would definitely benefit from > fast diffs and atomic commits. My experiences with SVN to-date have all > been positive and it was easy to learn. Good! That was my experience too, BTW -- SVN was a genuine improvement over CVS, and I was productive with it the first hour. There are "tricks" you'll learn too (or already have); for example, if you make a bunch of changes in a local checkout, and have to drop it for a while, it's easy and fast to create an SVN branch with those changes despite that you didn't plan on it from the start (create a new branch in the repository; `svn switch` to it locally, which leaves your local changes alone; then commit). > Also, I think it is a nice plus that our choosing SVN means that others > can choose SVK and get the benefits of a distributed rcs without us > having to do anything extra to support it. James Knight's thoughts on > the subject seem on target. Too new-fashioned for me, although I can see how it might appeal to kids ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Martin> Of course, Barry can only speak about the current availability Martin> of volunteers, which is quite good (especially since amk took Martin> over coordinating them) I don't know why, but the first image that popped into my mind was of amk beating a bunch of Hunchback of Notre Dame types (maybe more the Marty Feldman (*) hunchback types) into submission with a whip while one of them cried, "We'll do anything you ask, master. Just don't beat us again." The-beatings-will-continue-until-morale-improves-ly, y'rs, Skip (*) http://en.wikipedia.org/wiki/Marty_Feldman ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Tim Peters wrote: > [Martin v. Löwis] > >> I have placed a new version of the PEP on >> >> http://www.python.org/peps/pep-0347.html >> > > ... > > +1 from me. But, I don't think my vote should count much, and (sorry) > Guido's even less: what do the people who frequently check in want? > That means people like you (Martin), Michael, Raymond, Walter, Fred. > ... plus the release manager(s). +1 from me for various reasons: * Subversion seems to be stable enough, and it's better than CVS which is enough for me. * The python.org machines can probably handle the load of *one* repository better then the SF machines that of several thousands. * Connectivity to python.org is much better then to cvs.sf.net (at least from here). * Our company repository might move to svn in the near future, so a Python svn repository would be a perfect playground to learn svn. ;) Bye, Walter Dörwald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Tim Peters wrote: > [Martin v. Löwis] >> I would agree. However, there still is the debate of hosting the >> repository elsehwere. Some people (Anthony, Guido, Tim) would prefer >> to pay for it, instead of hosting it on svn.python.org. > > Not this Tim. Not this one either. I haven't actually used any of the various systems that much (work is ClearCase) so I have no opinions whatsoever. It's interesting reading though. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 347: Migration to Subversion
Nor this Guido, FWIW (I think we shouldn't rule it out as an option, but I don't have any preferences). On 8/16/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > Tim Peters wrote: > > > [Martin v. Löwis] > >> I would agree. However, there still is the debate of hosting the > >> repository elsehwere. Some people (Anthony, Guido, Tim) would prefer > >> to pay for it, instead of hosting it on svn.python.org. > > > > Not this Tim. > > Not this one either. I haven't actually used any of the various systems that > much (work is ClearCase) so I have no opinions whatsoever. It's interesting > reading though. > > Tim Delaney > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
[Michael Hudson] > I wonder if dir() should strip non-strings? -0 The behavior of dir() already a bit magical. Python is much simpler to comprehend if we have direct relationships like dir() and vars() corresponding as closely as possible to the object's dictionary. If someone injects non-strings into an attribute dictionary, why should dir() hide that fact? Likewise, we would have been better-off if ceval.c didn't pre-process data before handing it off to API functions (so that negative indices get handled the same way in operator module functions and in user defined methods, etc). Both Io and Lua have made a design principle out of keeping these relationships as direct as possible (i.e. a[b] always corresponds to the call a.__getitem__(b) with no intervening magic, etc.). The auto-exposure on my camera takes in nine data points and guesses whether the subject is backlit, whether there is a mix of light and dark, whether it is more important avoid blown highlights or to miss shadow detail, etc. The good news is that it often makes a decent guess. The bad news is that I've completely lost the ability to predict whether I've gotten a good shot based on the light conditions and camera settings. IOW, if you make the tools too smart, they become harder to use. Leica had it right all along. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] remote debugging with pdb
> One thing PDB needs is a mode that runs as a background thread and > opens up a socket so that another Python process can talk to it, for > embedded/remote/GUI debugging. There is a patch on SourceForge python.org/sf/721464 which allows pdb to read/write from/to arbitrary file objects. Would it answer some of your concerns (eg remote debugging)? The patch probably will not apply to the current code, but I guess, I could revive it if anyone thinks that it's worthwhile... What do you think? Ilya ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
