Re: [Python-Dev] Save file by using file() function and fileDialog()

[Amaury Forgeot d'Arc]

Hello,

On Thu, Oct 30, 2008 at 07:35, Sonia <[EMAIL PROTECTED]> wrote:
>
> I m using fileDialog(self, message, path, filename, filter,
> aStyle(opotional)) to save the file.
> In my code, i used fileDialog to show save dialog box and when we click on
> save button, it should save that file which is of txt type (filter =
> '*.txt'). But when we click on save button it returns error: "coercing to
> unicode: need string or buffer, list found" rather than saving / creating a
> file. I also tried f = file(myfile, 'w', 1000) instead of f = file(myfile,
> 'w'), where 1000 is buffer size, but both have the same error. where as if
> we use
> file( filename[, mode[, bufsize]])
> , then it creates a file of specified type. But it is not working in
> fileDialog(). Why?Where i m wrong?
>
> What should i do?
>
> Following is my code:
> def on_btn2_mouseClick(self, event):
> aStyle = wx.SAVE|wx.HIDE_READONLY|wx.OVERWRITE_PROMPT
> filter = '*.txt'
> result = dialog.fileDialog(self, 'ist def', '', 'n', wildcard,
> aStyle)
> myfile= result.paths
> if result.accepted == True :
> f = file(myfile, 'w')
> f.write('my file')
> f.close()

The python-dev mailing list is about the development of Python, not
the development with Python.

Please send this kind of questions to the comp.lang.python newsgroup,
or the wxPython-users mailing list.
There are many python users there willing to help.

Furthermore wxPython is not developed here (or is it PythonCard?), so
you'll get little expertise from us.

(a hint however: "result.paths" likely returns a list of paths; try
"result.paths[0]" to get a file name)
-- 
Amaury Forgeot d'Arc
___
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] My patches

[Victor Stinner]

Hi,

Since some months, I'm trying to improve Python but it's difficult because I'm 
not allowed to push patches and I have to wait for some reviews and then for 
someone interrested by my patches. Sometimes I just get a good reaction 
like "nice patch" and then nothing. Should I stop sending new patches and 
work on another project, improve old patches and send an email everydays to 
the mailing list to get some reaction?

Barry doesn't want to release Python 3.0rc2 because of release blocker issues. 
Guido asked if the mailing list has collapsed.

I don't understand: you want help, but some of my patches are waiting since 
many weeks ago... The problem is not just about me, but about anyone trying 
to contribute to Python: if it's to hard to contribute, people would just 
move to another more reactive project.

---

Well, here is a short list of my patches waiting to be commited:

http://bugs.python.org/issue3727 (fix poplib for python3)
 + patch posted 13 days ago

http://bugs.python.org/issue1210 (fix imaplib for python3)
 + patch posted 16 days ago

http://bugs.python.org/issue4036 (support bytes for subprocess.Popen)
 + patch posted 22 days ago

http://bugs.python.org/issue4021 (improve tokenize.detect_encoding)
 + patch posted 28 days ago
 + reviewed by amaury

http://bugs.python.org/issue4008 (IDLE: unicode fix checksyntax())
 + patch posted 28 days ago

http://bugs.python.org/issue3954 (fix _hotshot.logreader)
 + patch posted 39 days ago
 + reviewed by amaury and georg.brandl

http://bugs.python.org/issue3880 (fix _tkinter._flatten)
 + patch posted 44 days ago
 + reviewed by gpolo

http://bugs.python.org/issue3632 (ensure GIL in _PyObject_Dump)
 + patch posted 70 days ago
 + reviewed by amaury

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] My patches

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 30, 2008, at 11:08 AM, Victor Stinner wrote:

>Since some months, I'm trying to improve Python but it's difficult because
>I'm not allowed to push patches and I have to wait for some reviews and then
>for someone interrested by my patches. Sometimes I just get a good reaction
>like "nice patch" and then nothing. Should I stop sending new patches and
>work on another project, improve old patches and send an email everydays to
>the mailing list to get some reaction?
>
>Barry doesn't want to release Python 3.0rc2 because of release blocker
>issues. Guido asked if the mailing list has collapsed.
>
>I don't understand: you want help, but some of my patches are waiting since 
>many weeks ago... The problem is not just about me, but about anyone trying 
>to contribute to Python: if it's to hard to contribute, people would just 
>move to another more reactive project.

Victor, don't despair!  Your contributions are appreciated.

Let me remind you though that I've been mostly unavailable for the past two
weeks at a work conference.  I won't have time to look at anything until
Monday at the earliest.  That's why I set the 3.0 schedule the way I did.

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.  It
will be much easier for others to merge your changes, test them, review them,
etc. and it will be much easier for you to track changes in the official trunk
as other code lands.

In any case, I know it's frustrating not to get good timely feedback, but such
is the nature of open source projects.  Please be patient and don't worry.
I'll look at your patches when I'm back in the real world.

- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkJlMoACgkQ2YZpQepbvXG0DgCePlFiKrAH/UQkQhLb8Mr7dwtd
mmUAoJN2pOJN40fOQ0otMSgeVCt5sqLL
=Mnta
-END PGP SIGNATURE-
___
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] My patches

[Victor Stinner]

> Let me remind you though that I've been mostly unavailable for the past two
> weeks at a work conference.

Cool, you're back :-) But my email was not against you.

> That's why I set the 3.0 schedule the way I did.

Personnaly, I don't want to get python 3.0 final with some broken modules or 
some criticial problems. So it's a good thing to delay the release until bugs 
are fixed.

> 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? I tried Mercurial which is nice (at least some small 
project). But I think that GIT is the fatest and most robust system.

> you will be able to share your code, fixes, branches with everyone 
> in a much more live way than patches in a tracker.

Right and it's very difficult to manage patches using the tracker. After 
writing the patch, I have to revert all patches to be able to write a new 
patch because it's easier to generate a patch in this way. But some patches 
depend on other patches :-/

> In any case, I know it's frustrating not to get good timely feedback

A friend told me that his patch took 6 months to be applied :-/ (don't know 
which one)

If Python would be more reactive, more developer will be attracted. The 
communication is very important in an open source project. I contributed to 
many many projects, and I can say that Python is already one of the most 
reactive project! But it can be better ;-)

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] My patches

[Ulrich Eckhardt]

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.

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.

**

___
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] My patches

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:

>> Let me remind you though that I've been mostly unavailable for the past two
>> weeks at a work conference.
>
>Cool, you're back :-) But my email was not against you.

Well, not quite. :)  Monday.

>> 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? I tried Mercurial which is nice (at least some small 
>project). But I think that GIT is the fatest and most robust system.

We have experimental Bazaar and Mercurial mirrors of the various branches.
I've just put up a loggerhead (think ViewCVS for Bazaar) instance on
code.python.org.  http://code.python.org.  I haven't installed pysqlite yet on
that box, but when I do, it will be much more responsive.  (I also haven't
installed the init.d script yet so if it dies, let me know and I'll restart
it.)

Please note that these are *expermental*.  We have not officially chosen a
dvcs, or even decided that we're moving to one.  Brett as the head of the
infrastructure committee will have more to say about that.

>Right and it's very difficult to manage patches using the tracker. After 
>writing the patch, I have to revert all patches to be able to write a new 
>patch because it's easier to generate a patch in this way. But some patches 
>depend on other patches :-/

I think you will like using Bazaar^H^H^H^H^H^Ha dvcs :).

>If Python would be more reactive, more developer will be attracted. The 
>communication is very important in an open source project. I contributed to 
>many many projects, and I can say that Python is already one of the most 
>reactive project! But it can be better ;-)

I agree!  How can we improve our development process, given that we're an all
volunteer organization?

- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkJrYcACgkQ2YZpQepbvXGrgQCeIQV+n81qpZw/CaG3kzdCVYyU
RzYAn2lxqzwZ5QwBw38RkyNsix++h9iI
=O9T4
-END PGP SIGNATURE-
___
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] My patches

[Nick Coghlan]

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.

It's kept up to date, and will eventually move to a more complete DVCS
experiment (there are also mercurial and git mirrors being maintained,
but they haven't been linked from python.org yet - a trawl through the
python-dev archives should turn up the links to the URLs).

The PSF's infrastructure committee isn't that big though (and all
volunteers), and switching version control systems isn't exactly easy
(even the migration from Sourceforge CVS to python.org SVN took quite a
bit of effort from key people). The migration of all our regular
workflows from the familiar centralised VCS style to a DVCS style of
development promises to be pretty disruptive in the short term, no
matter how beneficial it will be in the long run.

That said, with the tracker migration from Sourceforge to Roundup behind
us, and a hopefully successful 3.0 release not too far away, it's
probably time to start giving the idea more serious thought.

Ultimately, any complete plan for migration from SVN to a DVCS will
likely need to come in the form of a meta-PEP like the one MvL wrote to
justify and document the migration from CVS to SVN:
http://www.python.org/dev/peps/pep-0347/

Unlike PEP 347 (where SVN was purpose built as a "better CVS", thus
making the overall migration path and workflow updates reasonably
straightforward), a PEP for migrating to a DVCS would need to provide
justification not only for moving to a DVCS in general, but also for the
choice of a particular DVCS. Similar to the exercise in selecting
Roundup, part of that would not only be the features of the tool itself,
but also the available volunteer expertise to maintain an instance of it
on python.org.

One thing that such a PEP could probably also use is additional feedback
from folks outside the core dev team on how a DVCS would benefit them
(since the core devs are the ones least affected by the limitations of a
centralised VCS - although having something better than svnmerge to
handle maintenance of multiple branches would be a very good thing for
us too!).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
___
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] My patches

[Nick Coghlan]

Barry Warsaw wrote:
> or even decided that we're moving to one.  Brett as the head of the
> infrastructure committee will have more to say about that.

While it is indeed the infrastructure committee's call (since they'll
shoulder the bulk of the effort in organising further investigation into
the idea), I personally believe that moving to some kind of DVCS makes
too much sense for it not to happen eventually.

Anything we can do to make it easier to maintain 4 active branches
(2.x-1 and 3.y-1 maintenance, 2.x and 3.y development) over the next few
years is going to be worth a fair amount of up front effort.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
___
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] Proper initialization of structs

[Christian Heimes]

I like to raise attention for a problem revealed by 
http://bugs.python.org/issue4237


---
The bug was caused by a design flaw -- which was partly my fault. Some
elements of the PyFileIOObject struct were initialized in __new__ while
other parts were initialized in __init__. I've moved the initialization
to __new__.

We should add a rule that all struct members must be properly
initialized in __new__. In the past Victor's fuzzying tool has revealed
several crashers related to similar design flaws.

I'm raising the severity of the bug to release blocker because I can't
predict if the problem can be abused to crash the interpreter. We should
also review all __new__ and __init__ methods of objects and extension
modules for similar issues.
---

The same design flaw was responsible for bugs like the pickle crasher 
http://bugs.python.org/issue3664. I like to establish a rule that *all* 
struct members must be initialized properly in the type's tp_new function.


Comments?

Christian

___
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] My patches

[Eric Smith]

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?

___
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] My patches

[A.M. Kuchling]

On Thu, Oct 30, 2008 at 11:04:42AM +, 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.

(What a DVCS might enable is making it easier to do larger
experiments, like the recent Vmgen work, and publish them in a form
that people can download.  We could create SVN branches now, but that
means people would then have commit access to all of the Python
source.)

--amk
___
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] My patches

[Arfrever Frehtes Taifersar Arahesis]

2008-10-30 16:04 A.M. Kuchling <[EMAIL PROTECTED]> napisał(a):
> On Thu, Oct 30, 2008 at 11:04:42AM +, 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.
>
> (What a DVCS might enable is making it easier to do larger
> experiments, like the recent Vmgen work, and publish them in a form
> that people can download.  We could create SVN branches now, but that
> means people would then have commit access to all of the Python
> source.)

SVN supports path-based authorization.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
___
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] My patches

[Fred Drake]

On Oct 30, 2008, at 11:11 AM, Arfrever Frehtes Taifersar Arahesis wrote:

SVN supports path-based authorization.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html



This has worked well for us with contractors and partners, and isn't  
problematic or tedious to maintain.



  -Fred

--
Fred Drake   

___
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] My patches

[Steve Holden]

Arfrever Frehtes Taifersar Arahesis wrote:
> 2008-10-30 16:04 A.M. Kuchling <[EMAIL PROTECTED]> napisał(a):
>> On Thu, Oct 30, 2008 at 11:04:42AM +, 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.
>>
>> (What a DVCS might enable is making it easier to do larger
>> experiments, like the recent Vmgen work, and publish them in a form
>> that people can download.  We could create SVN branches now, but that
>> means people would then have commit access to all of the Python
>> source.)
> 
> SVN supports path-based authorization.
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html

good point, but then we'd have an authentication management task ...

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@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] My patches

[Calvin Spealman]

On Thu, Oct 30, 2008 at 8:50 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:
> >If Python would be more reactive, more developer will be attracted. The
> >communication is very important in an open source project. I contributed to
> >many many projects, and I can say that Python is already one of the most
> >reactive project! But it can be better ;-)
>
> I agree!  How can we improve our development process, given that we're an all
> volunteer organization?

On that note, are more volunteers needed? Are there any capacities in
which extra sets of hands could make help these improvements or would
it just be more overhead and managing people and figuring out what to
do?

Moderately related note, I'm going to start the python-dev list
summaries again (I have been the worst summary maintainer *ever*) and
I'd like to set up the process as a community effort. That is, I've
got some code I'm going to launch (probably at appengine) where edits
can be made to the summaries by anyone, to be reviewed and taken in,
before submitting the final summaries every two weeks. This should
make keeping them going more likely, because no one person will need
to find the time. It will also make the summaries more accurate if
people actually involved in the discussions can fix any mistakes or
repair omissions. I think the summaries are important, and one of many
puzzle pieces to keeping people informed, which is all part of moving
the development process along. Of course, this is all assuming no one
objects to that plan.
___
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] My patches

[Paul Moore]

2008/10/30 A.M. Kuchling <[EMAIL PROTECTED]>:
> On Thu, Oct 30, 2008 at 11:04:42AM +, 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.

Agreed. There are lots of patches around, but not enough core dev
man-hours to review and apply them. As just adding extra people as
core devs isn't going to work (I don't believe it's *hard* to become a
core dev at the moment, it just needs a level of commitment that many
people can't offer), and as adding hours to the day isn't possible
(hmm, Guido - about that time machine?) I think the best way of
helping is with patch triage.

More people trawling the trackers and reviewing existing patches might
free up core dev time for looking at the more subtle stuff, as long as
(1) core devs could be happy to accept "this is OK, commit it"
comments from non-core devs, and/or (2) it's easy to locate stuff to
review, and just as importantly stuff which has been reviewed and is
"ready to go".

Question - is there anything Roundup can do to help triage? Extra
status or keyword values ("has patch", "ready to go", ...)? More
canned searches ("Show Open" and "Show Unassigned" aren't a lot of
help)? Custom reports (summaries by type)? Or are such things there
and simply not publicised enough?

I just did a quick experiment, checking for trivial documentation
patches I could review, and some things became obvious:

1. There is no way of telling which issues have a patch.
2. Some patches marked as "documentation" are doc fixes, others seem
to be issues where it has been decided that the behaviour is correct
as is, but needs to be documented. Fair enough, but it's much harder
to assess the latter, and there's no way of just grabbing the former
(for example, to spend a spare 30 minutes reviewing simple stuff).
3. There's nothing obvious I can do to move an issue forward. Sure, I
can make a comment, but that's about it. I'd like something that stood
a bit more chance of getting noticed (like a status change, or maybe a
list of people who think this is good to apply, which I can add myself
to).

All of which boil down to (1) quickly finding stuff I can deal with,
and (2) feeling like what I do has an effect.

Hmm, I've spent more time on this than I should have, and it's gone
way off topic. Is there anywhere better to discuss it?

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] My patches

[Raghuram Devarakonda]

On Thu, Oct 30, 2008 at 11:55 AM, Paul Moore <[EMAIL PROTECTED]> wrote:

> I just did a quick experiment, checking for trivial documentation
> patches I could review, and some things became obvious:
>
> 1. There is no way of telling which issues have a patch.

There is a "patch" keyword that is usually set for issues with patches
and search can be done for given keywords.

Thanks,
Raghu
___
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] My patches

[Tarek Ziadé]

On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
>> 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.
>
> Agreed. There are lots of patches around, but not enough core dev
> man-hours to review and apply them. As just adding extra people as
> core devs isn't going to work (I don't believe it's *hard* to become a
> core dev at the moment, it just needs a level of commitment that many
> people can't offer), and as adding hours to the day isn't possible
> (hmm, Guido - about that time machine?) I think the best way of
> helping is with patch triage.
>

Since it is a hard and long process  "to know it all"  in Python, and
to become a core developer

What about having two level of devs ?

+ core developers
+ standard library developers

I mean, the standard library could be open ihmo to a wider range of people,
or maybe even having people specialized in some packages, modules, even
if they don't know anything about the C apis of the core.

Those "standard library developers" could be blessed to work on
specific areas of the standard
library and "followed" by a core developer that can just make sure
everything goes in the right direction
without having too much extra work for that.

Regards,
Tarek

-- 
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
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] My patches

[Jesse Noller]

On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
>>> 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.
>>
>> Agreed. There are lots of patches around, but not enough core dev
>> man-hours to review and apply them. As just adding extra people as
>> core devs isn't going to work (I don't believe it's *hard* to become a
>> core dev at the moment, it just needs a level of commitment that many
>> people can't offer), and as adding hours to the day isn't possible
>> (hmm, Guido - about that time machine?) I think the best way of
>> helping is with patch triage.
>>
>
> Since it is a hard and long process  "to know it all"  in Python, and
> to become a core developer
>
> What about having two level of devs ?
>
> + core developers
> + standard library developers
>
> I mean, the standard library could be open ihmo to a wider range of people,
> or maybe even having people specialized in some packages, modules, even
> if they don't know anything about the C apis of the core.
>
> Those "standard library developers" could be blessed to work on
> specific areas of the standard
> library and "followed" by a core developer that can just make sure
> everything goes in the right direction
> without having too much extra work for that.
>
> Regards,
> Tarek

Interestingly enough, I consider myself in the "standard library
developers" RE: the multiprocessing package. I just thought that's how
things broke down unofficially. I personally don't feel comfortable
doing much of anything outside of my sandbox, but am more than willing
to commit patches that have been reviewed by people my senior (in
skill!).

-jesse
___
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] Fwd: Removal of GIL through refcounting removal.

[Sigurd Torkel Meldgaard]

Hi to all Python developers

For a student project in a course on virtual machines, we are
evaluating the possibility to
experiment with removing the GIL from CPython

We have read the arguments against doing this at
http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock.

But we think it might be possible to do this with a different approach
than what has been tried till now.

The main reason for the necessity of the GIL is reference counting.

We believe that most of the slowdown in the free threading
implementation of Greg Stein was due to the need of atomic
refcounting, as this mail seems to confirm:
http://mail.python.org/pipermail/python-ideas/2007-April/000414.html

So we want to change CPython into having a "real" garbage collector -
removing all reference counting, and then the need for locks (or
atomic inc/dec ops) should be
highly alleviated.

Preferably the GC should be a high-performance one for instance a
generational one.

We believe that it can run quite a lot faster than ref-counting.

Shared datastructures would get their lock obviously.
Immutable objects (especially shared global objects, like True, False, Null)
would not.

Most of the interpreter structure would be per-thread, at that point.

We do not know how Greg Stein did his locking in the free threads
patch, but as a part of the course we learned there exists much faster
ways of locking than using OS-locks (faster for the uncontented case)
that are used in e.g. the HOT-SPOT java-compiler. This might make
"free threading" in python more attractive than some pessimists think.
(http://blogs.sun.com/dave/entry/biased_locking_in_hotspot)
In particular, we are talking about making the uncontended case go fast,
not about the independent part of stack-allocating the mutex
structure, which can only be done and is only needed in Java.

These ideas are similar to the ones used by Linux fast mutexes
(futexes), the implementation of mutexes in NPTL.

We have read this mail thread - so it seems that our idea surfaced,
but Greg didn't completely love it (he wanted to optimize refcounting
instead):
http://mail.python.org/pipermail/python-ideas/2007-April/000436.html

He was not totally negative however. His main objections are about:
- cache locality (He is in our opinion partially right, as seen in some
other paper time ago - any GC, copying GC in particular, doubles the
amount of used memory, so it's less cache-friendly). But still GCs are
overall competitive or faster than explicit management, and surely
much faster of refcounting.

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).

Was this ever tried for CPython?

Any other comments, encouragements or warnings on the project-idea?

Best regards: Paolo, Sigurd
___
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] Proper initialization of structs

[Guido van Rossum]

Yes, that's what __new__ / tp_new is for! Thanks for finding this.

On Thu, Oct 30, 2008 at 7:20 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I like to raise attention for a problem revealed by
> http://bugs.python.org/issue4237
>
> ---
> The bug was caused by a design flaw -- which was partly my fault. Some
> elements of the PyFileIOObject struct were initialized in __new__ while
> other parts were initialized in __init__. I've moved the initialization
> to __new__.
>
> We should add a rule that all struct members must be properly
> initialized in __new__. In the past Victor's fuzzying tool has revealed
> several crashers related to similar design flaws.
>
> I'm raising the severity of the bug to release blocker because I can't
> predict if the problem can be abused to crash the interpreter. We should
> also review all __new__ and __init__ methods of objects and extension
> modules for similar issues.
> ---
>
> The same design flaw was responsible for bugs like the pickle crasher
> http://bugs.python.org/issue3664. I like to establish a rule that *all*
> struct members must be initialized properly in the type's tp_new function.
>
> Comments?
>
> Christian
>
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Fwd: Removal of GIL through refcounting removal.

[Jesse Noller]

On Thu, Oct 30, 2008 at 12:13 PM, Sigurd Torkel Meldgaard
<[EMAIL PROTECTED]> wrote:
> Hi to all Python developers
>
> For a student project in a course on virtual machines, we are
> evaluating the possibility to
> experiment with removing the GIL from CPython
>
> We have read the arguments against doing this at
> http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock.
>
> But we think it might be possible to do this with a different approach
> than what has been tried till now.
>
> The main reason for the necessity of the GIL is reference counting.
>
> We believe that most of the slowdown in the free threading
> implementation of Greg Stein was due to the need of atomic
> refcounting, as this mail seems to confirm:
> http://mail.python.org/pipermail/python-ideas/2007-April/000414.html
>
> So we want to change CPython into having a "real" garbage collector -
> removing all reference counting, and then the need for locks (or
> atomic inc/dec ops) should be
> highly alleviated.
>
> Preferably the GC should be a high-performance one for instance a
> generational one.
>
> We believe that it can run quite a lot faster than ref-counting.
>
> Shared datastructures would get their lock obviously.
> Immutable objects (especially shared global objects, like True, False, Null)
> would not.
>
> Most of the interpreter structure would be per-thread, at that point.
>
> We do not know how Greg Stein did his locking in the free threads
> patch, but as a part of the course we learned there exists much faster
> ways of locking than using OS-locks (faster for the uncontented case)
> that are used in e.g. the HOT-SPOT java-compiler. This might make
> "free threading" in python more attractive than some pessimists think.
> (http://blogs.sun.com/dave/entry/biased_locking_in_hotspot)
> In particular, we are talking about making the uncontended case go fast,
> not about the independent part of stack-allocating the mutex
> structure, which can only be done and is only needed in Java.
>
> These ideas are similar to the ones used by Linux fast mutexes
> (futexes), the implementation of mutexes in NPTL.
>
> We have read this mail thread - so it seems that our idea surfaced,
> but Greg didn't completely love it (he wanted to optimize refcounting
> instead):
> http://mail.python.org/pipermail/python-ideas/2007-April/000436.html
>
> He was not totally negative however. His main objections are about:
> - cache locality (He is in our opinion partially right, as seen in some
> other paper time ago - any GC, copying GC in particular, doubles the
> amount of used memory, so it's less cache-friendly). But still GCs are
> overall competitive or faster than explicit management, and surely
> much faster of refcounting.
>
> 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).
>
> Was this ever tried for CPython?
>
> Any other comments, encouragements or warnings on the project-idea?
>
> Best regards: Paolo, Sigurd

See also:
http://code.google.com/p/python-safethread/
https://launchpad.net/python-safethread
___
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] Fwd: Removal of GIL through refcounting removal.

[Guido van Rossum]

It's not that I have any love for the GIL, it just is the best
compromise I could find. I expect that you won't be able to do better,
but I wish you luck anyway.

On Thu, Oct 30, 2008 at 9:13 AM, Sigurd Torkel Meldgaard
<[EMAIL PROTECTED]> wrote:
> Hi to all Python developers
>
> For a student project in a course on virtual machines, we are
> evaluating the possibility to
> experiment with removing the GIL from CPython
>
> We have read the arguments against doing this at
> http://www.python.org/doc/faq/library/#can-t-we-get-rid-of-the-global-interpreter-lock.
>
> But we think it might be possible to do this with a different approach
> than what has been tried till now.
>
> The main reason for the necessity of the GIL is reference counting.
>
> We believe that most of the slowdown in the free threading
> implementation of Greg Stein was due to the need of atomic
> refcounting, as this mail seems to confirm:
> http://mail.python.org/pipermail/python-ideas/2007-April/000414.html
>
> So we want to change CPython into having a "real" garbage collector -
> removing all reference counting, and then the need for locks (or
> atomic inc/dec ops) should be
> highly alleviated.
>
> Preferably the GC should be a high-performance one for instance a
> generational one.
>
> We believe that it can run quite a lot faster than ref-counting.
>
> Shared datastructures would get their lock obviously.
> Immutable objects (especially shared global objects, like True, False, Null)
> would not.
>
> Most of the interpreter structure would be per-thread, at that point.
>
> We do not know how Greg Stein did his locking in the free threads
> patch, but as a part of the course we learned there exists much faster
> ways of locking than using OS-locks (faster for the uncontented case)
> that are used in e.g. the HOT-SPOT java-compiler. This might make
> "free threading" in python more attractive than some pessimists think.
> (http://blogs.sun.com/dave/entry/biased_locking_in_hotspot)
> In particular, we are talking about making the uncontended case go fast,
> not about the independent part of stack-allocating the mutex
> structure, which can only be done and is only needed in Java.
>
> These ideas are similar to the ones used by Linux fast mutexes
> (futexes), the implementation of mutexes in NPTL.
>
> We have read this mail thread - so it seems that our idea surfaced,
> but Greg didn't completely love it (he wanted to optimize refcounting
> instead):
> http://mail.python.org/pipermail/python-ideas/2007-April/000436.html
>
> He was not totally negative however. His main objections are about:
> - cache locality (He is in our opinion partially right, as seen in some
> other paper time ago - any GC, copying GC in particular, doubles the
> amount of used memory, so it's less cache-friendly). But still GCs are
> overall competitive or faster than explicit management, and surely
> much faster of refcounting.
>
> 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).
>
> Was this ever tried for CPython?
>
> Any other comments, encouragements or warnings on the project-idea?
>
> Best regards: Paolo, Sigurd
> ___
> 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/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Fwd: Removal of GIL through refcounting removal.

[VanL]

Sigurd Torkel Meldgaard wrote:
> Hi to all Python developers
> 
> For a student project in a course on virtual machines, we are
> evaluating the possibility to
> experiment with removing the GIL from CPython...

Just an FYI, these two particular students already introduced themselves
on the PyPy list. Paolo is a masters student with experience in the
Linux kernel; Sigurd is a PhD candidate.

Their professor is Lars Bak, the lead architect of the Google V8
Javascript engine. They spent some time working on V8 in the last couple
months.

___
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] Proper initialization of structs

[Fred Drake]

On Oct 30, 2008, at 10:20 AM, Christian Heimes wrote:
I like to establish a rule that *all* struct members must be  
initialized properly in the type's tp_new function.



I think this has always been a requirement.  The result of the "new"  
operation must conform to all the requirements that the type's C code  
demands.


It's good to move work into __init__ where reasonable, so that it can  
be avoided if a subclass wants it done in a completely different way,  
but new can't work that way.



  -Fred

--
Fred Drake   

___
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] Fwd: Removal of GIL through refcounting removal.

[VanL]

VanL wrote:

> Just an FYI, 

...and the FYI was to no one in particular, just interesting information
from the PyPy list. It is just unfortunate timing that made it look like
a cheeky reply to Guido.

___
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] Fwd: Removal of GIL through refcounting removal.

[Leif Walsh]

On Thu, Oct 30, 2008 at 1:07 PM, VanL <[EMAIL PROTECTED]> wrote:
> Just an FYI, these two particular students already introduced themselves
> on the PyPy list. Paolo is a masters student with experience in the
> Linux kernel; Sigurd is a PhD candidate.
>
> Their professor is Lars Bak, the lead architect of the Google V8
> Javascript engine. They spent some time working on V8 in the last couple
> months.

This just gives me really high expectations.  Go get 'em!

-- 
Cheers,
Leif
___
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] Fwd: Removal of GIL through refcounting removal.

[Guido van Rossum]

On Thu, Oct 30, 2008 at 10:20 AM, VanL <[EMAIL PROTECTED]> wrote:
> VanL wrote:
>
>> Just an FYI,
>
> ...and the FYI was to no one in particular, just interesting information
> from the PyPy list. It is just unfortunate timing that made it look like
> a cheeky reply to Guido.

No offense taken. The V8 experience makes me feel much more optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is pretty lame.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Fwd: Removal of GIL through refcounting removal.

[Eric Smith]

Guido van Rossum wrote:

No offense taken. The V8 experience makes me feel much more optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is pretty lame.)


The need to modify all extension modules is the usual non-starter I see 
mentioned when this topic comes up. The OP really needs to think about 
that issue.



___
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] Fwd: Removal of GIL through refcounting removal.

[Guido van Rossum]

On Thu, Oct 30, 2008 at 10:31 AM, Eric Smith <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>>
>> No offense taken. The V8 experience makes me feel much more optimistic
>> that they might actually pull this off. (I'm still skeptical about
>> support for extension modules, withougt which CPython is pretty lame.)
>
> The need to modify all extension modules is the usual non-starter I see
> mentioned when this topic comes up. The OP really needs to think about that
> issue.

It's a non-starter for immediate world-domination. But if they get the
core to be significantly faster I expect there will be motivation to
port extensions. There's also the PyPy effort to replace extension
modules with ctypes-based wrappers. I could also imagine that
extensions could be run in a sandbox that *does* use the equivalent of
the GIL.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Classifying language vs. impl-detail tests

[Armin Rigo]

Hi all,

Here is a first step towards classifying the Python test suite into
"real language tests" and "implementation details":

http://bugs.python.org/issue4242

If the general approach seems acceptable to people, I would be willing
to port more of PyPy's test suite patches.  The net result would be to
move the test suite towards being more directly useful for alternate
Python implementations.  (Right now, all of them have some custom tests
plus their own similarly patched copy of the stdlib test suite.)

Note that the patch above is against 2.7 trunk; the 2.x line is what all
non-CPython implementations currently target.  The general idea (and to
a large extend the patches) can easily be forward-ported to 3.x when it
makes sense.

Also, the actual decision of what is a "real" or a "detail" test is of
course up to discussion.  The patch above does the classification for
test_descr.  It was obtained by running it with PyPy, and for each
failure either fixing PyPy, or argumenting (by adding a comment) the
reason for which it is a detail -- usually referring to "well-known
agreement" expressed on python-dev about the matter.  (Of course,
"detail" tests still run normally on top of CPython.)


A bientot,

Armin.
___
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] My patches

[Brett Cannon]

On Thu, Oct 30, 2008 at 06:14, Nick Coghlan <[EMAIL PROTECTED]> 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.
>
> It's kept up to date, and will eventually move to a more complete DVCS
> experiment (there are also mercurial and git mirrors being maintained,
> but they haven't been linked from python.org yet - a trawl through the
> python-dev archives should turn up the links to the URLs).
>
> The PSF's infrastructure committee isn't that big though (and all
> volunteers), and switching version control systems isn't exactly easy
> (even the migration from Sourceforge CVS to python.org SVN took quite a
> bit of effort from key people). The migration of all our regular
> workflows from the familiar centralised VCS style to a DVCS style of
> development promises to be pretty disruptive in the short term, no
> matter how beneficial it will be in the long run.
>
> That said, with the tracker migration from Sourceforge to Roundup behind
> us, and a hopefully successful 3.0 release not too far away, it's
> probably time to start giving the idea more serious thought.
>
> Ultimately, any complete plan for migration from SVN to a DVCS will
> likely need to come in the form of a meta-PEP like the one MvL wrote to
> justify and document the migration from CVS to SVN:
> http://www.python.org/dev/peps/pep-0347/
>

I have actually started such a PEP, so this is being worked on.

-Brett
___
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] Fwd: Removal of GIL through refcounting removal.

[Michael Foord]

Guido van Rossum wrote:

On Thu, Oct 30, 2008 at 10:31 AM, Eric Smith <[EMAIL PROTECTED]> wrote:
  

Guido van Rossum wrote:


No offense taken. The V8 experience makes me feel much more optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is pretty lame.)
  

The need to modify all extension modules is the usual non-starter I see
mentioned when this topic comes up. The OP really needs to think about that
issue.



It's a non-starter for immediate world-domination. But if they get the
core to be significantly faster I expect there will be motivation to
port extensions. There's also the PyPy effort to replace extension
modules with ctypes-based wrappers. I could also imagine that
extensions could be run in a sandbox that *does* use the equivalent of
the GIL.

  
For IronClad [1], an implementation of the Python C API in C# to allow 
you to use Python C extensions from IronPython, we take a hybrid 
approach to garbage collection.


We hold a strong reference to objects created by extensions (preventing 
.NET from garbage collecting them) and allow the extension to manipulate 
the reference count in the usual way. Periodically we scan our "managed 
objects" [2] to see if there are objects whose reference count has 
dropped to zero and we then delete our strong reference - allowing 
garbage collection to happen normally.


We have also implemented a GIL for the C extensions even though 
IronPython has no GIL.


Simple extension modules can already be used with IronPython through 
Ironclad, and for Numpy (our goal) arrays can be created and used and we 
are working on 'everything else'.


Moving more C extensions to an implementation based on ctypes would be 
enormously useful for PyPy, IronPython and Jython, but ctypes is not yet 
as portable as Python itself which could be an issue (although one worth 
resolving).


Michael Foord


[1] http://code.google.com/p/ironclad
[2] Strictly speaking they are managed objects of unmanaged types, but 
we really need a better way of talking about them.


--
http://www.ironpythoninaction.com/

___
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] My patches

[Brett Cannon]

On Thu, Oct 30, 2008 at 05:50, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:
[SNIP]
>>If Python would be more reactive, more developer will be attracted. The
>>communication is very important in an open source project. I contributed to
>>many many projects, and I can say that Python is already one of the most
>>reactive project! But it can be better ;-)
>
> I agree!  How can we improve our development process, given that we're an all
> volunteer organization?

And this is a key point that people seem to forget. Guido is the ONLY
developer who gets paid to work on Python, and that is only 50% of his
time (when he doesn't have a Google-related workload), and honestly I
would rather he not deal with patches that do not affect what he is
working on.

The rest of us spend our evenings and weekends on this on top of
trying to balance a normal life. In my case I had to stop my Python
work recently because I have been working on my Ph.D. thesis proposal.
Everyone has their lives that take priority.

And no, I do not think that giving out more commit privileges will
necessarily solve everything. Python is known for its quality and part
of that reason is we are careful about handing out privileges. This is
not to say we can't try to help move people along towards getting
privileges faster, but I am not interested in doing what Pugs does and
give everyone who has submitted a patch commit privs.

-Brett
___
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] My patches

[Martin v. Löwis]

> Question - is there anything Roundup can do to help triage? Extra
> status or keyword values ("has patch",

There is "patch" keyword already, and a public query "Patches"
(as well as "My Patches")

> "ready to go", ...)?

We could give more people the right to set the resolution to "Accepted".
This is a matter of trust, though - if the committer then still needs
to review it, anyway, nothing is gained.

> More
> canned searches ("Show Open" and "Show Unassigned" aren't a lot of
> help)?

Please go to the "edit" label next to "Search". You can store your
own searches, but you can also share searches with others.

> Custom reports (summaries by type)? 

This I don't understand - how is it different from a search?

> Or are such things there and simply not publicised enough?

Perhaps. I really don't know what percentage of interested users
is aware of roundup capabilities.

> I just did a quick experiment, checking for trivial documentation
> patches I could review, and some things became obvious:
> 
> 1. There is no way of telling which issues have a patch.

There is the patch keyword, and you can query for it. There is a
canned query published already.

> 2. Some patches marked as "documentation" are doc fixes, others seem
> to be issues where it has been decided that the behaviour is correct
> as is, but needs to be documented. Fair enough, but it's much harder
> to assess the latter, and there's no way of just grabbing the former
> (for example, to spend a spare 30 minutes reviewing simple stuff).

There is the "easy" keyword. Of course, it might also be useful to
triage more issues as "easy".

> 3. There's nothing obvious I can do to move an issue forward. Sure, I
> can make a comment, but that's about it. I'd like something that stood
> a bit more chance of getting noticed (like a status change, or maybe a
> list of people who think this is good to apply, which I can add myself
> to).

The "developer" role has more user interface. I've just given it to you.

> Hmm, I've spent more time on this than I should have, and it's gone
> way off topic. Is there anywhere better to discuss it?

There is the tracker-discuss list for discussion, and the meta tracker
for actual problems/wishes for the tracker.

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] My patches

[Martin v. Löwis]

> What about having two level of devs ?
> 
> + core developers
> + standard library developers

We effectively have that already. Many of the committers will
only ever commit to a single module (+docs and tests), as they
volunteered to maintain that very module (e.g. Lars Gustäbel
for the tarfile module).

If a committer agrees to restrict himself to a certain area,
he will usually keep that promise, so there isn't really any
need for a finer-grained access control, IMO.

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] My patches

[Martin v. Löwis]

> Interestingly enough, I consider myself in the "standard library
> developers" RE: the multiprocessing package. I just thought that's how
> things broke down unofficially.

It's actually fairly official (see my other message) - "you know who you
are". It has been working that way fine for the last few years. The
public record if it is in Misc/developers.txt (although that file might
be slightly incomplete/incorrect).

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

[Python-Dev] svnmerge init in the release26-maint branch?

[Thomas Heller]

I have a fix for a modulefinder crash that I'm going to commit
into the trunk. Since the bug is also in release26-maint I will
also backport it.  While preparing this I noticed that in the
release26-maint branch 'svnmerge init' has not yet been done.

I assume that we will use svnmerge to merge from trunk to
release26-maint?  So, is it ok to do 'svnmerge init' in it?

-- 
Thanks,
Thomas

___
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] svnmerge init in the release26-maint branch?

[Christian Heimes]

Thomas Heller wrote:

I have a fix for a modulefinder crash that I'm going to commit
into the trunk. Since the bug is also in release26-maint I will
also backport it.  While preparing this I noticed that in the
release26-maint branch 'svnmerge init' has not yet been done.


Are you sure? I did a svnmerge init a couple of days after the 
release26-maint branch was created. I can see the properties on the 
branch, too.


.../python/release26-maint$ svn proplist -v . | grep svnmerge
  svnmerge-blocked : 
/python/trunk:66721-66722,66744-66745,66752,66756,66763-66765,66768,66791-66792,66857
  svnmerge-integrated : 
/python/trunk:1-66720,66723-66743,66746-66751,66753-66755,66757-66762,66766-66767,66769-66790,66793-66800,66802,66805-66812,66814-66821,66824-66831,66833-66835,66837-66851,66853,66858-66860,66862-66863,66881,66891,66906,66922,66928-66931,66933-66937,66939-66940,66958,66984,66995-66996,67000,67030-67031


Christian
___
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] svnmerge init in the release26-maint branch?

[Thomas Heller]

Christian Heimes schrieb:
> Thomas Heller wrote:
>> I have a fix for a modulefinder crash that I'm going to commit
>> into the trunk. Since the bug is also in release26-maint I will
>> also backport it.  While preparing this I noticed that in the
>> release26-maint branch 'svnmerge init' has not yet been done.
> 
> Are you sure? I did a svnmerge init a couple of days after the 
> release26-maint branch was created. I can see the properties on the 
> branch, too.
> 
> .../python/release26-maint$ svn proplist -v . | grep svnmerge
>svnmerge-blocked : 
> /python/trunk:66721-66722,66744-66745,66752,66756,66763-66765,66768,66791-66792,66857
>svnmerge-integrated : 
> /python/trunk:1-66720,66723-66743,66746-66751,66753-66755,66757-66762,66766-66767,66769-66790,66793-66800,66802,66805-66812,66814-66821,66824-66831,66833-66835,66837-66851,66853,66858-66860,66862-66863,66881,66891,66906,66922,66928-66931,66933-66937,66939-66940,66958,66984,66995-66996,67000,67030-67031

Oh, sorry - I forgot to 'svn up' first.

-- 
Thanks,
Thomas

___
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] buildbots

[Thomas Heller]

AFAICS there are no buildbots for the release26-maint branch.

Thomas

___
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] buildbots

[Martin v. Löwis]

> AFAICS there are no buildbots for the release26-maint branch.

That's correct. I'm waiting to create them until after we retire the
2.5 ones.

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] Classifying language vs. impl-detail tests

[Benjamin Peterson]

On Thu, Oct 30, 2008 at 12:16 PM, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Here is a first step towards classifying the Python test suite into
> "real language tests" and "implementation details":
>
>http://bugs.python.org/issue4242

I've actually implemented something like this along with more general
test skipping capabilities in my Bazaar testing branch. [1] It adds a
decorator @cpython_only that can be applied to tests.

>
> If the general approach seems acceptable to people, I would be willing
> to port more of PyPy's test suite patches.  The net result would be to
> move the test suite towards being more directly useful for alternate
> Python implementations.  (Right now, all of them have some custom tests
> plus their own similarly patched copy of the stdlib test suite.)

That would be great to see!

>
> Note that the patch above is against 2.7 trunk; the 2.x line is what all
> non-CPython implementations currently target.  The general idea (and to
> a large extend the patches) can easily be forward-ported to 3.x when it
> makes sense.
>
> Also, the actual decision of what is a "real" or a "detail" test is of
> course up to discussion.  The patch above does the classification for
> test_descr.  It was obtained by running it with PyPy, and for each
> failure either fixing PyPy, or argumenting (by adding a comment) the
> reason for which it is a detail -- usually referring to "well-known
> agreement" expressed on python-dev about the matter.  (Of course,
> "detail" tests still run normally on top of CPython.)

[1] http://code.python.org/python/users/benjamin.peterson/new_testing/main




-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
___
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] buildbots

[Benjamin Peterson]

On Thu, Oct 30, 2008 at 3:38 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> AFAICS there are no buildbots for the release26-maint branch.
>
> That's correct. I'm waiting to create them until after we retire the
> 2.5 ones.

That reminds me: Do we have a final release date for 2.5.3 set?



-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
___
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] buildbots

[Martin v. Löwis]

Benjamin Peterson wrote:
> On Thu, Oct 30, 2008 at 3:38 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> AFAICS there are no buildbots for the release26-maint branch.
>> That's correct. I'm waiting to create them until after we retire the
>> 2.5 ones.
> 
> That reminds me: Do we have a final release date for 2.5.3 set?

Not precisely. However, I want to make the release candidate for 2.5.3
a week after the 3.0 release, and the final release one week afterwards.
If the 3.0 release plan stands, that would give December 10 for the
release candidate, and December 17 for the final release.

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] My patches

[A.M. Kuchling]

On Thu, Oct 30, 2008 at 03:55:38PM +, Paul Moore wrote:
> 2. Some patches marked as "documentation" are doc fixes, others seem
> to be issues where it has been decided that the behaviour is correct
> as is, but needs to be documented. Fair enough, but it's much harder
> to assess the latter, and there's no way of just grabbing the former
> (for example, to spend a spare 30 minutes reviewing simple stuff).

Perhaps the documentation category could be split into 'Documentation'
and 'Documentation Needed'; the latter means the issue entails writing
new text as opposed to rewriting.  But I think on average
documentation issues get processed pretty quickly: Georg is responsive
to them, and patches are easy to apply because you don't need to worry
about breaking anything.

In general Python development is much less freewheeling and fun than
it used to be.  You could come up with new features and modules, add
lots of new capabilities to a module.  Today we're making much smaller
changes, discuss them at far great length, and have to worry about
breaking all the existing Python code out there, It's a sign of
Python's maturity, of course, and I'm not saying that the design
effort and the compatibility requirements should be dropped, but they
certainly act as a damper.

On some of my issues (esp. ones relating to curses and mailbox.py), I
feel paralyzed because problems are occurring on platforms I don't
have access to (e.g. FreeBSD).  The buildbots will report problems,
but then you have to debug them by committing changes, triggering a
build, and observing the results.  And all of these actions will send
e-mail to python-checkins.  (Imagine if every 'print "reached here!"'
you added while debugging was e-mailed to everyone...)

--amk
___
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] My patches

[Georg Brandl]

Arfrever Frehtes Taifersar Arahesis schrieb:
> 2008-10-30 16:04 A.M. Kuchling <[EMAIL PROTECTED]> napisał(a):
>> On Thu, Oct 30, 2008 at 11:04:42AM +, 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.
>>
>> (What a DVCS might enable is making it easier to do larger
>> experiments, like the recent Vmgen work, and publish them in a form
>> that people can download.  We could create SVN branches now, but that
>> means people would then have commit access to all of the Python
>> source.)
> 
> SVN supports path-based authorization.
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html

I don't see a problem with giving access to people wanting to work on
a branch, and telling them not to commit on the trunk.

We had and still have some such branches going on, e.g. for SoC students.
I also gave out access to several developers to work on the docs only,
or Sphinx which still is in Python's SVN repo.

After all, it's a VCS, and if someone plays against the rules, the commit is
reverted and the privs dropped in perhaps a minute.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] My patches

[Jean-Paul Calderone]

On Thu, 30 Oct 2008 17:17:02 -0400, "A.M. Kuchling" <[EMAIL PROTECTED]> wrote:

[snip]

On some of my issues (esp. ones relating to curses and mailbox.py), I
feel paralyzed because problems are occurring on platforms I don't
have access to (e.g. FreeBSD).  The buildbots will report problems,
but then you have to debug them by committing changes, triggering a
build, and observing the results.  And all of these actions will send
e-mail to python-checkins.  (Imagine if every 'print "reached here!"'
you added while debugging was e-mailed to everyone...)


I do that when I need to.  People whose lives would be ruined by the
receipt of such an email always have the option of leaving the checkin
list.

However, there is a buildbot feature named "try" which lets you submit
a patch (subject to authentication) and performs a build with the patch
applied.  This lets you try lots of little changes without getting your
VCS involved.  It needs to be enabled in the buildmaster configuration
and credentials created for any user who will be given access.

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] My patches

[Amaury Forgeot d'Arc]

On Thu, Oct 30, 2008 at 22:17, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On some of my issues (esp. ones relating to curses and mailbox.py), I
> feel paralyzed because problems are occurring on platforms I don't
> have access to (e.g. FreeBSD).  The buildbots will report problems,
> but then you have to debug them by committing changes, triggering a
> build, and observing the results.  And all of these actions will send
> e-mail to python-checkins.  (Imagine if every 'print "reached here!"'
> you added while debugging was e-mailed to everyone...)

By the way, it seems that this python-checkins mailing list did not
archive the recent commits:
http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
I miss them... Can someone fix it?

-- 
Amaury Forgeot d'Arc
___
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] Proper initialization of structs

[Alexandre Vassalotti]

On Thu, Oct 30, 2008 at 1:00 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
> It's good to move work into __init__ where reasonable, so that it can be
> avoided if a subclass wants it done in a completely different way, but new
> can't work that way.
>

And that is exactly the reason why, the _pickle module doesn't use
__new__ for initialization.  Doing any kind of argument parsing in
__new__ prevents subclasses from customizing the arguments for their
__init__.

Although, I agree that __new__ should be used, whenever it is
possible, to initialize struct members.

-- Alexandre
___
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] Proper initialization of structs

[Nick Coghlan]

Alexandre Vassalotti wrote:
> On Thu, Oct 30, 2008 at 1:00 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
>> It's good to move work into __init__ where reasonable, so that it can be
>> avoided if a subclass wants it done in a completely different way, but new
>> can't work that way.
>>
> 
> And that is exactly the reason why, the _pickle module doesn't use
> __new__ for initialization.  Doing any kind of argument parsing in
> __new__ prevents subclasses from customizing the arguments for their
> __init__.

No it doesn't - it just means the subclasses have to override __new__ as
well and then give the parent class the arguments it needs.

I've used this convention (*must* call parent class __new__ or the
instance will be broken, may call parent class __init__ if it is
helpful) many times, and it is far more robust than relying on
subclasses to remember to call the parent class __init__ when setting up
the class.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
___
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] Fwd: Removal of GIL through refcounting removal.

[James Y Knight]

On Oct 30, 2008, at 1:31 PM, Eric Smith wrote:


Guido van Rossum wrote:
No offense taken. The V8 experience makes me feel much more  
optimistic

that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is pretty  
lame.)


The need to modify all extension modules is the usual non-starter I  
see mentioned when this topic comes up. The OP really needs to think  
about that issue.



It's not a non-starter, it's just a non-finisher. :)

One could take an approach like Apple did for ObjC 2.0: libraries  
should be ported over time to be able to work with both refcounting  
and automatic-GC runtimes. When you link a program, you can choose to  
link it with the automatic GC objc runtime, as long as all the other  
frameworks you want to use are compatible with that.


What this would mean in python terms:
- Python would be able to be compiled in either refcounting or auto-gc  
mode.
- Extensions can be modified to be compatible with the auto-gc mode  
over the timespan of a few years.
- Then when most extensions have been adjusted, auto-gc would become  
the default mode for python to be compiled in.


It's seems theoretically entirely doable, but will surely be a lot of  
work...someone'd have to be ready to really do the hard work to push  
it through to completion.


James
___
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] My patches

[Martin v. Löwis]

> On some of my issues (esp. ones relating to curses and mailbox.py), I
> feel paralyzed because problems are occurring on platforms I don't
> have access to (e.g. FreeBSD).  The buildbots will report problems,
> but then you have to debug them by committing changes, triggering a
> build, and observing the results.  And all of these actions will send
> e-mail to python-checkins.

I wouldn't worry about that. If the checkin message indicates that
this is testing out a certain buildbot issue, most python-checkin
readers probably will skip over it quickly.

If you are still worried: buildbot has a "try" feature, where developers
can try out changes on the slaves before committing them. This isn't
currently activated in the Python buildbot - but if you need it, we
could look into it (if you are curious, just experiment with it
yourself).

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] My patches

[Martin v. Löwis]

> By the way, it seems that this python-checkins mailing list did not
> archive the recent commits:
> http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
> I miss them... Can someone fix it?

Which ones are you missing specifically?

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] My patches

[Benjamin Peterson]

On Thu, Oct 30, 2008 at 6:25 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> By the way, it seems that this python-checkins mailing list did not
>> archive the recent commits:
>> http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
>> I miss them... Can someone fix it?
>
> Which ones are you missing specifically?

I haven't seen any of the ones today.


-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
___
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] My patches

[Paul Moore]

2008/10/30 "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> Question - is there anything Roundup can do to help triage? Extra
>> status or keyword values ("has patch",
>
> There is "patch" keyword already, and a public query "Patches"
> (as well as "My Patches")

Sorry, I checked the keywords but missed it.

>> "ready to go", ...)?
>
> We could give more people the right to set the resolution to "Accepted".
> This is a matter of trust, though - if the committer then still needs
> to review it, anyway, nothing is gained.

Agreed. I was thinking vaguely in terms of a type of voting - rather
than a status or resolution, it might be more like the nosy list - a
list of people who have said they think the patch is OK. The more
people on the list, the stronger the assurance that it's acceptable.
It is still a matter of trust, of course - nothing can avoid that.

>> More
>> canned searches ("Show Open" and "Show Unassigned" aren't a lot of
>> help)?
>
> Please go to the "edit" label next to "Search". You can store your
> own searches, but you can also share searches with others.

I see it now. Thanks. It's not very obvious, but once you know it's
there, it looks fine.

>> Custom reports (summaries by type)?
>
> This I don't understand - how is it different from a search?

I was thinking in terms of summary reports - counts of numbers of
issues in various groups. The output layout is different from a
search. My idea was to make it easier to find areas which are worth
tackling (for example, if there are lots of documentation patches, it
might be worth a look through to see if any are trivial). It's graphs
and counts to help people to find areas they can help with that I was
thinking of.

It's not a very clear concept, even in my own mind though.

>> Or are such things there and simply not publicised enough?
>
> Perhaps. I really don't know what percentage of interested users
> is aware of roundup capabilities.

Fair point. My gut feeling is that more people would be interested if
we had ways of presenting the list of issues in better ways than the
current monolithic list. If people could see "hey, there's a lot of
documentation (or library, or C code, or whatever) patches which
haven't been looked at yet", they might be inclined to take a look.

Maybe even a simple graph of current issues on the python.org front
page, with a "Lend a hand!" type of heading, to suggest that people
could help.

There's still the trust issue you mentioned above, but my instinct is
that the average Python coder simply doesn't realise that they could
help - or they believe that taking a spare 15 minutes "wouldn't be
worth it".

>> 2. Some patches marked as "documentation" are doc fixes, others seem
>> to be issues where it has been decided that the behaviour is correct
>> as is, but needs to be documented. Fair enough, but it's much harder
>> to assess the latter, and there's no way of just grabbing the former
>> (for example, to spend a spare 30 minutes reviewing simple stuff).
>
> There is the "easy" keyword. Of course, it might also be useful to
> triage more issues as "easy".

That might help. But you can't search on combinations of keyword (e.g.
easy, with a patch). Maybe an extra property "Difficulty", with values
Easy, Moderate, Complex (and blank, for "not checked yet") would be
good. Interested parties could check for issues with blank difficulty,
and assign a difficulty level. That's useful triage, and not that hard
for anyone to do.

>> 3. There's nothing obvious I can do to move an issue forward. Sure, I
>> can make a comment, but that's about it. I'd like something that stood
>> a bit more chance of getting noticed (like a status change, or maybe a
>> list of people who think this is good to apply, which I can add myself
>> to).
>
> The "developer" role has more user interface. I've just given it to you.

Thanks. I'll try to justify it by doing a bit more on the tracker :-)

>> Hmm, I've spent more time on this than I should have, and it's gone
>> way off topic. Is there anywhere better to discuss it?
>
> There is the tracker-discuss list for discussion, and the meta tracker
> for actual problems/wishes for the tracker.

Thanks.
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] Proper initialization of structs

[Christian Heimes]

Alexandre Vassalotti wrote:

And that is exactly the reason why, the _pickle module doesn't use
__new__ for initialization.  Doing any kind of argument parsing in
__new__ prevents subclasses from customizing the arguments for their
__init__.

Although, I agree that __new__ should be used, whenever it is
possible, to initialize struct members.


You are missunderstanding me. I want everybody to set the struct members 
to *A* sensible default value, not *THE* value. Argument parsing can 
still happen in tp_init. tp_new should (or must?) set all struct members 
to sensible defaults like NULL for pointers, -1 or 0 for numbers etc.


Python uses malloc to allocate memory. Unless you are using debug builds 
the memory block is not initialized. In both cases the block of memory 
isn't zeroed. You all know the problems caused by uninitialized memory.


Christian
___
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] Proper initialization of structs

[Alexandre Vassalotti]

On Thu, Oct 30, 2008 at 6:36 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Alexandre Vassalotti wrote:
>> And that is exactly the reason why, the _pickle module doesn't use
>> __new__ for initialization.  Doing any kind of argument parsing in
>> __new__ prevents subclasses from customizing the arguments for their
>> __init__.
>
> No it doesn't - it just means the subclasses have to override __new__ as
> well and then give the parent class the arguments it needs.
>

Right, and that's what subclasses of built-in types need to do.
However for _pickle, I wanted to reduce interface differences between
the Python implementation. Perhaps, in that case, moving the content
of __init__ methods in both implementations would have been a better
choice. That would certainly make it easier to expose internal methods
easier to fix issue3385. Is it too late to change?

-- Alexandre
___
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] My patches

[Martin v. Löwis]

> I haven't seen any of the ones today.

OK, I've respooled them.

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] Proper initialization of structs

[Alexandre Vassalotti]

[oops, I forgot to cc the list]

On Thu, Oct 30, 2008 at 7:43 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Alexandre Vassalotti wrote:
>>
>> And that is exactly the reason why, the _pickle module doesn't use
>> __new__ for initialization.  Doing any kind of argument parsing in
>> __new__ prevents subclasses from customizing the arguments for their
>> __init__.
>>
>> Although, I agree that __new__ should be used, whenever it is
>> possible, to initialize struct members.
>
> You are missunderstanding me. I want everybody to set the struct members to
> *A* sensible default value, not *THE* value. Argument parsing can still
> happen in tp_init. tp_new should (or must?) set all struct members to
> sensible defaults like NULL for pointers, -1 or 0 for numbers etc.
>
> Python uses malloc to allocate memory. Unless you are using debug builds the
> memory block is not initialized. In both cases the block of memory isn't
> zeroed. You all know the problems caused by uninitialized memory.
>

But what if  PyType_GenericAlloc is used for tp_alloc? As far as I
know, the memory block allocated with PyType_GenericAlloc is zeroed.

-- Alexandre
___
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] My patches

[David Stanek]

On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
>
> What about having two level of devs ?
>
> + core developers
> + standard library developers
>

I was also thinking about two levels of developers,  but structured a
little differently. We have the same core developers with permission
to commit anywhere in the repo. Then we have a set of sub-core (or
whatever) that only have permission to commit to experimental
branches.

These experimental branches would be the testing place for some
patches. Once a patch has had enough exposure in the experimental
branch and has been verified by several people the core team could
merge it into the main development branch. A set of buildbot slaves
can also check that branch on a variety of systems and architectures.

The structure could then look like:
  * trunk - the mainline of development
  * branches/release##maint - for each version
  * branches/experimental## - for the sub-core devs

This may start to be a bit messy if the experimental branch diverges
too much from trunk. trunk would also have to be periodically merged
into the experimental branches. Even so I think it could still be
manageable. And if not the no harm/no foul the experimental branches
could be abandoned and little core developer time would be wasted.

-- 
David
http://www.traceback.org
___
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] My patches

[Victor Stinner]

Le Friday 31 October 2008 00:34:32 Paul Moore, vous avez écrit :
> Agreed. I was thinking vaguely in terms of a type of voting - rather
> than a status or resolution, it might be more like the nosy list - a
> list of people who have said they think the patch is OK. The more
> people on the list, the stronger the assurance that it's acceptable.
> It is still a matter of trust, of course - nothing can avoid that.

I like this idea. But there are different things to review. Examples:
 - the bug report: is the bug reproductible? is the bug isolated?
 - a patch: the patch works? the patch looks correct? or invalid coding style, 
introduce a regression, or anything else

> I was thinking in terms of summary reports (...)

I think that you need an new information: the issue progress, eg.
 - initial state: 0% => need more information
 - bug isolated: 25% => need a patch
 - patch present: 50% => patch needs reviewers
 - patch reviewed: 75% => patch just have to be applied
 - issue closed: 100% (done)

Beginners can search for progress < 25%. They can try to reproduce a problem 
to check the Python version, the OS, etc. Or just help to give more 
informations about the issue.

Core developers just have to check for progress >= 75%.

> Fair point. My gut feeling is that more people would be interested if
> we had ways of presenting the list of issues in better ways than the
> current monolithic list. (...)

Why not using icons (at least on the HTML view)? It helps to see quickly many 
informations and generates smaller reports. We can have an icon for each 
keyword.

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] Fwd: Removal of GIL through refcounting removal.

[Neil Schemenauer]

Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
> For a student project in a course on virtual machines, we are
> evaluating the possibility to experiment with removing the GIL
> from CPython

Hi,

It's great to hear of this kind of project.  I think what you want
to do is difficult but possible.  The major compilcation would be
that extension modules would have to re-written since they all
assume a reference counting GC.  A foreign function interface like
CMU Lisp's "alien" or GHC's FFI is not necessarily any worse but it
does place different demands on extension module authors. 

As a student project, I think it would make sense to forget about
extensions and try to create a barebones interpreter based on
CPython's runtime, compiler, etc with the reference counting ripped
out and some other GC installed.

I once had the Boehm GC working with Python.  That's not too
interesting.  I'm not really up-to-date on current GC research but I
think your GC has to do some copying in order to get really good
performance.  Producing a barebones version of the Python
interpreter that utilizes a modern, copying GC would be a nice
achievement and could be a platform for future work.

Regards,

  Neil

___
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] My patches

[Brett Cannon]

On Thu, Oct 30, 2008 at 17:27, Victor Stinner
<[EMAIL PROTECTED]> wrote:
> Le Friday 31 October 2008 00:34:32 Paul Moore, vous avez écrit :
>> Agreed. I was thinking vaguely in terms of a type of voting - rather
>> than a status or resolution, it might be more like the nosy list - a
>> list of people who have said they think the patch is OK. The more
>> people on the list, the stronger the assurance that it's acceptable.
>> It is still a matter of trust, of course - nothing can avoid that.
>
> I like this idea. But there are different things to review. Examples:
>  - the bug report: is the bug reproductible? is the bug isolated?
>  - a patch: the patch works? the patch looks correct? or invalid coding style,
> introduce a regression, or anything else
>
>> I was thinking in terms of summary reports (...)
>
> I think that you need an new information: the issue progress, eg.
>  - initial state: 0% => need more information
>  - bug isolated: 25% => need a patch
>  - patch present: 50% => patch needs reviewers
>  - patch reviewed: 75% => patch just have to be applied
>  - issue closed: 100% (done)
>
> Beginners can search for progress < 25%. They can try to reproduce a problem
> to check the Python version, the OS, etc. Or just help to give more
> informations about the issue.
>
> Core developers just have to check for progress >= 75%.
>

I have a similar list that I have been thinking about proposing. I did
a blog post about it at
http://sayspy.blogspot.com/2008/08/what-are-typical-steps-issue-goes.html
and received positive feedback:

* triage
* verify bug
* test needed
* needs patch
* patch review
* commit review
* committed/rejected

That way all the steps needed are obvious. I was going to start
working on proposing this after doing the first draft of the DVCS PEP.

-Brett
___
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] hg branch gone?

[Brett Cannon]

I just tried to update my 3.0 branch in hg from
http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
404. Anyone else having trouble?

-Brett
___
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] Fwd: Removal of GIL through refcounting removal.

[Nick Coghlan]

Neil Schemenauer wrote:
> Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
>> For a student project in a course on virtual machines, we are
>> evaluating the possibility to experiment with removing the GIL
>> from CPython
> 
> Hi,
> 
> It's great to hear of this kind of project.  I think what you want
> to do is difficult but possible.  The major compilcation would be
> that extension modules would have to re-written since they all
> assume a reference counting GC.  A foreign function interface like
> CMU Lisp's "alien" or GHC's FFI is not necessarily any worse but it
> does place different demands on extension module authors. 

Michael Foord's comment about the way Ironclad does it suggests a
possible interim step that would allow existing extensions to be used at
the cost of some additional overhead: use free threading in the core,
but have an "extension module lock" that cuts things back to a single
thread whenever non-core code is invoked.

It wouldn't be as fast as a completely free-threaded setup (since the
EML would need to operate as a variant of a 'read/write' lock, with the
core code mostly leaving it in the multiple-threads-allowed 'read' mode,
promoting it to single-thread-only 'write' mode when potentially
dispatching to non-core code, and dropping back to the 'read' mode when
the dispatch landed back in core code again).

Over time, extension modules which were updated to use their own
internal locks could also drop back to free-threading mode. In essence,
the GIL would still exist, but instead of being a simple mutex the way
it is now, it would have an intermediate stage which allowed multiple
threads to continue running. Once most extension modules had been
converted, the function to promote the EML from multi-threaded mode to
single-thread only mode could be removed.

A mechanism like that would avoid one of the more subtle problems in
removing the GIL: currently, CPython-specific Python code can assume
that invocation of a C function from Python code is an atomic operation,
since the body of the function executes as a single bytecode (we're
talking about the case here where the C function is known not to release
the GIL).

I've written code which relied on the GIL in exactly that way, and I'm
sure I'm far from the only Python programmer to do so. If the GIL was
removed without adding an extension module lock, such applications would
require additional locking either in the C extension module or in the
Python code.

A possible starting point for such a project: move the locking
mechanisms that are implemented in Python in the threading module to
C-based implementations in _thread so that a richer low overhead locking
arrangement is available to extensions modules (and the rest of the core).

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
___
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] Fwd: Removal of GIL through refcounting removal.

[Nick Coghlan]

Michael Foord wrote:
> Moving more C extensions to an implementation based on ctypes would be
> enormously useful for PyPy, IronPython and Jython, but ctypes is not yet
> as portable as Python itself which could be an issue (although one worth
> resolving).

If I recall correctly, the main blocker to ctypes portability is libffi
portability. So if anyone would like to see ctypes on more platforms,
then that's the limitation they really need to attack.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---

___
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] My patches

[Nick Coghlan]

Paul Moore:
> 3. There's nothing obvious I can do to move an issue forward. Sure, I
>  can make a comment, but that's about it. I'd like something that
> stood a bit more chance of getting noticed (like a status change, or
> maybe a list of people who think this is good to apply, which I can
> add myself to).

Speaking for myself, I rarely spend any time going through the
tracker looking for items I can help handle*. So one of the things I
find *most* helpful is when someone adds me to the nosy list for a
tracker issue, since that will drop an email into my issue tracker
folder with a link straight to the issue.

Obviously I'd prefer it if people only did that when I really can help,
but I don't mind getting the occasional misdirected issue if it means
that more problems in my areas of expertise are brought directly to my
attention.

(*I only spend a fairly limited amount of time on python at the moment,
and keeping up with python-dev, python-3000, reviewing the two checkins
list and looking into items that are brought directly to my attention
fills that up pretty well)

Tarek Ziadé wrote:
> Since it is a hard and long process  "to know it all"  in Python, and
>  to become a core developer
> 
> What about having two level of devs ?
> 
> + core developers + standard library developers
> 
> I mean, the standard library could be open ihmo to a wider range of
> people, or maybe even having people specialized in some packages,
> modules, even if they don't know anything about the C apis of the
> core.
> 
> Those "standard library developers" could be blessed to work on 
> specific areas of the standard library and "followed" by a core
> developer that can just make sure everything goes in the right
> direction without having too much extra work for that.

I think you'll that most of the "core devs" have areas where we're
confident of our domain knowledge and are happy to accept and commit
patches, and other areas where we're willing to review things and
provide recommendations, and then areas where we have next to no
knowledge at all. The standard library is pretty huge, and outside a few
generally useful core modules, which sections of it are useful to you
depends greatly on what kind of application you're working on.

To use myself as an example, if a bug or patch relating to the compiler
, the import system, runpy, contextlib, functools or a few others areas
is brought to my attention, I'll generally consider myself competent to
both assess the problem and apply any fixes (I may not consider the
issue *urgent*, or else I'll want to spend some time just mulling it
over, so the tracker item may still hang around for a while, but I'll
get to them eventually).

Then there are a few other areas (such as threading and
multiprocessing), where I'll take an active interest in matters (because
it's code I either use, or am likely to use at some point), but usually
defer to others when it comes to making the actual commits. This is
particular so when areas have clear owners (e.g. Raymond for itertools,
Jesse for multiprocessing, Facundo/Raymond for decimal) or are fairly
complex and I know I haven't studied them enough to understand them
properly (e.g. the memory allocator).

And finally, there are large swathes of the standard library that I've
never even used, let alone looked at in a code editor (such as nearly
all of the network protocol and database libraries, as what I personally
use Python for tends to be much lower level than that). For those areas,
I don't really consider myself competent to even provide effective
review, so I tend to ignore those patches completely.

In the past, even Guido has explicitly deferred to the appropriate
subject matter experts when it came to areas of the standard library he
personally didn't use much.

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---

___
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