[Python-Dev] Nab those release blockers!
As we approach the planned first betas for 2.6/3.0, my heart sinks when I see the imposing list of 16 release blockers. [1] Luckily, most of the issues have patches that just need *your* review. Others, namely the Py3k exception issues, may require a little more discussion, but I'm sure we can get it done. Let's get this release on time! [clapping] [1] http://bugs.python.org/issue?%40sort0=activity&%40sortdir0=on&%40sort1=&%40group0=&%40group1=&%40columns=title%2Cid%2Cactivity%2Cversions%2Cstatus&%40filter=priority%2Cstatus&priority=1&status=1&%40pagesize=50&%40startwith=0 -- Thanks Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
On Fri, Jun 6, 2008 at 2:19 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > On 2008-06-03 01:29, Gregory P. Smith wrote: > >> On Mon, Jun 2, 2008 at 4:09 PM, Guido van Rossum <[EMAIL PROTECTED]> >> wrote: >> >> I will freely admit that I haven't followed this thread in any detail, >>> but if it were up to me, I'd have the 2.6 internal code use PyString >>> >> >> ... >> >> Should we read this as a BDFL pronouncement and make it so? >> >> All that would mean change wise is that trunk r63675 as well as possibly >> r63672 and r63677 would need to be rolled back and this whole discussion >> over if such a big change should have happened would turn into a moot >> point. >> > > I would certainly welcome reverting the change. > > All that's needed to support PyBytes API in 2.x is a set of #defines > that map the new APIs to the PyString names. That's a clean and > easily understandable solution. > Okay, I've reverted r63675 in trunk revision r64048. That leaves all of the python modules and internals using PyString_ api names instead of PyBytes_ api names as they were before. PyBytes_ #define's exist for the appropriate PyString methods incase anyone wants to use those. Programmers interested in the code > for a PyString API can then still look up the code in stringobject.c, > e.g. to find out how a certain special case is handled or to check > the ref counting - just like they did for years. The files still exist with the new names. bytesobject.c instead of stringobject.c. Those renames were done in the other CLs i mentioned which have not yet been reverted. The current state seems a bit odd because they depend on the #defines to cause method definitions to be the PyString_ names instead of the PyBytes_ names. > > > Developer who want to start differentiating between mixed byte/text > data and bytes-only can start using PyBytes for byte data. > > I would also add macros that map the PyBytes_* APIs to PyString_*, but >>> I would not start using these internally except in code newly written >>> for 2.6 and intended to be "in the spirit of 3.0". IOW use PyString >>> for 8-bit strings containing text, and PyBytes for 8-bit strings >>> containing binary data. For 8-bit strings that could contain either >>> text or data, I'd use PyString, in the spirit of 2.x. >>> >> > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Assignment to None
> So, it's okay to setattr the attribute name "None" but not okay to set > it directly? Is this deliberate or is it an unintentional side effect > of parser changes to prevent assignment to None? It's deliberate. setattr(o, "foo bar", "baz") also works, even though "foo bar" is not an identifier. setattr doesn't take the Python grammar into account, but only the object's structure. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Assignment to None
On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote: > So, it's okay to setattr the attribute name "None" but not okay to > set it directly? I suspect this is off-topic for python-dev, and would be better on comp.lang.python or similar, but for what it's worth, I consider having an attribute named 'None' bad practise, regardless of any runtime checks. But as part of Python's "we're all consenting adults here" philosophy, I wouldn't approve of expensive or extensive run-time checks specifically to prevent it. If you really have to name your attribute None, and are prepared to live with the consequences, then go ahead. In a similar fashion: >>> class Parrot(object): ... pass ... >>> p = Parrot() >>> p.1 = 'spam' File "", line 1 p.1 ^ SyntaxError: invalid syntax >>> setattr(p, '1', 'spam') >>> -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Assignment to None
On Sun, Jun 8, 2008 at 9:24 PM, Curt Hagenlocher <[EMAIL PROTECTED]> wrote: > My apologies if this is one of those "dead horse" issues. The > following seems a little inconsistent to me: > c = C() c.None > Traceback (most recent call last): > File "", line 1, in > AttributeError: C instance has no attribute 'None' c.None = 'foo' > File "", line 1 > SyntaxError: assignment to None setattr(c, 'None', 'foo') c.None > 'foo' > > So, it's okay to setattr the attribute name "None" but not okay to set > it directly? Is this deliberate or is it an unintentional side effect > of parser changes to prevent assignment to None? I believe that runtime checks like the one needed for setattr would be too much of a performance hit to be practical. The syntax changes are meant to avoid mistakes and confusion rather than completely prevent something from ever happening. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Assignment to None
My apologies if this is one of those "dead horse" issues. The following seems a little inconsistent to me: >>> c = C() >>> c.None Traceback (most recent call last): File "", line 1, in AttributeError: C instance has no attribute 'None' >>> c.None = 'foo' File "", line 1 SyntaxError: assignment to None >>> setattr(c, 'None', 'foo') >>> c.None 'foo' >>> So, it's okay to setattr the attribute name "None" but not okay to set it directly? Is this deliberate or is it an unintentional side effect of parser changes to prevent assignment to None? -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL cpu usage problem, confirm me
On Sun, 8 Jun 2008 08:37:20 -0500, Benjamin Peterson <[EMAIL PROTECTED]> wrote: Certainly not in core Python. Have a look http://code.google.com/p/python-threadsafe/, though. http://code.google.com/p/python-safethread/ Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL cpu usage problem, confirm me
On Sun, Jun 8, 2008 at 6:15 AM, Pau Freixes <[EMAIL PROTECTED]> wrote: > Hi List, > > Surly this is a recurring theme into python dev world, but I need your help > for confirm if the follow image it's really > > http://www.milnou.net/~pfreixes/img/cpu_usage_gil_problem.png > > I'm writing a brief article for my blog and I need to make sure about the > current problem with GIL and multi core environments, this picture try to > explain with images the problem for scheduling multiple threads running > python code of same interpreter into multiple cpu cores. Can anyone confirm > to me this picture ? > > And if it's possible answer this two questions I will be happy :/ Next time, comp.lang.python would be the place to ask these questions. > > 1) When this situation it's produced into one core environment whats happens > when thread library or os switch context into other python thread and this > don't have a GIL ? They run together. > > 2) Exist some PEP or plans for modify this and run multiple thread python > for same interpreter at current time ? for python 3000? Certainly not in core Python. Have a look http://code.google.com/p/python-threadsafe/, though. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] GIL cpu usage problem, confirm me
Hi List, Surly this is a recurring theme into python dev world, but I need your help for confirm if the follow image it's really http://www.milnou.net/~pfreixes/img/cpu_usage_gil_problem.png I'm writing a brief article for my blog and I need to make sure about the current problem with GIL and multi core environments, this picture try to explain with images the problem for scheduling multiple threads running python code of same interpreter into multiple cpu cores. Can anyone confirm to me this picture ? And if it's possible answer this two questions I will be happy :/ 1) When this situation it's produced into one core environment whats happens when thread library or os switch context into other python thread and this don't have a GIL ? 2) Exist some PEP or plans for modify this and run multiple thread python for same interpreter at current time ? for python 3000? Thanks and excuse for this break. -- Pau Freixes Linux GNU/User ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
