Nick Coghlan added the comment:
Unfortunately, I don't think including implicit shlex.quote() calls is going to
have the effect I was originally looking for:
>>> subprocess.call("du -hs ../py*", shell=True)
593M../py3k
577M../py3k_pristine
479M../python27
Nick Coghlan added the comment:
I'm reasonably happy with the changes I just checked in, but rather than doing
multiple forward ports, my plan is to let them settle for a while, update them
based on any feedback I get, then incorporate the final version into the 3.x
s
Changes by Nick Coghlan :
--
assignee: docs@python -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue13237>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan added the comment:
Considering this further, I've realised that the idea of implicit quoting for
this style of helper function is misguided on another level - the parameters to
be interpolated may not even be strings yet, so attempting to quote them would
Nick Coghlan added the comment:
Without knowing this issue existed, I recently started working on adding some
convenience APIs for shell invocation to shutil:
http://bugs.python.org/issue13238
I think the getstatus and getstatusoutput APIs were copied from the commands
module in 3.0 without
Nick Coghlan added the comment:
I discovered a couple of APIs that were moved from the commands module to the
subprocess module in 3.0:
http://docs.python.org/dev/library/subprocess#subprocess.getstatusoutput
However, they have issues, especially on Windows:
http://bugs.python.org/issue10197
Nick Coghlan added the comment:
After a bit of thought, I realised I could use the string.Formatter API to
implement a custom formatter for the shell command helpers that auto-escapes
whitespace while leaving the other shell metacharacters alone (so you can still
interpolate paths containing
New submission from Nick Coghlan :
I just got bitten by the singularly unhelpful results of doing
inspect.getsource(generator_context_manager).
Now that @functools.wraps adds the __wrapped__ attribute, perhaps
inspect.getsource(f) should follow the wrapper chain by default?
This would affect
Nick Coghlan added the comment:
After a little thought, I think the explicit "unwrap" function is the only
viable approach. Doing the unwrapping implicitly just has too many nasty corner
cases to track down to ensure we aren't losing existing functionality.
I'd also s
Nick Coghlan added the comment:
This feature is unnecessary now that PEP 3147 has been adopted. The way it
works in 3.2+ is that orphaned bytecode files inside __pycache__ are always
ignored, while bytecode files that live directly in the source directories are
always imported.
This handles
Nick Coghlan added the comment:
Absent any further feedback, I think I'm done with the changes to the 2.7
subprocess docs. I'll let them sit for a few days, then do the forward port to
3.2 and default.
There are a couple of additional changes I'll add to the 3.x vers
Nick Coghlan added the comment:
That's deliberate, as I'm only showing a selected subset of the full
signature at that point and using the subprocess API's with positional
arguments would lead to almost incomprehensible code. I'm not in any great
hurry to forward port tho
Nick Coghlan added the comment:
We can only protect people from themselves so much - "shell=True" is invaluable
when you actually want to invoke the shell, and the shell has much better tools
for process invocation and pipeline processing than Python does (since shells
are, in effe
Nick Coghlan added the comment:
As the last checkin message says, I've made the documentation for the helper
functions more self-contained. Each now has its own short "shell=True" warning
with a pointer to the full explanation in the shared parameter description.
There was
Nick Coghlan added the comment:
I realised I could use the convert_field() option in the custom formatter to
choose between several interpolation quoting options:
default - str + shutil.quote_ascii_whitespace
!q - str + shlex.quote
!u - unquoted (i.e. no conversion, str.format default
Nick Coghlan added the comment:
Some examples:
>>> import shutil
>>> shutil.shell_call("du -hs {}", "../py*")
594M../py3k
579M../py3k_pristine
480M../python27
301M../python31
382M../python32
288K../python_swallowed_whole
0
>&
Nick Coghlan added the comment:
The first version I wrote *did* automatically invoke shlex.quote on all
interpolated values, but that breaks wildcard handling. You can see that in the
examples I posted above. With the default whitespace escaping (which allows
spaces in filenames), wildcard
Nick Coghlan added the comment:
Yeah, I was thinking about this a bit more and realised that I'd rejected the
"quote everything by default" approach before I had the idea of providing a
custom conversion specifier to disable the implicit string conversion and
quoting.
So p
New submission from Nick Coghlan :
In a recent python-ideas discussion of the differences between concatenation
and augmented assignment on lists, I pointed out the general guiding principle
behind Python's binary operation semantics was that the type of a binary
operation should not d
New submission from Nick Coghlan :
Currently, sqlite3 allows rows to be easily returned as ordinary tuples
(default) or sqlite3.Row objects (which allow dict-style access).
collections.namedtuple provides a much nicer interface than sqlite3.Row for
accessing ordered data which uses valid
Nick Coghlan added the comment:
Bitbucket repo and attached patch updated relative to current tip.
--
Added file:
http://bugs.python.org/file23569/issue11816_get_opinfo_branch_20111031.diff
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nick Coghlan :
Removed file:
http://bugs.python.org/file23197/issue11816_get_opinfo_branch_20110920.diff
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nick Coghlan :
Removed file:
http://bugs.python.org/file23095/issue11816_get_opinfo_branch_20110904.diff
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nick Coghlan :
Removed file:
http://bugs.python.org/file23019/issue11816_get_opinfo_branch_20110824.diff
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file21599/dis.patch
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list mailin
Nick Coghlan added the comment:
Bitbucket repo and attached patch updated relative to latest get_opinfo branch
(which in turn was updated to apply cleanly against current CPython tip).
(I still need to incorporate the doc updates and look into adding keyword
argument support
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file22616/pep380-missing-docs.diff
___
Python tracker
<http://bugs.python.org/issue11682>
___
___
Python-bug
Changes by Nick Coghlan :
Removed file:
http://bugs.python.org/file23096/issue11682_pep380_branch_20110904.diff
___
Python tracker
<http://bugs.python.org/issue11
New submission from Nick Coghlan :
In discussing the module aliasing PEP on python-ideas, it occurred to me that
we could potentially add some useful "sanity check" utilities to an
"importlib.diagnostics" subpackage. For example:
- scan sys.path looking for entries that
New submission from Nick Rowan :
There is a Python script that tries to print a message in Russian language.
It's okay when script runs in console, but it causes DecodeUnicodeError if it
invokes as CGI.
--
components: Interpreter Core, Library (Lib), Unicode
files: Test.py
mes
Nick Coghlan added the comment:
We can just use this one - it was more in the nature of a question "is there
anything we want to change about the status quo?" than a request for any
specific change.
I'm actually OK with buffer API based interoperability, but if we're goin
Nick Coghlan added the comment:
I should probably update that posted recipe to my latest version (which adds
"excluded_files" and "excluded_dirs" parameters).
However, since I've been dealing with remote filesystems where os.listdir() and
os.stat() calls from
Nick Coghlan added the comment:
This needs more thought - pypi package coming soon :)
--
___
Python tracker
<http://bugs.python.org/issue13229>
___
___
Python-bug
Nick Coghlan added the comment:
That's one of the nicer attempts I've seen at an object-oriented path library,
but I have a core problem with OOP path APIs, and it relates to the Unicode
encoding/decoding problem: the ultimate purpose of path objects is almost
always to either pa
Nick Coghlan added the comment:
Initial version available at: https://bitbucket.org/ncoghlan/iterwalk/src
I'll get it published to PyPI once the test suite is in a slightly better state
(no filesystem based tests as yet).
--
___
Python tr
Nick Coghlan added the comment:
Well, that forward port was definitely more complicated than I expected.
Additional reviews of both 3.2 and 3.3 (i.e. default) would be appreciated -
there were quite a few adjustments needed to cope with changes between 2.7 and
3.2 and then additional changes
Nick Coghlan added the comment:
After working on the documentation updates to the subprocess module to
emphasise the convenience functions, I've now changed my mind and think it
makes sense to keep these additions in that module.
Now that the shell helpers will default to using shlex.
Nick Coghlan added the comment:
Éric, to answer your question, with the planned version of the new API, a
"*.py" value interpolated with "{!u}" should indeed pick up all of those files,
since the wildcard will be passed unmodified to the underlying shell, and all
shell
New submission from Nick Coghlan :
The 3-tuple values yielded by os.walk could be made easier to work with in some
use cases by offering a namedtuple style interface (similar to what is done
with sys.float_info).
for dirinfo in os.walk(base_dir):
print(dirinfo.path)
print
Changes by Nick Coghlan :
--
stage: -> needs patch
type: -> feature request
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue13375>
___
__
Nick Coghlan added the comment:
A related idea is updating os.walk tuples to be a custom object offering a
namedtuple style API (similar to sys.float_info).
I created a separate issue for that: #13375
I've also updated the title of this issue to describe the problem it aims to
ad
Nick Coghlan added the comment:
In reviewing Zbyszek's doc updates and comparing them against the Grammar, I
discovered a gratuitous change in the implementation: it allows a bare (i.e. no
parentheses) 'yield from' as an argument to a function, even when there's
mu
Nick Coghlan added the comment:
OK, the bitbucket repo now has a more sane version of the new Grammar ('yield
from' now requires parentheses wherever 'yield' does).
The updated test_grammar does a more thorough check of the expected acceptance
and rejection of yield ex
Nick Coghlan added the comment:
Like any named tuple, the benefits lie in the better repr, and the fact
that if you only want some fields you don't have to unpack the whole tuple.
It's also easier to write variant APIs that add additional fields
accessible on
Nick Coghlan added the comment:
I changed the package name to walkdir:
https://bitbucket.org/ncoghlan/walkdir/overview
--
___
Python tracker
<http://bugs.python.org/issue13
Nick Coghlan added the comment:
Why provide any namedtuple interface in any context? After all, you can just
unpack them to individual variables.
The point is that the values produced by os.walk() *aren't* just an arbitrary
3-tuple - they have a definite API for describing a directory
Nick Coghlan added the comment:
I'm persuaded that there's no major gain to be had in building this in at the
base layer - it's easy enough to add in a higher level API.
--
resolution: -> rejected
status: open -> closed
___
Nick Coghlan added the comment:
Calling this one done - any further adjustments can be handled as new tracker
issues.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
___
Python track
Nick Coghlan added the comment:
doctests by their very nature tend to overspecify things - that's why actual
regression tests should be written with unittest, while doctest is kept for its
originally intended purpose of testing examples included in docstrings and
other documentation.
Nick Coghlan added the comment:
I added some review comments to the patch, but I'm not sure how usable this is
going to be in practice. References generally stay fairly stable while using
the interactive interpreter, but the new block accounting jumps around all over
the place due t
Nick Coghlan added the comment:
And walkdir is now a published package: http://walkdir.readthedocs.org
My plan for this issue now is to maintain walkdir as a standalone package for
2.7 and 3.2, but still add the functionality to shutil for 3.3+.
However, I'll gather feedback on the
Nick Coghlan added the comment:
This will likely be a decent "you have a problem" indicator, but you may still
need tools like Valgrind to actually track down the *cause* of that problem.
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
Similar to what I did with walkdir, I plan to publish a shellcommand module on
PyPI to give people a chance to look at the API and experiment with it without
having to patch shutil in the standard library.
The only aspect I'm 100% sold on at the moment fo
Changes by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue12627>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Please don't stress too much about providing an indication that the repr has
been truncated - it's an error message, not part of the normal program output.
Besides, the lack of a closing ')', ']', '}' or '>&#x
Nick Coghlan added the comment:
While this thread was amusing to read, *changing* Python from the engineering
notation to mathematical notation for imaginary numbers is not going to happen.
'i' has ambiguity problems relative to '1' and 'l' in too many fonts - &
New submission from Nick Coghlan :
I've linked
http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html in
response to enough tracker issues and python-ideas threads now, that I'm
convinced it (or at least something along those lines) belongs in the devguide.
It wou
Nick Coghlan added the comment:
+1 to 'c', but it should come with an update to PEP 8 to say "don't do that".
--
___
Python tracker
<http:
New submission from Nick Coghlan :
Currently, pipes in the subprocess module work strictly with bytes I/O,
*unless* you set "universal newlines=True". In that case, it assumes an output
encoding of UTF-8 for stdout and stderr and applies universal newlines process.
When stdin/o
Nick Coghlan added the comment:
Indeed, I'll add my suggestions over there.
--
assignee: docs@python ->
resolution: -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder: -> subprocess seems to use local 8-bit encoding
Nick Coghlan added the comment:
I discovered this same problem recently when updating the subprocess docs, and
also in working on the improved shell invocation support I am proposing for 3.3
(#13238).
I initially posted an earlier variant this suggestion as a new issue (#13442),
but Victor
Nick Coghlan added the comment:
Hmm, my initial reaction is that that specific wording is stronger than I had
in mind - there's nothing really wrong with having a shebang line and execute
bit set on a top level module and symlinking it from /usr/bin. The problem is
that we're d
Nick Coghlan added the comment:
Documenting the tracker UI itself isn't the big issue - what is useful (and
what I think Ezio is getting at) is having a single place where newcomers can
get a better idea of how we *use* the tracker.
If someone just wants to report a bug, then sure,
Nick Coghlan added the comment:
*Any* expression can be used as a standalone statement and (since PEP 352 was
implemented) that now applies to 'yield' as well.
PEP 352 fundamentally changed the way yield was conceptualised within the
language - thinking of it as "a statement t
Nick Coghlan added the comment:
Hmm, interesting mailing list post - I hadn't thought about how the
auto-initialisation of sys.path[0] aligns with the Windows vs Unix difference
in PATH handling (i.e. whether or not the current directory is considered to be
on PATH), with Python coming
Nick Coghlan added the comment:
Hosting "docs.python.org/devguide/jython" doesn't seem like an unreasonable
idea at all to me, and what's the benefit to CPython in making the Jython team
go to the effort of building out independent deployment and source control
infrastr
Nick Coghlan added the comment:
Meador's suggested name change has grown on me, so I plan to switch the name of
the new API to "get_instructions()" and the new class to "Instruction".
--
assignee: rhettinger -> ncoghlan
_
Changes by Nick Coghlan :
--
versions: -Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue9957>
___
___
Python-bugs-list mailing list
Unsub
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file23773/9512712044a6.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list m
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file23774/0d1d76f68750.diff
___
Python tracker
<http://bugs.python.org/issue11682>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
Yes, but that can be a separate patch - step 1 is to make the attribute
available, then relevant modules can subsequently be updated to use it as
appropriate.
--
___
Python tracker
<http://bugs.python.
New submission from Nick Coghlan :
PEP 395 spends a lot of time discussing ways that the current automatic
initialisation of sys.path[0] can go wrong, and even the proposed improvements
in that PEP don't claim to fix the default behaviour for every possible
scenario (just many of the
Nick Coghlan added the comment:
I created #13475 to discuss the idea of a command line option to override
sys.path[0] initialisation.
--
___
Python tracker
<http://bugs.python.org/issue10
New submission from Nick Coghlan :
unittest autodiscovery is very nice, but a '-x' option to specify directory
patterns *not* to search could be a nice enhancement.
(In my specific case, I want to run most of my tests, but one batch are Django
tests and it would be nice to have an e
Nick Coghlan added the comment:
Yeah, sorry Eric (Snow), you're trying to bite off *way* more than is
reasonable by proposing to removing sys.path[0] auto-initialisation. While it
has its problems, it's also far too entrenched in people's expections of
Python's behaviour
Nick Coghlan added the comment:
Somewhat inevitably, the detailed disassembler tests broke when Antoine updated
the code generation for function definitions (as part of PEP 3155). (At least,
the tests broke, and PEP 3155 seems the most likely culprit).
I subsequently realised there
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file23773/9512712044a6.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bug
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file23773/9512712044a6.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
I have updated my BitBucket repo with the following changes:
- the main API is now dis.get_instructions()
- the info class is now dis.Instruction
- get_instructions() accepts a 'line_offset' argument that is added to any
source code line numbers
- th
Nick Coghlan added the comment:
Zbigniew posted a nice summary of some of the issues sys.path[0]
autoinitialisation can cause to python-dev:
http://mail.python.org/pipermail/python-dev/2011-November/114668.html
--
___
Python tracker
<h
Nick Coghlan added the comment:
I realised "-P" is available for use as the short form of the "suppress
sys.path[0] initialisation" option.
So "-p" would override the calculation of sys.path[0], while "-P" would switch
it off completely (similar t
New submission from Nick Coghlan :
This is a meta-issue for the following blog post:
http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/
There are a bunch of good ideas there that should be split out into a number of
separate bug reports and
Nick Coghlan added the comment:
If you decide to work on one of the problems or feature requests mentioned in
that post:
1. Create a separate, appropriately titled, tracker issue
2. Add that issue to the Dependencies field on this one.
3. Add a comment here to map the point number from the
Nick Coghlan added the comment:
Also add dependencies and links for any already known issues. For example:
#10747 covers point 16) (re. version numbers in Windows shortcuts)
--
dependencies: +Include version info in Windows shortcuts
___
Python
Nick Coghlan added the comment:
Something else such docs could cover is how to manage remote Hg repos such that
the "Create Patch" button does the right thing.
Basically, you need to make sure an appropriate CPython version is found in the
ancestors of the tip your working branc
New submission from Nick Coghlan :
This issue proposes that we adopt and apply some standard practices when
documenting modules that have potential security implications and other
cross-cutting errors that may affect multiple interfaces within the module.
Accordingly, the main target is the
Nick Coghlan added the comment:
While I acknowledge the point (it's the reason I *didn't* remove those warnings
in my recent major update to the subprocess docs), Raymond's right that
scattering warnings everywhere in the docs for modules like subprocess isn't
the right
Nick Coghlan added the comment:
Yep, using notes rather than simple inline links would also be fine with me.
So, with "in-line text" changed to "a ReST note", what do people otherwise
think about the proposed style guide addition?
--
__
Nick Coghlan added the comment:
In Python 3.2 and later, standalone .pyc files are no longer created as a side
effect of import. Instead, cached files are stored in a __pycache__
subdirectory and ignored completely if the corresponding source file is no
longer present. (Standalone .pyc files
Nick Coghlan added the comment:
Indeed, this seems to be the most likely culprit for the current buildbot
failures in the new urllib2 tests:
http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2868/steps/test/logs/stdio
--
resolution: fixed ->
st
Changes by Nick Coghlan :
Removed file:
http://bugs.python.org/file23569/issue11816_get_opinfo_branch_20111031.diff
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nick Coghlan :
--
hgrepos: -17
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file23773/9512712044a6.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bug
Changes by Nick Coghlan :
--
hgrepos: +93
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nick Coghlan :
Added file: http://bugs.python.org/file23848/9512712044a6.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
OK, there's something crazy going on with "Create Patch" failing to pick up the
latest changes. I've removed all the obsolete patches, and am doing another
merge from default to see if I can get it to pick
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file23848/9512712044a6.diff
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bug
Nick Coghlan added the comment:
Grr, "Create Patch" insists on trying to produce a patch based on
https://bitbucket.org/ncoghlan/cpython_sandbox/changesets/9512712044a6.
That checkin is from *September* and ignores all my recent changes :P
Relevant meta-tracker is
Nick Coghlan added the comment:
OK, manual up-to-date patch attached.
--
Added file:
http://bugs.python.org/file23849/issue11816_get_opinfo_branch_20111204.diff
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
@Ron: Now that it has a reasonably clear signature, I could see my way clear to
making the Instruction._disassemble() method public, which makes it easy for
people to compose their own disassembly output.
For all the other display methods, I prefer Ryan
101 - 200 of 6501 matches
Mail list logo
