Re: [Python-Dev] Setting project home path the best way SOLVED

[Christian Tismer]

Hi Nick, Holger,

this is a crazy fault of mine, see the end below.

I wrote:

I have a project that has its root somewhere on my machine.
This project has many folders and contains quite some modules.

There is a common root of the module tree, and I want to use
- either absolute imports
- relative imports with '.'

Problem:

- I want to run any module inside the heirarchy from the command-line

- this should work, regardless what my 'cwd' is

- this should work with or without virtualenv.

So far, things work fine with virtualenv, because sys.executable is in the 
project module tree.

Without virtualenv, this is not so. But I hate to make settings like 
PYTHONPATH, because these are not permanent. .

Question:

How should I define my project root dir in a unique way, without setting an 
environment variable?
What is the lest intrusive way to spell that?

Reason:

I'd like to make things work correctly and unambigously when I call a script
inside the module heirarchy. Things are not fixed: there exist many checkouts
In the file system, and each should know where to search its home/root in the 
tree.

Is this elegantly possible to deduce from the actually executed script file?



Nick wrote:

On 12.11.12 01:38, Nick Coghlan wrote:


The only way I know how to do it is to have my cwd set to the 
directory I want on sys.path, then use -m for script execution (using 
a separate shell session for anything where I want a different working 
directory).


I don't know of any way to handle a varying cwd without manipulating 
the path directly through either virtualenv or PYTHONPATH.


Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)



Holger wrote (private message):

ich selbst nutze seit langer Zeit setuptools, genauer:

 python setup.py develop

z.B. in pytest, execnet, tox.  Das ist wie "setup.py install" nur dass
das paket "inplace" installiert wird.  Aber vermutlich kennst du das schon?!


So here is the crazy story:

I'm actually using setuptools for my tiffany project with

 setup.py develop

My real work is about the Pydica project which is a lot more.
There I'm playing sys.path tricks, using virtualenv and the fact
that I have full control over the local site-packages, and use some
tricky .pth scripts to set everything up. But it needs virtualenv.

Believe it or not:
*I was not able to realize that all my problems are already solved*
if I change Pydica and build a proper setup using setuptools.

I needed to bug python-dev with this, and finally got the right
hint from Holger Krekel who is absolutely right here - no point in
playing tricks, because this is all solved. And Pydica is about to
be prepared for PyPI, anyway.

My blocker was probably that Pydica is very much in development,
and I did not think right about it. The project does not need to be
ready in order to use setuptools!

My apologies, and many thanks again! This solved a Gordian Knot.

It is great when people help me to leave a dead-lock in my brain :-)

cheers - Chris

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"

[Jan Matějek]

Dne 31.10.2012 23:15, Steven D'Aprano napsal(a):


I wonder if this message can be improved with a
pointer to the concept on when global variables become local?


If you have a suggestion for an improved message, please tell us. Or raise
an issue on the bug tracker.


I believe the "human problem" here is that the one tends to gloss over "local 
variable VARNAME", because it describes VARNAME and you already think you know 
what that is, so you don't stop to think about it.


The following would be better in this regard, IMO:

"Variable VARNAME is local in FUNCNAME, but doesn't have a value at line 123"

regards
m.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Issue #16416: OS data are now always encoded/decoded to/from

[Antoine Pitrou]

On Mon, 12 Nov 2012 23:03:45 +0100 (CET)
victor.stinner  wrote:
>  
> +- Issue #16416: OS data are now always encoded/decoded to/from
> +  UTF-8/surrogateescape, instead of the locale encoding (which may be ASCII 
> if
> +  no locale environment variable is set), to avoid inconsistencies with
> +  os.fsencode() and os.fsdecode() functions which are already using
> +  UTF-8/surrogateescape.

I believe you mean "OS X", not "OS".

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Okay to document the "exec tuple" form of the exec statement in Python 2.7?

[Michael Bayer]

On Nov 5, 2012, at 4:51 PM, Greg Ewing wrote:

> Nick Coghlan wrote:
>> On Mon, Nov 5, 2012 at 10:08 PM, Mark Dickinson  wrote:
>>> In Python 2, the 'exec' statement supports 'exec'-ing a (statement,
>>> globals, locals) tuple:
> 
> If this is a deliberate feature, I'd guess it's because exec
> is a statement rather than a function in Python 2, so you
> can't use * to pass a tuple of arguments to it.

any chance, if this function is documented,  someone can make it very clear 
what the cross-compatibility implications are with the Python 2.x form of 
exec() and the Python 3.x form ?   I'm having a hard time demonstrating the 
difference to myself, though the winning answer to his StackOverflow question 
http://stackoverflow.com/questions/6561482/why-did-python-3-changes-to-exec-break-this-code
 seems to suggest the behavior of symbol tables has changed.


> 
> -- 
> Greg
> 
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/mike_mp%40zzzcomputing.com
> 

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"

[Glenn Linderman]

On 11/12/2012 7:30 AM, Jan Matějek wrote:


I believe the "human problem" here is that the one tends to gloss over 
"local variable VARNAME", because it describes VARNAME and you already 
think you know what that is, so you don't stop to think about it.


The following would be better in this regard, IMO:

"Variable VARNAME is local in FUNCNAME, but doesn't have a value at 
line 123" 


+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] accept the wheel PEPs 425, 426, 427

[Nick Coghlan]

On Mon, Oct 29, 2012 at 4:47 AM, Daniel Holth  wrote:

> I think Metadata 1.3 is done. Who would like to czar?
>
(Apologies for the belated reply, it's been a busy few weeks)

I'm happy to be BDFL delegate for these. I'd like to see PEP 425 updated
with some additional rationale based on Ronald's comments later in this
thread, though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com