Benjamin> Once you've pushed the branches, is there a way to remove them?
Related question: is there a way to view the various branches in a non-local
repository?
Skip
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 29, 2008, at 6:00 PM, Benjamin Peterson wrote:
>
> No, I mean the pushed version on code.python.org.
Not unless you have shell or sftp access, which you probably don't.
It's not a big deal though except for a mild feeling of
uncleanliness.
On Sat, Mar 29, 2008 at 4:59 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Mar 29, 2008, at 5:11 PM, Benjamin Peterson wrote:
>
> > Once you've pushed the branches, is there a way to remove them?
>
> Do you mean the local branches? If yes, th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 29, 2008, at 5:11 PM, Benjamin Peterson wrote:
> Once you've pushed the branches, is there a way to remove them?
Do you mean the local branches? If yes, then 'rm -rf mymergedbranch'
does exactly what you want. :)
- -Barry
-BEGIN PGP S
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
Jeffrey Yasskin schrieb:
> This apparently happens because the traceback in sys.exc_info keeps
> the frame for the call to RunSelfFunction._run alive even though there
> are otherwise no references to the object. In 2.6, this is fixed by
> calling sys.exc_clear() before allowing the thread to be jo
> The explanation seems to be that, while exc_info is cleared immediately, the
> thread state exception fields are only cleaned up at the end of
> PyEval_EvalFrameEx.
Patch and test in http://bugs.python.org/issue2507
___
Python-3000 mailing list
Pyth
Hi Jeffrey,
> I had thought that exc_info was
> automatically cleared at the end of any except block that caught an
> exception, but apparently that isn't the case. Is this a bug in 3.0,
> or do we need to keep sys.exc_clear() around?
The explanation seems to be that, while exc_info is cleared i
