-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2011 05:43 PM, Nick Coghlan wrote:
> I'm actually finding I quite like the virtualenv scheme of having
> "sys.prefix" refer to the virtual environment and "sys.real_prefix"
> refer to the interpeter's default environment. If pyvenv used the sa
On Sat, Oct 29, 2011 at 4:37 AM, Carl Meyer wrote:
>
> Why not modify sys.prefix?
> - --
>
> As discussed above under `Backwards Compatibility`_, this PEP proposes
> to add ``sys.site_prefix`` as "the prefix relative to which
> site-package directories are found". This main
Le samedi 29 octobre 2011 07:47:01, vous avez écrit :
> Therefore, as you imply, I think the solution to this issue is to start
> the process of deprecating the bytes version of the api in py3k with a
> view to removing it completely - possibly with a less aggressive
> timeline than normal. In Pyt
> I'd provide a fixed custom action which gets hold of the installer
> session, and then runs a Python script. IIUC, it should be possible
> to map categories to entries in the Directory table, so that the
> Python script would actually configure the installer process before
> the installer act
On Tue, Nov 8, 2011 at 14:47, Georg Brandl wrote:
> Am 08.11.2011 21:30, schrieb brian.curtin:
>> http://hg.python.org/cpython/rev/60ae7979fec8
>> changeset: 73463:60ae7979fec8
>> user: Brian Curtin
>> date: Tue Nov 08 14:30:02 2011 -0600
>> summary:
>> Remove the old style [...
Am 08.11.2011 21:30, schrieb brian.curtin:
> http://hg.python.org/cpython/rev/60ae7979fec8
> changeset: 73463:60ae7979fec8
> user:Brian Curtin
> date:Tue Nov 08 14:30:02 2011 -0600
> summary:
> Remove the old style [...] to denote optional args and show the defaults.
>
> files
On 09Nov2011 07:19, I wrote:
| Yes it does. I use this facility to merge timesheet files mainatined on
| separate hosts (home machine, travelling laptop) in my hgbox script.
| The hgrc says:
|
| [merge-patterns]
| timesheets-cameron/2* = merge-dumb
| dailylog-cameron/2*/[A-Z]* = merge-dumb
|
On 08Nov2011 13:50, Barry Warsaw wrote:
| On Nov 08, 2011, at 04:49 PM, Jesus Cea wrote:
| >When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately).
| >Instead of copy&paste the test manually between versions, has anybody
| >a better workflow?.
|
| Does Mercurial support custom merge p
> I'm curious to know how this level of flexibility can be achieved with the
> MSI format: I know one can code the equivalent logic in C (for example) in
> a custom action, but don't know how you can keep the logic in Python.
I'd provide a fixed custom action which gets hold of the installer
sessi
On 11/8/2011 10:49 AM, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately).
Instead of copy&paste the test manually between versions, has anybody
a better workflow?.
If a bug is fixed in 3.2.latest, then it will not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Nov 08, 2011, at 04:49 PM, Jesus Cea wrote:
>When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately).
>Instead of copy&paste the test manually between versions, has anybody
>a better workflow?.
Does Mercurial support custom merge plug
2011/11/8 stefan brunthaler :
> How does that sound?
I think I can hear real patches and benchmarks most clearly.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Hi guys,
while there is at least some interest in incorporating my
optimizations, response has still been low. I figure that the changes
are probably too much for a single big incorporation step. On a recent
flight, I thought about cutting it down to make it more easily
digestible. The basic idea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately).
Instead of copy&paste the test manually between versions, has anybody
a better workflow?.
Since any change applied to 3.2 should be applied to 3.3 too (except
very few cases), Mercuri
Nick Coghlan gmail.com> writes:
> Given the other things regrtest cleans up between tests, I'm not sure
> why it doesn't also kill TESTFN, though.
Well, there's a function regrtest.cleanup_test_droppings which aims to do just
this, and it's called in a finally: block from regrtest.runtest. It's
On Tue, Nov 8, 2011 at 8:02 PM, Vinay Sajip wrote:
> Sorry if this has come up before, but why do we couple the tests in this way,
> so
> that failure to clean up in one test causes drive-by failures in other,
> unrelated tests?
Personally, I just use the tempfile module in tests that I write
(h
I ran into an error today related to the use of support.TESTFN throughout the
regression test suite. In my Windows tests, test_base64 passed, but left a file
(named by support.TESTFN) lying around:
'test_base64' left behind file '@test_3532_tmp'
Much later in the run, a set of unrelated tests s
Hm.
I agree with Raymond that this should be treated as a feature request
and not "fixed" in 2.7 / 3.2. (However the mention of 'find' in the
error message for 'index' is a bug and should be fixed.)
As for the feature request, I think that allowing None in more places
is more regular and consiste
18 matches
Mail list logo