Stefan Seefeld added the comment:
I'm not entirely sure, but have to admit that the sentence
"The function imports the module name, potentially using the given globals and
locals to determine how to interpret the name in a package context."
is a bit obscure. What does &quo
Stefan Seefeld added the comment:
OK, thanks for the clarification. I think this is obscure enough to warrant at
least a paragraph or two to clarify the semantics of these arguments.
I changed the issue "components" and "type" to reflect that.
--
assignee: ->
New submission from Stefan Seefeld :
I'm trying to import custom scripts that expect the presence of certain
variables in the global namespace.
It seems `__import__('script', globals=dict(foo='bar'))` doesn't have the
expected effect of injecting "foo" into the namespace
Change by Stefan Seefeld :
--
resolution: -> works for me
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Stefan Seefeld added the comment:
Yes. Depending on the answer to my question(s), the request either becomes:
"please add support for this use-case", or "this use-case isn't documented
properly", i.e. a feature request or a bu
New submission from Stefan Seefeld :
I'm working on a project that I'd like to split into multiple separately
installable components. The main component is a command-line tool without any
external dependencies. Another component is a GUI frontend that adds some
third-party dependencies
Stefan Seefeld added the comment:
> The limitation is a consequence of how Linux works.
> Unix has no cross-platform API for non-blocking waiting for child process
> finish except handling SIGCHILD signal.
Why does the `wait()` have to be non-blocking ? We can call it once in
Stefan Seefeld added the comment:
OK, so while I have been able to work around the issues (by using `quamash` to
bridge between `asyncio` and `Qt`), I'd still like to understand the rationale
behind the limitation that any subprocess-managing event-loop has to run in the
main thread
Stefan Seefeld added the comment:
That's quite an unfortunate limitation ! I'm working on a GUI frontend to a
Python tool I wrote using asyncio, and the GUI (Qt-based) itself insists to run
its own event loop in the main thread.
I'm not sure how to work around this limitation, but I can
New submission from Stefan Seefeld :
This is an addendum to issue35621:
To be able to call `asyncio.create_subprocess_exec()` from another thread, A
separate event loop needs to be created. To make the child watcher aware of
this new loop, I have to call `asyncio.get_child_watcher
Change by Stefan Seefeld :
--
nosy: +stefan
___
Python tracker
<https://bugs.python.org/issue35621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Stefan Seefeld added the comment:
ad 3) sorry, I picked a bad example - I didn't mean to suggest that immutable
objects should in fact become mutable by modifying their `__doc__` attribute.
ad 1) good, glad to hear that.
ad 2) fine. In fact, I'm not even proposing that per-instance
Stefan Seefeld added the comment:
On 2018-12-09 19:48, Karthikeyan Singaravelan wrote:
> There was a related proposal in
> https://www.python.org/dev/peps/pep-0258/#attribute-docstrings
Right, but that was rejected (for unrelated reasons). The idea itself
was rejected by Guido
Stefan Seefeld added the comment:
On 2018-12-09 18:35, Steven D'Aprano wrote:
> Steven D'Aprano added the comment:
>
>> Is there any discussion concerning what syntax might be used for
>> docstrings associated with objects ?
> I don't know about PyDoc in general, but I
Stefan Seefeld added the comment:
Exactly ! I'm fully aware of the ubiquity of objects in Python, and it is for
that reason that I had naively expected `pydoc` to simply DoTheRightThing when
encountering an object containing a `__doc__` attribute. rather than only
working for types
New submission from Stefan Seefeld :
On multiple occasions I have wanted to add documentation not only to Python
classes and functions, but also instance variables. This seems to involve (at
least) two orthogonal questions:
1) what is the proper syntax to associate documentation (docstrings
New submission from Stefan Seefeld <ste...@seefeld.name>:
I'm using Python's `argparse` module to define optional arguments.
I'm calling the `argparse.add_argument` method to add both short and long
arguments, but I notice that the generated help message lists some information
Stefan Seefeld <ste...@seefeld.name> added the comment:
It looks like https://bugs.python.org/issue14191 is a conversation about the
same inconsistent behaviour. It is set to "fixed". Can you comment on this ?
Should I follow the advice mentioned there about how to work
Stefan Seefeld <ste...@seefeld.name> added the comment:
On 15.11.2017 12:54, R. David Murray wrote:
> Can you reproduce this without your PosArgsParser?
I can indeed (by simply commenting out the `action` argument to the
`add_argument()` calls).
That obviously results in all positional
New submission from Stefan Seefeld <ste...@seefeld.name>:
I'm trying to mix positional and non-positional arguments with a script using
`argparse`, but I observe inconsistent behaviour.
The attached test runs fine when invoked with
test_argparse.py --info a a=b
test_argparse.py a a=b
Stefan Seefeld added the comment:
OK, fair enough, that makes sense. As I said, in my last message, I was mainly
simply trying to figure out the exact location of the error in the executed
script, which I got from inspecting the SyntaxError.
So if all of this is expected behaviour, I think we
Stefan Seefeld added the comment:
Answering my own question:
It appears I can get the location of a syntax error by inspecting the
raised `SyntaxError`, which solves my specific use-case.
The bug remains, though: The traceback is incomplete if it stems from a syntax
error
Stefan Seefeld added the comment:
Some further experiements:
Replacing the `exec(f.read(), env)` line by
```
code = compile(f.read(), 'script', 'exec')
exec(code, env)
```
exhibits the same behaviour. If I remove the `try...except`, the correct
(full) traceback is printed out. So it looks like
New submission from Stefan Seefeld:
The following code is supposed to catch and report errors encountered during
the execution of a (python) script:
```
import traceback
import sys
try:
env = {}
with open('script') as f:
exec(f.read(), env)
except:
type_, value_, tb
New submission from Stefan Seefeld:
The unittest test discovery right now only looks into sub-packages if they
contain a `__init__.py` file. That's an unnecessary requirement, as packages
are also importable if only `__init__.pyc` is present.
--
components: Library (Lib)
messages
Stefan Seefeld added the comment:
I believe what I actually want is for the discovery mechanism to be fully
implicit. It turns out that already *almost* works right now.
What doesn't work (and what this bug report really was about initially), is the
use of the 'discover' command with the '-p
Stefan Seefeld added the comment:
Hi, I'm investigating more issues related to test loading, and thus I have
discovered issue #16662.
I have found quite a number of inconsistencies and bugs in the loading of
tests. But without getting a sense of what the supposed behavior is I find
New submission from Stefan Seefeld:
I'm trying to use the distutil compiler to preprocess some header (to be used
with the cffi package).
The code is
compiler = distutils.ccompiler.new_compiler()
compiler.add_include_dir(join(sys.prefix, 'include'))
compiler.preprocess(source
New submission from Stefan Seefeld:
I'm using the `cProfile` module to profile my code.
I tried to temporarily disable the profiler by using:
prof = sys.getprofile()
sys.setprofile(None)
...
sys.setprofile(prof)
resulting in an error.
The reason is that with `cProfile
New submission from Stefan Seefeld:
As described in the README contained in the attached tarball, I'm observing
wrong behavior. I have based this code on my understanding of
https://docs.python.org/2/library/unittest.html#load-tests-protocol, but the
effect isn't as expected (I see duplicate
New submission from Stefan Seefeld:
The docs at http://docs.python.org/lib/dom-element-objects.html
claim that removeAttribute(name) silently ignores the attempt to
remove an unknown attribute. However, the current implementation
in the minidom module (part of _xmlplus) raises
Stefan Seefeld added the comment:
Mark,
thanks for the quick follow-up.
OK, i now understand the situation better. The documentation I had read
originally didn't talk about special-casing built-in objects. (And since
I want to extend a tuple, I do have to override __getslice__ since I
want
New submission from Stefan Seefeld:
The python documentation states that since python 2.0 __getslice__ is
obsoleted by __getitem__. However, testing with python 2.3 as well as
2.5, I find the following surprising behavior:
class Tuple(tuple):
def __getitem__(self, i): print '__getitem__', i
33 matches
Mail list logo
