Tarek Ziadé gmail.com> writes:
>
> Another module I would like to move away from Distutils is
> "archive_util". It contains helpers to build archives, whether they
> are zip or tar files. I propose to move those useful functions into
> shutil, as this seems the most logical place.
Are these func
David Lyon pythontest.org> writes:
>
> I think I'll have better chances with PEPs.
>
> Being honest, if wonderful libraries like Sphinx and Mercurial
> and Git and BZR can't make it into the stdlib, then there is
> no hope for even newer code to get in there.
> [snip]
This is python-ideas mater
Hello,
> If we have done any original work, it is by accident.
:-)
> The increased memory usage comes from a) LLVM code generation, analysis
> and optimization libraries; b) native code; c) memory usage issues or
> leaks in LLVM; d) data structures needed to optimize and generate
> machine code
Reid Kleckner mit.edu> writes:
>
> > This is positively humongous. Is there any way to shrink these numbers
> > dramatically (I'm talking about the release builds)? Large executables or
> > libraries may make people anxious about the interpreter's memory
> > efficiency; and they will be a nuisanc
Dirkjan Ochtman ochtman.nl> writes:
>
> What I personally would consider interesting for the PEP is a (not too
> big) section evaluating where other Python-performance efforts are at.
> E.g. does it make sense to propose a u-s merge now when, by the time
> 3.3 (or whatever) is released, there'll
Michael Foord voidspace.org.uk> writes:
>
> Heh, so we have two different encoding mechanisms both called "default
> encoding". One is always utf-8 in Python 3 and one is platform
> dependent... Great.
The former is merely internal though. Also, if you grep for the "s#" and "s*"
argument type c
Terry Reedy udel.edu> writes:
>
> If the current guess is based on a mistaken assumption -- that it is
> giving the user what the user asked for -- it might be reconsidered. I
> personally would prefer that the default file encoding for Python 3 be
> utf-8 on any machine my code runs on unless
M.-A. Lemburg egenix.com> writes:
>
> It's rather common to exchange text files between users... and
> in form of XML and CSV files, these also tend to get used as
> input for programs every now and then
For XML files, encoding should be taken care of by the XML layer, not the IO
layer. That is
Terry Reedy udel.edu> writes:
>
> Dreadfully rong. In general, the default encoding on my Windows *does
> not work* on Python3 strings but causes
> UnicodeEncodeError:
> If the text is not written to the file, it is completely non-portable.
You must mistake "portable" for something else. "P
Le samedi 23 janvier 2010 à 20:43 +0100, M.-A. Lemburg a écrit :
>
> Now, we cannot easily remove this guessing since we're in stable
> mode again with 3.1. Perhaps we should add a way to at least be
> able to switch off this guessing, so that applications can be
> tested in a predictable way, rat
Stephen J. Turnbull xemacs.org> writes:
>
> That's throwing the baby out with the bathwater. Very few practical
> applications that care about the input encoding are going to be
> willing to accept an output encoding that doesn't correspond to the
> input encoding in an appropriate way.
Perhaps
Stephen J. Turnbull xemacs.org> writes:
>
> But it *does* determine the charset of ErrorDocuments displayed by
> Apache. Users are likely to get somewhat confused if the
> ErrorDocuments are in a different charset from your dynamic HTML.
Why would they? The browser picks the encoding from eithe
Oleg Broytman phd.pp.ru> writes:
>
>Depends on the kind of cat and especially on the ways of using it. If
> you ask cat to number lines (see manual for GNU cat) - what do "lines" mean
> for binary IO?
b"\n"-separated chunks of data. See the docs:
http://docs.python.org/3.1/library/io.html#io
Terry Reedy udel.edu> writes:
>
> The idea that CPython should not be improved because it would spoil
> programmers strikes me as a thin, even desparate objection. One could
> say that same thing about the recent optimization of string += string so
> that repeated concats are O(n) instead of O
Nick Coghlan gmail.com> writes:
>
> The big practical concern is actually the memory cost of adding yet
> another pointer (potentially 8 bytes of data) to every list object, even
> empty ones.
It needn't be, actually. Why?
You only need to store this other pointer when you have an orphaned area
Daniel Stutzbach stutzbachenterprises.com> writes:
>
>
> I don't think your analogy works, unless you recopy your to-do lists whenever
> you complete a task in the middle of the list.
I think his analogy suggests that his to-do list is a doubly-linked list ;)
Or perhaps an array with lazy dele
Le mercredi 27 janvier 2010 à 11:49 -0800, Steve Howell a écrit :
> A slightly more sane alternative would be to leave ob_size and ob_item
> alone with their current semantics, and then replace allocated with
> self->excess, where
>
> self->excess == excess_above * 256 + excess_below.
Or we cou
Raymond Hettinger gmail.com> writes:
>
> AFAICT, the performance of the proposal:
>
> * increases space requirements by a small fixed amount
Well, given my proposal (assuming it turns out ok) it doesn't.
> * s.append() performance slightly degraded.
Why?
> * the resize performance doesn't wo
Le Thu, 28 Jan 2010 14:33:11 +0100, Benjamin Schweizer a écrit :
>
> I've updated the traceback.py module; my improved version dumps all
> local variabes from the stack trace, which helps in debugging rare
> problems. You can find details in my latest blog post here:
>
As Facundo said it shouldn
Steve Howell yahoo.com> writes:
>
> What do you think of LISP, and "car" in particular (apart from the stupidly
> cryptic name)?
The question is not directed to me but I would say it's a brain-dead data
structure.
(pointed pairs did allow me to create C++ template classes with a variable
number
Cesare Di Mauro gmail.com> writes:
>
> If python dev community is interested, I can work on a 3.x branch, porting
> all optimizations I made (and many others that I've planned to implement) one
> step at the time, in order to carefully check and validate any change with
> expert people monitorin
Nick Coghlan gmail.com> writes:
>
> Antoine Pitrou wrote:
> > Or you could submit patches piecewise on http://bugs.python.org
> > I think the first step would be to switch to 16-bit bytecodes. It
would be
> > uncontroversial (the increase in code size probably h
Barry Warsaw python.org> writes:
>
> Putting Python version numbers in the packages would be a
> maintenance nightmare, since all the packages - *and their
> dependencies* - would have to be updated every time a new Python
> release was added or removed from the distribution. Because of the
> sh
Le Sun, 31 Jan 2010 18:46:54 +1000, Nick Coghlan a écrit :
>
> Actually, this is the first post I've seen noting objective problems
> with the use of a subdirectory. The others were just a subjective
> difference in perspective that saw subdirectory clutter as somehow being
> worse than file clutt
Le Sat, 30 Jan 2010 21:04:14 -0800, Jeffrey Yasskin a écrit :
>
> I have a couple bikesheddy or "why didn't you do this" comments. I'll be
> perfectly satisfied with an answer or a line in the pep.
>
> 1. Why the -R flag? It seems like this is a uniform improvement, so it
> should be the default.
> Would you still be a -1 on making it the new scheme the default if it
> used a single cache directory instead? That would actually be cleaner
> than the current solution rather than messier.
Well, I guess no, although additional directories are always more
intrusive than additional files (visua
Le Mon, 01 Feb 2010 11:35:19 -0800, Brett Cannon a écrit :
>
> As others have said, an uncompressed zip file could work here. Or even a
> file format where the first 4 bytes is the timestamp and then after that
> are chunks of length-of-bytecode|magic|bytecode. That allows for opening
> a file in
Jesse Noller gmail.com> writes:
>
> I don't see the need for the change from fork as of yet (for
> multiprocessing) and I am leery to change the internal implementation
> and semantics right now, or anytime soon. I'd be interested in seeing
> the patch, but if the concern is that global threading
Jesse Noller gmail.com> writes:
>
> I don't see spawnl as a viable alternative to fork. I imagine that I,
> and others successfully mix threads and multiprocessing on non-win32
> platforms just fine, knowing of course that fork() can cause heartburn
> if you have global locks code within the fork
Le lundi 01 février 2010 à 23:20 +0100, "Martin v. Löwis" a écrit :
>
> I don't know what spawnl is supposed to do, but it really sounds like
> the wrong solution.
As far as I understand, I think the idea is to use the same mechanism as
under Windows: spawn a new Python interpreter (in a separate
Le lundi 01 février 2010 à 23:58 +0100, "Martin v. Löwis" a écrit :
>
> Interestingly, the POSIX pthread_atfork documentation defines how you
> are supposed to do that: create an atfork handler set, and acquire all
> mutexes in the prepare handler. Then fork, and have the parent and child
> handle
Tres Seaver palladion.com> writes:
>
> Yup, but that's true for *any* POSIXy envirnnment, not just Python. The
> only sane non-exec mixture is to have a single-thread parent fork, and
> restrict spawning threads to the children.
The problem is that we're advocating multiprocessing as the soluti
Hello Eric,
> I notice that Guido vetoed this idea, but just in case it should come up
> again, I have some thoughts that likely have already occurred to people,
> but I didn't notice on the list.
Yes, I hindsight I think Guido was right.
(no, I'm not trying to make myself agreeable :-))
> Also
pobox.com> writes:
>
> I don't understand. On Unix-y systems isn't spawn* layered on top of
> fork/exec?
The point is that exec() relinquishes all the existing resources, so the initial
fork() becomes an implementation detail (IIUC).
> If you were going to
> combine both threading and multipro
Tres Seaver palladion.com> writes:
>
> Note that the "we" in your sentence is not anything like the "quod
> semper quod ubique quod ab omnibus" criterion for accepting dogma:
> mutliprocessing is a tool, and needs to be used according to its nature,
> just as with threading.
I don't remember eno
Barry Warsaw python.org> writes:
>
> As to the question of sibling directories or folder-per-folder I think
> performance issues should be the deciding factor. There are file system
> limitations to consider (but also a wide variety of file systems in use). Do
> the number of stat calls predomi
Le Tue, 02 Feb 2010 22:57:11 -0800, Barry Warsaw a écrit :
> On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote:
>
>>We deliberate don't document -U because its typical effect is "break the
>>world" - it makes all strings unicode in 2.x.
>
> As an aside, I think this should be documented *somewhere
Barry Warsaw python.org> writes:
>
> Python 3 uses the .py file for __file__ but I'd like to see a transition to
> __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or
> whatever compilation cache artifact file.
Well, I don't think we need another transition... Just keep
Neil Schemenauer arctrix.com> writes:
>
> Thanks for doing the work of writing a PEP. The rational section
> could use some strengthing, I think. Who is benefiting from this
> feature? Is it the distribution package maintainers? Maybe people
> who use a distribution packaged Python and instal
Le Wed, 03 Feb 2010 15:55:54 +0200, Simon Cross a écrit :
> On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou
> wrote:
>> Since there might be several compiled files for a single source file
>> (for example, a .pyc along with a JITted native .so), __cache__ should
>> probabl
Pascal Chambon gmail.com> writes:
>
> By the way, I'm having trouble with the "name" attribute of raw files,
> which can be string or integer (confusing), ambiguous if containing a
> relative path, and which isn't able to handle the new case of my
> library, i.e opening a file from an existing
Pascal Chambon gmail.com> writes:
>
> The problem is, doing that forwarding is quite complicated.
Hmm, why is it complicated? I agree it can be tedious (especially in C), but it
doesn't seem complicated in itself.
> My own FileIO class alas needs locking, because for example, on windows
> trunc
Le dimanche 07 février 2010 à 09:54 +0100, Pascal Chambon a écrit :
> > Actually, TextIOWrapper is simply not thread-safe for most of its
> > operations. I
> > think we did the work for simple writing, though, since it's better for
> > multi-threaded use of print().
>
> Argh, I had the impression
Barry Warsaw python.org> writes:
>
> >exarkun boson:~$ python -m timeit -s 'from os import getcwd' 'getcwd()'
> >100 loops, best of 3: 1.02 usec per loop
[...]
>
> I'd like to see the effect on command line scripts that are run often and then
> exit, e.g. Bazaar or Mercurial. Start up time
Nick Coghlan gmail.com> writes:
>
> The problem is that having '' as the first entry in sys.path currently
> means "do the import relative to the current directory". Unless we want
> to change the language semantics so we stick os.getcwd() at the front
> instead of '', then __file__ is still goin
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608 Is it ok to release new versions
> that are known to crash?
I've changed this issue to release blocker. What are the
> There are 65 entries and among them I can additionally confirm:
> http://bugs.python.org/issue3720
> http://bugs.python.org/issue7788
> http://bugs.python.org/issue5765
One of them is fixed and the other two are pathological cases. You can't
really trigger them by mistake.
Regards
Antoine.
Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
>
> The next 'big' change to unittest will (may?) be the introduction of
> class and module level setUp and tearDown. This was discussed on
> Python-ideas and Guido supported them. They can be useful but are also
> very easy to abuse (too
Le mardi 09 février 2010 à 22:55 +0100, "Martin v. Löwis" a écrit :
> > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> >> one - http://bugs.python.org/issue6608 Is it ok to release new versions
> >> that
Martin v. Löwis v.loewis.de> writes:
>
> IOW, I feel that release blockers should only be used if something
> really bad would happen that can be prevented by not releasing. If
> nothing actually gets worse by the release, the release shouldn't be
> blocked.
I think most blocking bugs we've had
anatoly techtonik gmail.com> writes:
>
> Is it possible to make exploits out of crashers?
It depends which ones. If it's something like a buffer overflow or a memory
management problem, it may be possible to exploit it through carefully crafted
input (in order to make the interpreter execute arb
Le mercredi 10 février 2010 à 05:26 +0100, "Martin v. Löwis" a écrit :
>
> Maybe I'm being pedantic, but I really think there should be more
> objective criteria for such things.
Well we could try to find objective criteria but I'm not sure we'll find
agreement on them.
> We could set a policy
anatoly techtonik gmail.com> writes:
>
> Unfortunately, not many people have privilege to change bug properties
> to attract attention to the issues. For example, this patch -
> http://bugs.python.org/issue7582 is ready to be committed, it is
> trivial, not a release blocker, but would be nice be
Le Thu, 11 Feb 2010 10:56:32 -0500, R. David Murray a écrit :
>
> @unittest.case_context(foo_cm)
> @unittest.test_context(foo_test_cm)
> class TestFoo(unittest.TestCase):
>
> def test_bar:
> foo = Foo(self.baz, testing=True)
> self.assertTrue("Context managers are cool")
>
>
Le Thu, 11 Feb 2010 10:36:22 -0500, Barry Warsaw a écrit :
>
> Unless other details come to light, I agree. This one isn't worth
> holding up the release for.
Ok, since everyone seems to agree on this, I've downgraded the priority
of the issue. Thanks for an insightful discussion :-)
cheers
A
Robert Collins robertcollins.net> writes:
>
> I'm not personally very keen on inspecting everything in self.__dict__,
> I suspect it would tickle bugs in other unittest extensions. However I'm
> not really /against/ it - I don't think it will result in bad test
> behaviour or isolation issues. So
Martin v. Löwis v.loewis.de> writes:
>
> Alterntively, the email notification sent to python-checkins could could
> report who the pusher was.
This sounds reasonable, assuming it doesn't disclose any private information.
Regards
Antoine.
___
Python
Martin v. Löwis v.loewis.de> writes:
>
> Georg Brandl wrote:
> > Am 13.02.2010 13:19, schrieb Antoine Pitrou:
> >> Martin v. Löwis v.loewis.de> writes:
> >>> Alterntively, the email notification sent to python-checkins could
could
> >>> rep
Le Fri, 12 Feb 2010 20:52:23 -0600, Benjamin Peterson a écrit :
> It's about time for another 3.1 bug fix release. I propose this
> schedule:
>
> March 6: Release Candidate (same day as 2.7a4)
> March 20: 3.1.2 Final release
Looks perfect to me!
Antoine.
__
Le Thu, 18 Feb 2010 22:46:41 +0100, Martin v. Löwis a écrit :
>> It's time to comment and review.
>
> Unfortunately, it's not. I strongly object to any substantial change to
> the code base without explicit approval by Fredrik Lundh.
Which most probably puts elementtree in bugfix-only mode. I don
Le Fri, 19 Feb 2010 13:49:23 -0500, Ian Bicking a écrit :
>
> * I'd rather ~/env/bin/python be a symlink instead of copying it.
How about simply adding a --prefix argument to the interpreter. Then
virtualenv can create a "python" script that simply adds --prefix and
forwards all the arguments t
Le Sat, 20 Feb 2010 13:08:39 +0100, Martin v. Löwis a écrit :
>
> Please be EXTREMELY careful. I urge you not to act on this until
> mid-March (which is the earliest time at which Fredrik has said he may
> have time to look into this).
Ok, so let's wait until then before we make a decision.
chee
Le Wed, 24 Feb 2010 12:13:10 +, Florent Xicluna a écrit :
> Hello,
>
> I am a semi-regular contributor for Python: I have contributed many
> patches since end of last year, some of them were reviewed by Antoine.
Semi-regular is quite humble. You have been cranking out patches at a
higher fre
Le Thu, 25 Feb 2010 14:38:42 -0500, Doug Hellmann a écrit :
>
> I have commit access, can I just check in the patch?
If you are sure of yourself, you can. But in this case see my comment on
the tracker.
Regards
Antoine.
___
Python-Dev mailing list
P
Le Fri, 26 Feb 2010 14:29:03 -0800, Guido van Rossum a écrit :
>
> Byte-code only wasn't always supported. We added it knowing full well it
> had all those problems (plus, it locks in the Python version), simply
> because a certain class of developers won't stop asking for it. Their
> users are ap
Le Sun, 28 Feb 2010 01:25:38 +,
Michael Foord a écrit :
>
> Well if we'd *never* had this feature this argument would be very
> strong indeed. On the other hand if we want them to switch to Python
> 3 - but by the way we cut one of the features you rely on, but don't
> worry all you have to d
Le Sun, 28 Feb 2010 21:45:56 +0100, Baptiste Carvello a écrit :
> bytecode-only in a zip is used by py2exe, cx_freeze and the like, for
> space reasons. Disabling it would probably hurt them.
Source code compresses quite well. I'm not sure it would make much of a
difference. AFAIR, when you creat
Le Sun, 28 Feb 2010 18:59:16 -0600,
Patrick Maupin a écrit :
>
> So, I do not mind the code sitting outside the standard library, and
> the PEP not reaching "Final" for several years, but I do believe that
> the PEP process is itself a really good way to build a better
> mousetrap by consensus.
Le Sun, 28 Feb 2010 19:46:30 -0600,
Patrick Maupin a écrit :
>
> I suppose I have that sort of reaction about areas I am not interested
> in, as well, but currently I am deeply interested in configuration
> files due to my circumstances. In any case, the observation that
> there are already seve
Le Sun, 28 Feb 2010 19:32:09 -0800,
Glenn Linderman a écrit :
>
> If your text editor blows up because it is binary, it is a sad text
> editor.
>
> If you have .py mapped to a text editor, that's sort of kooky too; I
> have it mapped to Python.
File extensions exist for a reason, even if you f
Le Mon, 01 Mar 2010 09:09:09 +0100,
Baptiste Carvello a écrit :
>
> I did a quick check on the stdlib: a zip with .py and .pyc is about
> 80% bigger than one with .pyc only. If you use only the bytecode,
> this can be seen as waisted space. On the other hand, if you ever
> need to debug the appli
Hello,
It seems someone has decided that code.python.org doesn't resolve
anymore.
This is annoying since there were Mercurial mirrors there
( at http://code.python.org/hg ). Until we make the official switch,
these mirrors are still useful.
Regards
Antoine.
___
Le Tue, 02 Mar 2010 22:54:25 +0100,
"Martin v. Löwis" a écrit :
>
> > This is annoying since there were Mercurial mirrors there
> > ( at http://code.python.org/hg ). Until we make the official switch,
> > these mirrors are still useful.
>
> Do you know who is in charge of creating the site? I co
Le Tue, 2 Mar 2010 17:28:11 -0800,
Raymond Hettinger a écrit :
> -1 for several reasons.
>
> 1) We've advertised -3 as part of TheOneTrueWay(tm). It's a core
> part of our transition story, so we should keep that as
> clean/consistent as possible. Deprecating the -3 switch seems like
> shooti
Le Wed, 03 Mar 2010 20:43:58 +0100,
"Martin v. Löwis" a écrit :
> > It seems someone has decided that code.python.org doesn't resolve
> > anymore.
>
> I have now restored it.
Thanks a lot!
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
ht
Le Wed, 3 Mar 2010 17:51:04 -0800,
Brett Cannon a écrit :
> On Wed, Mar 3, 2010 at 16:37, Jim Jewett wrote:
>
> > I understand the need to ship without source -- but why does that
> > require supporting .pyc (or .pyo) -only?
> >
> > Couldn't vendors just replace the real .py files with empty fil
Le Thu, 04 Mar 2010 16:22:13 +1300,
Greg Ewing a écrit :
> Glenn Linderman wrote:
>
> > In this scenario, the .pyc files would still live in __pycache__ ?
> > Complete with the foo..pyc naming ?
>
> It might be neater to have a separate cache directory
> for each bytecode version, named __cac
Le Thu, 04 Mar 2010 16:39:03 +1300,
Greg Ewing a écrit :
> Antoine Pitrou wrote:
>
> > Unless the .py files arrange to raise a syntax error on compiling.
>
> I guess that prevents a total disaster, but the
> program is still broken and you have to hunt down
> the off
Le Thu, 4 Mar 2010 23:30:12 -0500,
Barry Warsaw a écrit :
>
> If you really want to test that it's a unicode, shouldn't you
> actually test its type? (I'm not sure what would happen with that
> under 2to3.) Besides, the type of the string is very rarely
> important, so I think the u-prefix and
Le Fri, 5 Mar 2010 17:03:02 +1100,
Brian Quinlan a écrit :
>
> The PEP lives here:
> http://python.org/dev/peps/pep-3148/
Ok, here is my take on it:
> cancel()
>
> Attempt to cancel the call. If the call is currently being executed
> then it cannot be cancelled and the method will return False
Le Fri, 05 Mar 2010 13:51:15 -0500,
Neal Becker a écrit :
> I generally enjoy argparse, but one thing I find rather
> ugly and unpythonic.
>
> parser.add_argument ('--plot', action='store_true')
I would argue that a string is actually more Pythonic than
integers or anonymous objects repurpos
Le Sat, 6 Mar 2010 11:43:20 -0800,
Brett Cannon a écrit :
> I see two possible fixes for this. One is to not silence
> DeprecationWarning if Py_DivisionWarningFlag is set to >= 1. The
> other is to introduce a new subclass of DeprecationWarning called
> IntegerDivisionWarning and have that added t
Le Sun, 07 Mar 2010 11:10:52 +0100,
Stefan Behnel a écrit :
>
> Any reason the fix for bug 7173 didn't make it in? The test case that
> Amaury came up with seems to indicate that this a pretty serious
> issue.
The patch needs to properly include an unit test reproducing the test
case.
Also, a c
Le Mon, 08 Mar 2010 00:51:02 +,
Michael Foord a écrit :
>
> In other news, class and module fixtures (setUpClass /
> tearDownClass / setUpModule / tearDownModule) are now implemented in
> unittest (in trunk
> - not yet merged to py3k). These features are tested but I'm sure
> there are some
Le Mon, 08 Mar 2010 21:11:45 -,
exar...@twistedmatrix.com a écrit :
>
> Getting rid of the process-global state like this simplifies testing
> (both testing of the executors themselves and of application code
> which uses them). It also eliminates the unpleasant interpreter
> shutdown/modul
Le Fri, 12 Mar 2010 13:29:09 -0600,
s...@pobox.com a écrit :
>
> Traditionally Python has run on some (minority) platforms where C++
> was unavailable.
Is this concern still valid? We are in the 2010s now.
I'm not saying I want us to put some C++ in the core interpreter, but
the portability argum
Hello,
As some of you may know, Dave Beazley recently exhibited a situation
where the new GIL shows quite a poor behaviour (the old GIL isn't very
good either, but still a little better). This issue is followed in
http://bugs.python.org/issue7946
This situation is when an IO-bound thread wants t
Le Sat, 13 Mar 2010 17:11:41 -0600,
s...@pobox.com a écrit :
>
> If the 5ms interval is too long would it be possible to adaptively
> reduce it in this situation? How would you detect it? I assume this
> would be akin to your interactiveness computation.
I think modulating the interval is what
Le Sun, 14 Mar 2010 12:59:50 +,
Jon Ribbens a écrit :
>
> Sorry if I missed it, but why on earth is the bytecode directory
> __pycache__ and not .pycache? (Or indeed anything else that starts
> with a '.') Surely this is a classic ideal use case for a "hidden"
> directory?
I suppose the same
Le Sun, 14 Mar 2010 12:37:48 PDT,
Bill Janssen a écrit :
>
> The old GIL is causing me a great deal of grief. My server is heavily
> threaded, and when I get a number of Python 2.6 threads doing layout
> analysis, my 4 and 8 core machines turn into slow thrashers.
Have you checked whether the 2
Le Sun, 14 Mar 2010 23:11:44 +0200,
Nir Aides a écrit :
>
> I first disabled the call to spin() but client running time remained
> around 30 seconds.
> I then added TCP_NODELAY and running time dropped to a few dozen
> milliseconds for the entire no-spin run.
You don't want the benchmark to be d
Hi Kristján,
> In the new GIL, there appear to be several problems:
> 1) There is no FIFO queue of threads wanting the queue, thus thread
> scheduling becomes non-deterministic
Thread scheduling has always been non-deterministic.
> 2) The "ticking" of the GIL is
> now controled by a condition v
Le Tue, 16 Mar 2010 14:10:33 +,
Kristján Valur Jónsson a écrit :
>
> The key to this
> is implementing your GIL in such a way that you (and not the system)
> chooses which threads runs next. On Windows it works in a nice,
> determinitstic FIFO order becoause that's how the underlying Event
>
> David explained that in the issue tracker - 2.x typically doesn't do
> that much work per bytecode instruction,
Oh, but that's wrong in general.
Dave's *spinning loop* doesn't do much work per bytecode instruction,
however ;)
> The current settings mean we have less GIL overhead in the normal
Le Tue, 16 Mar 2010 17:02:13 +, Kristján Valur Jónsson a écrit :
>>
>> Well, I don't think this has ever been by design, and it's not obvious
>> this is desirable either (see Dave Beazley's benchmark).
>>
> Did Dave benchmark a straight FIFO system?
Well, he presented benchmark figures with t
Hello,
The title says it all. test_bigmem and test_bigaddrspace are partly
broken under py3k, and no buildbot ever tests that they run successfully.
As an example, here is a test_bigmem run under a 16GB machine. It gets
"killed" at some point, probably by the Linux kernel's OOM killer,
althoug
Hello,
Le mercredi 17 mars 2010 à 11:58 -0700, C. Titus Brown a écrit :
> On Wed, Mar 17, 2010 at 06:54:33PM +0000, Antoine Pitrou wrote:
> > The title says it all. test_bigmem and test_bigaddrspace are partly
> > broken under py3k, and no buildbot ever tests that they run succe
Martin v. Löwis v.loewis.de> writes:
>
> > As mentioned I have access to a 16GB machine which is able to run the
> > tests. The problem is that nobody seems interested in maintaining these
> > tests.
>
> So what do you propose to do?
Nothing. I was pointing out the issue here because it is not
Glenn Linderman g.nevcal.com> writes:
>
> For all the reasons that mixed decimal and float arithmetic is bad,
> mixed decimal and float comparisons are also bad. To do proper
> comparisons, you need to know the number of significant digits of both
> numbers, and the precision and numeric rang
Glenn Linderman g.nevcal.com> writes:
>
> On 3/18/2010 2:48 PM, Nick Coghlan wrote:
> > When there is a clear, correct way (based on Decimal.from_float) to make
> > numeric comparison behave in accordance with the rules of mathematics,
> > do we really want to preserve strange, unintuitive behavi
2601 - 2700 of 4909 matches
Mail list logo
