Phillip J. Eby wrote:
> At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
>> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
>> Joachim> files (and 'rmdir' directories, but not recursively) that it
>> Joachim> created, and that have not been modified in the m
[EMAIL PROTECTED] writes:
> With all these distributed revision control systems now available (bzr, hg,
> darcs, svk, many more), I find I need an introduction to the concepts and
> advantages of repository distribution.
> Can someone point me to some useful content (web pages or books)
> wh
http://python.org/sf/2451
"""
The new timeout support in 2.6 makes use of new function
socket.create_connection(). socket.create_connection() provides no way
to disable timeouts, other than by relying on socket.getdefaulttimeout()
returning None. This is unfortunate, because it was the purpose o
At 09:44 PM 3/21/2008 -0400, A.M. Kuchling wrote:
>On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
> > I'm making the assumption that the author(s) of PEP 262 had good
> > reason for including what they did, rather than assuming that we
> > should start the entire process over from
At 02:31 AM 3/22/2008 +0100, Martin v. Löwis wrote:
>>I'm making the assumption that the author(s) of PEP 262 had good
>>reason for including what they did, rather than assuming that we
>>should start the entire process over from scratch.
>
>The objections to the PEP remain the same as they were
I'm following up on this thread without checking if there were other
following negating a need to respond... If so, ignore as needed.
+1 from me. Always build on windows into an architecture specific
PCBuild/XXX directory. A bonus if the directory name matches the return
value of platform.machin
On Fri, Mar 21, 2008 at 06:41:00PM -0400, Phillip J. Eby wrote:
> I'm making the assumption that the author(s) of PEP 262 had good
> reason for including what they did, rather than assuming that we
> should start the entire process over from scratch.
The goal *was* originally to provide for RPM-
> I'm making the assumption that the author(s) of PEP 262 had good
> reason for including what they did, rather than assuming that we
> should start the entire process over from scratch.
The objections to the PEP remain the same as they were then,
though: In the requirements, it says "we need",
On Thu, Mar 20, 2008 at 9:43 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Mar 20, 2008, at 11:55 AM, Oleg Broytmann wrote:
> > Yes, exactly. Eric Raymond claims to be the inventor, but there are
> > different voices against him:
> > http://damagestudios.net/blog/2005/08/15/sourceforge-founde
On Fri, Mar 21, 2008 at 4:41 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
>
> > Even though the more popular PyInt_ APIs are still available (even if
> > only as macros).
>
> THe PyInt_* macros are only available when Include/intobject.h is
> included explicitly. I
On Sat, Mar 22, 2008 at 8:28 AM, Paul Moore <[EMAIL PROTECTED]> wrote:
> Basically, can some Bazaar expert offer a suggestion as to how a
> non-developer with read-only access would best use the Bazaar
> repositories to maintain a number of patches to be posted to the
> tracker?
>
Here's what
Guido van Rossum schrieb:
> Even though the more popular PyInt_ APIs are still available (even if
> only as macros).
THe PyInt_* macros are only available when Include/intobject.h is
included explicitly. It's not in Python.h any more.
> I disagree. Bad merges are already a frequent cause of insta
On Fri, Mar 21, 2008 at 2:40 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > | try:
> > |bytes
> > | except NameError:
> > |bytes = str
> > |
> > | somewhere, then write the code as I proposed above.
> >
> > This is exactly the sort of thing that should be and I expect will be i
On Fri, Mar 21, 2008 at 2:38 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/03/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> > I see your trunk history is stripped. For those who want the complete
> trunk
> > history (back to 17 years ago!), I have my own mirror here:
> > http://dev.
On Fri, Mar 21, 2008 at 6:12 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 21, 2008 at 3:10 PM, Benjamin Peterson
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> > On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> > >
> > > On 21/03/2008, Benjamin Peterson <[EMAIL
On Fri, Mar 21, 2008 at 3:10 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
>
>
>
>
> On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> >
> > On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote:
> > > I tend to make a repository and make a working copy for each patch
Martin v. Löwis schrieb:
> That never worked for me. TortoiseSVN then insists on fetching the
> revisions mentioned in the patch, runs some math, and tells me that
> I can't apply the patch because it is out of date (assuming it really
> is, which is normally the case when I get to look at a patch)
On 21/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> With all these distributed revision control systems now available (bzr, hg,
> darcs, svk, many more), I find I need an introduction to the concepts and
> advantages of repository distribution. It seems to me that it has the
> potenti
At 11:13 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>On 2008-03-21 22:21, Phillip J. Eby wrote:
> > At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
> >> I guess the only way to support all of these variants is
> >> to use a filesystem based approach, e.g. by placing a file
> >> with a special exten
On 21/03/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> You're heading off in the wrong direction: we should not be trying
> to rewrite RPM or InnoSetup in Python.
>
> Anything more complicated should be left to tools which are
> specifically written to manage complex software setups.
>
> I h
On Fri, Mar 21, 2008 at 05:17:00PM -0500, [EMAIL PROTECTED] wrote:
> With all these distributed revision control systems now available (bzr, hg,
> darcs, svk, many more), I find I need an introduction to the concepts and
> advantages of repository distribution. It seems to me that it has the
> pot
Eric Raymond started a study for this specific matter recently (announced
here : http://article.gmane.org/gmane.emacs.devel/85893). Everything is
under source control here : http://thyrsus.com/hg/uvc/
HTH,
Quentin
On Fri, Mar 21, 2008 at 11:17 PM, <[EMAIL PROTECTED]> wrote:
> With all these dis
On Fri, Mar 21, 2008 at 5:17 PM, <[EMAIL PROTECTED]> wrote:
> With all these distributed revision control systems now available (bzr,
> hg,
> darcs, svk, many more), I find I need an introduction to the concepts and
> advantages of repository distribution. It seems to me that it has the
> potenti
zooko:
> Um, isn't this tool called "unzip"? I have done this -- accessed the
> source code -- many times, and unzip suffices.
The type of issue I ran into with eggs is when you get an exception
with a trace that includes an egg, you can't use the normal means to
look at the code. Instead y
With all these distributed revision control systems now available (bzr, hg,
darcs, svk, many more), I find I need an introduction to the concepts and
advantages of repository distribution. It seems to me that it has the
potential for leading to anarchy, though I can see how some things would be
im
On Tue, Mar 18, 2008 at 9:11 PM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> I've been double checking the PEP 3127 implementation in py3k and the
> backport I did to 2.6. The PEP says this about the % operator:
>
> "The string (and unicode in 2.6) % operator will have 'b' format
> specifier added
On 2008-03-21 22:21, Phillip J. Eby wrote:
> At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>> I guess the only way to support all of these variants is
>> to use a filesystem based approach, e.g. by placing a file
>> with a special extension into some dir on sys.path.
>> The "database" logic cou
On Fri, Mar 21, 2008 at 5:04 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote:
> > I tend to make a repository and make a working copy for each patch in
> it.
> > The history is saved in the repository so it's efficient.
>
> OK, so just lots of
On 21/03/2008, Benjamin Peterson <[EMAIL PROTECTED]> wrote:
> I tend to make a repository and make a working copy for each patch in it.
> The history is saved in the repository so it's efficient.
OK, so just lots of copies, fair enough. Presumably just use bzr diff
to create patches? Much like Sub
On 21/03/2008, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
[...]
> I then try cygwin patch, which applies the patch nicely, but messes
> up the line endings while doing so.
>
> So in the end, I conclude that it just isn't possible to apply patches
> on Windows, and log into a Linux machine to
On Fri, Mar 21, 2008 at 4:28 PM, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Just to head this off, this is not a specific vote of confidence for
> > Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas
> > were willing to p
Hi,
Paul Moore gmail.com> writes:
>
> Excellent! For what it's worth, hg clone took 5 minutes on my PC (with
> broadband access). That's faster than simply downloading the Bazaar
> shared repository tarball (which took 13 minutes)!
>
> Are you keeping the mirror updated with respect to Subvers
> Totally unrelated to your posting:
>
> I wonder why http://www.python.org/dev/faq/#how-to-make-a-patch uses tee
> instead of > file ?
So you can see what the patch looks like?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://m
> --- snippet ---
> If you're using Windows make sure you have TortoiseSVN installed.
> Right-click on the folder containing the trunk source code, expand the
> TortoiseSVN submenu and select 'Apply Patch...'. Browse to the patch
> file and select it, then right click on the file appearing in the
> | try:
> |bytes
> | except NameError:
> |bytes = str
> |
> | somewhere, then write the code as I proposed above.
>
> This is exactly the sort of thing that should be and I expect will be in
> the conversion docs.
That expectation might be unfounded (in the sense that it might not be
w
On 21/03/2008, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> I see your trunk history is stripped. For those who want the complete trunk
> history (back to 17 years ago!), I have my own mirror here:
> http://dev.pitrou.net:8000/cpython/trunk/
Excellent! For what it's worth, hg clone took 5 minut
On 2008-03-21 22:32, Martin v. Löwis wrote:
>> It's not implementable because the work has to occur in ast.c (see
>> Py_UnicodeFlag). It can't occur later, because you need to skip the
>> encoding being done in parsestr(). But the __future__ import can only
>> be interpreted after the AST is b
> It's not implementable because the work has to occur in ast.c (see
> Py_UnicodeFlag). It can't occur later, because you need to skip the
> encoding being done in parsestr(). But the __future__ import can only
> be interpreted after the AST is built, at which time the encoding has
> already
On 21/03/2008, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Just to head this off, this is not a specific vote of confidence for
> Bazaar. The Bazaar developers were at PyCon and both Barry and Thomas
> were willing to put the time and effort to get the mirror up and going
> while the Bazaar team w
At 05:59 PM 3/21/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby schrieb:
> > Questions, comments... volunteers? :)
>
>I've yet to read the monster package utils thread so I can't comment on
>it. However I like to draw some attention to my PEP 370
>http://python.org/dev/peps/pep-0370/. It's
At 08:06 PM 3/21/2008 +0100, M.-A. Lemburg wrote:
>I guess the only way to support all of these variants is
>to use a filesystem based approach, e.g. by placing a file
>with a special extension into some dir on sys.path.
>The "database" logic could then scan sys.path for these
>files, read the data
> [Suggestion: perhaps we could set up a [EMAIL PROTECTED]
> list for discussing buildbot administrative minutiae, rather than
> polluting python-dev?]
I think polluting python-dev is fine.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.
On Thu, Mar 20, 2008 at 2:49 PM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Barry Warsaw schrieb:
>
> > I'm happy to announce that we now have available for public
> > consumption, the Python source code for 2.5, 2.6 and 3.0 available
> > under the Bazaar distributed version control system.
>
On Fri, Mar 21, 2008 at 11:06 AM, Eric Smith
<[EMAIL PROTECTED]> wrote:
> Christian Heimes wrote:
> > Eric Smith schrieb:
> > > It's not implementable because the work has to occur in ast.c (see
> >> Py_UnicodeFlag). It can't occur later, because you need to skip the
> >> encoding being done
On Thu, Mar 20, 2008 at 2:42 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I'm happy to announce that we now have available for public
> consumption, the Python source code for 2.5, 2.6 and 3.0 available
> under the Bazaar distributed version con
On Fri, Mar 21, 2008 at 1:42 AM, Jeroen Ruigrok van der Werven
<[EMAIL PROTECTED]> wrote:
> (To provide counterweight.)
>
>
> -On [20080320 20:44], Barry Warsaw ([EMAIL PROTECTED]) wrote:
> >We have not made a decision to move to Bazaar officially, nor have we made
> >a decision to even move off
Thanks Giampaolo!
Totally unrelated to your posting:
I wonder why http://www.python.org/dev/faq/#how-to-make-a-patch uses tee
instead of > file ?
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
I noticed that http://www.python.org/dev/faq/#how-do-i-apply-a-patch
...does not contain instruction for Windows user willing to apply a
patch starting from a .diff file.
Since Tortoise SVN is the most common choice I tried to describe the
steps to apply a patch by using it.
This could be added in
On 21/03/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Questions, comments... volunteers? :)
Sounds good. I won't volunteer as I have neither time nor expertise to
contribute much. But I'd like to see this happen, as it sounds like it
would address all my issues with setuptools (and just
Phillip J. Eby wrote:
> Questions, comments... volunteers? :)
This makes a lot of sense. I don't really have anything to add in terms
of implementation, but I wonder if we can learn something from how apt
or rpms or ports work, and how other programming languages (Ruby gems?)
solve this.
I
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
To Paul's question: I have only installed a couple of things (and not
recently) that added their own add/remove entry. But I am not sure I would
have called them add-ons as opposed to independent applications writte
On 2008-03-21 14:47, Phillip J. Eby wrote:
> So, to accomplish this, we (for some value of "we") need to:
>
> 1. Hash out consensus around what changes or enhancements are needed
> to PEP 262, to resolve the previously-listed open issues, those that
> have come up since (namespace packages, depe
At 11:21 AM 3/21/2008 -0500, [EMAIL PROTECTED] wrote:
> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
> Joachim> files (and 'rmdir' directories, but not recursively) that it
> Joachim> created, and that have not been modified in the meantime (after
> Joachi
[EMAIL PROTECTED] writes:
>
> Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
> Joachim> files (and 'rmdir' directories, but not recursively) that it
> Joachim> created, and that have not been modified in the meantime (after
> Joachim> the installation)
Christian Heimes wrote:
> Eric Smith schrieb:
> > It's not implementable because the work has to occur in ast.c (see
>> Py_UnicodeFlag). It can't occur later, because you need to skip the
>> encoding being done in parsestr(). But the __future__ import can only
>> be interpreted after the AST i
Eric Smith schrieb:
> It's not implementable because the work has to occur in ast.c (see
> Py_UnicodeFlag). It can't occur later, because you need to skip the
> encoding being done in parsestr(). But the __future__ import can only
> be interpreted after the AST is built, at which time the enco
Phillip J. Eby schrieb:
> Questions, comments... volunteers? :)
I've yet to read the monster package utils thread so I can't comment on
it. However I like to draw some attention to my PEP 370
http://python.org/dev/peps/pep-0370/. It's about a site packages
directory in the users home directory.
On 20 Apr, 2006, at 22:07, Martin v. Löwis wrote:
Guido van Rossum wrote:
This is another area where API standardization is
important; as soon as modules are loaded out of a zip file, the
traditional approach of looking relative to os.path.dirname(__file__)
no longer works.
2. standardize on
At 09:53 AM 3/21/2008 -0600, zooko wrote:
>Um, isn't this tool called "unzip"? I have done this -- accessed the
>source code -- many times, and unzip suffices.
>
>I don't know what else would be required in order to make an egg into
>"a standard distutils-style installation".
You also have to ren
Joachim> I think, the uninstall should _not_ 'rm -rf' but only 'rm' the
Joachim> files (and 'rmdir' directories, but not recursively) that it
Joachim> created, and that have not been modified in the meantime (after
Joachim> the installation).
That's not sufficient. Suppose file
On Mar 20, 2008, at 6:22 PM, Robert Brewer wrote:
> Phillip J. Eby wrote:
>> The other tool that would be handy to have, would be one that unpacks
>> eggs into standard distutils-style installation.
>
> Hear, hear. I'm an author of a couple libraries that need to
> interoperate with others. Of th
Phillip J. Eby wrote:
> Hm. So it seems to me that maybe one thing that would help is a
> "Setuptools Haters' Guide To Setuptools" -- that is, *short*
> documentation specifically written for people who don't want to use
> setuptools and want to minimize its impact on their systems.
Perhaps rele
On Fri, Mar 21, 2008 at 2:47 PM, Phillip J. Eby <[EMAIL PROTECTED]>
wrote:
> Second, there were no uninstall tools for it, so I'd have had to
> write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
> ain't easy, and I have an aversion to deleting stuff on people's
> systems without
Phillip J. Eby wrote:
> Second, there were no uninstall tools for it, so I'd have had to
> write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
> ain't easy, and I have an aversion to deleting stuff on people's
> systems without knowing what will break. There's a big difference
So, after having some time to absorb the Python-Dev threads about
setuptools, bootstrap, and all the rest, I think I see an opportunity
to let people route around the "damage" of eggs, while still making
it possible for the people who want to use easy_install or to put
dependencies in their set
-On [20080320 19:24], Steve Holden ([EMAIL PROTECTED]) wrote:
>We need to stop protesting that our installation tools are easy enough
>and try to get behind the various platforms, be it with Windows
>installers, rpms, or other support. We probably aren't doing this
>because it's work nobody part
Ralf Schmitt gmail.com> writes:
>
> I have also setup a mirror using mercurial: http://hgpy.de/py/It contains the
2.4, 2.5, trunk and py3k branches (in case anyone wants to compare this to bzr).
I see your trunk history is stripped. For those who want the complete trunk
history (back to 17 years
At 12:33 PM 3/21/2008 +, Paul Moore wrote:
>On 21/03/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> > The standard (and to me, preferable) way of dealing with such
> things is to
> > have an 'installation manager' that can reinstall as well as delete and
> > that has a check box for variou
On 21/03/2008, Terry Reedy <[EMAIL PROTECTED]> wrote:
> However, this Windows user, and I expect most, do NOT expect add-ons
> (things under the /Pythonx.y tree) to show up in the add/remove list.
That's an interesting counterpoint to my comments. I presume from this
that you dislike (and/or neve
Eric Smith wrote:
> This proposal is to add "from __future__ import
> unicode_string_literals", which would make all string literals in the
> importing module into unicode objects in 2.6.
I'm going to withdraw this, for 2 reasons.
1) The more I think about it, the less sense it makes.
2) Without
Sorry for the double post, Jeroen :|
-- Forwarded message --
From: Matthieu Brucher <[EMAIL PROTECTED]>
Date: 21 mars 2008 10:03
Subject: Re: [Python-Dev] Python source code on Bazaar vcs
To: Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]>
2008/3/21, Jeroen Ruigrok van der Wer
(To provide counterweight.)
-On [20080320 20:44], Barry Warsaw ([EMAIL PROTECTED]) wrote:
>We have not made a decision to move to Bazaar officially, nor have we made
>a decision to even move off of Subversion.
Good, because between this now and pytz the other 63 projects I follow use
Subversion o
72 matches
Mail list logo
