[Python-Dev] Buildbot master moved

[Martin v. Löwis]

I have now moved the buildbot master to OSU/OSL, and upgraded the
buildbot version in the process. If there are any issues, let me
know or Antoine.

Slaves should (and apparently do) reconnect if they were changed
to use "buildbot.python.org" as the master. Some probably weren't;
we'll figure this out.

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] [Infrastructure] Buildbot master moved

[Antoine Pitrou]

Le jeudi 28 juin 2012 à 09:13 +0200, "Martin v. Löwis" a écrit :
> I have now moved the buildbot master to OSU/OSL, and upgraded the
> buildbot version in the process. If there are any issues, let me
> know or Antoine.

It seems we lost the "force build" button. Judging from the templates,
the form is here, it just isn't displayed.

I also don't see any custom builders:
http://buildbot.python.org/all/waterfall?category=custom.stable&category=custom.unstable

Regards

Antoine.


___
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] [Infrastructure] Buildbot master moved

[Antoine Pitrou]

Le jeudi 28 juin 2012 à 12:06 +0200, Antoine Pitrou a écrit :
> Le jeudi 28 juin 2012 à 09:13 +0200, "Martin v. Löwis" a écrit :
> > I have now moved the buildbot master to OSU/OSL, and upgraded the
> > buildbot version in the process. If there are any issues, let me
> > know or Antoine.
> 
> It seems we lost the "force build" button. Judging from the templates,
> the form is here, it just isn't displayed.
> 
> I also don't see any custom builders:
> http://buildbot.python.org/all/waterfall?category=custom.stable&category=custom.unstable

Ok, it seems we should migrate to the ForceScheduler API:
http://buildbot.net/buildbot/docs/0.8.6/manual/cfg-schedulers.html#forcescheduler-scheduler



___
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] PEP 423 : naming conventions and recipes related to packaging

[Benoît Bryon]

Le 27/06/2012 13:34, Antoine Pitrou a écrit :

Similarly, I think the section about private projects ("Private
(including closed-source) projects use a namespace") should be removed.
It is not our duty to promote naming standards for private (i.e.
internal) projects.

The intention in the proposed PEP is to promote standards
for general Python usage, which implicitely includes both public
and private use.

The proposed PEP tries to explain how the conventions
apply in most use cases. Public and private scopes are mentioned
explicitely because they were identified as valuable use cases.

Here are some reasons why the "private code" use case has
been identified as valuable:

* New Python developers (or more accurately new distribution
  authors) may wonder "What makes a good name?", even if they are
  working in a private area. Guidelines covering private code would
  be welcome.

* At work, I already had discussions about naming patterns for
  closed source projects. These discussions consumed some energy
  made the team focus on some "less valuable" topics. We searched
  for an official convention and didn't find one. We made choices
  but none of us was really satisfied about it. An external
  arbitration from a trusted authority would have been welcome,
  even if we were making closed-source software.

* As Paul said, "personal code often ends up more widely used than
  originally envisaged". So following the convention from the start
  may help.

* Here, the PEP already covers (or tries to) most public code use
  cases. It's quite easy to extend it to private code. I feel
  drawbacks are negligible compared to potential benefits.

  .. note:: IMHO, main drawback is "read this long document".

* Isn't it obvious that, at last, people do what they want to in
  private code? In fact, they also do in public code. I mean the
  document is an informational PEP. It recommends to apply conventions
  but the actual choice is left to developers.


That said, would the changes below improve the document?

* Keep the parts about private and closed-source code, but add a
  note to insist on "in private code, you obviously do what you want
  to" and "be aware that personal code often ends up more widely used
  than originally envisaged".

* At the beginning of the document, add a section like
  
http://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds


Another option would have been to deal with "general Python code"
and don't mention "public" and "private" areas, i.e. implicitely
cover both. I haven't followed this way because it is implicit.



Also, I don't see what's so important about using
your company's name as a top-level namespace. You don't need it for
conflict avoidance: you can just as well use distinctive project names.


Using company's name as top-level namespace has been proven a
good practice:

* avoids clashes and confusion with public projects, i.e. don't
  create a "cms" private project because there could be a "cms"
  project on PyPI.

* makes it easy to release the code as open-source: don't change
  the project name.

* if there is no reason at all for the project to contain the
  company name (i.e. the project is not specific to the company),
  why not realeasing it as open source? (with a one-level name)

Using company's name is not the only option. But, as far as I know,
it fits most use cases, which is enough (and required) for a
convention.

Another option is to use any arbitrary name as top-level namespace.
You can. If an arbitrary name seems obvious to you, feel free to
use it. But, in most cases, company's name is an obvious choice.

So, would you appreciate a change so that:

* company name is recommended as a best practice.
* but any arbitrary name can be used.

Could be something in:

1. "For private projects, use company name (or any unique arbitrary name)
   as top-level namespace".

2. "For private projects, use any arbitrary name (company name is
   generally a good choice) as top-level namespace".

3. "For private projects, use a top-level namespace (company name is
   generally a good choice, but you can use any unique arbitrary name)."


Benoit

___
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] PEP 423 : naming conventions and recipes related to packaging

[Benoît Bryon]

Le 27/06/2012 12:50, Antoine Pitrou a écrit :

There is one Zen principle this PEP is missing:
Flat is better than nested.

This PEP seems to promote the practice of having a top-level namespace
denote ownership. I think it should do the reverse: promote
meaningful top-level packages (e.g. "sphinx") as standard practice, and
allow an exception for when a piece of software is part of a larger
organizational body.


The PEP's intention is to tell what Nick described. Maybe
the words are not clear...


Notes about the order of items in the overview:

1. respect names registered on PyPI. This is a requirement.

2. adopt specific conventions if any, i.e. don't break the
   rules that already exist in existing projects. This
   convention makes the PEP backward compatible. It is the
   first rule because, for project-related contributions, the
   first action should be to read the documentation of the main
   project.

3. important thing is to avoid name collisions. This is a
   requirement for project names, and a strong recommendation
   for package/module names.

4. use a single name. This rule simplifies the action of choosing
   a name and brings consistency. If you already know how your
   package/module is imported in code, you can simply use it as
   project name.

5. then, we'd better make it easy to find and remember the project.
   This is a strong advice.

6. then, all the points above being considered, we'd better use
   flat names.

7. rules about syntax (PEP 8).

8. state about specific conventions, if any. This is the complement
   of point 2.

9. ask.


Would you appreciate a reordering?
Could be something like that:

1. adopt specific conventions if any.

2. avoid name collisions.

3. you'd better use flat names.

4. you'd better make it easy to find and remember the project.

5. you'd better use a single name and distribute only one
   package at a time

6. follow rules about syntax (PEP 8)

7. once you are done, state about specific choices, if any.
   This is the complement of point 1.

8. if in doubt, ask.



(i.e., "Community-owned projects can avoid namespace packages" should
be the first item in the PEP and renamed so that it appears common rule)


I guess we could move "shared projects can use a one-level
name" before guidelines related to private projects.


Benoit

___
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] Creating release blockers for Python 3.4

[Nick Coghlan]

Just a heads up (primarily for Georg and Larry): I've started marking
some issues as release blockers for 3.4 (currently just the
bytes-bytes/str-str transform() API and the set_encoding() method
discussed recently on python-ideas).

These are important gaps identified in the new Unicode handling model,
and we should make sure to review and discuss them well in advance of
3.4 being released.

Those are the only two I've identified so far where that course of
action has seemed appropriate - most of the time for this kind of
thing, I'd just assign the issue to myself to take a look at after the
feature freeze is over or else bump the priority up to high.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   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] PEP 423 : naming conventions and recipes related to packaging

[Paul Moore]

On 28 June 2012 11:36, Benoît Bryon  wrote:
>> Also, I don't see what's so important about using
>> your company's name as a top-level namespace. You don't need it for
>> conflict avoidance: you can just as well use distinctive project names.
>
> Using company's name as top-level namespace has been proven a
> good practice:

Not to me. This is what Java does, and whenever I have encountered it,
I have found it a major pain.

As an individual developer, I have no company name. The "use your
domain" option doesn't help either, as I have 3 registered domains to
my name, none of which I use consistently enough to want to use as the
definitive domain to identify "my" code forever.

What if I abandon a project, and someone else picks it up? Do they
need to change the name?

I have lots of little projects. Do they all have to sit under a single
namespace package "paul"? That's a maintenance problem, as there's no
standard namespace package facility prior to 3.3 (I don't use
setuptools, in general).

The concept of using a company/domain/personal name as the top level
raises far more questions than it answers for me...

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] cpython (2.7): #9559: Append data to single-file mailbox files if messages are only added

[Antoine Pitrou]

On Thu, 28 Jun 2012 12:59:02 +0200
petri.lehtinen  wrote:
> http://hg.python.org/cpython/rev/c37cb11b546f
> changeset:   77832:c37cb11b546f
> branch:  2.7
> parent:  77823:73710ae9fedc
> user:Petri Lehtinen 
> date:Thu Jun 28 13:48:17 2012 +0300
> summary:
>   #9559: Append data to single-file mailbox files if messages are only added
> 
> If messages were only added, a new file is no longer created and
> renamed over the old file when flush() is called on an mbox, MMDF or
> Babyl mailbox.

Why so? Appending is not atomic and, if it fails in the middle, you
could get a corrupt mbox file.
Furthermore, I disagree that it's a bugfix: IMO it should wait for 3.4.

Regards

Antoine.


___
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] Signed packages

[Hynek Schlawack]

Am 23.06.12 14:03, schrieb mar...@v.loewis.de:

>> I'm surprised gpg hasn't been mentioned here.  I think these are all
>> solved problems, most free software that is signed signs it with the
>> gpg key of the author.  In that case all that is needed is that the
>> cheeseshop allows the uploading of the signature.
> For the record, the cheeseshop has been supporting pgp signatures
> for about ten years now. Several projects have been using that for
> quite a while in their releases.

Also for the record, it’s broken as of Python 3.2. See
http://bugs.python.org/issue10571
___
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] PEP 423 : naming conventions and recipes related to packaging

[Antoine Pitrou]

On Thu, 28 Jun 2012 12:35:24 +0200
Benoît Bryon  wrote:
> 
> Would you appreciate a reordering?
> Could be something like that:
> 
> 1. adopt specific conventions if any.
> 
> 2. avoid name collisions.
> 
> 3. you'd better use flat names.
> 
> 4. you'd better make it easy to find and remember the project.
> 
> 5. you'd better use a single name and distribute only one
> package at a time
> 
> 6. follow rules about syntax (PEP 8)
> 
> 7. once you are done, state about specific choices, if any.
> This is the complement of point 1.
> 
> 8. if in doubt, ask.

Yes, that would be better.

I think the PEP also needs to spell out the rationale better.
Also, reminding the distinction between modules, packages and
namespace packages could be useful to the reader, especially if it's
supposed to end up in the documentation.

Regards

Antoine.


___
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] PEP 423 : naming conventions and recipes related to packaging

[Benoît Bryon]

Le 27/06/2012 22:08, Yury Selivanov a écrit :

With python adoption (enterprise too) growing, we will inevitably
find out that one single namespace (PyPI) is not enough, and
name collisions will become a frequent headache.


An argument for top-level namespace is related to PyPI
as a central place to publish Python code VS code
released in popular code repositories:

* many developers don't register projects with PyPI,
  even if open source. As an example, many projects
  are hosted on code repositories, such as Github.com,
  and not on PyPI.

* one reason (not the only one) is that, as an individual,
  publishing some "proof of concept" code at PyPI scares
  me:

  * it is very personal, at least at the beginning. Not
sure it is interesting.

  * what if the project gets abandoned? It will remain
on PyPI and block a name slot.

* on Github, people work in a user space. All projects are
  managed under the user account. Groups and companies
  can use organization accounts. This scheme seems popular
  and comfortable.

* on Github, people can fork projects. Project names are
  not unique, but "user/organization+project name" is
  unique. It seems to work well.

* sometimes, forks become more popular than original
  projects. Sometimes original projects are abandoned
  and several forks are active.

* Notice that distinct projects (i.e. not forks) can
  have the same name, provided they are owned by distinct
  users.

* Also notice that there is no deep nesting. There are
  only two levels: one for the user or organization, one
  for the project.

* if we consider PyPI as the unique reference and
  central place to check for (public) name availability,
  then shouldn't we promote registration with PyPI?

* there are other reasons why authors should register
  with PyPI. As an example  the ability to ``pip install
  project`` without using complicated pip options.

* if many projects on Github are published on PyPI, then
  what would happen? I bet that, without adequate naming
  conventions, there will be many name collisions.

* so promoting top-level namespace (including individual)
  can help.

* a risk is that it also becomes difficult to find a
  project within PyPI. But having lots of projects in
  PyPI is not the problem. The problem is more or less
  related to the search. Meaningful names, memorable
  names and packaging metadata are important for that
  purpose. And if necessary, we will be able to improve
  PyPI search engine or list/browse views.


Benoit

___
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] Signed packages

[martin]

Zitat von Hynek Schlawack :


Am 23.06.12 14:03, schrieb mar...@v.loewis.de:


I'm surprised gpg hasn't been mentioned here.  I think these are all
solved problems, most free software that is signed signs it with the
gpg key of the author.  In that case all that is needed is that the
cheeseshop allows the uploading of the signature.

For the record, the cheeseshop has been supporting pgp signatures
for about ten years now. Several projects have been using that for
quite a while in their releases.


Also for the record, it?s broken as of Python 3.2. See
http://bugs.python.org/issue10571


That's different, though: PyPI continues to support it just fine.
It's only distutils which has it broken. If you manually run gpg,
and manually upload through the web interface, it still works.

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] PEP 423 : naming conventions and recipes related to packaging

[Chris McDonough]

On 06/28/2012 06:36 AM, Benoît Bryon wrote:

Le 27/06/2012 13:34, Antoine Pitrou a écrit :

Similarly, I think the section about private projects ("Private
(including closed-source) projects use a namespace") should be removed.
It is not our duty to promote naming standards for private (i.e.
internal) projects.

The intention in the proposed PEP is to promote standards
for general Python usage, which implicitely includes both public
and private use.

The proposed PEP tries to explain how the conventions
apply in most use cases. Public and private scopes are mentioned
explicitely because they were identified as valuable use cases.

Here are some reasons why the "private code" use case has
been identified as valuable:

* New Python developers (or more accurately new distribution
   authors) may wonder "What makes a good name?", even if they are
   working in a private area. Guidelines covering private code would
   be welcome.

* At work, I already had discussions about naming patterns for
   closed source projects. These discussions consumed some energy
   made the team focus on some "less valuable" topics. We searched
   for an official convention and didn't find one. We made choices
   but none of us was really satisfied about it. An external
   arbitration from a trusted authority would have been welcome,
   even if we were making closed-source software.

* As Paul said, "personal code often ends up more widely used than
   originally envisaged". So following the convention from the start
   may help.

* Here, the PEP already covers (or tries to) most public code use
   cases. It's quite easy to extend it to private code. I feel
   drawbacks are negligible compared to potential benefits.

   .. note:: IMHO, main drawback is "read this long document".

* Isn't it obvious that, at last, people do what they want to in
   private code? In fact, they also do in public code. I mean the
   document is an informational PEP. It recommends to apply conventions
   but the actual choice is left to developers.


That said, would the changes below improve the document?

* Keep the parts about private and closed-source code, but add a
   note to insist on "in private code, you obviously do what you want
   to" and "be aware that personal code often ends up more widely used
   than originally envisaged".

* At the beginning of the document, add a section like

http://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds



Another option would have been to deal with "general Python code"
and don't mention "public" and "private" areas, i.e. implicitely
cover both. I haven't followed this way because it is implicit.



Also, I don't see what's so important about using
your company's name as a top-level namespace. You don't need it for
conflict avoidance: you can just as well use distinctive project names.


Using company's name as top-level namespace has been proven a
good practice:

* avoids clashes and confusion with public projects, i.e. don't
   create a "cms" private project because there could be a "cms"
   project on PyPI.

* makes it easy to release the code as open-source: don't change
   the project name.

* if there is no reason at all for the project to contain the
   company name (i.e. the project is not specific to the company),
   why not realeasing it as open source? (with a one-level name)

Using company's name is not the only option. But, as far as I know,
it fits most use cases, which is enough (and required) for a
convention.

Another option is to use any arbitrary name as top-level namespace.
You can. If an arbitrary name seems obvious to you, feel free to
use it. But, in most cases, company's name is an obvious choice.

So, would you appreciate a change so that:

* company name is recommended as a best practice.
* but any arbitrary name can be used.

Could be something in:

1. "For private projects, use company name (or any unique arbitrary name)
as top-level namespace".

2. "For private projects, use any arbitrary name (company name is
generally a good choice) as top-level namespace".

3. "For private projects, use a top-level namespace (company name is
generally a good choice, but you can use any unique arbitrary name)."



It's probably always a reasonable idea to use a brand-prefixed namespace 
for *private* packages but in my experience it's almost always a bad 
idea to publish any set of otherwise-unrelated packages that share a 
branded namespace prefix to PyPI.


I know this because I've been involved with it at least twice with 
"zope." and "repoze." brands/namespaces.  The meaning of both of those 
namespaces has become soft over time and both now mean basically "this 
code was created by a group of people" instead of "this code is useful 
under a circumstance or for a purpose".  Those namespaces are both the 
moral equivalent of a "garbage barge" class in development: code related 
to the namespace might do anything ("zope" now means a compan

Re: [Python-Dev] [Infrastructure] Buildbot master moved

[Antoine Pitrou]

Le jeudi 28 juin 2012 à 12:11 +0200, Antoine Pitrou a écrit :
> Le jeudi 28 juin 2012 à 12:06 +0200, Antoine Pitrou a écrit :
> > Le jeudi 28 juin 2012 à 09:13 +0200, "Martin v. Löwis" a écrit :
> > > I have now moved the buildbot master to OSU/OSL, and upgraded the
> > > buildbot version in the process. If there are any issues, let me
> > > know or Antoine.
> > 
> > It seems we lost the "force build" button. Judging from the templates,
> > the form is here, it just isn't displayed.
> > 
> > I also don't see any custom builders:
> > http://buildbot.python.org/all/waterfall?category=custom.stable&category=custom.unstable

Ok, both are fixed.
Note: there are uncommitted changes in the local git repo, I left them
uncommitted.

Regards

Antoine.


___
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] PEP 423 : naming conventions and recipes related to packaging

[R. David Murray]

On Thu, 28 Jun 2012 08:14:07 -0400, Chris McDonough  wrote:
> It's probably always a reasonable idea to use a brand-prefixed namespace 
> for *private* packages but in my experience it's almost always a bad 
> idea to publish any set of otherwise-unrelated packages that share a 
> branded namespace prefix to PyPI.
> 
> I know this because I've been involved with it at least twice with 
> "zope." and "repoze." brands/namespaces.  The meaning of both of those 
> namespaces has become soft over time and both now mean basically "this 
> code was created by a group of people" instead of "this code is useful 
> under a circumstance or for a purpose".  Those namespaces are both the 
> moral equivalent of a "garbage barge" class in development: code related 
> to the namespace might do anything ("zope" now means a company and two 
> completely different application servers; "repoze" never really meant 
> anything, it was always a pure brand).
> 
> People typically look for code on PyPI that solves a problem, and 
> branding in namespacing there is usually confusing.  E.g. there are many 
> highly-general useful things in both the zope. and repoze. namespace 
> packages, but people are skittish about the meaning of the namespaces 
> and tend to look for a "more generic" solution.  They are often right to 

Looking at Zope mostly from the outside (I was involved with zope
development during an early stage of zope 3, but I haven't been involved
or used it for years), this matches my perception as well.  The zope
namespace made some sense early on, but as the project got refactored
into more cleanly separated pieces, it ends up just getting in the way
of wider adoption of the most useful pieces.

For what it is worth, notice that perl does not use organization names,
it uses functional names.

Which languages other than Java use organizational names?

--David
___
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] cpython (2.7): #9559: Append data to single-file mailbox files if messages are only added

[Petri Lehtinen]

Antoine Pitrou wrote:
> > If messages were only added, a new file is no longer created and
> > renamed over the old file when flush() is called on an mbox, MMDF or
> > Babyl mailbox.
> 
> Why so? Appending is not atomic and, if it fails in the middle, you
> could get a corrupt mbox file.
> Furthermore, I disagree that it's a bugfix: IMO it should wait for 3.4.

The code previosly already appended messages to the end of the file
when calling add(). This patch just changed it to not do a full
rewrite when flush() is called. Having a partially written message in
the end of your mailbox doesn't seem like a fatal corruption to me.

Furthermore, I (and R. David Murray) think this is not so surprising
for users. Most (or all) other implementations always write changes
in-place without renaming, as this makes it possible to find out
whether new mail has arrived.
___
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] PEP 423 : naming conventions and recipes related to packaging

[R. David Murray]

On Thu, 28 Jun 2012 12:53:47 +0200, =?ISO-8859-1?Q?Beno=EEt_Bryon?= 
 wrote:
> Le 27/06/2012 22:08, Yury Selivanov a écrit :
> > With python adoption (enterprise too) growing, we will inevitably
> > find out that one single namespace (PyPI) is not enough, and
> > name collisions will become a frequent headache.
> 
> * on Github, people work in a user space. All projects are
>managed under the user account. Groups and companies
>can use organization accounts. This scheme seems popular
>and comfortable.
> 
> * on Github, people can fork projects. Project names are
>not unique, but "user/organization+project name" is
>unique. It seems to work well.
> 
> * sometimes, forks become more popular than original
>projects. Sometimes original projects are abandoned
>and several forks are active.
> 
> * Notice that distinct projects (i.e. not forks) can
>have the same name, provided they are owned by distinct
>users.

That is completely irrelevant.  The top level name in the github case
isolates the forks only.  It has nothing to do with the organization of
the *software*, only the *forks*.  Within the fork, the software itself
retains the same name...that's the whole point.

--David
___
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] [Infrastructure] Buildbot master moved

[Hynek Schlawack]

Hi,

I don’t know if it’s known, but the bot infrastructure is FUBAR now.
http://buildbot.python.org/all/waterfall is a stacktrace and all tests
fail because of the XML-RPC tests that use our buildbot API.

Regards
Hynek
___
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] cpython (2.7): #9559: Append data to single-file mailbox files if messages are only added

[R. David Murray]

On Thu, 28 Jun 2012 16:16:45 +0300, Petri Lehtinen  wrote:
> Antoine Pitrou wrote:
> > > If messages were only added, a new file is no longer created and
> > > renamed over the old file when flush() is called on an mbox, MMDF or
> > > Babyl mailbox.
> > 
> > Why so? Appending is not atomic and, if it fails in the middle, you
> > could get a corrupt mbox file.
> > Furthermore, I disagree that it's a bugfix: IMO it should wait for 3.4.
> 
> The code previosly already appended messages to the end of the file
> when calling add(). This patch just changed it to not do a full
> rewrite when flush() is called. Having a partially written message in
> the end of your mailbox doesn't seem like a fatal corruption to me.
> 
> Furthermore, I (and R. David Murray) think this is not so surprising
> for users. Most (or all) other implementations always write changes
> in-place without renaming, as this makes it possible to find out
> whether new mail has arrived.

It is true, however, that Petri found that mutt (I think?) does some extra
gymnastics to provide recovery where the write fails part way through,
and it would be worth adding that as an enhanced bugfix if someone
has the motivation (basically, make a copy of the unmodified mailbox
and mv it back into place if the write fails).

Even that fix won't prevent corruption in the case of a system crash,
but, then, not much will in that case.

--David
___
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] [pydotorg-www] [Infrastructure] Buildbot master moved

[R. David Murray]

On Thu, 28 Jun 2012 16:04:21 +0200, Hynek Schlawack  wrote:
> I don’t know if it’s known, but the bot infrastructure is FUBAR now.
> http://buildbot.python.org/all/waterfall is a stacktrace and all tests
> fail because of the XML-RPC tests that use our buildbot API.

Heh, that's somewhat amusing.  Last upgrade, /console made a traceback
and /waterfall worked fine, this upgrade it is the reverse.

--David
___
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] cpython (2.7): #9559: Append data to single-file mailbox files if messages are only added

[Antoine Pitrou]

On Thu, 28 Jun 2012 16:16:45 +0300
Petri Lehtinen  wrote:
> Antoine Pitrou wrote:
> > > If messages were only added, a new file is no longer created and
> > > renamed over the old file when flush() is called on an mbox, MMDF or
> > > Babyl mailbox.
> > 
> > Why so? Appending is not atomic and, if it fails in the middle, you
> > could get a corrupt mbox file.
> > Furthermore, I disagree that it's a bugfix: IMO it should wait for 3.4.
> 
> The code previosly already appended messages to the end of the file
> when calling add(). This patch just changed it to not do a full
> rewrite when flush() is called.

Ok, I agree it sounds good then. Thanks for explaining.

Regards

Antoine.


___
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] [Infrastructure] Buildbot master moved

[Antoine Pitrou]

Le jeudi 28 juin 2012 à 16:04 +0200, Hynek Schlawack a écrit :
> Hi,
> 
> I don’t know if it’s known, but the bot infrastructure is FUBAR now.
> http://buildbot.python.org/all/waterfall is a stacktrace and all tests
> fail because of the XML-RPC tests that use our buildbot API.

It works if you reload the page, though. Looks like a weird bug in
buildbot, has anyone reported it upstream?

Regards

Antoine.


___
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] [Infrastructure] Buildbot master moved

[Antoine Pitrou]

Le jeudi 28 juin 2012 à 18:09 +0200, Antoine Pitrou a écrit :
> Le jeudi 28 juin 2012 à 16:04 +0200, Hynek Schlawack a écrit :
> > Hi,
> > 
> > I don’t know if it’s known, but the bot infrastructure is FUBAR now.
> > http://buildbot.python.org/all/waterfall is a stacktrace and all tests
> > fail because of the XML-RPC tests that use our buildbot API.
> 
> It works if you reload the page, though. Looks like a weird bug in
> buildbot, has anyone reported it upstream?

Ok, apparently it's http://trac.buildbot.net/ticket/2301 and it seems to
have been fixed upstream.

Now someone needs to incorporate these changes into our local git. I'm a
git newbie, and basic commands seem to fail for me:

$ git fetch -v
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Hynek, do you want to help?

Regards

Antoine.


___
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] [Infrastructure] Buildbot master moved

[Terry Reedy]

On 6/28/2012 10:04 AM, Hynek Schlawack wrote:

Hi,

I don’t know if it’s known, but the bot infrastructure is FUBAR now.
http://buildbot.python.org/all/waterfall is a stacktrace and all tests
fail because of the XML-RPC tests that use our buildbot API.


Errors seem intermittant. Above just worked for me after failing.
Clicking on links on http://www.python.org/dev/buildbot/ (which 
builtbot.python.org redirects to) may give display or error (from FF)


web.Server Traceback (most recent call last):

: 'NoneType' object has no attribute 
'getStatus'

/usr/lib/python2.7/dist-packages/twisted/web/server.py, line 132 in process
130try:
131  resrc = self.site.getResourceFor(self)
132  self.render(resrc)
133except:
/usr/lib/python2.7/dist-packages/twisted/web/server.py, line 167 in render
165"""
166try:
167  body = resrc.render(self)
168except UnsupportedMethod, e:
/data/buildbot/lib/python/buildbot/status/web/base.py, line 324 in render
322  return ''
323
324ctx = self.getContext(request)
325
/data/buildbot/lib/python/buildbot/status/web/base.py, line 196 in 
getContext

194class ContextMixin(AccessorMixin):
195  def getContext(self, request):
196status = self.getStatus(request)
197rootpath = path_to_root(request)
/data/buildbot/lib/python/buildbot/status/web/base.py, line 182 in getStatus
180class AccessorMixin(object):
181  def getStatus(self, request):
182return request.site.buildbot_service.getStatus()
183
/data/buildbot/lib/python/buildbot/status/web/baseweb.py, line 498 in 
getStatus

496
497  def getStatus(self):
498return self.master.getStatus()
499

: 'NoneType' object has no attribute 
'getStatus'


--
Terry Jan Reedy




___
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] PEP 423 : naming conventions and recipes related to packaging

[Ethan Furman]

Chris McDonough wrote:
People typically look for code on PyPI that solves a problem, and 
branding in namespacing there is usually confusing.  E.g. there are many 
highly-general useful things in both the zope


When I search PyPI I ignore anything with djange, zope, etc., as I have 
zero interest in pulling in a bunch of unrelated packages that I don't 
need.  If some of these pieces are truly stand-alone it would be nice if 
they were presented that way.


~Ethan~
___
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] [Infrastructure] Buildbot master moved

[Hynek Schlawack]

> Now someone needs to incorporate these changes into our local git. I'm a
> git newbie, and basic commands seem to fail for me:
> 
> $ git fetch -v
> Permission denied (publickey).
> fatal: The remote end hung up unexpectedly
> 
> Hynek, do you want to help?

I'd love to, but I'm afk for the rest of the (CEST) day. :( If it's broken 
still broken tomorrow, you know where to find me. :)

Cheers,
Hynek
___
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] [Infrastructure] Buildbot master moved

[Martin v. Löwis]

> I don’t know if it’s known, but the bot infrastructure is FUBAR now.

I'm quite certain it can be repaired.

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] PEP 423 : naming conventions and recipes related to packaging

[Glenn Linderman]

On 6/28/2012 9:36 AM, Ethan Furman wrote:
When I search PyPI I ignore anything with djange, zope, etc., as I 
have zero interest in pulling in a bunch of unrelated packages that I 
don't need.  If some of these pieces are truly stand-alone it would be 
nice if they were presented that way. 


+1 Precisely.

If a user wishes to install packages into "who_made_it" or 
"where_did_it_come_from" namespaces, and has a version of Python that 
supports namespaces, it would probably be a good idea for installers to 
easily permit that.  Then, if there are naming conflicts among packages 
from different sources, and they wish to use more than one 
"mypackage"... one from PyPI and one (or 3) from github, they can decide 
to name them as


mypackage (hah, this one is from PyPI and they used it first)
github.mypackage (first one from github)
github_fred.mypackage (the one by fred from github)
github_mary.mypackage (the one by mary from github)

The may choose to rename mypackage as PyPI.mypackage and 
github.mypackage as github_billy.mypackage to help discriminate, now 
that they have a need to discriminate, but that should be their choice, 
change versus compatibility.


Happily, it is possible to do either of the following to keep code names 
shorter:


import github_fred.mypackage as mypackage

import github_fred.mypackage as fredpackage

Reading JAVA code with lots of fully qualified by organization name is 
thoroughly confusing... it is unambiguous where the code came from, but 
it is also distracting when trying to understand the code, with all 
these long names that are irrelevant to the logic of the code.


And, of course, "mypackage" may be a set of alternative implementations 
of similar functionality, or it may be completely different 
functionalities that happen to use the same name (just as in English, 
when one word can have multitple definitions).


Maybe the PEP would be more useful by having it define package metadata 
standards such as


mypackage.__organization__ = 'The company or group or individual that 
created this package'
mypackage.__obtained_from__ = 'The location from which this package was 
obtained'


The former would be supplied by the package author; the latter would be 
filled in by the repository publisher (which may or may not be the same 
as the __organization__), or be a requirement to upload to the 
repository, or something along that line, so you'd know where to start a 
search for an updated version.
___
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] Bitbucket mirror?

[Tim Golden]

Just recently I'm sure I saw a post saying that the main Python repo was 
mirrored on bitbucket.org for the convenience of developers who could 
then fork to their own accounts.


For the life of me I can't find it now. Can someone confirm and/or nudge 
me in the right direction, please?


TJG
___
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] Bitbucket mirror?

[Brian Curtin]

On Thu, Jun 28, 2012 at 12:42 PM, Tim Golden  wrote:
> Just recently I'm sure I saw a post saying that the main Python repo was
> mirrored on bitbucket.org for the convenience of developers who could then
> fork to their own accounts.
>
> For the life of me I can't find it now. Can someone confirm and/or nudge me
> in the right direction, please?

https://bitbucket.org/python_mirrors
___
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] Bitbucket mirror?

[Oleg Broytman]

On Thu, Jun 28, 2012 at 06:42:46PM +0100, Tim Golden  
wrote:
> Just recently I'm sure I saw a post saying that the main Python repo
> was mirrored on bitbucket.org for the convenience of developers who
> could then fork to their own accounts.
> 
> For the life of me I can't find it now. Can someone confirm and/or
> nudge me in the right direction, please?

   This one? https://bitbucket.org/mirror/python-py3k

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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] Bitbucket mirror?

[Vinay Sajip]

Tim Golden  timgolden.me.uk> writes:

> 
> Just recently I'm sure I saw a post saying that the main Python repo was 
> mirrored on bitbucket.org for the convenience of developers who could 
> then fork to their own accounts.
> 
> For the life of me I can't find it now. Can someone confirm and/or nudge 
> me in the right direction, please?

I don't know how official it is, but I've used this mirror when I wanted to make
use of BitBucket side-by-side comparisons:

https://bitbucket.org/mirror/cpython/

It seems fairly up-to-date. Much of my early work on the venv code was done
using a clone from this mirror, and I pulled and merged from it lots of times
without any issues.

Regards,

Vinay Sajip

___
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] cpython (2.7): #9559: Append data to single-file mailbox files if messages are only added

[Petri Lehtinen]

R. David Murray wrote:
> It is true, however, that Petri found that mutt (I think?) does some extra
> gymnastics to provide recovery where the write fails part way through,
> and it would be worth adding that as an enhanced bugfix if someone
> has the motivation (basically, make a copy of the unmodified mailbox
> and mv it back into place if the write fails).

This is not what mutt does. It just writes the modified part of the
mailbox to a temporary file, and then copies the data from the
temporary file to the mailbox file. If this last step fails, the
temporary file is left behind for recovery.

Copying the whole mailbox before making modifications might be clever,
though. It's just quite a lot of writing, especially for big
mailboxes. OTOH, the whole file is rewritten by the current code, too.
___
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] Bitbucket mirror?

[Brian Curtin]

On Thu, Jun 28, 2012 at 1:08 PM, Vinay Sajip  wrote:
> Tim Golden  timgolden.me.uk> writes:
>
>>
>> Just recently I'm sure I saw a post saying that the main Python repo was
>> mirrored on bitbucket.org for the convenience of developers who could
>> then fork to their own accounts.
>>
>> For the life of me I can't find it now. Can someone confirm and/or nudge
>> me in the right direction, please?
>
> I don't know how official it is, but I've used this mirror when I wanted to 
> make
> use of BitBucket side-by-side comparisons:
>
> https://bitbucket.org/mirror/cpython/
>
> It seems fairly up-to-date. Much of my early work on the venv code was done
> using a clone from this mirror, and I pulled and merged from it lots of times
> without any issues.

Atlassian setup https://bitbucket.org/python_mirrors to mirror the
entire hg.python.org setup.

http://blog.python.org/2012/06/mercurial-mirrors-provided-by-atlassian.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] Bitbucket mirror?

[Tim Golden]

On 28/06/2012 19:10, Brian Curtin wrote:


Atlassian setup https://bitbucket.org/python_mirrors to mirror the
entire hg.python.org setup.

http://blog.python.org/2012/06/mercurial-mirrors-provided-by-atlassian.html



Thanks, Brian. That's obviously where I read about it, too.

TJG
___
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] [pydotorg-www] [Infrastructure] Buildbot master moved

[Martin v. Löwis]

> Ok, I've applied the patches by hand in the local repo, without
> committing them. It seems to fix the issue AFAICT.

I tried merging the change with git, but that would merge a lot of
other changes as well, and produce conflicts. So I just committed and
pushed your changes.

Feel free to commit anything you change right away; I can then push
the changes. Or you push them yourself. Just leaving them uncommitted
is fine as well.

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] PEP 423 : naming conventions and recipes related to packaging

[Benoît Bryon]

Let's try to summarize answers about top-level namespace with use cases
and examples... I hope I understood them well...

About "yes" or "no" meaning:

yes
  It fits the (work-in-progress) convention. You would
  recommend it.

no
  You wouldn't recommend the naming pattern for *new*
  projects (we can't require existing projects to be renamed).

=

Project is standalone (doesn't mean "have no dependencies"),
released on PyPI:

* only one-level name is recommended, no namespace package
* yes: sphinx, flask, lettuce
* no: zc.rst2 (brand name is superfluous)

=

Project is made of several subprojects which are not
standalone, released on PyPI:

* a namespace package is recommended

* the top-level namespace is functional: projects in
  namespace make a bigger project. They are not designed
  to work as standalone components.

* yes: ? Have you examples of such a use case?

* no: plone.app.* (too many levels)

=

Project is related to another one (i.e. kind of contrib),
released on PyPI:

* note: there is a difference between "related to another
  project" and "depends on another project". As an example,
  Fabric depends on ssh, but is not a contrib of it.

* choice depends on conventions of related project

* if there is no specific convention, a namespace package
  is recommended

* the top-level namespace is functional: projects in
  namespace have a common characteristic, they are specific
  to something, usually another project.

* yes: collective.castle

* yes because of explicit specific convention: sphinxcontrib-feed,
  Flask-Admin

* no: castle, feed, admin, Plone.recipe.command (not specific
  to Plone, in fact related to zc.buildout)

* Use of additional metadata is highly recommended (keywords,
  topic::framework)

=

Project is standalone, but really experimental (i.e.
name could change, not sure to publish version 0.2),
want to make it public:

* I want to share code, but I am really not sure it will
  live long. I don't want to "block" a name slot.

* use a one-level name, as any standalone public project

* publish it on gitorious/github/bitbucket accounts

* don't register it with PyPI until it becomes a bit
  mature? i.e. start with code repositories only?

* not valuable enough to be mentioned in PEP 423?
  Maybe not in the scope of PEP 423. I mean it is more
  about "what kind of projects we register with PyPI"
  than "which name to choose".

=

Project is standalone, but specific to my own usage, i.e.
I use it as personal software. It's not private because
I want to share the code (maybe someone will like it).

* use an one-level name, as any standalone public project

* publish it on code repositories.

* register it with PyPI? if only ready to maintain and
  document?

* not valuable enough to be mentioned in PEP 423?
  Maybe not in the scope of PEP 423. I mean it is more
  about "what kind of projects we register with PyPI"
  than "which name to choose".

=

.. note::

   conventions for private projects are provided as
   informational guidelines.


Project is private, made of only one component:

* a namespace package is recommended (not sure for this
  rule, could be an one-level project name)

* the top-level name can be any unique arbitrary value.
  The company name could be a good choice.

* the top-level namespace is not functional, but represents
  an ownership: the project is specific to the customer/product.
  It contains closed-source parts.

* yes: mycustomer.website

* no: mycustomerwebsite, website

=

Project is private, made of several components:

* a namespace package is recommended

* the top-level name can be any unique arbitrary value.
  The company name could be a good choice.

* the top-level namespace is not functional, but represents a
  common background: as an example, all components are specific
  to the customer/product.

* yes: mywebsite.blog, mywebsite.auth, mywebsite.calendar (where
  these components could be standalone WSGI applications, but
  contain specific stuff related to the customer/product).

* no: blog, auth, calendar


=

Do you prefer the examples above to the "top-level namespace relates to code 
ownership" rule?
Do you see other use cases?


Benoit

___
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] os.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories

[Giampaolo Rodolà]

2012/6/27 Nick Coghlan :
> If someone wants to see the error details, they should use os.stat directly
> rather than an existence check.

This is now tracked at http://bugs.python.org/issue15221

Regards,

--- Giampaolo
http://code.google.com/p/pyftpdlib/
http://code.google.com/p/psutil/
http://code.google.com/p/pysendfile/
___
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] Bitbucket mirror?

[Eli Bendersky]

> > I don't know how official it is, but I've used this mirror when I wanted
> to make
> > use of BitBucket side-by-side comparisons:
> >
> > https://bitbucket.org/mirror/cpython/
> >
> > It seems fairly up-to-date. Much of my early work on the venv code was
> done
> > using a clone from this mirror, and I pulled and merged from it lots of
> times
> > without any issues.
>
> Atlassian setup https://bitbucket.org/python_mirrors to mirror the
> entire hg.python.org setup.
>
> http://blog.python.org/2012/06/mercurial-mirrors-provided-by-atlassian.html
> ___
>


The devguide (http://docs.python.org/devguide/committing.html) says:

Bitbucket  also maintain an up to date
cloneof the main
cpython repository that can be used as the basis for a new clone or patch
queue.

[the link goes to https://bitbucket.org/mirror/cpython/overview]

Eli
___
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