Le samedi 21 juin 2008 à 17:49 +0200, "Martin v. Löwis" a écrit :
> I don't think any strategies based on timing will be successful.
> Instead, one should count and analyze objects (although I'm unsure
> how exactly that could work).
Would it be helpful if the GC was informed of memory growth by
Greg Ewing canterbury.ac.nz> writes:
>
> What happens if the program enters a phase where it's not
> producing any new cyclic garbage, but is breaking references
> among the old objects in such a way that cycles of them
> are being left behind? Under this rule, the oldest
> generation would never
Martin v. Löwis v.loewis.de> writes:
> Currently, only youngest collections are triggered by allocation
> rate; middle and old are triggered by frequency of youngest collection.
> So would you now specify that the youngest collection should occur
> if-and-only-if a new arena is allocated? Or disco
Martin v. Löwis v.loewis.de> writes:
>
> I'd like to see in an experiment whether this is really true.
Right, all those ideas should be implemented and tried out. I don't really have
time to spend on it right now.
Also, what's missing is a suite of performance/efficiency tests for the garbage
Raymond Hettinger rcn.com> writes:
>
> * Antoine Pitrou requested that hex() and oct() be supported as well as bin().
Just to qualify this, I said that if bin() were to gain float support, the
same should probably be done for hex() and oct(). That doesn't mean I'm in
favor o
Adam Olsen gmail.com> writes:
>
> We need two counters: one is the total number of traceable objects
> (those we would inspect if we did a full collection) and a number of
> "pending" trace operations. Every time an object is moved into the
> last generation, we increase "pending" by two - once
eyal.lotem+pyutils gmail.com gmail.com> writes:
> This is exactly what my post tried to address.
> I assumed it was clear that module clearing is the wrong solution, and
> that it was also clear that due to the cycles I mentioned
> (global.__class__.__dict__['any_method'].func_globals['global'] i
eyal.lotem+pyutils gmail.com gmail.com> writes:
>
> That would be no worse than what happens now - but its still not
> perfect (__del__ ordering issues). Also, you would need to temporarily
> revive the cycles as mentioned above (to avoid accessibility of
> partially destructed objects).
The id
eyal.lotem+pyutils gmail.com gmail.com> writes:
>
> Additionally, there is another problem: If the cycle is not
> temporarily revived, and you call __del__ manually, it may break the
> cycle by removing the references.
> Thus, objects in the cycle will go down to refcount=0 during your
> attempt
Antoine Pitrou pitrou.net> writes:
>
> I was thinking a flag in the PyObject header would do the trick but there
> aren't any flags in the PyObject header... *gasp*.
Actually, we only care about GC-tracked objects (the others are deallocated
simply when their refcount falls
Hi,
> Subsequently doing a: print a[1] to get the 0x942a (鐪) actually requires
> a[2] on the 2-byte Python 3.0.
How is it annoying *in practice*? In actual code the index, instead of
being a constant, will be retrieved through various means such as .find()
or re.search().start()... as you show y
Hello,
Short story: bytearray and array.array by construction allow user code to
reallocate their internal memory buffer. But a raw pointer to the said buffer
can also be obtained by another thread, and used after releasing the GIL (for
CPU-intensive operations like compression). As a consequence
Le dimanche 06 juillet 2008 à 00:28 +0200, "Martin v. Löwis" a écrit :
> I propose that new codes s*, t*, w* are added, and that s#,t#,w# refuses
> objects which implement a releasebuffer procedure (alternatively, s# etc
> might be removed altogether right away). Users of s* then need to pass
> in
Hello,
As someone who could (perhaps) (potentially) provide a buildbot machine, there
are several questions which need answering before I take a decision:
- are more buildbots needed and if so, which kinds of platforms/architectures?
- for which software? Python itself? third-party apps and libr
Andrew Bennetts puzzling.org> writes:
>
> On the other hand, “assert*” names are positive statements of what the
> behaviour of the system-under-test is. And conversely, “fail*” names are a
> bit like implementation details of how the test is written. So I personally
> have a mild preference fo
Ben Finney benfinney.id.au> writes:
>
> That would better be written (preferring PEP 8 names)
> "fail_unless_equal".
Which is still a double negative ("fail" and "unless" are both negative words).
> That's another reason to avoid "assert" in the name: these methods
> *don't* necessarily use the
Let's split hairs a little...
Steve Holden holdenweb.com> writes:
> "Fail" isn't a negative. As Guido said, it's a description of the test
> behavior under particular circumstances.
In most circumstances, "fail" is a negative word defined as the contrary of
something else (that is, as the "fai
Steve Holden holdenweb.com> writes:
> But Guido said:
>
> > I like using only the assertKeyword variants, removing assert_, fail*,
> > and assertEquals.
>
> So we are now no longer discussing what color to paint the bike shed, we
> are discussing how to describe the color. Let's stop. This i
Ben Finney benfinney.id.au> writes:
> The following attribute names exist only as synonyms for other names.
> They are to be removed, leaving only one name for each attribute in
> the API.
Just for information, here is the current distribution of the two synonym kinds:
(on py3k)
$ grep "self.ass
Hi,
> I think some variant
> of py.test could be done that is compatable with unittest
> and the did not have the "magic" present in earlier versions of py.test.
It already exists:
http://www.somethingaboutorange.com/mrl/projects/nose/
Regards
Antoine.
___
Paul Moore gmail.com> writes:
>
> If we're setting up a variety of DVCS systems there, I'd be willing to
> set up Mercurial repos (I have my own local one, just trunk at the
> moment but py3k would be easy enough to add).
Using the convert extension or using hgsvn?
I already have public mirrors
Paul Moore gmail.com> writes:
>
> Personally, I use convert, because it's more robust on WIndows (there
> were a few commits with case clashes which hgsvn can't get past on a
> Windows box).
If the convert extension is finally usable for incremental mirroring, then it's
good news. I don't want t
Le mardi 15 juillet 2008 à 13:57 -0700, Brett Cannon a écrit :
> I can't give the privileges, Antoine, but I know that an SSH 2 public
> key is going to be needed (see the dev FAQ at
> http://www.python.org/dev/faq/ if you don't know how to generate one).
It's attached.
> They will also need to k
> So far I have "precedent and tradition" and "positive admonition looks
> better" in support of preferring the 'assert*' names. Are there any
> others?
Avoiding double negatives.
(and don't tell me "fail" is not a negative word, because you just used
the phrase "positive admonition" to refer to
Ben Finney benfinney.id.au> writes:
>
> This "fail is a negative word" has already been rebutted, by native
> speakers of English.
Well, Stephen's and Greg's own answers notwithstanding, if you really want an
authoritative answer, the best would be to open a dictionary and contrast the
given def
Ben Finney benfinney.id.au> writes:
> > * http://www.thefreedictionary.com/fail
> > "To prove deficient or lacking; perform ineffectively or inadequately; To be
> > unsuccessful"
>
> Yes. It's a verb, not a negative modifer. To use it with a negative
> like "not" is not creating a "double negativ
Steven D'Aprano pearwood.info> writes:
>
> I am interested in this suggestion. I didn't know about py.test.
>
> I admit to dissatisfaction with unittest (too Java-ish and heavyweight
> for my tastes). I would love a test suite midway in weight between
> doctests and unittest, so I will check i
Fred Drake acm.org> writes:
>
> Sounds like adding a new method, catchException(...), that returns the
> exception it catches, would be a reasonable compromise. I can't think
> of any reason that the method that catches-and-returns needs to be the
> existing API, which does something diffe
I said:
> Let's just make assertRaises return the exception instance, it seems like it
> feels the need correctly.
and I meant "fills", not "feels", obviously...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinf
Guido van Rossum python.org> writes:
>
> Thanks Barry! Indeed, I want everyone to focus on stabilization and
> release blockers (and the occasional speed-up). Be extra careful with
> what you submit between now and October, ask for a code review unless
> you're really sure. Also, remember, NO NEW
Nick Coghlan gmail.com> writes:
>
> Before beta 3, I think if we need minor features (such as re.ASCII) to
> fix fairly major bugs (re.IGNORECASE not working properly by default in
> Py3k) then they should probably go in (case by case permission still
> needed from Barry or Guido though, as wi
Victor Stinner haypocalc.com> writes:
>
> Le Monday 21 July 2008 15:33:19 A.M. Kuchling, vous avez écrit :
> > On Sun, Jul 20, 2008 at 10:45:39PM +0200, Victor Stinner wrote:
> > > Hum... how can I say it? It's trivial to crash _sre So I blacklisted
> > > _sre.compile() in my fuzzer.
> >
> > We
Hi,
> I'm making some good progress with the AST optimizer, and now the main
> thing standing in my way is lnotab. Currently lnotab expects bytecode
> sequencing to be roughly in-sync with the order of the source file and a
> few things that the optimizer does (e.g. swapping the bodies of an
Antoine Pitrou pitrou.net> writes:
>
> In http://bugs.python.org/issue2459 ("speedup for / while / if with better
> bytecode") I had the same problem and decided to change the lnotab format so
> that line number increments are signed bytes rather than unsigned.
By the w
Thomas Lee vector-seven.com> writes:
> By the way, you were right about JUMP_IF_TRUE/JUMP_IF_FALSE. It's far
> too late. Apologies.
>
> I'm still pretty sure this is the peepholer's doing,
Yes indeed.
> Which is what's being achieved with the AST optimization I originally
> proposed, right?
Facundo Batista gmail.com> writes:
>
> 2008/7/30 Matt Giuca gmail.com>:
>
> > 2. Default to UTF-8.
> > In favour: Matt Giuca, Brett Cannon, Jeroen Ruigrok van der Werven
> > Pros: Fully working and tested solution is implemented; recommended by
> > RFC 3986 for all future schemes; recommended
Martin v. Löwis v.loewis.de> writes:
>
> P.S. Just in case it isn't clear: I would oppose any specific proposal
> to add this Ascii85 algorithm to the standard library. It would sound
> like we don't have any real problems to solve.
According to Wikipedia, "its main modern use is in Adobe's Post
Le samedi 02 août 2008 à 14:07 -0700, Guido van Rossum a écrit :
> On Sat, Aug 2, 2008 at 12:58 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> > It is also used by git for diffs of binary files, and those diffs are
> > supposedly
> > understood by other VCSes like
Tres Seaver palladion.com> writes:
>
> -1. The feature exists to allow adherence to PEP-8, "Limit all lines to
> a maximum of 79 characters.", without requiring runtime concatenation
> costs. I use it frequently when assembling and testing message strings,
> for instance.
In many cases there i
Le dimanche 03 août 2008 à 20:38 +0200, Simon Cross a écrit :
> The "many cases" only extends to strings whose combined length is less
> than 20 characters:
Oops. I didn't know that. Is there any rationale (I suppose so)?
___
Python-Dev mailing list
P
Hi,
Welcome to python-3000!
> How up to date is this?
Probably way out of date.
The best way to find tasks is to go to the tracker (bugs.python.org) and search
for issues tagged with version 3.0. Preferably the "release blocker", "critical"
or "high priority" ones (there are quite a lot of them
Paul Pogonyshev gmx.net> writes:
>
> Right. But wouldn't it be easier if there was a standard Python macro
> for this, sort of like proposed Py_ASSIGN?
I proposed something similar in http://bugs.python.org/issue3081.
___
Python-Dev mailing list
Py
Martin v. Löwis v.loewis.de> writes:
> URLs are just not made for non-ASCII characters.
Perhaps they are not, but every non-English wiki (just to take a simple, generic
example) potentially contains non-ASCII URLs.
e.g. http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant
http://wiki.python.org/moin/J
Barry Warsaw python.org> writes:
>
> I agree. Our last beta is scheduled for this wednesday
Are you sure?
According to http://mail.python.org/pipermail/python-3000/2008-July/014269.html,
it's scheduled for August 23rd.
___
Python-Dev mailing list
P
Barry Warsaw python.org> writes:
>
> Ah darn, that's a typo in the PEP. I definitely meant August 13, as
> the Google calendar shows.
Ah, am I the only one *not* to use Google calendar? :)
> Do we think we can be ready for beta3 this Wednesday? If not, I'd
> rather stick to a weekday rele
Guido van Rossum python.org> writes:
>
> On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen parc.com> wrote:
> >> Is it using fork()? Threads?
> >
> > No on fork(), yes on threads.
>
> Hmm... I don't believe that io.py is thread-safe.
There is an issue open for the BufferedWriter + threads probl
Barry Warsaw python.org> writes:
> The goal
> should be to produce something like a unittest-ng, distribute it via
> the Cheeseshop, and gather consensus around it for possible inclusion
> in Python 2.7/3.1.
There is already unittest, nose, py.test, trial... perhaps others I don't know
of.
Facundo Batista gmail.com> writes:
>
> The test_raiseMemError() in test_unicode.py is complicating me the
> regression tests: tries to use all the memory in my system, which
> starts to swap as crazy, and almost freezes everything. When the test
> finishes (always pass ok), I have all the memory
Facundo Batista gmail.com> writes:
>
> I do *not* want to remove the test.
You misunderstood my remark.
If the test takes a lot of time and eats a lot of memory, it's precisely because
the MemoryError isn't raised; and the test needs MemoryError to be raised in
order to be meaningful.
I was pro
Eric Smith trueblade.com> writes:
>
> I finally backported this to 2.6 in r65814. There's a similar 30%
> speedup for the simplest cases. Unicode optimization is worse than
> string optimization, because of the way int, long, and float formatters
> work. This can be fixed, but I'm not sure
Brett Cannon python.org> writes:
> >
> > I saw those checkins go by on the checkins list - they have to do with
> > silencing -3 warnings for modules that the stdlib still uses in Python
> > 2.6 for backwards compatibility reasons (but switching to the relevant
> > new approaches in 3.0, thus maki
Mark Hammond skippinet.com.au> writes:
>
> However, test_cpickle takes a different path and doesn't see this doubling of
> the count - therefore dieing at the depth of 629 that I can see.
629 is a very low number, far lower than the default recursion limit of 1000.
Please open a bug for the prob
Hi Mark,
> I believe that this is the only path that allows us to go past an
> *actual* recursion level of 1/2 the nominated maximum value due to that
> other regression I mentioned.
I believe it's the wrong diagnosis :) If you look at
http://bugs.python.org/issue3373 and the small script I post
Facundo Batista gmail.com> writes:
>
> Two thoughts:
>
> - In view of jumping to a new standard at *this* point, what I'd like
> to have is a comprehensive test suite for unicodedata in a similar
> sense to what happens with Decimal... It would be great to have from
> the Unicode Consortium a se
Neal Norwitz gmail.com> writes:
> Can someone (else) compare performance of 2.5, 2.6, and 3.0?
Tests done on a 32-bit Linux installation on an Athlon 3600+ X2. Compiled with
gcc in UCS2 mode.
pystone
---
- 2.5: 43859.6 pystones/second
- 2.6: 42016.8 pystones/second
- 3.0: 38759.7 pystones/
Hi,
> So 3.0 is about 10% slower than 2.x. Given all the changes, that
> doesn't seem too bad.
Yes, I think it's rather good.
> > - 2.5: 770.54 ms per iteration
> > - 2.6: 572.84 ms per iteration
> > - 3.0: 566.69 ms per iteration
>
> I'm a little concerned about why the big change here. Tho
Martin v. Löwis v.loewis.de> writes:
>
> It's needed for IDNA. The IDNA RFC requires that Unicode 3.2 is used
> for performing IDNA (in particular, for determining what a valid domain
> name is).
Speaking of which, Martin, did you take a look at
http://bugs.python.org/issue3232 ?
I suppose the
M.-A. Lemburg egenix.com> writes:
>
> That's a huge slow-down compared to 2.5.
>
> Are there any obvious reasons for this ? Has the exception handling
> mechanism changed that much between 2.5 and 2.6 ?
I've looked at it a bit and I think it's because of the
issubclass()/isinstance() slowdown (
Hello,
Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at
http://code.python.org/hg/
Here are the URLs for each of the available repositories:
- http://code.python.org/hg/trunk/
- http://code.python.org/hg/branches/py3k/
- http://code.python.org/hg/branches/release2.5-maint
Benjamin Peterson gmail.com> writes:
>
> Cool! It's nice to have these become "official". My hg branches are
> all pointing to your site. Can I easily relocate the parent branch?
Just edit .hg/hgrc in your branches and modify the "default" value in the
"[paths]" section. Then "hg in" to be sure
Brett Cannon python.org> writes:
>
> But can we push branches up to our personal directories on
> code.python.org like we can with bzr?
If you have an ssh access to code.python.org, it should be easy. However, giving
other people anonymous read-only access would require some manual configuration
Antoine Pitrou pitrou.net> writes:
> > > NormalClassAttribute:339ms340ms0.28us1.111ms
> >
> > Over twice as slow?
>
> Yes, should be investigated.
>
[...]
>
> > > SpecialClassAttribute:534ms535ms0.45us
Hello everyone,
What is the rationale behind the distinction between "stable" and "unstable"
buildbots?
I ask that because the OpenBSD buildbot has failed compiling 3.0 for quite some
time, but since that buildbot was in the "unstable" bunch, it was not discovered
until someone filed a bug report
Facundo Batista gmail.com> writes:
>
> Maybe a good requisite to move a buildbot from unstable to stable is
> to find a champion for it. I mean, something that can test on that
> platform and cares enough about it to, or fix the issue
> himself/herself, or find who broke it and bother the respons
Hi,
I was working on a recursion overflow checking bug
(http://bugs.python.org/issue2548) and, while I've managed to produce a working
patch, I've also become uncomfortable with the very idea of trying to plug all
those holes just for the sake of plugging them. I'll try to explain why, by
describ
Nick Coghlan gmail.com> writes:
>
> Is this just intended to discourage subclassing? If so, why give the
> misleading impression that these things can be subclassed by naming them
> as if they were classes?
>
> How should this be handled when it comes to the addition of PEP 8
> compliant aliases
Jean-Paul Calderone divmod.com> writes:
>
> Here's a complaint. It's surprising that you can't use Event et al with
> isinstance. This is something I'm sure a lot of people run into (I did,
> many years ago) when they start to use these APIs. Once you do figure
> out why it doesn't work, it's
Nick Coghlan gmail.com> writes:
>
> Given the proximity of RC1, Antoine's option 3 (leaving the capitalised
> factory functions in both multiprocessing and threading APIs) is
> actually sounding pretty appealing to me at the moment.
I was actually suggesting this course for the threading module,
Terry Reedy udel.edu> writes:
>
> An alternative to manipulating PATH would be to make and add to the
> Start Menu a Command Prompt shortcut, call it Command Window or
> something, that starts in the Python directory.
The reason for adding the directory to the PATH is for it to be recognized i
Mark Hammond skippinet.com.au> writes:
> >
> > The reason for adding the directory to the PATH is for it to be
> > recognized in any command prompt, not only the Python-dedicated
> > command prompt shortcut.
>
> Actually, that is *your* reason for adding it to the global path.
What do you mean
Mark Hammond skippinet.com.au> writes:
>
> I mean that many Windows use the PATH, and as such, may fail if a new
> directory is added to the PATH that contains a DLL they indirectly use.
Then it's just a matter of not putting any DLLs in those directories, isn't it?
> If I *did* expect other pr
techtonik gmail.com> writes:
>
> SVN checkout over HTTPS protocol requires password. Is it intentional
> or just temporary server issue? I am behind a proxy that doesn't
> support PROPFIND requests and I can't test SVN+SSH, because 22 port is
> closed.
As a workaround, if you only need read-only
techtonik gmail.com> writes:
>
> I do not need the whole branch - only a small subset of files related
> to distutils. I know that bazaar can't do partial checkouts - it can
> only fetch the whole branch. What about mercurial?
Mercurial can't do it either. But I don't think it matters a lot; unl
Barry Warsaw python.org> writes:
>
> Here are the issues I'm not comfortable with deferring:
>
>3640 test_cpickle crash on AMD64 Windows build
There is a patch by Amaury which needs review.
> 874900 threading module can deadlock after fork
I've made a patch which needs review.
>3660
Here's an interesting blog post comparing Python performance of various versions
from 2.2.3 upto the latest 3.0 beta.
http://www.ogre.com/node/147
The fact that only Mandelbrot calculation (a hardly representative benchmark for
a high-level dynamic language such as Python) has become significant
Benjamin Peterson gmail.com> writes:
>
> That options as I see it are:
> 1. Switch the initialization order back to the original (io streams
> first) and compile _bytesio and _stringio directly into the Python
> binary. This is probably the easiest option.
Since io.py imports _bytesio and _strin
Fredrik Lundh pythonware.com> writes:
>
> So what's the new ETA? Should I set aside some time to work on the
> patches, say, tomorrow, or is it too late?
Given the state of things in the tracker, I'd say it doesn't look too late.
___
Python-Dev mai
Christian Heimes cheimes.de> writes:
>
> Ok, from the marketing perspective it's a nice catch to release 2.6 and
> 3.0 on the same day. "Python 2.6.0 and 3.0.0 released" makes a great
> headline.
It's not only the marketing. Having both releases in lock step means the
development process is sy
A.M. Kuchling amk.ca> writes:
>
> Bad news: the big slowdowns are:
[snip]
I don't get the same results, but there can be significant variations between
two pybench runs. Did use the same compiler and the same flags for both Python
versions?
___
Pytho
Nick Coghlan gmail.com> writes:
>
> That said, I'm seeing big enough swings in the percentages between runs
> that I'd like to get some tips on how to smooth out the variations -
> e.g. will increasing the warp factor increasing the amount of time each
> individual run takes?
Increasing the numb
Thomas Wouters python.org> writes:
>
> If anyone feels particularly frustrated by the old URLs breaking, I wouldn't
mind adding a redirection for each individual URL as long as I don't have to
build that mapping
Well in general URLs aren't supposed to break (except the ones which are
deliberatel
>
> Not a single one, no. The URLs *all* changed. There is not a single
> one that's the same. We may be able to do a single rewrite rule for
> most of the module-*.html URLs, but everything else -- and there is
> quite a lot of 'else' in the 2.5-and-earlier docs -- needs a better
> mapping. Feel
Christian Heimes cheimes.de> writes:
>
> Ouch! This shouldn't have happend. I'm going to discuss the matter on
> #python-dev. Perhaps --with-pydebug could add more restrict error
> checking to the Makefile like -std=c89 -pedantic -Werror
As discussed on python-dev, I think it should also be ad
Brett Cannon python.org> writes:
>
> Beats me. Are that many projects crazy enough to have that many active
> branches?
Any project using branch-driven development has many active branches. Our
specificity is that we must maintain in sync two branches (trunk, py3k) which
have widely diverged fro
Martin v. Löwis v.loewis.de> writes:
>
> > This may be more complicated than it sounds, because you'd probably
> > add a very general requirement-indicating feature to PyPI, not merely
> > a 'supports 3.0' Boolean on each record, and requirements are actually
> > pretty complicated: alternative p
Martin v. Löwis v.loewis.de> writes:
>
> Although it would be possible, I think it's not appropriate.
I also think it's inappropriate. We want people to know about the existence of
Python 3, and the best for that is to have Python 3-related information in the
standard PyPI site where people look
Raymond Hettinger rcn.com> writes:
>
> The 2.6/3.0 development process was so disruptive that I doubt
> that 2.5 received adequate attention for bug fixes. Why not wait
> two or three months for the dust to settle?
I know that I, and a couple of others, have tried to backport "important" bug
fi
Kristján Valur Jónsson ccpgames.com> writes:
> timeit.Timer("(l.sort(), l[-1])",
> s).timeit(1000)
>
> 0.29406761513791935
This is clearly wrong. l.sort() will sort the list in place when it is first
invoked, and therefore will be very fast in subsequent calls.
Compare with:
timeit.Timer("
Kristján Valur Jónsson ccpgames.com> writes:
>
> 0.39713821814841893 (old)
> 0.35184029691278162 (hakced, for special list treatment)
>
> So, there is a 12% performance boost to be had by specializing for lists.
> How about it?
It depends on the added code complexity. In any case, you shoul
Raymond Hettinger rcn.com> writes:
>
> If we wanted to go the distance and type specialize,
> it is possible to use the same ideas that used in
> Py2.6's builtin sum() to speed-up compares for particular types.
Would it be useful to create a macro that packs some of the optimizations in
http://b
A.M. Kuchling amk.ca> writes:
>
> threaded code: A technique for implementing virtual machine
> interpreters, introduced by J.R. Bell in 1973, where each op-code in
> the virtual machine instruction set is the address of some (lower
> level) code to perform the required operation.
Hi,
J. Sievers gmail.com> writes:
>
> A sequence of code such as LOAD_CONST LOAD_FAST BINARY_ADD will, in
> CPython, push some constant onto the stack, push some local onto the
> stack, then pop both off the stack, add them and push the result back
> onto the stack.
> Turning this into a superi
Steve Holden holdenweb.com> writes:
> Though it would seem redundant to create multiple copies of constant
> structures. Wouldn't there be some way to optimize this to allow each
> call to access the data from the same place?
It's just copying a table of pointers, so a bare memcpy() or its hand-
Hi,
Jesse Noller gmail.com> writes:
> If python were to have free threading, courtesy of a lack
> of the GIL, it would help those people quite a bit. Sometimes you just
> need shared state. Myself? I used multiprocess *and* threads all the
> time for various reasons.
I think it is important to
Hi Brett,
Brett Cannon python.org> writes:
>
> I have started the DVCS PEP which can be seen at
> http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there
> beyond the rationale, usage scenarios I plan to use, and what other
> sections I plan to write.
I'm not sure that's the kind
Brett Cannon python.org> writes:
>
> At this point I am looking for any suggestions for fundamental usage
> scenarios that I am missing from the PEP. If you think the few already
> listed are missing some core part of a VCS, please let me know.
You might want to refine the "patch review" scenari
Victor Stinner haypocalc.com> writes:
>
> I tried to do benchmark on all these patches using pystone or pybench, but
> the
> results are inaccurate. Pystone results change with +/- 20% with the same
> code on different runs. I tried more loops (pystone 25), but it doesn't
> change anythin
Greg Ewing canterbury.ac.nz> writes:
>
> Terry Reedy wrote:
>
> > Math is pretty much float, not int functions.
>
> Also, it's supposed to be confining itself to
> wrapping the C math library.
Too late, because we now have a math.factorial() function.
As for numbits, I think it should be a me
Mark Dickinson gmail.com> writes:
>
> Right: numbits is only a natural property of a *binary* integer.
>
> On the other hand, I can't realistically see Python ever adopting a
> non power-of-two based implementation.
No, but Python is duck-typed and alternate integer classes could adopt such an
Brett Cannon python.org> writes:
>
> It is specifically there to be overridden (and as an aside, it was a
> pain to support in the C port of warnings), so it really isn't
> monkey-patching. =)
Should we coin a new word for this? Pretty-patching?
cheers
Antoine.
__
3801 - 3900 of 4909 matches
Mail list logo
