[PATCH] Makefile: Remove usage of deprecated Python "has_key" method

[PATCH] Makefile: Remove usage of deprecated Python "has_key" method

[David Aguilar]

"has_key" is a deprecated dictionary method in Python 2.6+.
Simplify the sys.path manipulation for installed scripts by
passing a default value to os.getenv().

SCRIPT_PYTHON is currently empty but this future-proofs us.
It also fixes things for users who maintain local git forks
with their own SCRIPT_PYTHON additions.

Signed-off-by: David Aguilar <davvid@gmail.com>
---
 Makefile |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 3a6c6ea..806ccdf 100644
--- a/Makefile
+++ b/Makefile
@@ -1609,9 +1609,8 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
 	    -e '}' \
 	    -e 's|^import sys.*|&; \\\
 	           import os; \\\
-	           sys.path[0] = os.environ.has_key("GITPYTHONLIB") and \\\
-	                         os.environ["GITPYTHONLIB"] or \\\
-	                         "@@INSTLIBDIR@@"|' \
+	           sys.path.insert(0, os.getenv("GITPYTHONLIB",\
+	                                        "@@INSTLIBDIR@@"));|' \
 	    -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
 	    $@.py >$@+ && \
 	chmod +x $@+ && \
-- 
1.7.0.3.291.g5e4f6

Re: [PATCH] Makefile: Remove usage of deprecated Python "has_key" method

[Junio C Hamano]

David Aguilar <davvid@gmail.com> writes:

> "has_key" is a deprecated dictionary method in Python 2.6+.
> Simplify the sys.path manipulation for installed scripts by
> passing a default value to os.getenv().

It looks like the old code was replacing sys.path[0] but you are
prepending this.  Doesn't that change also make a difference?

> SCRIPT_PYTHON is currently empty but this future-proofs us.
> It also fixes things for users who maintain local git forks
> with their own SCRIPT_PYTHON additions.
>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
>  Makefile |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 3a6c6ea..806ccdf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1609,9 +1609,8 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
>  	    -e '}' \
>  	    -e 's|^import sys.*|&; \\\
>  	           import os; \\\
> -	           sys.path[0] = os.environ.has_key("GITPYTHONLIB") and \\\
> -	                         os.environ["GITPYTHONLIB"] or \\\
> -	                         "@@INSTLIBDIR@@"|' \
> +	           sys.path.insert(0, os.getenv("GITPYTHONLIB",\
> +	                                        "@@INSTLIBDIR@@"));|' \
>  	    -e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
>  	    $@.py >$@+ && \
>  	chmod +x $@+ && \
> -- 
> 1.7.0.3.291.g5e4f6

Re: [PATCH] Makefile: Remove usage of deprecated Python "has_key" method

[David Aguilar]

On Sun, Mar 28, 2010 at 09:38:54AM -0700, Junio C Hamano wrote:
> David Aguilar <davvid@gmail.com> writes:
> 
> > "has_key" is a deprecated dictionary method in Python 2.6+.
> > Simplify the sys.path manipulation for installed scripts by
> > passing a default value to os.getenv().
> 
> It looks like the old code was replacing sys.path[0] but you are
> prepending this.  Doesn't that change also make a difference?

The original code replaced sys.path[0] which is ''
(aka the current directory).  It's a little odd to
rely on the 0th element being something that is safe
to remove.

By prepending the path we have the same intended effect without
having to know that the 0th element is something that is
safe to remove.

Does removing '' break relative imports? (It might...)

Due to the portability concerns with relative imports the
recommendation is to always use absolute imports.  Thus, this
shouldn't hurt us in practice if we stick to absolute imports,
but I figured I'd mention it as another reason why prepending
might be preferred over replacing.

-- 
		David

Re: [PATCH] Makefile: Remove usage of deprecated Python "has_key" method

[Tay Ray Chuan]

Hi,

On Mon, Mar 29, 2010 at 5:54 AM, David Aguilar <davvid@gmail.com> wrote:
> On Sun, Mar 28, 2010 at 09:38:54AM -0700, Junio C Hamano wrote:
>> David Aguilar <davvid@gmail.com> writes:
>>
>> > "has_key" is a deprecated dictionary method in Python 2.6+.
>> > Simplify the sys.path manipulation for installed scripts by
>> > passing a default value to os.getenv().
>>
>> It looks like the old code was replacing sys.path[0] but you are
>> prepending this.  Doesn't that change also make a difference?
>
> The original code replaced sys.path[0] which is ''
> (aka the current directory).  It's a little odd to
> rely on the 0th element being something that is safe
> to remove.

more accurately, it's "directory containing the script that was used
to invoke the Python interpreter":

  http://docs.python.org/library/sys.html#sys.path

-- 
Cheers,
Ray Chuan

Re: [PATCH] Makefile: Remove usage of deprecated Python "has_key" method

[Johan Herland]

On Sunday 28 March 2010, David Aguilar wrote:
> "has_key" is a deprecated dictionary method in Python 2.6+.
> Simplify the sys.path manipulation for installed scripts by
> passing a default value to os.getenv().
> 
> SCRIPT_PYTHON is currently empty but this future-proofs us.
> It also fixes things for users who maintain local git forks
> with their own SCRIPT_PYTHON additions.
> 
> Signed-off-by: David Aguilar <davvid@gmail.com>

Acked-by: Johan Herland <johan@herland.net>

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: [PATCH] Makefile: Remove usage of deprecated Python "has_key" method

[Junio C Hamano]

David Aguilar <davvid@gmail.com> writes:

> On Sun, Mar 28, 2010 at 09:38:54AM -0700, Junio C Hamano wrote:
>> David Aguilar <davvid@gmail.com> writes:
>> 
>> > "has_key" is a deprecated dictionary method in Python 2.6+.
>> > Simplify the sys.path manipulation for installed scripts by
>> > passing a default value to os.getenv().
>> 
>> It looks like the old code was replacing sys.path[0] but you are
>> prepending this.  Doesn't that change also make a difference?
>
> The original code replaced sys.path[0] which is ''
> (aka the current directory).  It's a little odd to
> rely on the 0th element being something that is safe
> to remove.
>
> By prepending the path we have the same intended effect without
> having to know that the 0th element is something that is
> safe to remove.
>
> Does removing '' break relative imports? (It might...)

That is exactly why I asked if it was an improvement that was not
described in the log message.

I'll queue with Johan's Ack, perhaps rewording the message a bit.
Thanks.