headers
Georg Brandl | 1 Nov 2008 18:43
Picon
Gravatar

Re: My patches

Tarek Ziadé schrieb:
> On Fri, Oct 31, 2008 at 7:46 AM, Nick Coghlan <ncoghlan <at> gmail.com> wrote:
>>>
>>> What about having two level of devs ?
>>>
>>> + core developers + standard library developers
>>>
>>> [cut]
>>
>>
>> So I'd suggest thinking about developer responsibilities more in terms
>> of areas of expertise rather than "levels" of developers. Those of us
>> that happen to understand the guts of the compiler or the VM aren't more
>> competent globally or more trusted than those maintaining the various
>> modules in the standard library - just interested in different things.
> 
> Right,
> 
> I would like to share my experience about this, if it can be helpful.
> 
> I have focused so far in distutils, which, I believe
> was not in the top priority of core developers during the last year.
> (If this is not true
> please forgive me).

I think it's safe to say that anything not directly involved in Python
3000 changes was not top priority for most core developers.

> Anyway, so I am starting to become quite specialized in this part of
> Python, and I pushed patches for it in the tracker.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maciej Fijalkowski | 1 Nov 2008 21:12
Picon

Re: Fwd: Removal of GIL through refcounting removal.

> ...

>
> We know it is the plan for PyPy to work in this way, and also that
> Jython and Ironpython works like that (using the host vm's GC), so it
> seems to be somehow agreeable with the python semantics (perhaps not
> really with __del__ but they are not really nice anyway).
>

PyPy has a semi-advanced generational moving gc these days. It's not
as well tuned as JVMs one, but it works quite well. Regarding semantic
changes, there is a couple which as far as I remember are details
which you should not rely on anyway (At least some of the below
applies also for Jython/IronPython):

* __del__ methods are not called immediately when object is not in a cycle

* all objects are collected, which means objects in cycles are broken
in arbitrary order (gc.garbage is always empty), but normal ordering
is preserved.

* id's don't always resemble address of object in memory

* resurrected objects have __del__ called only once in total.

I think for example last one is so obscure detail that if someone
relies on it it's his problem :)

Cheers,
fijal
(Continue reading)

Permalink | Reply | 8 comments |
headers
Gregory P. Smith | 1 Nov 2008 22:32
Favicon

Re: [ANN] VPython 0.1

On Fri, Oct 24, 2008 at 12:53 AM, J. Sievers <cadr4u <at> gmail.com> wrote:
> "M.-A. Lemburg" <mal <at> egenix.com> writes:
>
> [snip]
>> BTW: I hope you did not use pybench to get profiles of the opcodes.
>> That would most certainly result in good results for pybench, but
>> less good ones for general applications such as Django or Zope/Plone.
>
> Algorithm used for superinstruction selection:
>
> 1) idea: LOAD_CONST/LOAD_FAST + some suffix
> 2) potential suffixes:
>   $ grep '..*(..*--..*)$' ceval.vmg | grep 'a1 a2 --' > INSTRUCTIONS
> 3) delete any instruction that I felt wouldn't be particularly frequent
>   from INSTRUCTIONS (e.g. raise_varargs)
> 4) use awk to generate superinstruction definitions
>
> Not only is this relatively unbiased but also very low effort.
>
> -jakob
>

Thanks Jakob.  I'm glad to see that you've done this.  I had been
hoping to see super instructions tried on the python VM for years but
never found the time to do it myself.

-gps
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Coghlan | 2 Nov 2008 01:21
Picon
Gravatar

Re: Fwd: Removal of GIL through refcounting removal.

Maciej Fijalkowski wrote:
>> ...
> 
>> We know it is the plan for PyPy to work in this way, and also that
>> Jython and Ironpython works like that (using the host vm's GC), so it
>> seems to be somehow agreeable with the python semantics (perhaps not
>> really with __del__ but they are not really nice anyway).
>>
> 
> PyPy has a semi-advanced generational moving gc these days. It's not
> as well tuned as JVMs one, but it works quite well. Regarding semantic
> changes, there is a couple which as far as I remember are details
> which you should not rely on anyway (At least some of the below
> applies also for Jython/IronPython):
> 
> * __del__ methods are not called immediately when object is not in a cycle
> 
> * all objects are collected, which means objects in cycles are broken
> in arbitrary order (gc.garbage is always empty), but normal ordering
> is preserved.
> 
> * id's don't always resemble address of object in memory
> 
> * resurrected objects have __del__ called only once in total.

Yep, I'm pretty those are all even explicitly documented as
implementation details of CPython (PEP 343's with statement was largely
added as a cross-implementation way of guaranteeing prompt cleanup of
resources like file handles without relying on CPython's __del__
semantics or writing your own try/finally statements everywhere).
(Continue reading)

Permalink | Reply | 7 comments |
headers
Barry Warsaw | 2 Nov 2008 13:33
Favicon

Re: My patches


On Oct 30, 2008, at 10:22 AM, Eric Smith wrote:

> Ulrich Eckhardt wrote:
>> On Thursday 30 October 2008, Victor Stinner wrote:
>>>> One of the reasons why I'm very keen on us moving to a distributed
>>>> version control system is to help break the logjam on core  
>>>> developers.
>>> Yeah, exactly :-) Does anyone already maintain a distributed tree?
>>> Mercurial, GIT, anything else?
>> Bazaar. Take a look at the developers' pages on python.org, they  
>> mention that a BZR checkout is available. I know that it works  
>> (though the initial checkout is glacially slow) but I don't know  
>> what "official" support it has or what is planned with it.
>
> I'd like to try it out, but the instructions on http://www.python.org/dev/bazaar/ 
>  say to get wget http://code.python.org/snapshots/python-bzr-snapshot.tar.bz2 
> , which is a 404. Anyone know the actual URL?

This is fixed now.
-Barry
Permalink | Reply | 0 comments |
headers
Barry Warsaw | 2 Nov 2008 13:42
Favicon

Re: My patches


On Oct 30, 2008, at 11:04 AM, A.M. Kuchling wrote:

> On Thu, Oct 30, 2008 at 11:04:42AM +0000, Barry Warsaw wrote:
>> One of the reasons why I'm very keen on us moving to a distributed  
>> version
>> control system is to help break the logjam on core developers.   
>> True, your
>> code will still not be able to land in the "official" branch  
>> without core
>> developer intervention, but you will be able to share your code,  
>> fixes,
>> branches with everyone in a much more live way than patches in a  
>> tracker.
>
> I don't see how a DVCS will fix anything.  The bottleneck is in
> assessing patches for inclusion in the master tree; not enough people
> are doing that.  We'd just end up with lots of proposed branches
> waiting to be merged, instead of patches to be applied.

I disagree.  Dealing with patches is much more painful than dealing  
with branches.  A patch is a dead thing sitting in a tracker.  They  
easily get out of date, are difficult to apply and update, etc.  Live  
branches are much easier to review, update, track changes in the  
trunk, and share.

Yes, it still means we'll have a lot of branches to review, but the  
overhead of reviewing them and shepherding them to landing will go down.

> (What a DVCS might enable is making it easier to do larger
(Continue reading)

Permalink | Reply | 1 comment |
headers
Giovanni Bajo | 2 Nov 2008 14:26
Favicon
Gravatar

Re: Fwd: Removal of GIL through refcounting removal.

On Sun, 02 Nov 2008 10:21:26 +1000, Nick Coghlan wrote:

> Maciej Fijalkowski wrote:
>>> ...
>> 
>>> We know it is the plan for PyPy to work in this way, and also that
>>> Jython and Ironpython works like that (using the host vm's GC), so it
>>> seems to be somehow agreeable with the python semantics (perhaps not
>>> really with __del__ but they are not really nice anyway).
>>>
>>>
>> PyPy has a semi-advanced generational moving gc these days. It's not as
>> well tuned as JVMs one, but it works quite well. Regarding semantic
>> changes, there is a couple which as far as I remember are details which
>> you should not rely on anyway (At least some of the below applies also
>> for Jython/IronPython):
>> 
>> * __del__ methods are not called immediately when object is not in a
>> cycle
>> 
>> * all objects are collected, which means objects in cycles are broken
>> in arbitrary order (gc.garbage is always empty), but normal ordering is
>> preserved.
>> 
>> * id's don't always resemble address of object in memory
>> 
>> * resurrected objects have __del__ called only once in total.
> 
> Yep, I'm pretty those are all even explicitly documented as
> implementation details of CPython (PEP 343's with statement was largely
(Continue reading)

Permalink | Reply | 6 comments |
headers
Aditi Meher | 2 Nov 2008 15:40
Picon

buffer function

i am using it postgresql as back-end and HTML as front-end,i want to
display 10-10 records at a time which is there in the database using
python.so what is function for buffer that we can use it in python?i
am able to connect my databse in python,but dont know how to create
buffer in python and how to take records from tables which are there
in the database?can please provide me any kind of function or code for
buffer in python?

i have one more doubt that how to call python script in HTML?

PLEASE REPLY
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Steve Holden | 2 Nov 2008 16:38
Picon
Picon
Gravatar

Re: buffer function

Aditi Meher wrote:
> i am using it postgresql as back-end and HTML as front-end,i want to
> display 10-10 records at a time which is there in the database using
> python.so what is function for buffer that we can use it in python?i
> am able to connect my databse in python,but dont know how to create
> buffer in python and how to take records from tables which are there
> in the database?can please provide me any kind of function or code for
> buffer in python?
> 
> i have one more doubt that how to call python script in HTML?
> 
> PLEASE REPLY

Please submit this question to the comp.lang.python group (python-list
at python dot org). Python-dev is for discussion or the development *of*
Python, not development *with* Python.

regards
 Steve
--

-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antoine Pitrou | 2 Nov 2008 19:13

Re: Fwd: Removal of GIL through refcounting removal.


Hi,

Jesse Noller <jnoller <at> 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 remind that the GIL doesn't prevent (almost) true
multithreading. The only thing it prevents is full use of multi-CPU resources in
a single process. But if you are using threads to reduce latencies rather than
increase throughput, the GIL isn't really an obstacle (it probably makes things
a bit worse than a free-threading scenario, but not that much; and you can tweak
sys.setcheckinterval()).

Regards

Antoine.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 1 comment |

Gmane