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
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
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
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
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
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 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 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 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 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
>> ... 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
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
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
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
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
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
> 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
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
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
>>>
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
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
> 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
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
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
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
> +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
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
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
[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
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
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
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
> 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
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
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.
>
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 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
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 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 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
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
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
> 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
> 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.
> - 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,
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
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 à 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
> 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
>
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
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
>> 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
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
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
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
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 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,
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
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
> 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
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
61 matches
Mail list logo
