Just now I was trapped by the "Importing the main module twice" problem
for a while, and then I searched on web and go into here. It seems pretty
good to fix this problem, since it is really difficult to find out this
problem. Anyway, a module should not be initialized twice which results in
th
On 09/03/2011 16:30, P.J. Eby wrote:
At 05:35 PM 3/4/2011 +, Michael Foord wrote:
That (below) is not distutils it is setuptools. distutils just uses
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Er, what? That's news to me. Could you file a bug report about what
doe
At 05:35 PM 3/4/2011 +, Michael Foord wrote:
That (below) is not distutils it is setuptools. distutils just uses
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Er, what? That's news to me. Could you file a bug report about what
doesn't work, specifically?
___
On Sun, Mar 6, 2011 at 2:54 PM, Ron Adam wrote:
>
> ... if the key matches sys.modules.__missing__
>
> Works for me. ;-)
>
> We can find a better name than __missing__ later. (minor detail)
__missing__ is a dict method. I was merely noting it would make more
sense to override that rather than
On 03/05/2011 06:33 PM, Nick Coghlan wrote:
On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam wrote:
Adding a second references to the '__main__' module begins to blur the
purpose of sys.modules from being a place to keep imported modules to a
place that also has some ordering information. (Practical
On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam wrote:
> Adding a second references to the '__main__' module begins to blur the
> purpose of sys.modules from being a place to keep imported modules to a
> place that also has some ordering information. (Practicality over purity?,
> Or an indication of wha
On 03/05/2011 01:14 AM, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam wrote:
Fixing direct execution inside packages
+1 on both of these.
I don't see any major problems with these. Any minor issues can be worked
out.
I suggest separating these two items out into their own
On Sat, Mar 5, 2011 at 3:08 AM, Toshio Kuratomi wrote:
> Some of them can be annoying as hell when dealing with a system that also
> installs multiple versions of a module. But one could argue that's the
> fault of setuptools' version handling rather than the entry-points
> handling.
Agreed; I d
On Fri, Mar 04, 2011 at 12:56:16PM -0500, Fred Drake wrote:
> On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
> wrote:
> > That (below) is not distutils it is setuptools. distutils just uses
> > `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
>
> Right; distutils scripts are just
On Sat, Mar 5, 2011 at 2:40 PM, Ron Adam wrote:
>> Fixing direct execution inside packages
>
> +1 on both of these.
>
> I don't see any major problems with these. Any minor issues can be worked
> out.
>
> I suggest separating these two items out into their own PEP, and doing them
> first.
This f
On 03/04/2011 09:30 AM, Nick Coghlan wrote:
Fixing dual imports of the main module
--
Two simple changes are proposed to fix this problem:
1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
install the specified module in ``sys.
On Sat, Mar 5, 2011 at 2:59 AM, Thomas Wouters wrote:
> This does nothing to fix another common error: *unwittingly* importing the
> main module under its real name -- for example when you intended to import,
> say, a standard library module of the same name. ('socket.py' is a
> surprisingly commo
On Sat, Mar 5, 2011 at 3:04 AM, Steven D'Aprano wrote:
> I think you mean that sys.path[0] will be set to the directory path.
Indeed I did.
> Should the current working directory continue to be included in the path
> when running a sub-package module?
No, it would be similar to the current diff
On Sat, Mar 5, 2011 at 2:22 AM, Fred Drake wrote:
> On Fri, Mar 4, 2011 at 10:59 AM, wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/tria
On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
wrote:
> That (below) is not distutils it is setuptools. distutils just uses
> `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Right; distutils scripts are just sad.
OTOH, entry-point based scripts are something setuptools got very
On 04/03/2011 17:24, Barry Warsaw wrote:
On Mar 04, 2011, at 05:35 PM, Michael Foord wrote:
That (below) is not distutils it is setuptools. distutils just uses
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Sure, but that'll all be moot when distutils2 is integrated into Py
On Mar 04, 2011, at 05:35 PM, Michael Foord wrote:
>That (below) is not distutils it is setuptools. distutils just uses
>`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Sure, but that'll all be moot when distutils2 is integrated into Python
3.3, right? :)
-Barry
signature.as
On 04/03/2011 17:07, Barry Warsaw wrote:
On Mar 04, 2011, at 11:22 AM, Fred Drake wrote:
On Fri, Mar 4, 2011 at 10:59 AM, wrote:
Something to consider here is how this will interact with Python files which
are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
refer to the
On Mar 04, 2011, at 11:22 AM, Fred Drake wrote:
>On Fri, Mar 4, 2011 at 10:59 AM, wrote:
>> Something to consider here is how this will interact with Python files which
>> are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
>> refer to the module defined by /usr/bin/trial.
Nick Coghlan wrote:
Fixing direct execution inside packages
---
To fix this problem, it is proposed that an additional filesystem check be
performed before proceeding with direct execution of a ``PY_SOURCE`` or
``PY_COMPILED`` file that has been named on the
On Fri, Mar 4, 2011 at 07:30, Nick Coghlan wrote:
> Fixing dual imports of the main module
> --
>
> Two simple changes are proposed to fix this problem:
>
> 1. In ``runpy``, modify the implementation of the ``-m`` switch handling to
> install the specified mo
Fred Drake wrote:
On Fri, Mar 4, 2011 at 10:59 AM, wrote:
Something to consider here is how this will interact with Python files which
are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
refer to the module defined by /usr/bin/trial.
I've long held the position that mod
On Fri, Mar 4, 2011 at 10:59 AM, wrote:
> Something to consider here is how this will interact with Python files which
> are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
> refer to the module defined by /usr/bin/trial.
I've long held the position that modules and scripts
On 03:30 pm, ncogh...@gmail.com wrote:
Fixing dual imports of the main module
--
Two simple changes are proposed to fix this problem:
1. In ``runpy``, modify the implementation of the ``-m`` switch
handling to
install the specified module in ``sys.module
24 matches
Mail list logo
