Brett Cannon wrote:
On Sun, Nov 1, 2009 at 13:39, Raymond Hettinger wrote:
As I said: Python 2 support is not only about supporting old versions of
Python,
but also supporting users of Python2-only modules. So 2.7 support will
for the most part be a case not of supporting Python versions, bu
> The new GIL does away with this by ditching _Py_Ticker entirely and
> instead using a fixed interval (by default 5 milliseconds, but settable)
> after which we ask the main thread to release the GIL and let another
> thread be scheduled.
I've looked at this part of the implementation, and have a
On Sat, Oct 31, 2009 at 9:47 PM, Brett Cannon wrote:
> Just wanted to publicly thank everyone who has been causing all the
> checkins to fix and stabilize the test suite (I think it's mostly
> Antoine and Mark, but I could be missing somebody; I'm under a
> deadline so only have marginal higher br
Cameron Simpson zip.com.au> writes:
>
> Personally, I'm for the iteration spec in a lot of ways.
>
> Firstly, a .get()/.pick() that always returns the same element feels
> horrible. Is there anyone here who _likes_ it?
I do. Since the caller is asking for an arbitrary element, returning the sam
Martin v. Löwis skrev:
b) notice that, on Windows, minimum wait resolution may be as large as
15ms (e.g. on XP, depending on the hardware). Not sure what this
means for WaitForMultipleObjects; most likely, if you ask for a 5ms
wait, it waits until the next clock tick. It would be bad if,
Sturla Molden wrote:
> Martin v. Löwis skrev:
>> b) notice that, on Windows, minimum wait resolution may be as large as
>>15ms (e.g. on XP, depending on the hardware). Not sure what this
>>means for WaitForMultipleObjects; most likely, if you ask for a 5ms
>>wait, it waits until the nex
Martin v. Löwis v.loewis.de> writes:
>
> I've looked at this part of the implementation, and have a few comments.
> a) why is gil_interval a double? Make it an int, counting in
>microseconds.
Ok, I'll do that.
> b) notice that, on Windows, minimum wait resolution may be as large as
>15m
Hi,
all your points are valid -- for the experienced Python programmer who has
stumbled across this issue already and solved it in one of several ways. All
your points, however, do not support the "one obvious way to do it" philosophy
of Python. It's all about making Python even more clean and
twistedmatrix.com> writes:
>
> Starting with a mainstream distro doesn't seem like a bad idea. For
> example, there isn't currently a 32bit Ubuntu (any version) slave. That
> would be a nice gap to fill in, right?
I've setup a buildslave on an EC2 Ubuntu Karmic instance here:
http://www.pyth
>> c) is the gil_drop_request handling thread-safe? If your answer is
>>"yes", you should add a comment as to what the assumptions are of
>>this code (ISTM that multiple threads may simultaneously attempt
>>to set the drop request, overlapping with the holding thread actually
>>drop
Martin v. Löwis v.loewis.de> writes:
>
[gil_drop_request]
> Even if it is read from memory, I still wonder what might happen on
> systems that require explicit memory barriers to synchronize across
> CPUs. What if CPU 1 keeps reading a 0 value out of its cache, even
> though CPU 1 has written an
Antoine Pitrou wrote:
> Cameron Simpson zip.com.au> writes:
>> Personally, I'm for the iteration spec in a lot of ways.
>>
>> Firstly, a .get()/.pick() that always returns the same element feels
>> horrible. Is there anyone here who _likes_ it?
>
> I do. Since the caller is asking for an arbitrar
> I've setup a buildslave on an EC2 Ubuntu Karmic instance here:
> http://www.python.org/dev/buildbot/all/buildslaves/pitrou-ubuntu
>
> However, since it's right now billed on my credit card, I'll shut it down in a
> couple of days. I wonder how we can get the PSF to be billed instead of me, if
>
Le lundi 02 novembre 2009 à 13:31 +0100, "Martin v. Löwis" a écrit :
>
> There was discussion that an EC2 instance can be turned on only when
> needed, so we could try to set up something like that (the build master
> could then trigger activation of the machine, IIUC). However, it might
> be that
On Nov 2, 2009, at 6:30 AM, Antoine Pitrou wrote:
twistedmatrix.com> writes:
Starting with a mainstream distro doesn't seem like a bad idea. For
example, there isn't currently a 32bit Ubuntu (any version) slave.
That
would be a nice gap to fill in, right?
I've setup a buildslave on an
Le lundi 02 novembre 2009 à 07:42 -0500, sstein...@gmail.com a écrit :
>
> If you could send me the script that you used to set it up, I could
> give it a shot on RackSpace where it's cheaper (and I have a temporary
> developer account).
There's no need for a special script, really.
Install P
> - all machines Python runs on should AFAIK be cache-coherent: CPUs synchronize
> their views of memory in a rather timely fashion.
Ok. I thought that Itanium was an example where this assumption is
actually violated (as many web pages claim such a restriction), however,
it seems that on Itanium,
> An always-on "small" EC2 instance is at least 500$ a year, with a small
> storage cost added to that.
OTOH, that isn't that expensive (compared to the other PSF expenses),
plus people keep donating money, so when we say what we use it for,
there may be a larger return than just the test results.
> OTOH, that isn't that expensive (compared to the other PSF expenses),
> plus people keep donating money, so when we say what we use it for,
> there may be a larger return than just the test results.
>
> OTTH, the same could be achieved by buying a hosted server elsewhere.
One advantage of a re
On Mon, Nov 2, 2009 at 8:06 AM, Antoine Pitrou wrote:
>
>> OTOH, that isn't that expensive (compared to the other PSF expenses),
>> plus people keep donating money, so when we say what we use it for,
>> there may be a larger return than just the test results.
>>
>> OTTH, the same could be achieved
Martin v. Löwis skrev:
Maybe you should study the code under discussion before making such
a proposal.
I did, and it does nothing of what I suggested. I am sure I can make the
Windows GIL
in ceval_gil.h and the mutex in thread_nt.h at lot more precise and
efficient.
This is the kind of code
Sturla Molden molden.no> writes:
>
> And the timeout "milliseconds" would now be computed from querying the
> performance
> counter, instead of unreliably by the Windows NT kernel.
Could you actually test your proposal under Windows and report what kind of
concrete benefits it brings?
Thank yo
Sturla Molden skrev:
I would turn on multimedia timer (it is not on by default), and
replace this
call with a loop, approximately like this:
for (;;) {
r = WaitForMultipleObjects(2, objects, TRUE, 0);
/* blah blah blah */ QueryPerformanceCounter(&cnt);if (cnt >
timeout) break;
Sturla Molden skrev:
And just so you don't ask: There should not just be a Sleep(0) in the
loop, but a sleep that gets shorter and shorter until a lower
threshold is reached, where it skips to Sleep(0). That way we avoid
hammering om WaitForMultipleObjects and QueryPerformanceCounter more
th
Sturla Molden molden.no> writes:
>
> By the way Antoine, if you think granularity of 1-2 ms is sufficient,
It certainly is.
But once again, I'm no Windows developer and I don't have a native Windost host
to test on; therefore someone else (you?) has to try.
Also, the MSDN doc (*) says timeBegi
Antoine Pitrou skrev:
It certainly is.
But once again, I'm no Windows developer and I don't have a native Windost host
to test on; therefore someone else (you?) has to try.
I'd love to try, but I don't have VC++ to build Python, I use GCC on
Windows.
Anyway, the first thing to try then is t
Sturla Molden wrote:
> Antoine Pitrou skrev:
>> It certainly is.
>> But once again, I'm no Windows developer and I don't have a native
>> Windost host
>> to test on; therefore someone else (you?) has to try.
>>
> I'd love to try, but I don't have VC++ to build Python, I use GCC on
> Windows.
>
Sturla Molden molden.no> writes:
>
> I'd love to try, but I don't have VC++ to build Python, I use GCC on
> Windows.
You can use Visual Studio Express, which is free (gratis).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
> I did, and it does nothing of what I suggested. I am sure I can make the
> Windows GIL in ceval_gil.h and the mutex in thread_nt.h at lot more precise
> and
> efficient.
Hmm. I'm skeptical that your code makes it more accurate, and I
completely fail to see that it makes it more efficient (by wh
On Mon, Nov 2, 2009 at 11:27 AM, "Martin v. Löwis" wrote:
> Hmm. This creates a busy wait loop; if you add larger sleep values,
> then it loses accuracy.
>
I thought that at first, too, but then I checked the documentation for
Sleep(0):
"A value of zero causes the thread to relinquish the remain
On Mon, Nov 2, 2009 at 4:15 AM, Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>>
> [gil_drop_request]
>> Even if it is read from memory, I still wonder what might happen on
>> systems that require explicit memory barriers to synchronize across
>> CPUs. What if CPU 1 keeps reading a
I'm -0 on backporting nonlocal to 2.7. I could be +0 if we added "from
__future__ import nonlocal_keyword" (or some such phrasing) to enable
it.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
[Guido van Rossum]
I'm -0 on backporting nonlocal to 2.7. I could be +0 if we added "from
__future__ import nonlocal_keyword" (or some such phrasing) to enable
it.
With the "from __future__" option, what keeps you from being
a full +1 on nonlocal? Is there something that makes it a better
so
On Mon, Nov 2, 2009 at 10:06 AM, Raymond Hettinger wrote:
>
> [Guido van Rossum]
>>
>> I'm -0 on backporting nonlocal to 2.7. I could be +0 if we added "from
>> __future__ import nonlocal_keyword" (or some such phrasing) to enable
>> it.
>
> With the "from __future__" option, what keeps you from b
Martin v. Löwis skrev:
I did, and it does nothing of what I suggested. I am sure I can make the
Windows GIL in ceval_gil.h and the mutex in thread_nt.h at lot more precise and
efficient.
Hmm. I'm skeptical that your code makes it more accurate, and I
completely fail to see that it makes it
> +lots on adding a module field (independent of automatically adding
> maintainers to the nosy list, it would assist in "I just did a major
> cleanup of module X, are there any old bugs I can kill off").
Link (1:1) or Multilink (1:n)? What is the impact on the Component field?
Would you be willi
s...@pobox.com wrote:
> Brett> Another summit, another potential time to see if people want to
> Brett> change anything about the issue tracker.
>
> I have no idea how hard this would be to implement and won't be at the
> language summit to formally present the idea, but it seems to me tha
On Mon, 2 Nov 2009 at 10:09, Guido van Rossum wrote:
On Mon, Nov 2, 2009 at 10:06 AM, Raymond Hettinger wrote:
[Guido van Rossum]
I'm -0 on backporting nonlocal to 2.7. I could be +0 if we added "from
__future__ import nonlocal_keyword" (or some such phrasing) to enable
it.
With the "from
I've updated PEP 373 with my proposed release schedule:
- 2.7/3.2 alpha 1 2009-12-05
- 2.7/3.2 alpha 2 2010-01-09
- 2.7/3.2 alpha 3 2010-02-06
- 2.7/3.2 alpha 4 2010-03-06
- 2.7/3.2 beta 1 2010-04-03
- 2.7/3.2 beta 2 2010-05-01
- 2.7/3.2 rc1 2010-05-29
- 2.7/3.2 rc2 2010-06-12
- 2.7/3.2 final 2010
> I don't currently have an opinion on this backport proposal, but in
> regard to this argument: if we do not do any 2.x releases after 2.7,
> then over time the number of packages that can afford to drop 2.6 support
> will grow, yet many will need to retain 2.7 support for much longer.
I don't t
On Mon, 2 Nov 2009 at 22:17, "Martin v. L?wis" wrote:
I don't currently have an opinion on this backport proposal, but in
regard to this argument: if we do not do any 2.x releases after 2.7,
then over time the number of packages that can afford to drop 2.6 support
will grow, yet many will need t
On Mon, Nov 2, 2009 at 1:27 PM, R. David Murray wrote:
> On Mon, 2 Nov 2009 at 22:17, "Martin v. Löwis" wrote:
>>>
>>> I don't currently have an opinion on this backport proposal, but in
>>> regard to this argument: if we do not do any 2.x releases after 2.7,
>>> then over time the number of pack
R. David Murray wrote:
> On Mon, 2 Nov 2009 at 22:17, "Martin v. Löwis" wrote:
>>> I don't currently have an opinion on this backport proposal, but in
>>> regard to this argument: if we do not do any 2.x releases after 2.7,
>>> then over time the number of packages that can afford to drop 2.6
>>>
Guido van Rossum python.org> writes:
>
> Is it even wort doing a 2.7 release? Isn't the effort better spent on
> 3.2 alone? (Note, these aren't rhetorical questions. It's well
> possible that there are good reasons for pushing along with 2.7. Maybe
> considering those reasons will also help answe
> Is it even wort doing a 2.7 release? Isn't the effort better spent on
> 3.2 alone? (Note, these aren't rhetorical questions. It's well
> possible that there are good reasons for pushing along with 2.7. Maybe
> considering those reasons will also help answering questions about
> whether to backpor
On Wed, Oct 7, 2009 at 11:26 AM, Olemis Lang wrote:
> On Wed, Oct 7, 2009 at 10:49 AM, Vinay Sajip wrote:
>> Olemis Lang gmail.com> writes:
>>
>>> This kind of problems is similar to the one mentioned in another
>>> thread about modifying config options after executing commands. In
>>> that case
Cameron Simpson wrote:
Personally, I'm for the iteration spec in a lot of ways.
Firstly, a .get()/.pick() that always returns the same element feels
horrible. Is there anyone here who _likes_ it?
It doesn't sound very useful to me. However, an iterating
version of it doesn't sound any more us
Not that anyone has asked yet, but here's my opinion on two issues
that have been raised on the python-dev mailing list lately:
+1 on 2.7 release with as much 3.0 "easy-port goo" as is practicable
without delaying the product beyond the tentative schedule. Sooner
would, of course, be bett
On Nov 2, 2009, at 6:24 PM, sstein...@gmail.com wrote:
+1 on 2.7 being the last of the 2.x series. Enough already!
-1. (not that it matters)
I, personally, haven't even written my first line of 3.x code, nor
have I had any good reason to.
Me neither.
If I saw the actual end of
James> 2.x seems to be a fine edition of Python, why not let it keep
James> going to 2.8 and beyond?
Resources would be my guess. In much the same way that people move on to
newer releases of Windows, Mac OSX or Linux leaving an ever-dwindling group
available to support old versions, the
>> ... it seems to me that some integration between the issue tracker
>> and Rietveld would be beneficial.
Martin> See
Martin> http://psf.upfronthosting.co.za/roundup/meta/issue247
Cool. I still haven't used Rietveld for anything, though I am getting
comfortable with Review Boar
On Nov 2, 2009, at 7:26 PM, James Y Knight wrote:
It really sounds like you're saying that switching to 3.x isn't
worth the cost to you, but you want to force people (including
yourself) to do so anyways, because ...?
Because that's the future of Python, where the developers who make
re
On Mon, Nov 2, 2009 at 16:26, James Y Knight wrote:
>
> On Nov 2, 2009, at 6:24 PM, sstein...@gmail.com wrote:
>
>> +1 on 2.7 being the last of the 2.x series. Enough already!
>
> -1. (not that it matters)
>
>> I, personally, haven't even written my first line of 3.x code, nor have I
>> ha
On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
A better language, i.e. Python 3.x, will become better faster
without dragging the 2.x series out any longer.
If Python 2.7 becomes the last of the 2.x series, then I personally
favor back porting as many features from Python 3 as poss
On Nov 2, 2009, at 11:28 PM, Barry Warsaw wrote:
On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
A better language, i.e. Python 3.x, will become better faster
without dragging the 2.x series out any longer.
If Python 2.7 becomes the last of the 2.x series, then I personally
favor
On Mon, Nov 2, 2009 at 9:51 PM, sstein...@gmail.com wrote:
> BeautifulSoup, which I use every day, is one such product. Since the crappy
> old SMGL parser's gone, BeautifulSoup uses the one that's left in Python 3
> and it makes BeautifulSoup completely useless for my daily work.
This sounds an
On Nov 3, 2009, at 12:06 AM, Guido van Rossum wrote:
Though I imagine what
it really needs is a "quirks mode" parser that is compatible with the
HTML dialect accepted by, say, IE6. Maybe a summer of code project?
Already exists: html5lib.
http://code.google.com/p/html5lib/
Or if you want a fa
Barry Warsaw wrote:
> On Nov 2, 2009, at 10:48 PM, sstein...@gmail.com wrote:
>
>> A better language, i.e. Python 3.x, will become better faster without
>> dragging the 2.x series out any longer.
>
> If Python 2.7 becomes the last of the 2.x series, then I personally
> favor back porting as many
I'd just like to mention that the scientific community is highly
dependent on NumPy. As long as NumPy is not ported to Py3k, migration is
out of the question. Porting NumPy is not a trivial issue. It might take
a complete rewrite of the whole C base using Cython. NumPy's ABI is not
even PEP 311
On 02Nov2009 10:21, Antoine Pitrou wrote:
| Cameron Simpson zip.com.au> writes:
| >
| > Personally, I'm for the iteration spec in a lot of ways.
| >
| > Firstly, a .get()/.pick() that always returns the same element feels
| > horrible. Is there anyone here who _likes_ it?
|
| I do. Since the c
On Mon, Nov 2, 2009 at 2:18 AM, Mark Dickinson wrote:
> On Sat, Oct 31, 2009 at 9:47 PM, Brett Cannon wrote:
>> Just wanted to publicly thank everyone who has been causing all the
>> checkins to fix and stabilize the test suite (I think it's mostly
>> Antoine and Mark, but I could be missing some
61 matches
Mail list logo
