Re: [Python-Dev] I'm not getting email from SF when assigned a bug/patch
Martin v. Löwis wrote: > That isn't actually worth that much: somebody would need to operate it, > too. Mere existence doesn't help. why do you keep repeating this when I've already posted a link to a company that does this for only a few bucks per month ? ___ 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] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Tim Peters wrote: >> Author: walter.doerwald >> Date: Sat Apr 1 22:40:23 2006 >> New Revision: 43545 >> >> Modified: >>python/trunk/Doc/lib/libcalendar.tex >>python/trunk/Lib/calendar.py >> Log: >> Make firstweekday a simple attribute instead >> of hiding it behind a setter and a getter. > > Walter, what's the purpose of this patch? The first weekday is still an > attribute, but instead of being settable and > gettable via methods, looks like it's now settable and gettable via > module-global functions, and only for the single default > instance of Calendar created by the module. This is because in 2.4 there where no Calendar objects and firstweekday was only setable and getable via module level functions. > If so, then (a) the functionality of the Calendar class is weaker now, No really. firstweekday is changeable simply by assigning to the attribute: import calendar cal = calendar.Calendar() cal.firstweekday = 6 The only thing lost is the range check in the setter. > and in a > backward-incompatible way; Yes, this change is backwards-incompatible, but imcompatible to code that has been in the repository since Friday, so this shouldn't be a problem! ;) > and, > (b) the new > module-global firstweekday() and setfirstweekday() functions are a more > obscure way to restore the lost functionality for > just one > specific instance of a Calendar subclass. That's because in 2.4 the module level interface was all there was. > I don't see the attraction to any part of this. Simple attribute access looks much more Pythonic to me than setters and gettes (especially as the attributes of subclasses are simple attributes). Or are you talking about the Calendar class itself? > [...] 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] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
Walter Dörwald wrote: > firstweekday is changeable simply by assigning to the attribute: > > import calendar > cal = calendar.Calendar() > cal.firstweekday = 6 > > The only thing lost is the range check in the setter. Any particular reason for not making it a property? Then you could keep the range check while still manipulating it as if it was a simple attribute. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] I'm not getting email from SF when assigned a bug/patch
Fredrik Lundh wrote: >> That isn't actually worth that much: somebody would need to operate it, >> too. Mere existence doesn't help. > > why do you keep repeating this when I've already posted a link to a > company that does this for only a few bucks per month ? Because they don't do that. They won't import the Python SF data on their own: somebody has to tell them. Even then, they won't do that: somebody has to provide them with the data (if for no other reason that SF gives access only to project admins). If you are (still) talking about python-hosting.com: where on their website do they say that they will import SF data into trac when asked to? In short: somebody has to take charge, and make sure the thing is available. Maybe it is as simple as filing a support request, but somebody *still* has to do that (or else they won't guess that something is broken). I haven't heard anybody volunteering to do this specific job, working with this specific company. I don't volunteer to do that (I work with SF on issues with their tracker, but only because nobody else does, and because I believe these things need to be done). My impression of of python-hosting is that they provide the machine, and the initial setup. Then you are mostly on your own. 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
[Python-Dev] New uriparse.py
Announcing uriparse.py, submitted for inclusion in the standard library. Patch request 1462525. Per the original discussion at http://mail.python.org/pipermail/python-dev/2005-November/058301.html I'm submitting a library meant to deprecate the existing urlparse library. Questions and comments welcome. --pj ___ 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] Firefox searchbar engine for Python bugs
On 4/2/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Sunday 02 April 2006 14:17, Anthony Baxter wrote: > > I've created a searchbar plugin for the firefox search bar that > > allows you to search bugs. > > I should clarify - it allows you to pull up a bug by bug ID, using the > www.python.org/sf/ redirector. I just use a "Quick Search" item, keyword pysf, URL http://www.python.org/sf. I also have one with keyword "pep" and URL javascript:window.location=%22http://www.python.org/peps/pep-%22+%22%s%22.slice(-4)+%22.html%22 (the latter is a bit more fiddly to automatically pad a number to 4 digits, so I can write "pep 1" for example). Paul. ___ 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] I'm not getting email from SF when assignedabug/patch
Brett Cannon wrote: > > oh, I forgot that the Procrastination & Stop energy Foundation was involved > > in this. > Fredrik, if you would like to help move this all forward, great; I > would appreciate the help. You can write a page scraper to get the > data out of SF if you don't believe SF will cooperate fast enough for > your tastes or I am giving them too long to try to fix things on their > end (I don't expect they will fix things fast enough either, but > because of school ending soon I don't have time right now to start > working on a scraper myself plus I am willing to give them a little > time to try to fix the XML export so we can minimize headaches on our > end). here > > If you would rather contribute by collecting a list of possible > trackers along with who will maintain it, then please do. I am not > going to dive into that quite yet, but if you want to parallelize the > work needed then I would appreciate the help. The tracker will need > to be able to import the SF data somehow (probably will require a > custom tool so the volunteers need to be aware of this), be able to > export data (so we can back it up on a regular basis so we don't have > to go through this again), and an email interface for at least > replying to tracker items. A community-wide announcement will > probably be needed to get a good group of volunteers together for any > one non-commercial tracker. > > But I am not procrastinating. I don't think I have ever come off as a > procrastinator on this list and I don't think I deserve the label. I > am not putting more time in now because I am near the end of term here > at school and thus passing my courses takes precendent over a new bug > tracker. I ended up the chairman at the infrastructure committee > during one of my busiest school terms I have ever had. But I will see > this through and it will be done in a timely manner. > > -Brett > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org > ___ 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] I'm not getting email from SF when assigned a bug/patch
Brett Cannon wrote: > > oh, I forgot that the Procrastination & Stop energy Foundation was involved > > in this. > > Fredrik, if you would like to help move this all forward, great; I > would appreciate the help. You can write a page scraper to get the > data out of SF challenge accepted ;-) http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ contains three basic tools; getindex to grab index information from a python tracker, getpages to get "raw" xhtml versions of the item pages, and getfiles to get attached files. I'm currently downloading a tracker snapshot that could be useful for testing; it'll take a few more hours before all data are downloaded (provided that SF doesn't ban me, and I don't stumble upon more cases where a certain rhettinger has pasted binary gunk into an iso-8859-1 form ;-). $ python status.py tracker-105470 6681 items 1201 pages (17%) 104 files tracker-305470 3610 items 0 pages (0%) 0 files tracker-355470 430 items 430 pages (100%) 80 files the final step is to finish the "off-line scraper" library (a straightfor- ward ET hack), and make a snapshot archive available to interested parties. (drop me a line if you want a copy) > If you would rather contribute by collecting a list of possible > trackers along with who will maintain it, then please do. I am not > going to dive into that quite yet, but if you want to parallelize the > work needed then I would appreciate the help. that is what I expected the PSF infrastructure committee to do (I hope you're not the only one in that committee?); it's a bit disappointing to hear that we're still stuck on the SF export issue. (wasn't there someone with backchannel access to the SF data ?) > The tracker will need to be able to import the SF data somehow (probably will > require a > custom tool so the volunteers need to be aware of this), be able to > export data (so we can back it up on a regular basis so we don't have > to go through this again), and an email interface for at least > replying to tracker items. A community-wide announcement will > probably be needed to get a good group of volunteers together for any > one non-commercial tracker. > But I am not procrastinating. I don't think I have ever come off as a > procrastinator on this list and I don't think I deserve the label. I wasn't talking about individuals, I was referring to the trend where PSF moves something off a public forum, and the work just ends up going nowhere. ___ 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] Bug Day on Friday, 31st of March
Georg Brandl wrote: > it's time for the 7th Python Bug Day. The aim of the bug day is to close > as many bugs, patches and feature requests as possible, this time with a > special focus on new features that can still go into the upcoming 2.5 alpha > release. so, how did it go? a status report / summary would be nice, I think ? ___ 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] New uriparse.py
Paul Jimenez wrote: > Announcing uriparse.py, submitted for inclusion in the standard library. > Patch request 1462525. > Per the original discussion at > http://mail.python.org/pipermail/python-dev/2005-November/058301.html > I'm submitting a library meant to deprecate the > existing urlparse library. Questions and comments welcome. My initial reaction was "why is it necessary to break everything"? I then re-read the thread, and found this is all fine. However, this shows (to me) that there is a big lack of rationale in this contribution. You explained it as "urlparse breaks abstractions"; however, this didn't mean anything to me. Saying "urlparse doesn't comply with STD66 (aka RFC3986) because it hard-codes URI schemes, instead of applying the same syntax to all of them" is something I would have understood as a problem. So in short: are you willing to write documentation for this? The rationale section could either go into the urllib documentation (pointing out that particular problem, and referring to urilib as an improvement) 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] I'm not getting email from SF when assigneda bug/patch
Fredrik Lundh wrote: >> Yes. We found a way to export all data (except for file attachments), >> through a different exporter. This gives all data, unfortunately, it >> is ill-formed XML (& is not properly entity-referenced sometimes). > > so why didn't Brett know about this ? I'm not sure; I'm sure I mentioned it. 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] Saving the hash value of tuples
On 4/1/06, Noam Raphael <[EMAIL PROTECTED]> wrote: > I've found out that the hash value of tuples isn't saved after it's > calculated. With strings it's different: the hash value of a string is > calculated only on the first call to hash(string), and saved in the > structure for future use. Saving the value makes dict lookup of tuples > an operation with an amortized cost of O(1). Have you done any measurements to confirm that this makes any difference? I'm not particularly enamored of theoretical optimizations. This one in particular has a definite cost in space which needs to be weighed seriously. > Saving the hash value means that if an item of the tuple changes its > hash value, the hash value of the tuple won't be changed. I think it's > ok, since: > 1. Hash value of things shouldn't change. > 2. Dicts assume that too. Sure. (But you do realize that if a tuple contains a mutable value its hash value raises an exception, right?) > I tried the change, and it turned out that I had to change cPickle a > tiny bit: it uses a 2-tuple which is allocated when the module > initializes to lookup tuples in a dict. I changed it to properly use > PyTuple_New and Py_DECREF, and now the complete test suite passes. I > run test_cpickle before the change and after it, and it took the same > time (0.89 seconds on my computer). Not just cPickle. I believe enumerate() also reuses a tuple. > What do you think? I see three possibilities: > 1. Nothing should be done, everything is as it should be. > 2. The cPickle module should be changed to not abuse the tuple, but > there's no reason to add an extra word to the tuple structure and > break binary backwards compatibility. > 3. Both should be changed. I'm -1 on the change. Tuples are pretty fundamental in Python and hashing them is relatively rare. I think the extra required space for all tuples isn't worth the potential savings for some cases. -- --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] String formating in python 3000
Hi Crutcher,
We've created a separate list for discussing Python 3000.
http://mail.python.org/mailman/listinfo/python-3000
--Guido
On 4/2/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> Python currently supports 'S % X', where S is a strinng, and X is one of:
> * a sequence
> * a map
> * treated as (X,)
>
> But I have some questions about this for python 3000.
>
> 1. Shouldn't there be a format method, like S.format(), or S.fmt()?
>
> 2. What about using __call__ instead of / in addition to __rmod__?
> * "time: %s"(time.ctime()) == "time: %s" % time.ctime()
> * "%(a)s %(b)s"(a=1, b=2) == "%(a)s %(b)s" % {'a'=1, 'b'=2}
>
> --
> Crutcher Dunnavant <[EMAIL PROTECTED]>
> littlelanguages.com
> monket.samedi-studios.com
> ___
> 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] New uriparse.py
On Sun, 2 Apr 2006, "Martin v. Löwis" wrote: Paul Jimenez wrote: Announcing uriparse.py, submitted for inclusion in the standard library. Patch request 1462525. [...] abstractions"; however, this didn't mean anything to me. Saying "urlparse doesn't comply with STD66 (aka RFC3986) because it hard-codes URI schemes, instead of applying the same syntax to all of them" is something I would have understood as a problem. Evidently Paul quickly realised that back at the time of the original thread: hence the lack of posts from Paul protesting at Guido & Mike Brown's explanations, and the appearance now of this nice module :-) So in short: are you willing to write documentation for this? The rationale section could either go into the urllib documentation (pointing out that particular problem, and referring to urilib as an improvement) Currently of course we have both the functions in urllib, plus module urlparse. This module is roughly a replacement for urlparse. Probably if this module is accepted (after a few changes, no doubt) the urllib functions should then be deprecated (which would probably trigger adding a few more functions to the new module). I guess module urlparse would also be deprecated. I have a list of concrete and mostly easily-resolved problems with the module (including not liking the name). I also suspect there are issues related to unicode, %-encoding &c. exist which should be resolved before including this in the stdlib; I won't comment further on that until I've read the relevant RFCs. I've posted detailed comments on the tracker. John___ 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] String formating in python 3000
Yep, moved this there. On 4/2/06, Aahz <[EMAIL PROTECTED]> wrote: > On Sun, Apr 02, 2006, Crutcher Dunnavant wrote: > > > > But I have some questions about this for python 3000. > > Please use the python-3000 list for questions like this. > -- > Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ > > "Look, it's your affair if you want to play with five people, but don't > go calling it doubles." --John Cleese anticipates Usenet > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.com ___ 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] Bug Day on Friday, 31st of March
[/F] > so, how did it go? a status report / summary would be nice, I think ? http://wiki.python.org/moin/PythonBugDayStatus has been kept up to date. Note that, e.g., there are still open items in the "Bugs/patches to assess for commit" section, if you want to do more than just read. ___ 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] Bug Day on Friday, 31st of March
Tim Peters wrote: > [/F] >> so, how did it go? a status report / summary would be nice, I think ? 19 bugs, 9 patches (which were mostly created to fix one of the bugs). Not much, but better than nothing and there has been quite a participation from "newbies". > http://wiki.python.org/moin/PythonBugDayStatus > > has been kept up to date. Note that, e.g., there are still open items > in the "Bugs/patches to assess for commit" section, if you want to do > more than just read. BTW, Tim, thanks for coming. I'm often in a situation that I look at a patch and say, "yes, that's working, but I'm not sure whether to apply this" and need a yes or no from someone up the ranks. Cheers, Georg ___ 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] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
[Tim, gripes about ...]
>>> Author: walter.doerwald
>>> Date: Sat Apr 1 22:40:23 2006
>>> New Revision: 43545
>>>
>>> Modified:
>>>python/trunk/Doc/lib/libcalendar.tex
>>>python/trunk/Lib/calendar.py
>>> Log:
>>> Make firstweekday a simple attribute instead
>>> of hiding it behind a setter and a getter.
[Walter][
> This is because in 2.4 there where no Calendar objects and firstweekday was
> only setable and getable via module level functions.
I didn't realize that, of course . Skipping the rest ;-),
then, it would be best to make firstweekday a property on the new base
class.
> ...
> The only thing lost is the range check in the setter.
Which isn't a good thing to lose. It's not good that the current
Calendar constructor skips that sanity check either ("errors should
never pass silently").
> ...
> Simple attribute access looks much more Pythonic to me than setters and gettes
> (especially as the attributes of subclasses are simple attributes).
> Or are you talking about the Calendar class itself?
Yes, it would be best if Calendar had a property, so that sanity
checks were performed when setting `firstweekday`, and also if the
Calendar constructor performed that sanity check (which could happen
"by magic" if `firstweekday` were a property).
___
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] SF #1462485 - StopIteration raised in body of 'with' statement suppressed
Discovered this while playing around with the 2.5 released end of last
week.
Given:
@contextmanager
def gen():
print '__enter__'
yield
print '__exit__'
with gen():
raise StopIteration('body')
I would expect to get the StopIteration exception raised. Instead it's
suppressed by the @contextmanager decorator.
I think we should only suppress the exception if it's *not* the
exception passed into gen.throw() i.e. it's raised by the generator.
Does this sound like the correct behaviour? I've attached tests and a
fix implementing this to the bug report.
I can't confirm right now (at work, need to install 2.5) but I'm also
wondering what will happen if KeyboardInterrupt or SystemExit is raised
from inside the generator when it's being closed via __exit__. I suspect
a RuntimeError will be raised, whereas I think these should pass
through.
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] Saving the hash value of tuples
On 4/2/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I tried the change, and it turned out that I had to change cPickle a > > tiny bit: it uses a 2-tuple which is allocated when the module > > initializes to lookup tuples in a dict. I changed it to properly use > > PyTuple_New and Py_DECREF, and now the complete test suite passes. I > > run test_cpickle before the change and after it, and it took the same > > time (0.89 seconds on my computer). > > Not just cPickle. I believe enumerate() also reuses a tuple. Maybe it does, but I believe that it doesn't calculate the hash value of it - otherwise, the test suite would probably have failed. > > > What do you think? I see three possibilities: > > 1. Nothing should be done, everything is as it should be. > > 2. The cPickle module should be changed to not abuse the tuple, but > > there's no reason to add an extra word to the tuple structure and > > break binary backwards compatibility. > > 3. Both should be changed. > > I'm -1 on the change. Tuples are pretty fundamental in Python and > hashing them is relatively rare. I think the extra required space for > all tuples isn't worth the potential savings for some cases. That's fine with me. But what about option 2? Perhaps cPickle (and maybe enumerate) should properly discard their tuples, so that if someone in the future decides that saving the hash value is a good idea, he won't encounter strange bugs? At least in cPickle I didn't notice any loss of speed because of the change, and it's quite sensible, since there's a tuple-reuse mechanism anyway. Noam ___ 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] Bug Day on Friday, 31st of March
Georg Brandl wrote: > Tim Peters wrote: >> [/F] >>> so, how did it go? a status report / summary would be nice, I >>> think ? > > 19 bugs, 9 patches (which were mostly created to fix one of the bugs). > Not much, but better than nothing and there has been quite a > participation > from "newbies". I've just added 1462485 and 1462700 to be assessed for commit. So make that 11 patches (although technically not finished on the day :) 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] I'm not getting email from SF when assigned abug/patch
> > Fredrik, if you would like to help move this all forward, great; I > > would appreciate the help. You can write a page scraper to get the > > data out of SF > > challenge accepted ;-) > > http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ > > contains three basic tools; getindex to grab index information from a > python tracker, getpages to get "raw" xhtml versions of the item pages, > and getfiles to get attached files. > > I'm currently downloading a tracker snapshot that could be useful for > testing; it'll take a few more hours before all data are downloaded > (provided that SF doesn't ban me, and I don't stumble upon more > cases where a certain rhettinger has pasted binary gunk into an > iso-8859-1 form ;-). alright, it took my poor computer nearly eight hours to grab all the data, and some tracker items needed special treatment to work around some interesting SF bugs, but I've finally managed to download *all* items available via the SF tracker index, and *all* data files available via the item pages: tracker-105470 (bugs) 6682 items 6682 pages (100%) 1912 files tracker-305470 (patches) 3610 items 3610 pages (100%) 4663 files tracker-355470 (feature requests) 430 items 430 pages (100%) 80 files the complete data set is about 300 megabytes uncompressed, and ~85 megabytes zipped. the scripts are designed to make it easy to update the dataset; adding new items and files only takes a couple of minutes; refreshing the item information may take a few hours. ::: I've also added a basic "extract" module which parses the XHTML pages and the data files. this module can be used by import scripts, or be used to convert the dataset into other formats (e.g. a single XML file) for further processing. the source code is available via the above link; I'll post the ZIP file some- where tomorrow (drop me a line if you want the URL). ___ 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] I'm not getting email from SF when assigned a bug/patch
On 4/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: > > > > oh, I forgot that the Procrastination & Stop energy Foundation was > > > involved > > > in this. > > > > Fredrik, if you would like to help move this all forward, great; I > > would appreciate the help. You can write a page scraper to get the > > data out of SF > > challenge accepted ;-) > > http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ > > contains three basic tools; getindex to grab index information from a > python tracker, getpages to get "raw" xhtml versions of the item pages, > and getfiles to get attached files. > > I'm currently downloading a tracker snapshot that could be useful for > testing; it'll take a few more hours before all data are downloaded > (provided that SF doesn't ban me, and I don't stumble upon more > cases where a certain rhettinger has pasted binary gunk into an > iso-8859-1 form ;-). > > $ python status.py > tracker-105470 > 6681 items > 1201 pages (17%) > 104 files > tracker-305470 > 3610 items > 0 pages (0%) > 0 files > tracker-355470 > 430 items > 430 pages (100%) > 80 files > > the final step is to finish the "off-line scraper" library (a straightfor- > ward ET hack), and make a snapshot archive available to interested > parties. (drop me a line if you want a copy) > > > If you would rather contribute by collecting a list of possible > > trackers along with who will maintain it, then please do. I am not > > going to dive into that quite yet, but if you want to parallelize the > > work needed then I would appreciate the help. > > that is what I expected the PSF infrastructure committee to do (I hope > you're not the only one in that committee?); it's a bit disappointing to > hear that we're still stuck on the SF export issue. > The reason I didn't want to deal with the trackers quite yet was that I could see people getting the trackers up and squared away, and then just get frustrated when we were unable to get the SF data to them quickly. I didn't want other people stuck spinning there wheels waiting on us. -Brett > (wasn't there someone with backchannel access to the SF data ?) > > > The tracker will need to be able to import the SF data somehow (probably > > will require a > > custom tool so the volunteers need to be aware of this), be able to > > export data (so we can back it up on a regular basis so we don't have > > to go through this again), and an email interface for at least > > replying to tracker items. A community-wide announcement will > > probably be needed to get a good group of volunteers together for any > > one non-commercial tracker. > > > But I am not procrastinating. I don't think I have ever come off as a > > procrastinator on this list and I don't think I deserve the label. > > I wasn't talking about individuals, I was referring to the trend where > PSF moves something off a public forum, and the work just ends up > going nowhere. > > > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] I'm not getting email from SF when assigned abug/patch
On 4/2/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > > Fredrik, if you would like to help move this all forward, great; I > > > would appreciate the help. You can write a page scraper to get the > > > data out of SF > > > > challenge accepted ;-) > > Woohoo! > > http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ > > > > contains three basic tools; getindex to grab index information from a > > python tracker, getpages to get "raw" xhtml versions of the item pages, > > and getfiles to get attached files. > > > > I'm currently downloading a tracker snapshot that could be useful for > > testing; it'll take a few more hours before all data are downloaded > > (provided that SF doesn't ban me, and I don't stumble upon more > > cases where a certain rhettinger has pasted binary gunk into an > > iso-8859-1 form ;-). > > alright, it took my poor computer nearly eight hours to grab all the > data, and some tracker items needed special treatment to work around > some interesting SF bugs, but I've finally managed to download *all* > items available via the SF tracker index, and *all* data files available > via the item pages: > > tracker-105470 (bugs) > 6682 items > 6682 pages (100%) > 1912 files > tracker-305470 (patches) > 3610 items > 3610 pages (100%) > 4663 files > tracker-355470 (feature requests) > 430 items > 430 pages (100%) > 80 files > > the complete data set is about 300 megabytes uncompressed, and ~85 > megabytes zipped. > > the scripts are designed to make it easy to update the dataset; adding > new items and files only takes a couple of minutes; refreshing the item > information may take a few hours. > > ::: > > I've also added a basic "extract" module which parses the XHTML > pages and the data files. this module can be used by import scripts, > or be used to convert the dataset into other formats (e.g. a single > XML file) for further processing. > > the source code is available via the above link; I'll post the ZIP file some- > where tomorrow (drop me a line if you want the URL). > Wonderful, Fredrik! Thank you for doing this!When the data is available I will arrange to get it put on python.org somewhere and then start drafting the tracker announcement with where the data is and how to get at it. -Brett ___ 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] Whole bunch of test failures on OSX
On 4/2/06, Tim Peters <[EMAIL PROTECTED]> wrote: > > Does anyone else routinely use -R? If anyone does, do all the tests > pass for them? Yes and no. Every 12 hours, see Misc/build.sh For the latest results, see: http://docs.python.org/dev/results/make-test-refleak.out Several tests fail consistently with -R. These are the most recent from the link above: test_decimal test_difflib test_logging test_optparse test_warnings. It would be great if someone would figure out why these tests fail when running under -R and fix them. n ___ 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] Whole bunch of test failures on OSX
[EMAIL PROTECTED] > I'm not sure this is going to be all that helpful. If there's more I can do > to help track down these problems, let me know. Sure: you can do _everything_ to track them down ;-) > Last night I ran > > make test EXTRATESTOPTS='-R :: -uall -r' > > on my Mac laptop after a fresh svn up. I wasn't ready for how long that > would run! I never tried it (specifically the '-R ::' bit), but I see what you mean. Note that we have an OSX buildbot slave that passes all the trunk tests. Can you say whether make test EXTRATESTOPTS='-uall -r' (without '-R ::') also fails on your box? The point is to separate what's unique to your Mac box from what's unique to '-R ::'. > .. > And though it didn't list test_bsddb3 as a failure, it got a bunch of > DBLockDeadlockError exceptions. That one's almost a FAQ here -- all platforms see those from time to time, and have for years (especially when the box is heavily loaded). > ... > For test_decimal it printed: > > test test_decimal failed -- errors occurred; run in verbose mode for > details > > but when I ran test_decimal manually it ran fine. Did your manual run also include '-R ::'? When I run test_decimal in isolation on my Windows box with that option, it also fails here, on its second run: C:\Code\python\PCbuild>python_d -E -tt ../lib/test/regrtest.py -uall -R:: test_decimal test_decimal beginning 9 repetitions 123456789 test test_decimal failed -- errors occurred; run in verbose mode for details 1 test failed: test_decimal [29478 refs] > Same thing for test_warnings: > > test test_warnings failed -- errors occurred in > test.test_warnings.TestModule > > When I ran it manually it passed. With or without -R::? This one also fails for me in isolation with '-R ::', and also on its second run: C:\Code\python\PCbuild>python_d -E -tt ../lib/test/regrtest.py -uall -R:: test_warnings test_warnings beginning 9 repetitions 123456789 test test_warnings failed -- errors occurred in test.test_warnings.TestModule 1 test failed: test_warnings [15467 refs] Does anyone else routinely use -R? If anyone does, do all the tests pass for them? ___ 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] TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.
Now that the bug day has been and gone, it's time to cut 2.5a1. Please consider the trunk FROZEN from 00:00 UTC/GMT on Wednesday the 5th of April. I'll post again when it's unfrozen. Please help in not making the release manager cry because the trunk is broken. Thanks, Anthony ___ 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] String formating in python 3000
Python currently supports 'S % X', where S is a strinng, and X is one of:
* a sequence
* a map
* treated as (X,)
But I have some questions about this for python 3000.
1. Shouldn't there be a format method, like S.format(), or S.fmt()?
2. What about using __call__ instead of / in addition to __rmod__?
* "time: %s"(time.ctime()) == "time: %s" % time.ctime()
* "%(a)s %(b)s"(a=1, b=2) == "%(a)s %(b)s" % {'a'=1, 'b'=2}
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.com
___
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] Saving the hash value of tuples
>> I've found out that the hash value of tuples isn't saved after it's >> calculated. With strings it's different: the hash value of a string is >> calculated only on the first call to hash(string), and saved in the >> structure for future use. Saving the value makes dict lookup of tuples >> an operation with an amortized cost of O(1). >> [...] >> I will be happy to send a patch, if someone shows interest. > > Regardless of whether anyone shows interest, please submit a patch! Then > post the URL back here. That way if someone gets interested in the > future, your code is still available. FWIW, I think that is not a good idea. Guido shot it down for good reason. Once a patch is loaded, the question will continually resurface every few months and waste everyone's time re-hashing the issue. We have bigger dragons to slay. 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] I'm not getting email from SF when assigned a bug/patch
Fredrik Lundh wrote: >> If you would rather contribute by collecting a list of possible >> trackers along with who will maintain it, then please do. I am not >> going to dive into that quite yet, but if you want to parallelize the >> work needed then I would appreciate the help. > > that is what I expected the PSF infrastructure committee to do (I hope > you're not the only one in that committee?); it's a bit disappointing to > hear that we're still stuck on the SF export issue. > > (wasn't there someone with backchannel access to the SF data ?) Yes. We found a way to export all data (except for file attachments), through a different exporter. This gives all data, unfortunately, it is ill-formed XML (& is not properly entity-referenced sometimes). Anybody who wants to work with these data, please let me know; I made a snapshot a few days ago. The "backchannel access to SF data" was actually someone different: he experimented with the existing export, confirmed the problem, promised to talk to Paul Moore about that, and referred us to the other XML exporter as a work-around (that one allows to export 500 items at a time). 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
