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
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
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
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
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
> 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"
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
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
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
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
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
> 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
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
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
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}"
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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.) »
«
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
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
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
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
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
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
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
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
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, ..)
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
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
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
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.
___
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
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
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
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
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
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
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
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
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.
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
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
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
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
> 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
> > (*) 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
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
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
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
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
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,
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
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
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
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.
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
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
> > ...
> >&
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
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
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
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
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
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
> 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
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/
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
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
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
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
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
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,
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()
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
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
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
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
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
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
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
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
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
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
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'
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
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
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
2401 - 2500 of 4909 matches
Mail list logo