Re: [Python-Dev] PEP 3144 review, and the inclusion process

2009-09-27 Thread Antoine Pitrou
Peter Moody hda3.com> writes: > > I've never said otherwise. In fact, from an email last night, "If what > the community requires is the library you've described, then ipaddr is > not that library." The changes *you* require make ipaddr significantly > less useful to me. I'm not prepared to make

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

2009-09-27 Thread Antoine Pitrou
Hello, I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. Regards Antoine. ___ Python-Dev m

Re: [Python-Dev] PEP 3144 review.

2009-09-27 Thread Antoine Pitrou
Martin v. Löwis v.loewis.de> writes: > > > Could you explain what benefit there is for allowing the user to create > > network objects that don't represent networks? Is there a use-case > > where these networks-that-aren't-networks are something other than a > > typo? Under what circumstances

Re: [Python-Dev] PEP 3144 review.

2009-09-28 Thread Antoine Pitrou
Dj Gilcrease gmail.com> writes: > > >>> net1 = IPNetwork("10.1.2.3/24") > >>> net2 = IPNetwork("10.1.2.0/24") > >>> print hash(net1) == hash(net2) > False > >>> print net1 == net2 > True Ouch :-) It is very bad practice for equal objects to hash differently. Differing hashes are supposed to impl

Re: [Python-Dev] PEP 3144 review, and the inclusion process

2009-09-28 Thread Antoine Pitrou
Guido van Rossum python.org> writes: > > At the same time I don't think a complete reset of the proposed API is > necessary. I am rather more thinking of judicious API tweaks in order > to cover some new use cases, without requiring a complete rewrite or > destroying the usability of the proposa

Re: [Python-Dev] PEP 3144 review.

2009-09-28 Thread Antoine Pitrou
> Unfortunately, that would mean that we should provide two comparison > operations, and have neither available as == (unless one is more clearly > right than the other, which I'm skeptical about). That's probably why some people have argued to have two separate classes for the case of "networks"

Re: [Python-Dev] PEP 3144 review.

2009-09-28 Thread Antoine Pitrou
Martin v. Löwis v.loewis.de> writes: > > Still, people proposing that 192.168.1.1/24 should be rejected (I still > don't know whether anybody is actually proposing that) *have* to provide > a proposal how this should be input instead. It was proposed to have a dedicated function or class method

Re: [Python-Dev] PEP 3144 review.

2009-09-28 Thread Antoine Pitrou
Le lundi 28 septembre 2009 à 22:11 +0200, "Martin v. Löwis" a écrit : > > That's not the question that was asked, though - the question asked > was "Under what circumstances would I want to specify...". I hope > most people agree that it is desirable to be able to specify a network > not just by i

Re: [Python-Dev] PEP 389: argparse - optparse compatibility

2009-09-28 Thread Antoine Pitrou
Steven Bethard gmail.com> writes: > > I could conceivably add an OptionParser class which:: > [...] Actually, I think that would be a waste of time. It would be less time-consuming to keep optparse.py than write a whole new compatibility bridge that you'll have to debug and maintain anyway, with

Re: [Python-Dev] Fuzziness in io module specs - PEP update proposition V2

2009-09-29 Thread Antoine Pitrou
Guido van Rossum python.org> writes: > > All in all I think we should change this before it's too late; it will > affect a very small number of apps (perhaps none?), but I would rather > have the right semantics in the future. Also, it's trivial to write > code that doesn't care (in fact code run

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-09-29 Thread Antoine Pitrou
Hello, > I've also encountered this trap multiple times. Obviously, the problem > is not rebuilding Python which is quick, but to figure out the correct > configure option to use (--enable-unicode=ucs4). Others have also > spent some time scratching their heads over the strange > PyUnicodeUCS4_Fro

Re: [Python-Dev] PEP 3144 review.

2009-09-29 Thread Antoine Pitrou
> I've mentioned at least once (and others have mentioned as well) that > it's very common, when describing the ip address/prefix of a NIC to > write, "192.168.1.100/24" You say it yourself : it describes "the ip address/prefix of a NIC". It isn't the job of a Network class. A Network shouldn't d

Re: [Python-Dev] Python logging and 1.5.2 compatibility

2009-09-30 Thread Antoine Pitrou
Le Wed, 30 Sep 2009 13:27:41 +, Vinay Sajip a écrit : > I'm planning to "officially" drop support for Python 1.5.2 in the > logging package. Thanks for the announcement. So, what is the minimum supported version now? Regards Antoine. ___ Python-D

Re: [Python-Dev] sharing stdlib across python implementations

2009-09-30 Thread Antoine Pitrou
Chris Withers simplistix.co.uk> writes: > > I'm on on stdlib-sig and I'm afraid I don't have the bandwidth to start > on it, but I'd just like to throw in (yet again) that it would be great > if the stdlib was actually a set of separate python packages with their > own version metadata so that

Re: [Python-Dev] transitioning from % to {} formatting

2009-09-30 Thread Antoine Pitrou
James Y Knight fuhm.net> writes: > > The user could write either: > logging.Formatter("%(asctime)s - %(name)s - %(level)s - %(msg)s") > (as always -- that can't be changed without a long deprecation > period), or: > logging.Formatter(newstyle_formatstr("{asctime} - {name} - {level} - > {msg}"

Re: [Python-Dev] transitioning from % to {} formatting

2009-09-30 Thread Antoine Pitrou
Vinay Sajip yahoo.co.uk> writes: > > Does it seems too onerous to expect people to pass an additional "use_format" > keyword argument with every logging call to indicate how to interpret the > message format string? Or does the PercentMessage/BraceMessage type approach > have any mileage? What do

Re: [Python-Dev] transitioning from % to {} formatting

2009-10-01 Thread Antoine Pitrou
Vinay Sajip yahoo.co.uk> writes: > > This seems perhaps usable for a Formatter instantiation (infrequent) but a > problem for the case where you want to convert format_str + args -> message > (potentially frequent, and less readable). Why is it a problem? I don't understand. It certainly is less

Re: [Python-Dev] transitioning from % to {} formatting

2009-10-01 Thread Antoine Pitrou
Hello, > Well, it's less readable, as I said in parentheses. It would work, of course. > And the special wrappers needn't be too intrusive: > > __ = BraceMessage > > logger.debug(__("Message with {0} {1}", 1, "argument")) Ah, I hadn't thought about that. It looks a bit less awful indeed. I'm o

Re: [Python-Dev] transitioning from % to {} formatting

2009-10-02 Thread Antoine Pitrou
Steven Bethard gmail.com> writes: > > But it's not much of a transition plan. Or are you suggesting: The question is why we want a transition plan that will bother everyone with no tangible benefits for the user. Regards Antoine. ___ Python-Dev mai

Re: [Python-Dev] transitioning from % to {} formatting

2009-10-02 Thread Antoine Pitrou
Raymond Hettinger rcn.com> writes: > > Because there has been limited uptake on {}-formatting (afaict), > we still have limited experience with knowing that it is actually > better, less error-prone, easier to learn/rember, etc. It is known to be quite slower. The following timings are on the p

Re: [Python-Dev] summary of transitioning from % to { } formatting

2009-10-03 Thread Antoine Pitrou
Steven Bethard gmail.com> writes: > > If %-formatting is to be deprecated, the transition strategy here > is trivial. However, no one has yet written translators, and it is > not clear what heuristics should be used, e.g. should the method > just try %-formatting first and then {}-formatt

Re: [Python-Dev] summary of transitioning from % to {} formatting

2009-10-03 Thread Antoine Pitrou
> Define "fails": > > >>> "{a} {b} c" % {'a':12} > '{a} {b} c' > > That didn't fail... Ah, my bad. I had completely overlooked that formatting was laxist when faced with unused named parameters. Then we need something smarter, like counting the number of unescaped "%" characters, the number of

Re: [Python-Dev] summary of transitioning from % to { } formatting

2009-10-03 Thread Antoine Pitrou
MRAB mrabarnett.plus.com> writes: > > Another possibility: > > A StringFormat class with subclasses PercentStringFormat, > BraceStringFormat, and perhaps DollarStringFormat. > > Or: > > A StringFormat class with methods parse_percent_format, > parse_brace_format, and parse_dollar_format. Ther

Re: [Python-Dev] Package install failures in 2.6.3

2009-10-05 Thread Antoine Pitrou
Hello, > Now I am astonished that we are talking about reverting changes in > Distutils that were done for bugfixes, for a third party package that > does monkey > patches on Distutils. I think we should avoid any questions of responsability here (besides, it is quite clear that you, Tarek, are n

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-10-05 Thread Antoine Pitrou
Le lundi 05 octobre 2009 à 19:18 +0200, Jan Matejek a écrit : > > I > don't see what is bad about improving compatibility in a place where the > setting doesn't hurt one way or the other. I can't speak for Mandriva, but I'm sure they care more about not breaking user installs when they upgrade to

Re: [Python-Dev] eggs now mandatory for pypi?

2009-10-05 Thread Antoine Pitrou
Guido van Rossum python.org> writes: > > There are plenty of things we > can learn about fighting spam and other forms of vandalism from other > areas of the social web, including our very own wiki, and other wikis > (WikiPedia survives despite spam). Doesn't Wikipedia have a lot of human eyes w

Re: [Python-Dev] Python byte-compiled and optimized code

2009-10-07 Thread Antoine Pitrou
Fred Drake gmail.com> writes: > > 3) Is it possible to redirect the location of the generation of .pyc files > > to other than that of the corresponding .py files? > > I think some support for this has been developed, at least > experimentally, but I'm not sure if it's part of a stable release or

Re: [Python-Dev] transitioning from % to {} formatting

2009-10-07 Thread Antoine Pitrou
Vinay Sajip yahoo.co.uk> writes: > > >>> "%0#8x" % 0x1234 > '0x001234' > >>> "{0:0>#8x}".format(0x1234) > '000x1234' Apart from the sheer unreadability of the {}-style format string, the result looks rather unexpected from a human being's point of view. (in those situations, I would output the

Re: [Python-Dev] please consider changing --enable-unicode default to ucs4

2009-10-07 Thread Antoine Pitrou
Zooko O'Whielacronx gmail.com> writes: > > I accidentally sent this letter just to MAL when I intended it to > python-dev. Please read it, as it explains why the issue I'm raising > is not just the "we should switch to ucs4 because it is better" issue > that was previously settled by GvR. For

Re: [Python-Dev] eggs now mandatory for pypi?

2009-10-07 Thread Antoine Pitrou
Arc Riley gmail.com> writes: > > Is the intention of Pypi really to turn it into a social networking site?  Sure, why not? It's not like there are enough social networking sites nowadays, are there? :) Regards Antoine. ___ Python-Dev mailing list

Re: [Python-Dev] PEP 389: argparse - new command line parsing module

2009-10-07 Thread Antoine Pitrou
Hrvoje Niksic avl.com> writes: > > Of course; simply use the >&- pseudo-redirection, which has been a > standard sh feature (later inherited by ksh and bash, but not csh) for > ~30 years. The error message is amusing, too: > > $ python -c 'print "foo"' >&- > close failed in file object destru

Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)

2009-10-08 Thread Antoine Pitrou
Hello, Thanks for the summary :) [Distribute 0.7] > - easy_install is going to be deprecated ! use Pip ! Apparently there are a couple of things Pip doesn't support: « It cannot install from eggs. It only installs from source. (Maybe this will be changed sometime, but it’s low priority.) » «

Re: [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)

2009-10-08 Thread Antoine Pitrou
Le Thu, 08 Oct 2009 13:27:57 +0200, M.-A. Lemburg a écrit : > > This sounds a lot like DLL- or RPM-hell to me. > > I think it's much better to keep things simple and under user control, > e.g. by encouraging use of virtualenv-like setups and perhaps adding > better native support for these to Pyt

Re: [Python-Dev] locals() different behaviour when tracing?

2009-10-08 Thread Antoine Pitrou
Anders Waldenborg 0x63.nu> writes: > > Is it intentional that locals() returns a copy/snapshot of the local > variables sometimes, and sometimes a reference? Like when enabling > tracing, such as in the code pasted below. Since someone else opened a bug, I answered there. Anyone, feel free to

Re: [Python-Dev] Distutils and Distribute roadmap (and so me words on Virtualenv, Pip)

2009-10-08 Thread Antoine Pitrou
Toshio Kuratomi gmail.com> writes: > > This is needing to install multiple versions and use the newly installed > version for testing. [...] What you're missing is that having separate environments has a virtue of cleanliness, understandability and robustness that a multiple-versioned solution d

Re: [Python-Dev] Distutils and Distribute roadmap (and so me words on Virtualenv, Pip)

2009-10-08 Thread Antoine Pitrou
Ned Deily acm.org> writes: > > How to decide on and then effectively > communicate that direction is not at all trivial, I think. I think it's quite trivial actually. Since everybody agrees (except perhaps PJE) that Distribute should replace setuptools, the word will spread and trickle quite qu

Re: [Python-Dev] Distutils and Distribute roadmap (and so me words on Virtualenv, Pip)

2009-10-09 Thread Antoine Pitrou
Ian Bicking colorstudy.com> writes: > > Someone mentioned that easy_install provided some things pip didn't; > outside of multi-versioned installs (which I'm not very enthusiastic > about) I'm not sure what this is? http://pip.openplans.org/#differences-from-easy-install If it's obsolete the we

Re: [Python-Dev] PEP 370 and IronPython

2009-10-09 Thread Antoine Pitrou
Christian Heimes cheimes.de> writes: > > >>> sys.vm > sys.vm(id='cpython', name='CPython', platform='C', > usersitesuffix='python26') # on win32: Python2.6 > > >>> sys.vm > sys.vm(id='ironpython', name='IronPython', platform='.NET', > usersitesuffix='ironpython26) # on win32: IronPython2.6 `use

Re: [Python-Dev] BDFL pronouncement?

2009-10-09 Thread Antoine Pitrou
Chris Withers simplistix.co.uk> writes: > > Well, if this was the BDFL pronouncement that a lot of people have taken > it to be, does that allow Martin von Lewis to give the keys to > http://pypi.python.org/pypi/setuptools to the "distribute" developers, > so we can get on and use the original

Re: [Python-Dev] BDFL pronouncement?

2009-10-09 Thread Antoine Pitrou
Chris Withers simplistix.co.uk> writes: > > *sigh* I don't see it as hijacking, provided Guido is making a BDFL > pronouncement that you're maintaining this software Well, what you are proposing *is* hijacking. PJE is not paid or employed by Guido, he is the full author of setuptools. Forking i

Re: [Python-Dev] PEP about sys.implementation and impleme ntation specific user site directory

2009-10-10 Thread Antoine Pitrou
Willem Broekema gmail.com> writes: > > a) implementation details of the C implementation (subversion, _*, > dllhandle, dont_write_bytecode, settscdump, ..) in one module, > > b) portable functionality (interpreter name and version etc, > builtin_module_names, copyright, excepthook, settrace, ..)

Re: [Python-Dev] Initialization of __builtins__

2009-10-10 Thread Antoine Pitrou
Vinay Sajip yahoo.co.uk> writes: > > In the py3k branch, logging has the line > > _unicode = 'unicode' in dir(__builtins__) Why do you do this? In py3k, unicode is always enabled but it's called "str" and the name "unicode" doesn't exist. > to determine the existence of Unicode support. The co

Re: [Python-Dev] Top-posting on this list

2009-10-11 Thread Antoine Pitrou
Greg Ewing canterbury.ac.nz> writes: > > That's no reason to squander it, though. Quoting the entire > message every time makes the size of the thread grow as > O(n**2), and makes things harder to read as well. That's > just senseless. +1. It's always annoying to skim through a three-page quoted

[Python-Dev] Weak dict iterators are fragile

2009-10-11 Thread Antoine Pitrou
Hello, In py3k, the weak dict methods keys(), values() and items() have been changed to return iterators (they returned lists in 2.x). However, it turns out that it makes these methods quite fragile, because a GC collection can occur whenever during iterating, destroy one of the weakref'ed obj

Re: [Python-Dev] Top-posting on this list

2009-10-11 Thread Antoine Pitrou
MRAB mrabarnett.plus.com> writes: > [snipped three pages of quoted messages before a one-liner] > Didn't the iPhone also lack cut-and-paste? Not to sound harsh, but your quoting was a perfect example of wasted visual bandwidth... (are you posting from an iPhone ? ;-)) Antoine. ___

Re: [Python-Dev] Weak dict iterators are fragile

2009-10-11 Thread Antoine Pitrou
Antoine Pitrou pitrou.net> writes: > > 1. Add the safe methods listkeys(), listitems(), listvalues() which would > behave as the keys(), etc. methods from 2.x > > 2. Make it so that keys(), items(), values() atomically build a list of > items internally, which makes them

Re: [Python-Dev] Weak dict iterators are fragile

2009-10-11 Thread Antoine Pitrou
Daniel Stutzbach stutzbachenterprises.com> writes: > > -1 on 1.+0 on 2.It'd be nice if we could postpone the resize if there are active iterators, but I don't think there's a clean way to track the iterators. I've started experimenting, and it seems reasonably possible using a simple guard class

Re: [Python-Dev] Weak dict iterators are fragile

2009-10-11 Thread Antoine Pitrou
Antoine Pitrou pitrou.net> writes: > > Daniel Stutzbach stutzbachenterprises.com> writes: > > > > -1 on 1.+0 on 2.It'd be nice if we could postpone the resize if there are > active iterators, but I don't think there's a clean way to track the > it

Re: [Python-Dev] Backport new float repr to Python 2.7?

2009-10-11 Thread Antoine Pitrou
Michael Sparks gmail.com> writes: > > I know it's the upteen-thousandth time it's been discussed, but > removal of the GIL in 3.x would probably be pretty big carrots for > some. I know the arguments [...] Not before someone produces a patch anyway. It is certainly not as easy as you seem to thi

Re: [Python-Dev] Better module shutdown procedure

2009-10-14 Thread Antoine Pitrou
Neil Schemenauer arctrix.com> writes: > > I would like to commit this change but I'm not sure if it is a good > time in the development cycle or if anyone has objections to the > idea. Please speak up if you have input. Have you tried to remove the various hacks/workarounds in the stdlib that cu

Re: [Python-Dev] Better module shutdown procedure

2009-10-15 Thread Antoine Pitrou
Le Wed, 14 Oct 2009 18:27:37 -0500, Daniel Stutzbach a écrit : > > Here is my understanding of the proposed procedure: > > 1. Replace modules in sys.modules with weakrefs 2. Run the garbage > collector > 3. Replace globals in any remaining modules with None 4. Run the garbage > collector > > Is

Re: [Python-Dev] Can 3.1 still be built without complex?

2009-10-15 Thread Antoine Pitrou
pobox.com> writes: > > I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files > but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in > configure or pyconfig.h.in. Are builds --without-complex still supported? > Has it been tested at any time in the recen

Re: [Python-Dev] Can 3.1 still be built without complex?

2009-10-15 Thread Antoine Pitrou
Mark Dickinson gmail.com> writes: > > There's one respect in which complex is slightly more tightly > integrated in py3k than in trunk: raising a negative number to a > non-integer power (e.g., (-1)**0.5) gives a complex result in py3k. >>> (-1)**.5 (6.123031769111886e-17+1j) Don't we have a p

[Python-Dev] PY_SSIZE_T_CLEAN in py3k

2009-10-17 Thread Antoine Pitrou
Hello, It turns out (*) that even in py3k, not all modules are PY_SSIZE_T_CLEAN. Should we try to remedy that, and make PY_SSIZE_T_CLEAN the default in future 3.x versions? As far I know, there's no reason not to be PY_SSIZE_T_CLEAN, except for having to convert old code. (*) http://bugs.python.

[Python-Dev] SIGCHECK() in longobject.c

2009-10-18 Thread Antoine Pitrou
Hello, In Objects/longobject.c, there's the SIGCHECK() macro which periodically checks for signals when doing long integer computations (divisions, multiplications). It does so by messing with the _Py_Ticker variable. It was added in 1991 under the title "Many small changes", and I suppose it wa

Re: [Python-Dev] SIGCHECK() in longobject.c

2009-10-18 Thread Antoine Pitrou
Mark Dickinson gmail.com> writes: > > Yes, I suspect there are. Though you don't need millions of digits for a single > operation to take a noticeable amount of time: try str(10**10), > for example. > > Is there a benefit to removing the check? Apart from casual cleanup, the reason I'm as

Re: [Python-Dev] SIGCHECK() in longobject.c

2009-10-18 Thread Antoine Pitrou
Daniel Stutzbach stutzbachenterprises.com> writes: > > I sometimes do million-digits calculations that I want to interrupt using Control-C.(particularly when I didn't *intend* to do a million-digits calculation... ;) )-- Sure, but it's no different than doing, e.g.: list(range(1)).so

Re: [Python-Dev] GIL behaviour under Windows

2009-10-21 Thread Antoine Pitrou
Hello Kristjan, > This depends entirely on the platform and primitives used to implement the > GIL. > I'm interested in windows. Could you try ccbench (*) under Windows? The only Windows system I have here is a qemu virtual machine and it wouldn't be very realistic to do concurrency measurement

Re: [Python-Dev] GIL behaviour under Windows

2009-10-21 Thread Antoine Pitrou
> I don't really know how this test works, so I won't claim to understand > the results either. However, here you go: Thanks. Interesting results. I wonder what they would be like on a multi-core machine. The GIL seems to behave perfectly on your setup (no performance degradation due to concurren

Re: [Python-Dev] GIL behaviour under Windows

2009-10-21 Thread Antoine Pitrou
> > (*) http://svn.python.org/view/sandbox/trunk/ccbench/ > > I´ve run it twice on my dual core machine. It hangs every time, but not in > the same place: > D:\pydev\python\trunk\PCbuild>python.exe \tmp\ccbench.py Ah, you should report a bug then. ccbench is pure Python (and not particularly e

Re: [Python-Dev] Interest in integrating C decimal module i nto Python?

2009-10-21 Thread Antoine Pitrou
Mark Dickinson gmail.com> writes: > > There are certainly some open issues (e.g., what to do with > the existing Python module; what should other Python implementations > do). The existing module could be kept as a fallback. Also, the test suite should be careful to test both implementations (l

Re: [Python-Dev] GIL behaviour under Windows

2009-10-21 Thread Antoine Pitrou
Sturla Molden molden.no> writes: > > It does not crash the interpreter, but it seems it can deadlock. Kristján sent me a patch which I applied and is supposed to fix this. Anyway, thanks for the numbers. The GIL does seem to fare a bit better (zero latency with the Pi calculation in the backgro

Re: [Python-Dev] GIL behaviour under Windows

2009-10-21 Thread Antoine Pitrou
Le mercredi 21 octobre 2009 à 12:42 -0500, John Arbash Meinel a écrit : > > You can use time.clock() instead to get <15ms resolution. Changing all > instances of 'time.time' to 'time.clock' gives me this result: [snip] > > --- Latency --- > > Background CPU task: Pi calculation (Python) > > CPU

Re: [Python-Dev] time.clock() on windows

2009-10-21 Thread Antoine Pitrou
Kristján Valur Jónsson ccpgames.com> writes: > > You are right, on windows time.clock() is based relative to its first call in the process. There is no such > promise made on unix. > QueryPerformanceCounter() (what time.clock uses()) is a robust high resolution timer that is > processor/core ind

Re: [Python-Dev] time.clock() on windows

2009-10-22 Thread Antoine Pitrou
Robert Collins robertcollins.net> writes: > > Could you offset it by the system time on the first call? Two problems: - the two measurements are not done simultaneously, so the result *still* does not guarantee you have the same time reference in all processes (but gives you the illusion you do,

Re: [Python-Dev] GIL behaviour under Windows

2009-10-22 Thread Antoine Pitrou
Sturla Molden molden.no> writes: > > With two threads and a check interval og 100, only 61 of 10 check > intervals failed to produce a thread-switch in the interpreter. I'd call > that rather fair. This number lacks the elapsed time. 61 switches in one second is probably enough, the same

Re: [Python-Dev] Python Package Management Roadmap in Python Releases

2009-10-22 Thread Antoine Pitrou
Glenn Linderman g.nevcal.com> writes: > > Maybe what David is missing is that since python-dev is uninterested in > the package management issue, [...] It's a bit strong to say we are uninterested. Most of us are not interested enough to tackle it ourselves (*), but we are certainly interested

Re: [Python-Dev] time.clock() on windows

2009-10-22 Thread Antoine Pitrou
M.-A. Lemburg egenix.com> writes: > > I'm not sure I understand why time.clock() should be considered > broken. Because in some cases you want comparable high-resolution numbers from distinct processes. > time.clock() is used for measuring process CPU time According to the docs, under Windows

[Python-Dev] readonly __doc__

2009-10-22 Thread Antoine Pitrou
Speaking of the __doc__ property, I just noticed the following thing on py3k: >>> class C: pass ... >>> C.__doc__ = "hop" Traceback (most recent call last): File "", line 1, in AttributeError: attribute '__doc__' of 'type' objects is not writable Is this deliberate? Antoine.

Re: [Python-Dev] GIL behaviour under Windows

2009-10-22 Thread Antoine Pitrou
Tres Seaver palladion.com> writes: > > I read Sturla as saying there were 99,939 switches out of a possible > 100,000, with sys.checkinterval set to 100. Oops, you're right. But depending on the elapsed time (again :-)), it may be too high, because too many switches per second will add a lot of

Re: [Python-Dev] readonly __doc__

2009-10-22 Thread Antoine Pitrou
Guido van Rossum python.org> writes: > > On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou pitrou.net> wrote: > > > > Speaking of the __doc__ property, I just noticed the following thing on py3k: > > > >>>> class C: pass > > ... > >&

Re: [Python-Dev] readonly __doc__

2009-10-22 Thread Antoine Pitrou
Brett Cannon python.org> writes: > > > I honestly don't follow that sentence. But __doc__ is special because of its > use; documenting how to use of an object. In this case when you call > something like help() on an instance of an object it skips the instance's > value for __doc__ and goes s

Re: [Python-Dev] readonly __doc__

2009-10-22 Thread Antoine Pitrou
Le jeudi 22 octobre 2009 à 13:59 -0700, Guido van Rossum a écrit : > > I don't really understand how this explains the read-only __doc__. > > I am talking about modifying __doc__ on a class, not on an instance. > > (sure, a new-style class is also an instance of type, but still...) > > Antoine, it

Re: [Python-Dev] language summit topic: issue tracker

2009-10-23 Thread Antoine Pitrou
Le Thu, 22 Oct 2009 21:47:06 -0700, Brett Cannon a écrit : > > - Dropping Stage in favor of some keywords (e.g. 'needs unit test', > 'needs docs') What would it bring? We don't have a very strict process and the current "stage" looks sufficient to me. Saying that unit tests or docs are lacking

[Python-Dev] Clean up Python/thread_*.h ?

2009-10-24 Thread Antoine Pitrou
Hello, I am wondering which of the files in Python/thread_*.h are really necessary today. Looking at these files, I think most of them could perhaps be removed in py3k. I've identified three categories of potentially removable files: * The unused file: thread_wince.h Windows CE has actually bee

Re: [Python-Dev] interning

2009-10-24 Thread Antoine Pitrou
Alexander Belopolsky gmail.com> writes: > > AB> I disagree with Martin. I think interning is a set > AB> operation and it is unfortunate that set API does not > AB> support it directly. > > ML> I disagree with Alexander's last remark in several respects: [...] > ML> The operation "give me the me

Re: [Python-Dev] Clean up Python/thread_*.h ?

2009-10-24 Thread Antoine Pitrou
Martin v. Löwis v.loewis.de> writes: > > > Making a decision and removing the files considered unnecessary would > > clarify > > what platforms still are/should be supported. > > I think any such removal should go through the PEP 11 process. Put a > #error into the files for 3.2, and a removal

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-25 Thread Antoine Pitrou
> For a), I think we can solve this only by redundancy, i.e. create more > build slaves, hoping that a sufficient number would be up at any point > in time. We are already doing this, aren't we? http://www.python.org/dev/buildbot/3.x/ It doesn't seem to work very well, it's a bit like a Danaides

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-25 Thread Antoine Pitrou
twistedmatrix.com> writes: > > To me, that raises the question of why people aren't more concerned with > the status of the build system. Shouldn't developers care if the code > they're writing works or not? The fact that we ask questions and publicly express worries should hint that we /are/

[Python-Dev] Reworking the GIL

2009-10-25 Thread Antoine Pitrou
Hello there, The last couple of days I've been working on an experimental rewrite of the GIL. Since the work has been turning out rather successful (or, at least, not totally useless and crashing!) I thought I'd announce it here. First I want to stress this is not about removing the GIL. There s

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-25 Thread Antoine Pitrou
Martin v. Löwis v.loewis.de> writes: > > If it's offline too often, I'm skeptical that it would be useful. If > you report breakage after a day, then it will be difficult to attribute > this to a specific commit. It is most useful to have continuous > integration if error reports are instantaneou

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-25 Thread Antoine Pitrou
ssteinerX gmail.com gmail.com> writes: > On Oct 25, 2009, at 5:43 PM, Martin v. Löwis wrote: > > > Only turning on the slave occasionally makes it useless. > > For certain use cases; not mine. Let's say that for the use case we are talking here (this is python-dev), Martin's statement holds tr

Re: [Python-Dev] Reworking the GIL

2009-10-26 Thread Antoine Pitrou
Terry Reedy udel.edu> writes: > > I am curious as to whether the entire mechanism is or can be turned off > when not needed -- when there are not threads (other than the main, > starting thread)? It is an implicit feature: when no thread is waiting on the GIL, the GIL-holding thread isn't noti

Re: [Python-Dev] Reworking the GIL

2009-10-26 Thread Antoine Pitrou
Sturla Molden molden.no> writes: > > Antoine Pitrou skrev: > > - priority requests, which is an option for a thread requesting the GIL > > to be scheduled as soon as possible, and forcibly (rather than any other > > threads). T > Should a priority request for the G

Re: [Python-Dev] Reworking the GIL

2009-10-26 Thread Antoine Pitrou
Daniel Stutzbach stutzbachenterprises.com> writes: > > Do we really need priority requests at all?  They seem counter to your > desire for simplicity and allowing the operating system's scheduler to do > its work. No, they can be disabled (removed) if we prefer. With priority requests disabled,

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

2009-10-26 Thread Antoine Pitrou
Jesse Noller gmail.com> writes: > > So far, fiddling with the PEP, I'm on the fence - adding a method to a > built-in object type is sort of a grey area (at least in my mind). It > depends on if doing so significantly alters the language/syntax. We have recently added things like float.fromhex()

Re: [Python-Dev] Reworking the GIL

2009-10-26 Thread Antoine Pitrou
Collin Winter gmail.com> writes: > > My results for an 2.4 GHz Intel Core 2 Duo MacBook Pro (OS X 10.5.8): Thanks! [the Dave Beazley benchmark] > The results below are benchmarking py3k as the control, newgil as the > experiment. When it says "x% faster", that is a measure of newgil's > perfor

Re: [Python-Dev] Set methods for mapping views

2009-10-26 Thread Antoine Pitrou
Steven D'Aprano pearwood.info> writes: > > I don't understand that rationale. Let's take a concrete example. The > new `yield from` syntax was accepted Was it? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-27 Thread Antoine Pitrou
Martin v. Löwis v.loewis.de> writes: > > It's not really reproducible. I think it sometimes happens when I > restart the master; sometimes, some clients fail to reconnect > (properly). Another common problem is that some buildbot fails in the middle of the test suite, with the following kind of

Re: [Python-Dev] Retrieve an arbitrary element from a set withoutremoving it

2009-10-27 Thread Antoine Pitrou
Raymond Hettinger rcn.com> writes: > > [Chris Bergstresser] > Still, I think my > > point stands--it's a clear extrapolation from the existing dict.get(). > > Not really. One looks-up a key and supplies a default value if not found. > The other, set.get(), doesn't have a key to lookup. set.g

Re: [Python-Dev] nonlocal keyword in 2.x?

2009-10-28 Thread Antoine Pitrou
Lennart Regebro gmail.com> writes: > > So 2.7 support will for the most part be a case not of supporting > Python versions, but Python *users*. That's still not a good reason to backport nonlocal. The same reasoning could be used to backport new features to the 2.6 branch after all. Regards An

Re: [Python-Dev] Reworking the GIL

2009-10-28 Thread Antoine Pitrou
Kristján Valur Jónsson ccpgames.com> writes: > > In my experience (from stackless python) using priority wakeup for IO can result in very erratic > scheduling when there is much IO going on, every IO trumping another. I whipped up a trivial multithreaded HTTP server using socketserver.ThreadingM

Re: [Python-Dev] nonlocal keyword in 2.x?

2009-10-28 Thread Antoine Pitrou
pobox.com> writes: > > >> So 2.7 support will for the most part be a case not of supporting > >> Python versions, but Python *users*. > > Antoine> That's still not a good reason to backport nonlocal. The same > Antoine> reasoning could be used to backport new features to the 2.6

Re: [Python-Dev] MSDN subscribers: Using Visual Studio?

2009-10-29 Thread Antoine Pitrou
Steve Holden gmail.com> writes: > > I just wondered, with the recent flood of new MSDN subscriptions loosed > on the developer community, how many people have installed the required > version of Visual Studio and built Python for Windows from source? Not > being that familiar with the process mys

[Python-Dev] "Buildbot" category on the tracker

2009-10-29 Thread Antoine Pitrou
Hello, What do you think of creating a "buildbot" category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] (no subject)

2009-10-29 Thread Antoine Pitrou
Martin v. Löwis v.loewis.de> writes: > > > What do you think of creating a "buildbot" category in the tracker? There > > are > > often problems on specific buildbots which would be nice to track, but there's > > nowhere to do so. > > Do you have any specific reports that you would want to class

Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it

2009-10-30 Thread Antoine Pitrou
Steven D'Aprano pearwood.info> writes: > > If you can think of any other way to efficiently cycle over the elements > in a set, I'm all for it :) How about "for x in s"? Or if you want to cycle: >>> s = set('abc') >>> it = itertools.cycle(s) >>> next(it) 'a' >>> next(it) 'c' >>> next(it) 'b'

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-30 Thread Antoine Pitrou
Hello, Sorry for the little redundancy, I would like to underline Jean-Paul's suggestion here: Le Sun, 25 Oct 2009 14:05:12 +, exarkun a écrit : > I think that money can help in two ways in this case. > > First, there are now a multitude of cloud hosting providers which will > operate a sl

Re: [Python-Dev] Possible language summit topic: buildbots

2009-10-30 Thread Antoine Pitrou
Le vendredi 30 octobre 2009 à 09:31 -0700, C. Titus Brown a écrit : > [ ... ] > > I'm happy to provide VMs or shell access for Windows (XP, Vista, 7); Linux > ia64; Linux x86; and Mac OS X. Others have made similar offers. The > architectures supported by the cloud services don't really add anyt

Re: [Python-Dev] "Buildbot" category on the tracker

2009-10-30 Thread Antoine Pitrou
twistedmatrix.com> writes: > > Is your idea that this would be for tracking issues with the *bots* > themselves? That is, not just for tracking cases where some test method > fails on a particular bot, but for tracking cases where, say, a bot's > host has run out of disk space and cannot run

<    20   21   22   23   24   25   26   27   28   29   >