[Python-Dev] Discussion draft: Proposed Py2.5 C API for set and frozenset objects

2005-08-13 Thread Raymond Hettinger 
The object and types

PySetObject subclass of object
used for both sets and frozensets
PySet_Type  a basetype
PyFrozenSet_Typea basetype

The type check macros
-
PyFrozenSet_CheckExact(ob)  a frozenset
PyAnySet_CheckExact(ob) a set or frozenset
PyAnySet_Check(ob)  a set, frozenset, or subclass of either

The constructors

obj PySet_New(it)   takes an iterable or NULL; returns new
ref
obj PyFrozenSet_New(it) takes an iterable or NULL; returns new
ref

The fine grained methods

int PySet_Size(so)

int PySet_Contains(so, key) 1 for yes; 0 for no; -1 for error
raises TypeError for unhashable key
does not automatically convert to
frozenset

int PySet_Add(so, key)  0 for success; -1 for error
raises TypeError for unhashable key
raises MemoryError if no room to grow

obj PySet_Pop(so)   return new ref or NULL on failure
raises KeyError if set is emtpy

int PySet_Discard(so, key)  1 if found and removed
0 if not found (does not raise KeyError)
-1 on error
raises TypeError for unhashable key
does not automatically convert to
frozenset


Course grained methods left for access through PyObject_CallMethod()

copy, clear, union, intersection, difference, symmetric_difference,
update,
intersection_update, difference_update, symmetric_difference_update
issubset, issuperset, __reduce__

Other functions left for access through the existing abstract API
-
PyObject_RichCompareBool()
PyObject_Hash()
PyObject_Repr()
PyObject_IsTrue()
PyObject_Print()
PyObject_GetIter()

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Hosting svn.python.org

2005-08-13 Thread Martin v. Löwis 
[EMAIL PROTECTED] wrote:
> I will enthusiastically cast my vote for tummy.com, Sean Reifschneider's
> company.  Mojam leases a server there (Mojam & Musi-Cal websites running
> CentOS 4, Apache+mod_perl, Python, Mason, MySQLdb, Mailman, etc).  Their
> service has been absolutely awesome.

But we don't want to lease a server - we are looking for an Subversion
hoster. If we *just* wanted a server, there would be no reason to
drop (*) the current svn.python.org.

So what precisely is the Subversion offer of tummy.com ($/per month
for what disk limit, monthly download limit, number of developers
limit, backup service, email notification, ability for offsite
download of the repository tarball, what access method (is svn+ssh
supported, anonymous WebDAV))?

In case this isn't clear yet: several people are concerned that
running the Python svn repository by volunteers will risk service
outage, and unnecessarily consume volunteer resources. So just replacing
the machine we get for free now with a machine we have to pay for
won't do any good.

I understand that I could now go to tummy.com, contact them, and
research all details myself. But I'm not willing to: everybody
who wants to suggest a different service should find out all the
details of that service, and report them so I can include them
into the PEP.

Regards,
Martin

(*) This PEP is actually not at all about svn.python.org, and the
pydotorg SVN repository. Those are in the realms of the infrastructure
committee, and they do a great job. The PEP is *only* about
migrating the Python source code proper from CVS (along with
the other code snippets that are in that CVS).
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xml.parsers.expat no userdata in callback functions

2005-08-13 Thread Martin v. Löwis 
Kristian Benoit wrote:
> This means one cant parse multiple files at the same time using the same
> handlers. You cant pass the context current context to the handler, you must
> base your code on global variables which is not so nice.

This is not true. You can create multiple parsers, and then can make the
callback functions bound methods, using self to store parse-specific
data. There is no need to have extra callback data.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Extension to dl module to allow passing strings from native function

2005-08-13 Thread Martin v. Löwis 
Senko Rasic wrote:
> Thoughts, comments? Could this be put in standard module, does it make
> sense, etc?

Are you aware of the ctypes module?

http://starship.python.net/crew/theller/ctypes/

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] new PEP type: Process

2005-08-13 Thread David Goodger 
[Aahz]
> Go ahead and make PEP 6 a Process PEP.

Done!

--
David Goodger 


signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Exception Reorg PEP checked in

2005-08-13 Thread Wilfredo Sánchez Vega 
   I'm curious about why Python lacks FileNotFoundError,  
PermissionError and the like as subclasses of IOError.

   Catching IOError and looking at errno to figure out what went  
wrong seems pretty unpythonic, and I've often wished for built-in  
subclasses of IOError.

   I sometimes subclass them myself, but a lot of the time, I'm  
catching such exceptions as thrown by the standard library.

 -wsv

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] xml.parsers.expat no userdata in callback functions

2005-08-13 Thread Guido van Rossum 
> Kristian Benoit wrote:
> > This means one cant parse multiple files at the same time using the same
> > handlers. You cant pass the context current context to the handler, you must
> > base your code on global variables which is not so nice.
> 
"Martin v. Löwis" replied:
> This is not true. You can create multiple parsers, and then can make the
> callback functions bound methods, using self to store parse-specific
> data. There is no need to have extra callback data.

What he said. Kristian's complaint is probably a common misconception
about Python -- not too many languages have unified the concepts of
"bound methods" and "callables" so completely as Python. Every
callable is in a sense a closure (or can be). Nested functions are
other examples.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: Distributed RCS

2005-08-13 Thread Guido van Rossum 
With permission, I'm forwarding an email from Mark Shuttleworth about
Bazaar-2 (aka Bazaar-NG), a distributed source control system (not
entirely unlike bitkeeper, I presume) written in Python and in use by
the Ubuntu system. What do people think of using this for Python? Is
it the right model? Do we want to encourage widespread experimentation
with the Python source code?

--Guido van Rossum (home page: http://www.python.org/~guido/)

-- Forwarded message --
From: Mark Shuttleworth <[EMAIL PROTECTED]>
Date: Aug 11, 2005 12:13 PM
Subject: Distributed RCS
To: Guido van Rossum <[EMAIL PROTECTED]>
Cc: Steve Alexander <[EMAIL PROTECTED]>, Martin Pool
<[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]>


Hi Guido

Steve forwarded your mail to me regarding distributed revision control,
so I thought I'd follow up with some thoughts on why I agree with
Frederick Lundh that it's important, and where we are going with the
Bazaar project.

First, distributed RCS systems reduce the barrier to participation.
Anybody can create their own branches, and begin work on features, with
full revision control support, without having to coordinate with the
core RCS server sysadmin. So, for example, if someone gets an idea to
work on PEP X, they can simply create a branch, and start hacking on it
locally, with full RCS functionality like commit and undo, and logs of
their changes over time. They can easily merge continually from the
trunk, to keep their branch up to date. And they can publish their
branch using only a web server.

With Bazaar, these branches can be personal or shared group branches.

The net effect of this is to make branching a core part of the
development process. Each feature gets developed on a branch, and then
merged when its ready. Instead of passing patches around in email, you
find yourself passing out branch references, which are much easier to
deal with since they are always "up to date". In Launchpad, we have
evolved to work around this branch-per-feature approach, and built a
review process so that each branch gets a review before the code is
merged to the trunk.

It also has a positive social impact, because groups that are interested
in a feautre can begin to collaborate on it immediately rather than
waiting to get consensus from everybody else, they just start their
branch and get more testing when it is reaching a reasonable state of
maturity - then the project decides whether or not it lands. That
results in less argument about whether or not a feature is a good idea
before anybody really knows what it's going to look like. Those who are
interested, participate, and those who aren't reserve judgement till
it's done.

As for Bazaar, we have just wrapped up our latest sprint, where we
decided that bazaar-ng (bzr), which is being written in Python by Martin
Pool, will become Bazaar 2.x, in the first quarter of 2006. The current
1.x line of development has served us well, but the ideas we developed
and which have been implemented as a working bazaar-ng reference by
Martin are now proven enough that I'm committing the project (Ubuntu,
and all of Launchpad) to it. Martin will continue to work on it full
time, and will be joined by the current Bazaar 1.x team, Robert Collins,
David Allouche and James Blackwell. That makes for a substantial chunk
of resources but I think it's worth it because we need a truly superb
free revision control system when dealing with something as large and
complex as an entire distribution.

The whole of Ubuntu will be in Bazaar in due course. Currently, we have
about 500 upstreams published in the Bazaar 1.x format (see
http://bazaar.ubuntu.com/ for the list), all of those will be converted
to Bazaar 2.x and in addition we will continue to publish more and more
upstreams in the 2.x archive format. We actively convert CVS and SVN
upstreams and publish them in the Bazaar format to allow us to use a
single, distributed revision control system across all of those
packages. So there's a lot of real-world data and real-world coding
going on with Bazaar as the RCS holding it all together.

Perhaps more importantly, we are integrating Bazaar tightly with the
other Launchpad applications, Rosetta and Malone. This means that bug
tracking and translation will be "branch aware". You will be able to
close a bug by noting that a commit in one of your branches fixes the
bug, then merging it into the relevant mainline branch, and have the
launchpad bug tracker automatically mark the bug as closed, if you wish.
Similarly you will be able to get the latest translations just by
merging from the branch published by Rosetta that has the latest
translations in it for your application.

The combination of distributed revision control, and ultimately
integrated bug tracking and translations, will I think be a very
efficient platform for collaborative development.

Bazaar is free, and the use of Launchpad is free though we have not yet
released the code to the web services for bug

[Python-Dev] cvs to bzr?

2005-08-13 Thread skip 
Based on the message Guido forwarded, I installed bazaar-ng.  From Mark's
note it seems they convert cvs repositories to bzr repositories, but I
didn't see any mention in the bzr docs of any sort of cvs2bzr tool.
Likewise, Google didn't turn up anything obvious.  Anyone know of something?

Thx,

Skip

___
Python-Dev mailing list
[email protected]
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: Distributed RCS

2005-08-13 Thread Neil Schemenauer 
On Sat, Aug 13, 2005 at 02:27:22PM -0700, Guido van Rossum wrote:
> What do people think of using this for Python?

I think it deserves consideration.  One idea would be to have a
Bazaar-NG repository that tracks the CVS SF repository.  I haven't
tried it yet but there is a tool called Tailor[1] that automates the
task.  That would give people a chance to experiment with Bazaar-NG
(and still work with SF is down) without committing to it.

> Is it the right model? Do we want to encourage widespread
> experimentation with the Python source code?

I think Python works fairly well with the centralized model.
However, I expect it's hard to know what we are missing.

  Neil

1. http://darcs.net/DarcsWiki/Tailor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cvs to bzr?

2005-08-13 Thread Neil Schemenauer 
On Sat, Aug 13, 2005 at 06:00:37PM -0500, [EMAIL PROTECTED] wrote:
> Based on the message Guido forwarded, I installed bazaar-ng.  From Mark's
> note it seems they convert cvs repositories to bzr repositories, but I
> didn't see any mention in the bzr docs of any sort of cvs2bzr tool.

Haven't tried it but should work:

http://darcs.net/DarcsWiki/Tailor 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: Distributed RCS

2005-08-13 Thread Guido van Rossum 
Another fwd, describing how Steve Alexander's group user bazaar.

--Guido van Rossum (home page: http://www.python.org/~guido/)

-- Forwarded message --
From: Steve Alexander <[EMAIL PROTECTED]>
Date: Aug 12, 2005 4:00 PM
Subject: Re: Distributed RCS
To: Guido van Rossum <[EMAIL PROTECTED]>
Cc: Mark Shuttleworth <[EMAIL PROTECTED]>, Martin Pool
<[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]>


Hi Guido,

I'm not going to post to python-dev just now, because I'm leaving on 1.5
weeks vacation tomorrow, and I'd rather be absent than unable to answer
questions promptly.

Martin Pool will be around next week, and will be able to take part in
discussions on the list.

Feel free to post all or part of Mark's or my emails to the python lists.

Mark wrote:
>
> I hope that puts bazaar into perspective for you. Give it a spin - the
> development 2.x codebase is robust enough now to handle a line of
> development and do basic merging, we are switching our own development
> to the pre-release 2.x line in October, and we will switch over all the
> public archives we maintain in around March next year.

A large part of the internal development at Canonical is the Launchpad
system.  This is about 30-40 kloc of Python code, including various
Twisted services, cron scripts, a Zope 3 web application, database
tools, ...

It's being worked on by 20 software developers.  Everyone uses bazaar
1.4 or 1.5, and around October, we'll be switching to use bazaar 2.x.

I'll describe how we work on Launchpad using Bazaar.  This is all from
the Bazaar 1.x perspective, and some things will become simpler when we
change to using Bazaar 2.x.

I've left the description quite long, as I hope it will give you some of
the flavour of working with a distributed RCS.


== Two modes of working: shared branches and PQM ==

Bazaar supports two different modes of working for a group like the
Launchpad team.

1. There's a shared read/write place that all the developers have access
to.  This is contains the branches we release from, and represents the
"trunk" of the codebase.

2. A "virtual person" called the "patch queue manager" (PQM) has
exclusive write access to a collection of branches.  PQM takes
instructions as GPG signed emails from launchpad developers, to merge
their code into PQM's branches.

We use the latter mode because we have PQM configured not only to accept
requests to merge code into PQM's codebase, but to run all the tests
first and refuse to merge if any test fails.


== The typical flow of work on Launchpad ==

Say I want to work on some new feature for Launchpad.  What do I do?

1. I use 'baz switch' to change my working tree from whatever I was
working on last, and make it become PQM's latest code.

  baz switch [EMAIL PROTECTED]/launchpad--devel--0

 "rocketfuel" is the code-name for the branches we release our
 code from.  PQM manages the rocketfuel branches.  In Bazaar 1.x,
 collections of branches are called "archives" and are identified
 by an email address plus some other optional information.
 So, "[EMAIL PROTECTED]" is PQM's email address.
 "launchpad--devel--0" is simply the name of the main launchpad
 branch.  The format of branch names is very strict in Bazaar 1.x.
 It is much more open in Bazaar 2.x.


2. I use 'baz branch' to create my own branch of this code that I can
commit changes to.

  baz branch [EMAIL PROTECTED]/launchpad--ImproveLogins--0

 My archive is called "[EMAIL PROTECTED]".  The branch
 will be used to work on the login functionality of Launchpad, so
 I have named the branch "launchpad--ImproveLogins--0".


3. I hack on the code, and from time to time commit my changes.  I need
to 'baz add' new files and directories, and 'baz rm' to remove files,
and 'baz mv' to move files around.

  # hack hack hack
  baz commit -s "Refactored the whatever.py module."
  # hack hack hack
  baz del whatever_deprecated.py
  baz commit -s "Removed deprecated whatevers."
  # hack hack hack


4. Let's say I hacked on some stuff, but I didn't commit it.  I don't
like what I did, and I want to start again.

  # hack hack hack
  baz undo

 'baz undo' puts the source code back into the state it was in after the
last commit, and puts the changes somewhere.  If I change my mind again,
I can say 'baz redo', and get my changes back.


5. All this hacking and committing has been happening on my own
workstation, without a connection to the internet.  Perhaps I've been on
a plane or at a cafe.  When I have a connection again, I can make my
work available for others to see by mirroring my code to a central
location.  Each Launchpad developer has a mirror of the archive they use
for Launchpad work on a central machine at the Canonical data centre.
In our case, the mirror command uses sftp to copy the latest changes I
have made into the mirror on this central server.

  baz archive-mirror


6. Because we have a strict code review proccess for Launchpad
development, I can't (or rather, shouldn't) submit my change

Re: [Python-Dev] Distributed RCS

2005-08-13 Thread Terry Reedy 
> Another fwd, describing how Steve Alexander's group user bazaar.

I found this rather clear and easy to understand even without having 
directly used CVS (other than to browse).  Some of the automation features 
seem useful but I don't know whether they are specific to bazaar.  Anyway, 
my thoughts.

It seems to me that auto testing of the tentatively updated trunk before 
final commitment would avoid the 'who checked in test-breaking code' 
messages that appear here occasionally.  But it requires that the update + 
test-suite time be less than the average inter-update interval.

I understand the main difference between baz and cvs (and similar) to be 
that checked-out-to-developers copies remain 'within' the distributed 
system and accessible to the master system rather than becoming external 
(and lost track of) copies.  In consequence (again if I understand 
correctly), pre- and post-review diffs and merges are done directly between 
the developers branch and the current system trunk rather than (for diffs) 
with a possibly out-of-date master on the developer's machine, leading to 
trunk updates with a possibly out-of-date diff.  If so, this would 
eliminate reviewers having to make requests such as 'please run a new diff 
against the current CVS head' that I remember sometimes seeing on the SF 
tracker.

The current bottleneck in Python development appears to be patch reviews. 
So merely making submission and commitment easier will not help much.  An 
alternative to more reviewers is more automation to make more effective use 
of existing reviewers.  (And this might also encourage more reviewers.) 
The Launchpad group seems to be ahead in this regard, but I don't know how 
much this is due to using bazaar.  In any case, ease of improving the 
review process might be a criterion for choosing a source code system.  But 
I leave this to ML.

*Other things being equal*, using a state-of-the-art development system 
written in Python to develop Python would be a marketing plus.

Terry J. Reedy





___
Python-Dev mailing list
[email protected]
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: Distributed RCS

2005-08-13 Thread Anthony Baxter 
I have great hopes for baz-ng, but I don't know that it's really ready for 
production use just yet. I don't know that we want to be right out on the 
bleeding edge of revision control systems for Python. 

The current bazaar, last time I looked (a few months ago) did not work on 
Windows. This is a complete deal-breaker for us, unless we can agree to dump 
that Windows support (who needs it, really? ) I *hope* that baz-ng will
work fine on Windows - I haven't looked too closely at that side of it.

Anthony 
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com