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
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
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
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
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.
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
On 28 June 2012 11:36, Benoît Bryon ben...@marmelune.net 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
On Thu, 28 Jun 2012 12:59:02 +0200
petri.lehtinen python-check...@python.org wrote:
http://hg.python.org/cpython/rev/c37cb11b546f
changeset: 77832:c37cb11b546f
branch: 2.7
parent: 77823:73710ae9fedc
user:Petri Lehtinen pe...@digip.org
date:Thu Jun 28 13:48:17 2012
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
On Thu, 28 Jun 2012 12:35:24 +0200
Benoît Bryon ben...@marmelune.net 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
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
Zitat von Hynek Schlawack h...@ox.cx:
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
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.
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
On Thu, 28 Jun 2012 08:14:07 -0400, Chris McDonough chr...@plope.com 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
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
On Thu, 28 Jun 2012 12:53:47 +0200, =?ISO-8859-1?Q?Beno=EEt_Bryon?=
ben...@marmelune.net 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
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
On Thu, 28 Jun 2012 16:16:45 +0300, Petri Lehtinen pe...@digip.org 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,
On Thu, 28 Jun 2012 16:04:21 +0200, Hynek Schlawack h...@ox.cx 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
On Thu, 28 Jun 2012 16:16:45 +0300
Petri Lehtinen pe...@digip.org 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
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
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
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
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
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
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:
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
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
On Thu, Jun 28, 2012 at 12:42 PM, Tim Golden m...@timgolden.me.uk 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
On Thu, Jun 28, 2012 at 06:42:46PM +0100, Tim Golden m...@timgolden.me.uk
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
Tim Golden mail at 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
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
On Thu, Jun 28, 2012 at 1:08 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Tim Golden mail at 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
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
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
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
2012/6/27 Nick Coghlan ncogh...@gmail.com:
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/
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
39 matches
Mail list logo
