Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On Wed, Mar 4, 2009 at 3:01 AM, Glenn Linderman wrote: > C'mon folks, brainstorm, don't complain about ordereddict if you can't come > up with some alternatives for discussion!!! (and some reasons why the > suggestions might be good or bad) Even your bad ideas might trigger a good > name in someone else's head... TemporalDict -- Since the order of insertion is important SerialDict -- From Websters: of, relating to, consisting of, or arranged in a series, rank, or row -- Benji York ___ 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] Doctest and Footnotes
A coworker of mine (Gary Poster) had a really good idea a couple weeks ago: teach doctest about ReST-style footnotes. I implemented it over the weekend and brought it to Tim Peter's attention today. Tim generally liked the idea and suggested I bring it up here. Here's the idea: when a footnote is referenced in prose, execute the code associated with the footnote at that point. For example: """ After initializing the system [#init]_ it is possible to retrieve status information: >>> system.status() 'good to go' [snip some of the doctest] .. [#init] Initialize the system: >>> system = System() >>> system.init() """ The footnote code is executed every time the footnote is referenced, and is /not/ executed at any other time (i.e. it's not executed at the point the footnote is defined). A warning is generated if a footnote (that includes code) is defined but never used. This would allow moving repetitive or verbose code (e.g. tests for corner cases) into footnotes so they won't hinder the documentation aspect of a test. It also allows defining reusable bits of setup code, freeing the doctest author to structure the prose as they wish instead of being constrained by having to place bits of code with common environmental needs together. I've implemented this in a branch of zope.testing (which contains a copy of a post-Python 2.4.3 version of doctest (http://tinyurl.com/nekam). The behavior is controlled by an optionflag, much like ELLIPSIS or NORMALIZE_WHITESPACE. Tim has given me a few pointers on improvements to make, which I'll work on this week. Thoughts/questions? -- Benji York Senior Software Engineer Zope Corporation ___ 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] Doctest and Footnotes
Phillip J. Eby wrote: > It would be nice if tracebacks in the footnote show the invoking context Yep. Someone (Jim Fulton I think) had suggested that to me. I'll look into it. > My other thought would be that having a patch that works against the 2.5 > version of doctest would be good My intent is to update zope.testing to the 2.5 version of doctest and generate a new patch against that. It would be even better if there were a stand-alone release of doctest instead, or (another Jim suggestion) if doctest were made extensible. I have another doctest/ReST idea I'd like to try some time (using ReST tables for FIT), so if there's interest perhaps I'll try my hand at a plugin system of some sort. (wish I could use zope.component :) -- Benji York ___ 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] Doctest and Footnotes
Alexander Belopolsky wrote: > Benji York zope.com> writes: >>Here's the idea: when a footnote is referenced in prose, execute the >>code associated with the footnote at that point. For example: >> > > Another natural place for the referenced code is the __test__ dictionary. > Using that has an advantage of not clobbering the display in the default > pydoc viewer. I'm not quite sure what you're suggesting. A guess: put the code that isn't to be seen in the __test__ dict with a string key being the name of the footnote? I don't think a ReST processor would like that much. It would see references to footnotes that are never defined. Or perhaps you're suggesting a non-ReST mechanism for the references? Also, for many of the use-cases we have, we do want the code in the test, just not in such a prominent place, and not repeated more than once. -- Benji York Senior Software Engineer Zope Corporation ___ 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] [wwwsearch-general] 2.5: recently introduced sgmllib regexp bug hangs Python
John J Lee wrote: > Looks like revision 47154 introduced a regexp that hangs Python Revision 47155 was a similar change to the 2.4 branch. -- Benji York Senior Software Engineer Zope Corporation ___ 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] [Python-3000] Warning for 2.6 and greater
Paul Moore wrote: > How many other projects/packages anticipate *not* migrating to Py3K, I wonder? I certainly can't speak for the project as a whole, but I anticipate a fair bit of work to port Zope 3 (100+ KLOC) to Python 3.0. -- Benji York ___ 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] [Python-checkins] buildbot failure in amd64 gentoo 2.5
Michael Hudson wrote: > Giovanni Bajo <[EMAIL PROTECTED]> writes: > >> On 23/01/2007 10.20, Brian Warner wrote: >> >>>>> Do I miss something here, or is the buildbot hit by spammers now? >>>> It looks like it is. If that continues, we have to disable the web >>>> triggers. >>> Good grief. If anyone has any bright ideas about simple ways to change that >>> form to make it less vulnerable to the spambots, I'd be happy to incorporate >>> them into Buildbot. >> I'd throw a CAPTCHA in. There are even some written in Python. > > I'd guess even the simplest thing would work: > > "Type "Python" into this box: __" The approach (outlined here http://damienkatz.net/2007/01/negative_captch.html) of having a hidden field that is "attractive" to spam bots, but hidden from humans would seem to be as effective without the (slight) annoyances of filling in an extra field every time. -- Benji York ___ 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] New syntax for 'dynamic' attribute access
Collin Winter wrote: > On 2/12/07, Brett Cannon <[EMAIL PROTECTED]> wrote: >> I actually kind of like that. The connection to pointer indirection >> meshes well with the idea of indirectly figuring out what attribute to >> access at runtime. > > There's a connection, but I'd say it's the wrong one. In C, "x->y" > dereferences x, while in Python, "x->y" would dereference y. That's > just begging for trouble. Then the syntax should obviously be "x<-y". [insert in-Soviet-Russia-variables-dereference-you joke here] -- Benji York ___ 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] PEP 30XZ: Simplified Parsing
Ron Adam wrote: > The following inconsistency still bothers me, but I suppose it's an edge > case that doesn't cause problems. > > >>> print r"hello world\" >File "", line 1 > print r"hello world\" > ^ > SyntaxError: EOL while scanning single-quoted string > In the first case, it's treated as a continuation character even though > it's not at the end of a physical line. So it gives an error. No, that is unrelated to line continuation. The \" is an escape sequence, therefore there is no double-quote to end the string literal. -- Benji York http://benjiyork.com ___ 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] [Python-3000] Documentation switch imminent
Georg Brandl wrote: > I put the CHM at <http://www.python.org/~gbrandl/pydoc.chm>, if you want > to have a look. Generally looks good. I did get this error when opening the CHM: """ A Runtime Error has occurred. Do you with to Debug? Line: 236 Error: Expected identifier, string or number """ Nothing happened when I clicked "Yes". The error is repeated each time a new page is opened. An additional opinion: The red, appear-on-hover permalink markers don't make much sense in a CHM and are somewhat distracting. Can those be hidden, perhaps via CSS? -- Benji York http://benjiyork.com ___ 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] [Python-3000] Documentation switch imminent
Georg Brandl wrote: > Okay, I uploaded a new version without JavaScript and with hidden permalink > markers. Very nice. I've compared this version and the 2.4 CHM a little and while mostly similar, there are several small improvements I appreciate. One other minor issue, when viewing the "random" module docs, it looks like two or more lines overlap in the footer (scroll all the way down). -- Benji York http://benjiyork.com ___ 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] Does Python need a file locking module (slightly higher level)?
Barry Warsaw wrote: > On Oct 22, 2007, at 8:15 AM, [EMAIL PROTECTED] wrote: > >> I'm always daunted by the prospect of trying to implement file >> locking. > If you want something like this, you might start by looking at > Mailman's LockFile.py. Also related is the very simple zc.lockfile: http://pypi.python.org/pypi/zc.lockfile -- Benji York http://benjiyork.com ___ 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] for loop with if filter
Gustavo Carneiro wrote: > I am finding myself often doing for loops over a subset of a list, like: > > for r in results: > if r.numNodes != numNodes: > continue > # do something with r > > It would be nice if the plain for loop was as flexible as list comprehensions > and allowed an optional if clause, like this: > > for r in results if r.numNodes == numNodes: > # do something with r You can do the same today, sans sugar: for r in (s for s in results if s.numNodes == numNodes): # do something with r -- Benji York http://benjiyork.com ___ 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] On quote styles
On Sat, May 10, 2008 at 10:51 PM, <[EMAIL PROTECTED]> wrote: > It might be useful to have a wiki page which identified some of the > conventions people use. One such entry could be "Do what python does.": >>> 'I am a string.' 'I am a string.' >>> "I'm a string" "I'm a string" -- Benji York ___ 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] Iterable String Redux (aka String ABC)
On Tue, May 27, 2008 at 3:42 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > [+python-3000] > > On Tue, May 27, 2008 at 12:32 PM, Armin Ronacher > <[EMAIL PROTECTED]> wrote: >> Basically *the* problematic situation with iterable strings is something like >> a `flatten` function that flattens out every iterable object except of >> strings. >> Imagine it's implemented in a way similar to that:: > > I'm not against this, but so far I've not been able to come up with a > good set of methods to endow the String ABC with. Another problem is > that not everybody draws the line in the same place -- how should > instances of bytes, bytearray, array.array, memoryview (buffer in 2.6) > be treated? Maybe the opposite approach would be more fruitful. Flattening is about removing nested "containers", so perhaps there should be an ABC that things like lists and tuples provide, but strings don't. No idea what that might be. -- Benji York ___ 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] multiprocessing source not "Unix clean"
On Fri, Jun 13, 2008 at 4:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Fri, Jun 13, 2008 at 1:09 PM, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: >> On Fri, Jun 13, 2008 at 3:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >>> On Fri, Jun 13, 2008 at 12:32 PM, Benjamin Peterson >>> <[EMAIL PROTECTED]> wrote: >>>> I've converted the line endings in the trunk and py3k. >>> >>> Thanks! Can we have a post-mortem of this? How did they get in there >>> in the first place without anybody noticing? >> >> svn cat tells me that they were CRLF when I initially imported them. I >> wonder if this has something to do with the patch utility I used to >> apply Jesse's patch. > > I'm guessing Jesse uploaded the patch from a Windows box. > > It would be good to have something in the toolchain to change this. Subversion can be configured to normalize line endings, either manually through properties, or automatically via ~/.subversion/config: [miscellany] enable-auto-props = yes [auto-props] *.c = svn:eol-style=native *.h = svn:eol-style=native etc. -- Benji York ___ 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] multiprocessing source not "Unix clean"
On Fri, Jun 13, 2008 at 4:28 PM, Benji York <[EMAIL PROTECTED]> wrote: > Subversion can be configured to normalize line endings, either manually > through properties, or automatically via ~/.subversion/config: After sending this I though "surely this is in the developer docs", and indeed it is: http://www.python.org/dev/faq/#what-configuration-settings-should-i-use -- Benji York ___ 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] Where is Fred Drake?
On Wed, Jan 21, 2009 at 6:39 PM, Aahz wrote: > Mail to fdr...@acm.org is bouncing; I don't know whether it's a > temporary failure. Does anyone have another address for him? /me channels Fred: Use freddr...@verizon.net until the acm.org account is back up. -- Benji York ___ 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] Merging PEP 310 and PEP 340-redux?
I think this is my first post to python-dev, so a mini-intro: I've
been lurking here for about 5 years, "professional" user a bit longer,
now working at Zope Corp.
Guido van Rossum wrote:
> Going for all-out simplicity, I would like to be able to write these examples:
>
> class locking:
> def __init__(self, lock): self.lock = lock
> def __enter__(self): self.lock.acquire()
> def __exit__(self, *args): self.lock.release()
>
> class opening:
> def __init__(self, filename): self.filename = filename
> def __enter__(self): self.f = open(self.filename); return self.f
> def __exit__(self, *args): self.f.close()
I've read the entire discussion, but may have missed this point, so,
correct me if I'm wrong. Wouldn't these semantics let "normal" objects
be used in a do. For example, if the file object had these methods:
def __enter__(self): return self
def __exit__(self, *args): self.close()
you could write
do file('whatever) as f:
lines = f.readlines()
Or a lock:
def __enter__(self): self.aquire(); return self
def __exit__(self, *args): self.release()
do my_lock:
a()
b()
c()
--
Benji York
Sr. Software Engineer
Zope Corporation
___
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] iter alternate form and *args and **kwargs (Was: Wishlist: dowhile)
Steven Bethard wrote:
> It reminds me of one of my minor gripes about the standard lib -- a
> number of functions that take another function as an argument don't
> take *args and **kwargs to be passed to that function when it's
> called. The iter() alternate form is a common example of this. I
> would prefer that the alternate iter() form was broken off into
> another separate function, say, iterfunc(), that would let me write
> Jp's solution something like:
>
> for chunk in iterfunc('', f1.read, CHUNK_SIZE):
> f2.write(chunk)
How about 2.5's "partial":
for chunk in iter(partial(f1.read, CHUNK_SIZE), ''):
f2.write(chunk)
--
Benji York
___
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] http://www.python.org/dev/doc/devel still available
Alexander Schremmer wrote: > In fact, PHP does it like php.net/functionname which is even shorter, i.e. > they fallback to the documentation if that path does not exist otherwise. Like many things PHP, that seems a bit too magical for my tastes. -- Benji York ___ 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] buildbot is all green
Neal Norwitz wrote: > http://www.python.org/dev/buildbot/ If there's interest in slightly nicer buildbot CSS (something like http://buildbot.zope.org/) I'd be glad to contribute. -- Benji York ___ 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] buildbot is all green
Martin v. Löwis wrote: > I personally don't care much about the visual look of web pages. > However, people have commented that the buildbot page is ugly, > so yes, please do contribute something. See http://www.benjiyork.com/pybb. It doesn't look quite as good in IE because of the limited HTML the buildbot waterfall display generates and the limitations of IE's CSS support. > Bonus points for visually separating the "trunk" columns from > the "2.4" columns. The best I could do without hacking buildbot was to highlight the trunk "builder" links. This only works in Firefox, also because of IE's limited CSS2 support. More could be done if the HTML generation was modified, but that didn't seem prudent. -- Benji York ___ 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] buildbot is all green
Walter Dörwald wrote: > I'd like to see vertical lines between the column. I've done a version like that (still at http://www.benjiyork.com/pybb). > Why is everything bold? I was trying to increase the legibility of the smaller type (a result of trying to fit more in the horizontal space). The current version is bold-free with slightly larger text. -- Benji York ___ 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] buildbot is all green
Martin v. Löwis wrote: > Benji York wrote: > >>See http://www.benjiyork.com/pybb. > > > Great! you haven't explicitly stated that: may I copy this on > python.org? (I did, but I need confirmation) Sure! Feel free to use it as you wish. I replied to Walter Dörwald's suggestions and made a few changes, but don't know which I like better. If you prefer the new one at http://www.benjiyork.com/pybb you can use it as well. (copying python-dev as a permanent record of permission) -- Benji York ___ 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] buildbot is all green
Guido van Rossum wrote: > FWIW, it looks like all the sample templates are still wasting a lot > of horizontal space in the first two columns the second is almost > always empty. Perhaps the author of the change could be placed *below* > the timestamp instead of next to it? Also for all practical purposes > we can probably get rid of the seconds in the timestamp. So far the cosmetic changes have been done purely in CSS, implementing the above would (AFAICT) require modifying the buildbot waterfall display HTML generation. Something that's been shied away from thus far. -- Benji York ___ 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] Switch to MS VC++ 2005 ?!
M.-A. Lemburg wrote: > Microsoft has recently released their express version of the Visual C++. > Given that this version is free for everyone, wouldn't it make sense > to ship Python 2.5 compiled with this version ?! > > http://msdn.microsoft.com/vstudio/express/default.aspx The express editions are only "free" until November 7th: http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx#pricing -- Benji York ___ 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] I'm not getting email from SF when assignedabug/patch
Wolfgang Langner wrote: > It is a Java system. Why promote Java solutions for python ? > I think there are good python solutions for a bug tracker and we > should prefer them. It is an application. Why worry about its implementation language? If there are good Python solutions they should be used, if not it's better to use something that works well regardless of what it's written in. (Not that I qualify to have an opinion. I don't have time to contribute to Python, other than with snarky emails.) -- Benji York ___ 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] 2.5a1 Performance
Realizing that early releases don't normally perform as well as final releases, I ran pystone for 2.5a1 and compared with 2.4.2 (what I had handy). 2.5a1 got slightly more than 30k, while 2.4.2 gets slightly more than 35k (1.4 GHz, Pentium M, 1 Meg L2 cache). I also ran a large test suite for a project with both 2.5a1 and 2.4.2 and got nearly identical times. I haven't seen general performance mentioned here lately, so I thought I'd share those numbers. On a related note: it might be nice to put a pystone run in the buildbot so it'd be easier to compare pystones across different releases, different architectures, and between particular changes to the code. (That's assuming that the machines are otherwise idle, though.) -- Benji York ___ 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] 2.5a1 Performance
Martin v. Löwis wrote: > What operating system and compiler? Oops, should have included that: Ubuntu Breezy, Kernel 2.6.12-10-686 GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) > It won't do it across different > releases, because we don't have Python binaries for each release > available on each slave. I was thinking of "active" branches that there are buildbot slaves dedicated to (2.4 at the moment) and the trunk, but (as I mentioned) non-idleness pretty much kills that idea. I wonder if the slaves that are known to be dedicated to running buildbot and nothing else could be flagged as such. -- Benji York ___ 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] 2.5a1 Performance
Neal Norwitz wrote: > 32-bit or 64-bit? I would expect a modest diff on 64-bit between 2.4 and 2.5. 32-bit; don't know of any 64-bit Pentium Ms :) > You built both HEAD and 2.4 from scratch, right? Right. -- Benji York ___ 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] 2.5a1 Performance
Jeff Epler wrote: > I'm not trivially able to try a 32-bit build, but for my system it > appears that 2.5 is moderately faster than 2.4 when built with all the > defaults. OK, this prompted me to question my sanity. Being on a laptop the default is to do frequency scaling (different speeds depending on CPU load). When running pystone I've always seen an initial run that was much slower than subsequent runs, so I'd run several and throw out the first few. This gives a max of 35k pystones with 2.4.2 and 30k with 2.5a1. I decided to force the CPU freq. to the maximum (1.4 GHz) and remeasure. 2.5a1 reported the same pystones (30k) and, to my surprise, 2.4 reported 31k (about 5k *less* than with freq. scaling on). So there seems to be some interaction between frequency scaling and pystones. Benchmarking is hard, let's go shopping! -- Benji York ___ 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] Dropping __init__.py requirement for subpackages
Guido van Rossum wrote: > So I have a very simple proposal: keep the __init__.py requirement for > top-level pacakages, but drop it for subpackages. So this would mean that current non-package subdirectories in a package (that contain things like data files or configuration info) would become packages with no modules in them? sharpening-my-farm-implements-ly y'rs, -- Benji York ___ 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] Positional-only Arguments
I've not followed the PEP 3102 (keyword-only arguments) discussion closely enough to know if this has been mentioned, but we were discussing a need at work today for the ability to enforce position-only arguments. The specific instance was an argument that was intended to be used as a positional argument which a group had began using as a keyword argument instead. There was no way for the users to know it was intended for positional use only. And it makes refactoring the signature difficult. Of course you could use *args from the get-go, but ugly signatures as default isn't nice. Is there any reason to pursue the idea, or this mostly a misguided desire for symmetry? -- Benji York ___ 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] Positional-only Arguments
Terry Reedy wrote: > You could discourage name use by not documenting the actual, internal name > of the parameters. The issue we had was that the name wasn't documented at all, the users simply looked at the code and began using the keyword name. This may well be an area where "we're all adults here" wins. OTOH there is a /slight/ possibility that it'd be better to disallow using an argument as a keyword unless explicitly flagged as such. Similar to how the C API works now. This has the same advantages of the keyword-only PEP (3102): tools will know which arguments are positional and which are keyword. Doing so would recast PEP 3102 from "how to get a keyword-only argument" into "how to get a keyword (non-positional) argument". A downside would be the need to specify when an argument can be positional *or* keyword. -- Benji York ___ 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] Positional-only Arguments
Guido van Rossum wrote: > I've used a double leading underscore on the name. Works great for methods! We discussed that. My main issue with that is that it's possible/likely that all arguments should be positional by default, should they all then begin with underscores? Makes for ugly function bodies (or lots of name rebinding). -- Benji York ___ 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] Python sprint mechanics
Paul Moore wrote: > Is it possible to create a branch in the main Python svn, and grant > commit privs to that branch only, for sprint participants? I'm not familiar with the mechanics, recent versions of Subversion allow per-directory security. We do this to give some customers read access to parts of the repo, and read-write to others. It shouldn't be difficult (given a recent enough Subversion) to set up a sprint area in the repo. -- Benji York ___ 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] lambda in Python
Ian D. Bollinger wrote: > I'm not sure Xah is so much a troll as he is completely out of his > mind. Is that Bollinger's law? Any sufficiently advanced insanity is indistinguishable from trolling. -- Benji York ___ 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] Python sprint mechanics
Martin v. Löwis wrote: > Benji York wrote: > >>I'm not familiar with the mechanics, recent versions of Subversion allow >>per-directory security. > > It works fine for http(s), but not for svn+ssh. Versions prior to 1.3 could use Apache's authorization system. Subversion 1.3 added a path-based authorization feature to svnserve. -- Benji York ___ 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] Python sprint mechanics
Martin v. Löwis wrote: > Benji York wrote: >>Subversion 1.3 added a path-based authorization feature to svnserve. > > That's what I mean by "does not work fine": I would need to update > to subversion 1.3. I noted that in my original message. I thought you meant that it wasn't possible at all with svnserve. A simple misunderstanding. -- Benji York ___ 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] fixing buildbots
Neal Norwitz wrote: > I can > understand why we wouldn't want to unconditionally overwrite a user's > modified Setup. However, for the buildbots, it seems safer to always > overwrite it. FWIW, with the buildbots I run, I use "clobber" mode, with which the entire build directory is removed and rebuilt on each run. It slows things down a bit, but the results have been more consistent and it's easier to administer. -- Benji York ___ 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] Code coverage reporting.
Brett Cannon wrote: > But it does seem accurate; random checking of some modules that got high > but not perfect covereage all seem to be instances where dependency > injection would be required to get the tests to work since they were > based on platform-specific things. > I don't know if we need it hooked into the buildbots (unless it is dirt > cheap to generate the report). It would be interesting to combine the coverage over several platforms and report that. -- Benji York ___ 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] Code coverage reporting.
Brett Cannon wrote: > Ah, do the union of the coverage! Yeah, that would be nice and give the > most accurate coverage data in terms of what is actually being tested. > But as Titus says in another email, question is how to get that data > sent back to be correlated against. It might be interesting as a BuilBot extension: you already know the definitive identity of the thing that you're running (svn path and revision), a central server with established communication channel, plus all the other BuildBot machinery. -- Benji York ___ 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] Switch statement
Delaney, Timothy (Tim) wrote:
> Guido van Rossum wrote:
>
>
>>I wonder if there should be two default clauses, or some other
>>syntactic way to indicate whether we expect all x to be hashable?
>
>
> switch expr:
> case 1:
> statements
> case 2:
> statements
> else:
> statements
> except KeyError:
> statements
> finally:
> statements
Small variation:
switch expr:
case 1:
statements
case 2:
statements
else:
statements
except:
statements
--
Benji York
___
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] ImportWarning flood
Nick Coghlan wrote: > Perhaps ImportWarning should default to being ignored, the same way > PendingDeprecationWarning does? > > Then -Wd would become 'the one obvious way' to debug import problems +1 -- Benji York ___ 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] ImportWarning flood
Michael Hudson wrote: > Benji York <[EMAIL PROTECTED]> writes: > >>Nick Coghlan wrote: >> >>>Perhaps ImportWarning should default to being ignored, the same way >>>PendingDeprecationWarning does? >>> >>>Then -Wd would become 'the one obvious way' to debug import problems >> >>+1 > > I'm not sure what this would achieve I'm more concerned with what it shouldn't achieve (changing the rules in an annoying and disruptive way). > The more I think about it, the more I like the idea of saying > something when an import fails only because of a missing __init__.py > file. I totally agree! I just doubted that approach would be appealing [to Guido] when the choice of adding warnings had already been made. -- Benji York ___ 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] For sandboxing: alternative to crippling file()
A.M. Kuchling wrote: > This thought was sparked by the piece on failure-oblivious computing > in today's Linux Weekly News about this paper: > http://www.usenix.org/events/osdi04/tech/rinard.html. The paper is also available from one of the authors at http://www.cag.lcs.mit.edu/~rinard/paper/osdi04.pdf -- Benji York ___ 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] PEP: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: > Donovan Baarda wrote: >>What this means is SVN has no way of automatically identifying the >>common version. > If this is too painful, you can probably use subversion to store > the relevant information. For example, you could define a custom > property on the directory A script named "svnmerge" that does just that is included in the contrib directory of the Subversion tar. We (ZC) have just started using it to track two-way merge operations, but I don't have much experience with it personally yet. -- Benji York ___ 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] Fwd: Distributed RCS
Martin v. Löwis wrote: > [EMAIL PROTECTED] wrote: >>Granted. What is the cost of waiting a bit longer to see if it (or >>something else) gets more usable and would hit the mark better than svn? > > It depends on what "a bit" is. Waiting a month would be fine; waiting > two years might be pointless. This might be too convoluted to consider, but I thought I might throw it out there. We use svn for our repositories, but I've taken to also using bzr so I can do local commits and reversions (within a particular svn reversion). I can imagine expanding that usage to sharing branches and such via bzr (or mercurial, which looks great), but keeping the trunk in svn. -- Benji York ___ 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] Proof of the pudding: str.partition()
Raymond Hettinger wrote:
> [Fredrik Lundh]
>
>>it is, however, a bit worrying that you end up ignoring one or more
>>of the values in about 50% of your examples...
>
> It drops to about 25% when you skip the ones that don't care about the
> found/not-found field:
>
>>>! _, sep, port = host.partition(':')
>>>! head, sep, _ = path.rpartition('/')
>>>! line, _, _ = line.partition(';') # strip
>>>! pname, found, _ = pname.rpartition('.')
>>>! line, _, _ = line.partition('#')
>>>! filename, _, _ = filename.partition(chr(0))
I know it's been discussed in the past, but this makes me wonder about
language support for "dummy" or "don't care" placeholders for tuple
unpacking. Would the above cases benefit from that, or (as has been
suggested in the past) should slicing be used instead?
Original:
_, sep, port = host.partition(':')
head, sep, _ = path.rpartition('/')
line, _, _ = line.partition(';')
pname, found, _ = pname.rpartition('.')
line, _, _ = line.partition('#')
Slicing:
sep, port = host.partition(':')[1:]
head, sep = path.rpartition('/')[:2]
line = line.partition(';')[0]
pname, found = pname.rpartition('.')[:2]
line = line.partition('#')[0]
I think I like the original better, but can't use "_" in my code because
it's used for internationalization.
--
Benji York
___
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] Active Objects in Python
Phillip J. Eby wrote: > Well, you could pickle and unpickle the objects you send from one function > to another, and for cross-process communication, you'll need to do > something like that anyway, or else use that shared-memory objects > thing. PySHM? I don't remember its name, but it's an extension that lets > you store Python objects in shared memory and use them from multiple > processes, modulo certain strict limitations. "POSH": http://poshmodule.sourceforge.net/posh/html/ -- Benji York ___ 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] locale and LC_NUMERIC
Fredrik Lundh wrote: > my rationale for running the tests with a non-US locale was to increase > the chance of catching bugs where the external locale setting affects > Python's behaviour. > > maybe it would be a good idea to add a "use setlocale" flag to the test- > runner ? Sounds like a good use for buildbot. After running the tests "normally" they could be re-run with a different locale. -- Benji York ___ 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
