Re: Environment vars

[Bob van der Poel]

On Fri, Nov 27, 2020 at 1:41 PM dn via Python-list 
wrote:

> On 26/11/2020 05:46, Bob van der Poel wrote:
> > I've got a program which accepts an optional env variable listing a
> single
> > or multiple directory for the app to use. I've done a bit of a search and
> > see both a comma and semicolon being used/suggested as a path separator.
> > Any consensus on which is better?
>
>
> Further to comments about some users expecting one option, whereas
> others may be thinking of another...
>
>
> Herewith an irreverent article from "ElReg".
>
> NB Do not read "The Register" unless you can cope with sardonic,
> British, humor; and especially if you do not believe that "confession is
> good for the soul"!
>
> It's always DNS, especially when a sysadmin makes a hash of their
> semicolons
> Remember the days when 'we made it up as we went along'?
> Richard Speed Mon 23 Nov 2020 // 08:15 UTC
> https://www.theregister.com/2020/11/23/who_me/
> --
> Regards =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
>

This article clearly represents things which could go wrong in the good old
days. Those days are gone forever and things like that could never go wrong
today :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[dn via Python-list]

On 26/11/2020 05:46, Bob van der Poel wrote:

I've got a program which accepts an optional env variable listing a single
or multiple directory for the app to use. I've done a bit of a search and
see both a comma and semicolon being used/suggested as a path separator.
Any consensus on which is better?



Further to comments about some users expecting one option, whereas 
others may be thinking of another...



Herewith an irreverent article from "ElReg".

NB Do not read "The Register" unless you can cope with sardonic, 
British, humor; and especially if you do not believe that "confession is 
good for the soul"!


It's always DNS, especially when a sysadmin makes a hash of their semicolons
Remember the days when 'we made it up as we went along'?
Richard Speed Mon 23 Nov 2020 // 08:15 UTC
https://www.theregister.com/2020/11/23/who_me/
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Greg Ewing]

On 26/11/20 10:30 am, Bob van der Poel wrote:

Yes, but os.path.split() turns a single path into its components. We're
chatting about a bunch of complete path names separated by os.pathsep.


Yeah, it's unfortunate that the word "path" is conventionally
used for two very different things...

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Eryk Sun]

On 11/25/20, Bob van der Poel  wrote:
>
> Ahha! Didn't know about os.pathsep. Seems simple enough to use that and be
> done with it.
>
> I'm just using str.split() just now. Is there a os.splitpath()? I don't see
> anything in the docs.

There are no platform standard rules to follow when splitting a path
list. A string split() on os.pathsep suffices. If you don't have a
special use for empty entries, you can filter the result with a list
comprehension, e.g. [p for p in (os.environ.get('MYPATH') or
default).split(os.pathsep) if p]. The `default` value here is for when
MYPATH isn't defined or has an empty-string value.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Bob van der Poel]

On Wed, Nov 25, 2020 at 2:22 PM dn via Python-list 
wrote:

> > Ahha! Didn't know about os.pathsep. Seems simple enough to use that and
> be
> > done with it.
> >
> > I'm just using str.split() just now. Is there a os.splitpath()? I don't
> see
> > anything in the docs.
>
>
> https://docs.python.org/3/library/os.path.html#os.path.split
> --
> Regards =dn


Yes, but os.path.split() turns a single path into its components. We're
chatting about a bunch of complete path names separated by os.pathsep.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[dn via Python-list]

Ahha! Didn't know about os.pathsep. Seems simple enough to use that and be
done with it.

I'm just using str.split() just now. Is there a os.splitpath()? I don't see
anything in the docs.



https://docs.python.org/3/library/os.path.html#os.path.split
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Bob van der Poel]

On Wed, Nov 25, 2020 at 12:43 PM Eryk Sun  wrote:

> On 11/25/20, Bob van der Poel  wrote:
> > I've got a program which accepts an optional env variable listing a
> single
> > or multiple directory for the app to use.
>
> In Unix one would use colon as the preferred delimiter. In Windows,
> it's a semicolon because DOS paths use colon to designate drives.
> Python makes the platform's preferred path delimiter available as
> os.pathsep.
>
> A bonus with using semicolon in Windows 10 is that the system
> environment variable editor implements a multi-line form to edit the
> value if it detects a drive-like path as the first item. For example,
> editing "MYPATH=Z:\Spam;foo;bar" splits the value into three
> single-line text-edit fields containing "Z:\Spam", "foo", and "bar".
>

Ahha! Didn't know about os.pathsep. Seems simple enough to use that and be
done with it.

I'm just using str.split() just now. Is there a os.splitpath()? I don't see
anything in the docs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[dn via Python-list]

On 26/11/2020 08:43, Chris Angelico wrote:

On Thu, Nov 26, 2020 at 6:19 AM dn via Python-list
 wrote:



I've got a program which accepts an optional env variable listing a single
or multiple directory for the app to use. I've done a bit of a search and
see both a comma and semicolon being used/suggested as a path separator.
Any consensus on which is better?

...

The one thing I really would *not* recommend is a DWIM arrangement of
having it guess at which delimiter to use. :)



Interesting description. Historically I've always quoted "Postel's Law":
...
In psychology the jargon is "satisficing" - being happy with whichever
works when we try it: Why look [for a label]? I'll just push the door
away from me - and if that doesn't work, then I'll pull on the handle
(but if it's locked, my frustration will result in words being said...)
How quickly does something 'easy' move from 'who cares' to 'almost anger'?

So, if some users are likely to assume commas, but others [semi-]colons,
perhaps the best service is to enable either/both! (hint: str.translate() )


That's absolutely fine IF and ONLY IF you can guarantee that all those
forms of punctuation cannot occur within the elements. I do this kind
of thing all the time when it's unambiguous; for instance, a multiline
input saying "enter Twitch channel names" takes the user input and
splits it on comma, semicolon, newline, or space, and then trims
individual entries with "http%*[s]://twitch.tv/%s%*[?/]" to get to
just the channel name. That works really well, because there's no way
that a channel name can contain that sort of punctuation.


That's the dichotomy: as soon as we aim for 'flexibility', we risk 
ambiguity.


Sometimes it might be better to go with the Zen of Python: "There should 
be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch."*

Sadly, whilst we coders can reasonably be encouraged "In the face of 
ambiguity, refuse the temptation to guess.", it will never appear in 
(many) user's manifestos - possibly an 'age' thing, more likely a "don't 
think" thing...



* I'm amused (not offended) by this casual racism, but wonder how it 
continues to be allowed given the Python Foundation's diversity principles.



That said, Python/PSL enables differences between OpSys to be 
'abstracted away', eg using / or \ as separator in a file/dir's path. 
Where applicable, use!




It's completely NOT okay if you're working with something that might
contain anything - especially if your users aren't thinking about the
different separators. You might get away with using a comma to


Well, as debated earlier, Steve Krug suggests that users 
aren't/shouldn't be thinking. So, fallacies abound!




separate names of people, happily working with lists like "Fred,
Barney, Wilma" and "Elsa, Anna, Kristoff, Sven" and "Steve, Steven,
Stephen, Stefan, Stephanie", but then along comes "Charles, Prince of
Wales" and suddenly your system breaks. But far worse than simply
using commas as separators is magically deciding to do so on the basis
of what someone's given you to parse. If someone tries to use "Fred;
Barney; Wilma" and "Elsa; Anna; Kristoff; Sven" and it works fine,
then they might expect that it'd be safe to list the British royal
family with semicolons between their names - but your code suddenly
decides to use commas, and now everything's broken.


Hey, they're the Australian Royal Family too, aren't they?
(cue Republicanism sentiment)

How often does Prince Charles (the rest is "title" not name, BTW - thus 
"Charles Windsor" or even "Charles Wales") visit your web site/use your 
app?


Wouldn't you expect to cater less to princes and more to frogs?



The worst part of a DWIM system is that it's hard - often impossible -
to correct its errors. You end up fighting with it to interpret your
input correctly. With a simpler system, it might be bizarre and arcane
(seriously, look at bash's argument splitting and interpolation
rules!), but at least you don't have to fight it, and what works with
one set of data will definitely work with another.


Yes, the issue lies with, and starts with, the combination. Referencing 
@Eryk's post, even users with knowledge of their OpSys will come to the 
problem with a different set of assumptions (hopes, fears, ...)


Accordingly, it may be appropriate to eschew free-form lists entirely. Thus:

MYPATH=Z:\Spam
MYPATH=foo
MYPATH=bar

... but then sit-back and wait for the first help-call from a user 
worrying that the first/last is the only specification that will be applied.


Are we likely to 'win' any-time soon?


Clearly, what might be appropriate or usable in one 'solution', should 
be out-right rejected in another situation.




Conversely, consider the level of frustration faced by a user who
expects one thing but is *restricted* to something else, eg sites which
ask one to register a password, but don't advise up-front that they
require some arcane 

Re: Environment vars

[Eryk Sun]

On 11/25/20, Bob van der Poel  wrote:
> I've got a program which accepts an optional env variable listing a single
> or multiple directory for the app to use.

In Unix one would use colon as the preferred delimiter. In Windows,
it's a semicolon because DOS paths use colon to designate drives.
Python makes the platform's preferred path delimiter available as
os.pathsep.

A bonus with using semicolon in Windows 10 is that the system
environment variable editor implements a multi-line form to edit the
value if it detects a drive-like path as the first item. For example,
editing "MYPATH=Z:\Spam;foo;bar" splits the value into three
single-line text-edit fields containing "Z:\Spam", "foo", and "bar".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Chris Angelico]

On Thu, Nov 26, 2020 at 6:19 AM dn via Python-list
 wrote:
>
> >> I've got a program which accepts an optional env variable listing a single
> >> or multiple directory for the app to use. I've done a bit of a search and
> >> see both a comma and semicolon being used/suggested as a path separator.
> >> Any consensus on which is better?
> ...
> > The one thing I really would *not* recommend is a DWIM arrangement of
> > having it guess at which delimiter to use. :)
>
>
> Interesting description. Historically I've always quoted "Postel's Law":
> ...
> In psychology the jargon is "satisficing" - being happy with whichever
> works when we try it: Why look [for a label]? I'll just push the door
> away from me - and if that doesn't work, then I'll pull on the handle
> (but if it's locked, my frustration will result in words being said...)
> How quickly does something 'easy' move from 'who cares' to 'almost anger'?
>
> So, if some users are likely to assume commas, but others [semi-]colons,
> perhaps the best service is to enable either/both! (hint: str.translate() )

That's absolutely fine IF and ONLY IF you can guarantee that all those
forms of punctuation cannot occur within the elements. I do this kind
of thing all the time when it's unambiguous; for instance, a multiline
input saying "enter Twitch channel names" takes the user input and
splits it on comma, semicolon, newline, or space, and then trims
individual entries with "http%*[s]://twitch.tv/%s%*[?/]" to get to
just the channel name. That works really well, because there's no way
that a channel name can contain that sort of punctuation.

It's completely NOT okay if you're working with something that might
contain anything - especially if your users aren't thinking about the
different separators. You might get away with using a comma to
separate names of people, happily working with lists like "Fred,
Barney, Wilma" and "Elsa, Anna, Kristoff, Sven" and "Steve, Steven,
Stephen, Stefan, Stephanie", but then along comes "Charles, Prince of
Wales" and suddenly your system breaks. But far worse than simply
using commas as separators is magically deciding to do so on the basis
of what someone's given you to parse. If someone tries to use "Fred;
Barney; Wilma" and "Elsa; Anna; Kristoff; Sven" and it works fine,
then they might expect that it'd be safe to list the British royal
family with semicolons between their names - but your code suddenly
decides to use commas, and now everything's broken.

The worst part of a DWIM system is that it's hard - often impossible -
to correct its errors. You end up fighting with it to interpret your
input correctly. With a simpler system, it might be bizarre and arcane
(seriously, look at bash's argument splitting and interpolation
rules!), but at least you don't have to fight it, and what works with
one set of data will definitely work with another.

> Conversely, consider the level of frustration faced by a user who
> expects one thing but is *restricted* to something else, eg sites which
> ask one to register a password, but don't advise up-front that they
> require some arcane combination/mix of characters - until after you've
> entered your [ignorant] choice - twice. Grrr!

Ohh I hear you on that. Especially when they think they need more
security than everyone else, so they say "have to have two uppercase,
two lowercase, one digit, and two symbols". And then they reject
password after password because, apparently, "!" isn't one of their
list of symbols. Or something. And of course, they never permit long
passwords. Oh no, that would be way too helpful, not to mention that
it'd actually be more secure. Sigh.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[dn via Python-list]

I've got a program which accepts an optional env variable listing a single
or multiple directory for the app to use. I've done a bit of a search and
see both a comma and semicolon being used/suggested as a path separator.
Any consensus on which is better?

...

The one thing I really would *not* recommend is a DWIM arrangement of
having it guess at which delimiter to use. :)



Interesting description. Historically I've always quoted "Postel's Law":

<<<
Robustness principle
In computing, the robustness principle is a design guideline for software:

Be conservative in what you do, be liberal in what you accept from 
others (often reworded as "Be conservative in what you send, be liberal 
in what you accept").
The principle is also known as Postel's law, after Jon Postel, who wrote 
in an early specification of TCP:[1]

>>>
https://en.wikipedia.org/wiki/Robustness_principle


More recently, folk have been reading Steve Krug - "oh you mean, Don't 
Make Me Think!"; which I fear is too readily taken literally, if not as 
non sequitur.

https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think
(but reading the book will be time well-spent by anyone working at the 
'front end'!)



In psychology the jargon is "satisficing" - being happy with whichever 
works when we try it: Why look [for a label]? I'll just push the door 
away from me - and if that doesn't work, then I'll pull on the handle 
(but if it's locked, my frustration will result in words being said...) 
How quickly does something 'easy' move from 'who cares' to 'almost anger'?


So, if some users are likely to assume commas, but others [semi-]colons, 
perhaps the best service is to enable either/both! (hint: str.translate() )


Conversely, consider the level of frustration faced by a user who 
expects one thing but is *restricted* to something else, eg sites which 
ask one to register a password, but don't advise up-front that they 
require some arcane combination/mix of characters - until after you've 
entered your [ignorant] choice - twice. Grrr!

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Grant Edwards]

On 2020-11-25, Bob van der Poel  wrote:

> What does DWIN mean?

It's DWIM: "do what I mean". It refers to software (like PHP) that
instead of requiring unambiguous input, it silently (and often
incorrectly) guesses what ambiguous input is supposed to mean using
heuristics known to and understood by only the developer. [I'm giving
PHP developers the benefit of the doubt with the assumption that they
do understand what they do and that that it makes sense to them.]

> Hmmm, using colons? Yet another option :)

That's quite certainly what Unix users are going to expect to use.

--
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Bob van der Poel]

On Wed, Nov 25, 2020 at 11:00 AM dn via Python-list 
wrote:

> On 26/11/2020 05:46, Bob van der Poel wrote:
> > I've got a program which accepts an optional env variable listing a
> single
> > or multiple directory for the app to use. I've done a bit of a search and
> > see both a comma and semicolon being used/suggested as a path separator.
> > Any consensus on which is better?
> >
> > MYPATHS=foo,bar,woof
> > or
> >  MYPATHS=foo;bar;woof
> > And, certainly not
> >  MYPATHS=foo,bar;woof
> >
> > I did think I could be clever and check to see if the string contained a
> ,
> > or ; and spit it accordingly, but then what if the reason (hopefully,
> > pretty damned unlikely!) that a , or ; is being used as part of a path
> name?
>
>
> Is this a Python question? ie the above code should be run inside the
> Python interpreter (it won't).
>
> MS-Windows has an option to use a comma or a semi-colon as a
> list-separator on the 'command line' - as a local/locale definition, but
> there are caveats.
>
> Alternately, did you mean that the above is part of a data-file?
> -
>

Just to clarify, the variable can be set on the command line or in a shell
script. Most likely:

  MYPATH=aa,bb,cc  myprogram

and myprogram will look for the variable and slice it into chunks at ","s
or ";".

You're right, this is not really a python question. Probably a shell thing.

Thanks.

-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Bob van der Poel]

On Wed, Nov 25, 2020 at 10:59 AM Chris Angelico  wrote:

> On Thu, Nov 26, 2020 at 4:36 AM Bob van der Poel  wrote:
> >
> > I've got a program which accepts an optional env variable listing a
> single
> > or multiple directory for the app to use. I've done a bit of a search and
> > see both a comma and semicolon being used/suggested as a path separator.
> > Any consensus on which is better?
> >
> >MYPATHS=foo,bar,woof
> > or
> > MYPATHS=foo;bar;woof
> > And, certainly not
> > MYPATHS=foo,bar;woof
> >
> > I did think I could be clever and check to see if the string contained a
> ,
> > or ; and spit it accordingly, but then what if the reason (hopefully,
> > pretty damned unlikely!) that a , or ; is being used as part of a path
> name?
> >
>
> Both are very much possible. I would recommend following a well-known
> standard; fortunately, there are plenty to choose from.
>
> 1) Separate them with spaces, because words.
> 2) Separate them with commas, because lists in English.
> 3) Separate with colons the way $PATH is.
>
> Whichever way you do it, you'll have to cope with the possibility that
> the character exists in a path name. That means you'll either need an
> escaping system (eg "\ " meaning a space, or ",," meaning a comma) or
> a quoting system (so "foo,bar",woof would mean two entries, the first
> of which contains a comma). Or you just acknowledge that MYPATHS is
> unable to represent something with the delimiter - which is how $PATH
> works - and then you'll probably need some workaround for that, like
> maybe a command line argument.
>
> The one thing I really would *not* recommend is a DWIM arrangement of
> having it guess at which delimiter to use. :)
>

Thanks Chris.

What does DWIN mean?

Hmmm, using colons? Yet another option :)

Spaces ... nope. That means the entire option will need to be quoted to
escape the shell's work.

So, back to commas or semicolons. I think I'll just stick with the commas
'cause I already wrote it that way :)


-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[dn via Python-list]

On 26/11/2020 05:46, Bob van der Poel wrote:

I've got a program which accepts an optional env variable listing a single
or multiple directory for the app to use. I've done a bit of a search and
see both a comma and semicolon being used/suggested as a path separator.
Any consensus on which is better?

MYPATHS=foo,bar,woof
or
 MYPATHS=foo;bar;woof
And, certainly not
 MYPATHS=foo,bar;woof

I did think I could be clever and check to see if the string contained a ,
or ; and spit it accordingly, but then what if the reason (hopefully,
pretty damned unlikely!) that a , or ; is being used as part of a path name?



Is this a Python question? ie the above code should be run inside the 
Python interpreter (it won't).


MS-Windows has an option to use a comma or a semi-colon as a 
list-separator on the 'command line' - as a local/locale definition, but 
there are caveats.


Alternately, did you mean that the above is part of a data-file?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: Environment vars

[Chris Angelico]

On Thu, Nov 26, 2020 at 4:36 AM Bob van der Poel  wrote:
>
> I've got a program which accepts an optional env variable listing a single
> or multiple directory for the app to use. I've done a bit of a search and
> see both a comma and semicolon being used/suggested as a path separator.
> Any consensus on which is better?
>
>MYPATHS=foo,bar,woof
> or
> MYPATHS=foo;bar;woof
> And, certainly not
> MYPATHS=foo,bar;woof
>
> I did think I could be clever and check to see if the string contained a ,
> or ; and spit it accordingly, but then what if the reason (hopefully,
> pretty damned unlikely!) that a , or ; is being used as part of a path name?
>

Both are very much possible. I would recommend following a well-known
standard; fortunately, there are plenty to choose from.

1) Separate them with spaces, because words.
2) Separate them with commas, because lists in English.
3) Separate with colons the way $PATH is.

Whichever way you do it, you'll have to cope with the possibility that
the character exists in a path name. That means you'll either need an
escaping system (eg "\ " meaning a space, or ",," meaning a comma) or
a quoting system (so "foo,bar",woof would mean two entries, the first
of which contains a comma). Or you just acknowledge that MYPATHS is
unable to represent something with the delimiter - which is how $PATH
works - and then you'll probably need some workaround for that, like
maybe a command line argument.

The one thing I really would *not* recommend is a DWIM arrangement of
having it guess at which delimiter to use. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Environment vars

[Bob van der Poel]

I've got a program which accepts an optional env variable listing a single
or multiple directory for the app to use. I've done a bit of a search and
see both a comma and semicolon being used/suggested as a path separator.
Any consensus on which is better?

   MYPATHS=foo,bar,woof
or
MYPATHS=foo;bar;woof
And, certainly not
MYPATHS=foo,bar;woof

I did think I could be clever and check to see if the string contained a ,
or ; and spit it accordingly, but then what if the reason (hopefully,
pretty damned unlikely!) that a , or ; is being used as part of a path name?


-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue16961] No regression tests for -E and individual environment vars

[STINNER Victor]

STINNER Victor  added the comment:

I added a lot of tests on environment variables and -I/-E options in 
test_embed. I consider that this issue is now fixed.

--
nosy: +vstinner
resolution: out of date -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16961] No regression tests for -E and individual environment vars

[Nick Coghlan]

Nick Coghlan  added the comment:

Victor Stinner added a great many regression tests in this area for Python 3.7+

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16961] No regression tests for -E and individual environment vars

[SilentGhost]

SilentGhost  added the comment:

Nick, please re-open if you feel this issue is still relevant.

--
nosy: +SilentGhost
resolution:  -> out of date
stage:  -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16961] No regression tests for -E and individual environment vars

[Mark Lawrence]

Change by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16961] No regression tests for -E and individual environment vars

[Nick Coghlan]

Changes by Nick Coghlan ncogh...@gmail.com:


--
assignee: ncoghlan - 

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16961
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16961] No regression tests for -E and individual environment vars

[Mark Lawrence]

Mark Lawrence added the comment:

Consider yourself reminded :)

--
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16961
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16961] No regression tests for -E and individual environment vars

[Nick Coghlan]

New submission from Nick Coghlan:

Accessing an environment variable without Py_GETENV (or breaking 
Py_IgnoreEnvironmentFlag configuration *cough*) may lead to environment 
variables being accessed even if -E is passed on the command line.

As part of the PEP 432 implementation, I'm adding appropriate regression tests 
for affected environment variables as I go.

Creating this as a reminder to look into backporting the relevant regression 
tests at least to 3.3

--
assignee: ncoghlan
messages: 179934
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: No regression tests for -E and individual environment vars
versions: Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16961
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com