[PATCH 3 of 3 v2] run-tests: use strings for env object

timeless timeless at gmail.com
Thu May 5 08:48:00 EDT 2016


It's possible. I really don't want to do it.
This whole thing is a mess. If someone else wants to do that and save
me from another 24 hours of encoding hell, i'd be appreciative.

This is probably the fourth or fifth night I've lost trying to fight encodings.

On Thu, May 5, 2016 at 8:17 AM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 05/05/2016 01:09 PM, timeless wrote:
>>
>> I just spent some time investigating this.
>>
>> The answer is: NO. WE SHOULD NOT USE environb.
>>
>> That's an awful red herring.
>>
>> os.environb
>>
>> Bytes version of environ: a mapping object representing the
>> environment as byte strings. environ and environb are synchronized
>> (modify environb updates environ, and vice versa).
>>
>> environb is only available if supports_bytes_environ is True.
>>
>> New in version 3.2.
>>
>> https://docs.python.org/3/library/os.html#os.environb
>>
>> os.supports_bytes_environ
>>
>> True if the native OS type of the environment is bytes (eg. False on
>> Windows).
>>
>> New in version 3.2.
>>
>> https://docs.python.org/3/library/os.html#os.supports_bytes_environ
>>
>> Trying to use environb would break python3 on windows because we'd
>> have an os.environ object instead of an os.environb object, and we'd
>> be trying to stash bytes into it.
>>
>> I'm going to reassert that what I'm doing is correct. And I'd like to
>> get a version of it in so that I can unclutter my repository. I have a
>> whole slew of things that are blocked by this. Especially test.env
>> work.
>>
>> I will send a patch to *REMOVE* all use of environb and an item for
>> check code to reject it.
>
>
> Could we have a version that use environb implementing a thin layer in the
> window case to provide an environb like object in this case?
>
> --
> Pierre-Yves David


More information about the Mercurial-devel mailing list