Nick Coghlan added the comment:
Finally reviewed Stefan's latest patch. It mostly looks great to me. Aside from
a few minor cosmetic quibbles, the only substantive change I would like is to
expose the Py_buffer len field as "memoryview.size" instead of "memoryview.len&qu
Nick Coghlan added the comment:
Mark, please stop discussing per-run parameters in this issue. Those are NOT
the kind of parameters we're talking about (and are easily handled via a global
settings module, anyway, the exact same way you can handle process global
settings for *any* ki
Nick Coghlan added the comment:
Back on topic...
While I can see the advantage of parameterisation at the level of individual
tests, I'm not at all clear on the benefits at the TestCase level.
For CPython's own test suite, if we want to share tests amongst multiple test
cases, w
Nick Coghlan added the comment:
I agree with David, so switching this over to a docs enhancement request.
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
title: Support parameterized TestCases in unittest -> Add example of using
load_tests to parame
Nick Coghlan added the comment:
"nbytes" sounds reasonable to me, given the unfortunate ambiguity of both size
and len.
As far as #12834 goes, I'm happy to go along with whatever you think is best.
You've spent a lot more time down in the guts of the implementation t
Nick Coghlan added the comment:
Err, make that #12384 (oops)
--
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list mailing list
Unsub
Changes by Nick Coghlan :
--
Removed message: http://bugs.python.org/msg151539
___
Python tracker
<http://bugs.python.org/issue10181>
___
___
Python-bugs-list m
Nick Coghlan added the comment:
Generators deliberately don't support the context management protocol. This is
so that they raise an explicit TypeError or AttributeError (pointing out that
__exit__ is missing) if you leave out the @contextmanager decorator when you're
using a ge
Nick Coghlan added the comment:
Éric, are you still planning to work on this? Otherwise I'll make a first pass
at doing the split into 3 sections (as per my earlier comment) and implementing
some of Terry's suggestions.
Linked Hg repo is a 2.7 based feature branch where I'll b
New submission from Nick Coghlan :
With the current argparse docs, it's very hard to get a quick reminder of how
to spell the various parameters for add_argument, and just what they do. This
issue suggests adding a "Quick Reference" section for add_argument, with the
followi
Nick Coghlan added the comment:
Looking at the docs, a 4th table in the quick reference section would be
useful: the parameters for ArgumentParser itself.
Note that the ArgumentParser and add_arguments() parameters are already
summarised in their respective entries, but there are currently
Nick Coghlan added the comment:
My specific suggestion is to have a dedicated "Quick Reference" section before
the first example.
This section would be aimed at two groups of people:
- those wanting a quick overview of the features argparse offers them ("This
looks complicat
Nick Coghlan added the comment:
I realised that the lack of a clear binary/text distinction would make it messy
to do the split docs in 2.7, so I made a new branch based on 3.2 instead (link
to repo updated accordingly).
--
assignee: eric.araujo -> ncogh
Nick Coghlan added the comment:
Pushed an initial cut to my sandbox branch. Built HTML is attached so you can
get a general idea of how it looks (links, etc, obviously won't work).
So far, I have made the split into 3 sections and updated the new (shorter)
Sequence Types section.
Nick Coghlan added the comment:
Note: without the Python docs CSS to create the sidebar, the internal table of
contents appears at the *bottom* of the rendered page.
Really, reviewing this sensibly is probably going to require building the docs
locally after using hg pull to retrieve the
Nick Coghlan added the comment:
Having a second table of "Applicable Parameters" could definitely work. I don't
think the "no horizontal headers" limitation should be a big problem - the
matrix should be readable even if the action names are just list
New submission from Nick Coghlan :
As far I am aware, the simplest way to indent a multi-line string is with the
following snippet:
'\n'.join((4 * ' ') + x for x in s.splitlines())
It would be a lot simpler and clearer if I could just write that as
"textwrap.i
Nick Coghlan added the comment:
David Miller pointed out a shorter spelling:
s.replace('\n', '\n' + (4 * ' '))
Still not particularly obvious to the reader (or writer), though.
--
___
Python tracker
<
Nick Coghlan added the comment:
I'd actually suggest that as the default behaviour (and is a good argument in
favour of a dedicated function in textwrap - both suggested alternatives will
blithely add whitespace to otherwise empty lines).
To handle the empty line requires either switchi
Nick Coghlan added the comment:
1. Any syntax change requires a PEP (and, IMO, any such PEP for this issue
should get rejected: I don't consider this an important enough feature to
deserve dedicated syntax. Others disagree, which is one of the reasons why a
PEP is needed. The other,
Nick Coghlan added the comment:
Just noting that the pep380 integration branch is also available in the
hg.python.org clone of my sandbox repo.
--
hgrepos: +107
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
Aside from some minor comments that I included in my review, the latest patch
gets a +1 from me.
--
___
Python tracker
<http://bugs.python.org/issue10
Nick Coghlan added the comment:
Antoine's review picked up on several issues I missed or glossed over - I
actually agree with his point about making most of the new APIs private rather
than public.
With regards to exposing _testbuffer in the documentation of memoryview's has
Nick Coghlan added the comment:
Branch status update:
- Text Sequence Types section updated to reflect the new structure
- changed the prose that describes the relationship between printf-style
formatting and the str.format method (deliberately removing the implication
that the former is any
Nick Coghlan added the comment:
One other things the branch doesn't currently sort out is the official
signature of count() and index().
In 3.2, for *all* of str, bytes, bytearray, tuple, list, range, the index()
method takes the optional start:stop parameters.
collections.Sequence.
Nick Coghlan added the comment:
Yeah, the basic layout of this entire section has been in place for a *long*
time
(http://docs.python.org/release/1.4/lib/node4.html#SECTION0031)
Some aspects haven't really aged all that well, as people have made minimalist
chang
Nick Coghlan added the comment:
Radical suggestion: make it public as collections.simple_ndarray?
(prefixing with simple_ to be explicit that this is not even *close* to being
the all-singing, all-dancing NumPy.ndarray)
--
___
Python tracker
Nick Coghlan added the comment:
One other point... the branch is actually now relative to default, not 3.2.
While that was due to a merging mistake on my part, it also means I can
legitimately ignore the narrow/wide build distinction in the section on strings
Nick Coghlan added the comment:
I finished off the binary data section, so the first draft of the update is now
complete in the bitbucket repo.
--
___
Python tracker
<http://bugs.python.org/issue4
Nick Coghlan added the comment:
I'm with Antoine here - we want to be *very* conservative with what we expose
through the limited API. Due to the ABI compatibility promise, anything exposed
that way is very hard to change.
Keeping things out of the limited API isn't really an issue
Nick Coghlan added the comment:
The division of responsibilities between generator objects and the eval loop is
currently a little messy. The eval loop deals almost entirely with frame
objects and also handles swapping exception states around on behalf of
generators, which is why the
Nick Coghlan added the comment:
Also, +1 to replacing _testbuffer with .cast() to demonstrate the
multi-dimensional support. Without an actual multi-dimensional array object in
the standard library, demonstrating those aspects is always going to be a
little tricky. However, it's worth
Nick Coghlan added the comment:
As part of the PEP 408 discussions, Guido approved the addition of 'regex' in
3.3 (using that name, rather than as a drop-in replacement for re) [1,2]
That should greatly ease the backwards compatibility concerns, even if it isn't
as transpa
Nick Coghlan added the comment:
Alex has a valid point in relation to PEP 399, since, like lzma, regex will be
coming in under the "special permission" clause that allows the addition of C
extension modules without pure Python equivalents. Unlike lzma, though, the new
regex engi
Nick Coghlan added the comment:
Ah, nice idea of bringing the boolean constants into the mix so we don't need
to invent a new sentinel value.
However, to preserve the current behaviour that "raise X from Y" is essentially
just syntactic sugar for: "_var = X; _var.__caus
Nick Coghlan added the comment:
Trying to make this change in 2.7 would actually be a bit of a nightmare - how
do you cleanly split documentation of the binary data and text processing
sequence types when "str" is used for both?
The change would be *mostly* feasible in 3.2 (th
Nick Coghlan added the comment:
This was discussed a little more in the python-dev thread for PEP 409, but both
Guido and I have been burned in the past by badly written libraries that
replaced detailed exceptions that explained *exactly* what was going wrong with
bland, generic "it
Nick Coghlan added the comment:
Good point, without doing the split in both, any doc merges in this section
will be a nightmare. OK, with the caveat that the initial 3.2 version may gloss
over some issues that no longer apply in 3.3 (specifically the narrow/wide
split), I'll make
Nick Coghlan added the comment:
Please go ahead!
And Georg is right - the short spelling doesn't handle the first line
correctly. It also suffers from the "trailing whitespace" problem that Amaury
pointed out in my original version.
The tests for the new function should c
Nick Coghlan added the comment:
It sounds like you may want runpy.run_module [1], rather than using imports at
all. If you know how many levels up you want to go, it isn't hard to do your
own munging of __name__ to create absolute module references to pass to runpy.
The signatu
Nick Coghlan added the comment:
Hmm, given the various *at() APIs that sort alphabetically next to their path
based counterparts, perhaps we can make the naming consistency change go the
other way? (i.e. listdirfd() and walkfd()). Even if POSIX puts the fd at the
front, do we really have to
Nick Coghlan added the comment:
Taking a closer look at the current naming scheme in the os module, fdopen()
appears to be the only current function that uses the 'fd' prefix. All the
other operations that accept a file descriptor just use 'f' as the prefix
(fchmod,
Nick Coghlan added the comment:
With the release of 0.3, I'm pretty happy with the WalkDir design (previous
versions coerced the output values to ordinary 3-tuples, now it will pass along
whatever the underlying iterable produces with changing the type a
Nick Coghlan added the comment:
I'm also a fan of using the simpler approach unless/until we have solid
evidence that the file descriptor limit could be a problem in practice.
A comment in the code mentioning the concern, along with the fact that there's
an alternate algorithm a
Nick Coghlan added the comment:
This behaviour came up recently when implementing os.fwalk() [1]. There are
problems with all 3 possible approaches (list as dirs, list as files, don't
list at all) when followlinks is False. Since all alternatives are potentially
surprising, the cu
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue6210>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
I started work on integrating this into 3.3 this evening, but ran into too many
issues to finish it.
Problems found and fixed:
- traceback.py displayed the wrong exception (test added and impl fixed)
Additional changes:
- eliminated duplicate code paths for
Nick Coghlan added the comment:
I believe Charles-François was referring to this message:
http://mail.python.org/pipermail/python-dev/2012-January/115372.html
We shouldn't be encumbering threading *all the time* with stuff that "might be
useful sometimes". Adding selective
Nick Coghlan added the comment:
I'm inclined to close this as a functional duplicate of
http://bugs.python.org/issue13229
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
A fair point indeed.
To follow the shutil naming convention (rmtree, copytree, and likely chmodtree,
chowntree), a more appropriate name might be "globtree". (Thanks to string
methods, the 'r' prefix doesn't read correctly to me: what
Nick Coghlan added the comment:
I can live with it either way - I just wanted to point out that our current
examples of this kind of recursive filesystem access use a 'tree' suffix rather
than an 'r' prefix.
--
___
P
Nick Coghlan added the comment:
I think it's important to be clear on what the walkdir API aims to be: a
composable toolkit of utilities for directory tree processing. It's overall
design is inspired directly by the itertools module.
Yes, it started life as a simple propo
Nick Coghlan added the comment:
We do have the option of aliasing glob.iglob as shutil.glob...
--
___
Python tracker
<http://bugs.python.org/issue13968>
___
___
Nick Coghlan added the comment:
This discussion (particularly my final globtree recipe) made me realise that
the exact same approach would greatly improve the usability of the all_paths,
file_paths and dir_paths iterators in walkdir [1]. Accordingly, walkdir 0.4
will let you write a
Nick Coghlan added the comment:
Given the complexities proposed for the dir matching, I'm shifting back to a
solid -1 on this. Trying to match multi-part directories with globs is a
nightmare and I currently don't allow it at all in walkdir. Instead, dir
filtering and file fil
Nick Coghlan added the comment:
FWIW, it's likely I'll be adding contextlib.ContextStack (see [1]) for 3.3.
While it's far from the primary use case, that API also serves as a "no-op"
context manager (if you never register any contexts or callbacks, the __exit__
New submission from Nick Coghlan :
(This proposes a new builtin, so may need to become a PEP)
A common programming task is "I want to process this text file, I know it's in
an ASCII compatible encoding, I don't know which one specifically, but I'm only
manipulating t
Nick Coghlan added the comment:
No point to adding a new keyword arg - if people are going to do something like
that, they may as well learn to use "errors" and "encoding" properly.
Adding open_ascii() would be an acknowledgement that "basically ASCII, but
maybe wi
Nick Coghlan added the comment:
Pondering it further (and reading subsequent comments here and in the thread),
I agree an open_ascii() builtin would be a step backwards, not forwards.
So, morphing this issue into a documentation one to work out:
- the bare minimum we think Python 3 users
Changes by Nick Coghlan :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
title: Add open_ascii() builtin -> Clearly explain the bare minimum Python 3
users should know about Unicode
versions: +Python 3.2, Pyth
Nick Coghlan added the comment:
Just noting that this has slipped a bit down my Python to-do list (there are
other things I want to focus on before the first 3.3 alpha).
I'll get back to it at some point, but if someone want to take my branch and
run with it in the meantime, please feel
Changes by Nick Coghlan :
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/issue12627>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
Usually because the file may contain certain ASCII markers (or you're inserting
such markers), but beyond that, you only care that it's in a consistent ASCII
compatible encoding.
Parsing log files from sources that aren't set up correctly o
Nick Coghlan added the comment:
If such use cases are indeed better handled as bytes, then that's what should
be documented. However, there are some text processing assumptions that no
longer hold when using bytes instead of strings (such as "x[0:1] == x[0]"). You
also can
Nick Coghlan added the comment:
WalkDir attempts to handle symlink loops, but the test suite doesn't currently
ensure that that handling works as expected (I did some initial manual tests
and haven't updated it since, though).
It's... not trivial:
https://bitbucket.org/ncogh
Nick Coghlan added the comment:
It's still on my radar to come back and have a look at it. Feedback from the
web folks doing Python 3 migrations is that it would have helped them in quite
a few cases.
I want to get a couple of other open PEPs out of the way first, though (mainly
394 an
New submission from Nick Coghlan :
io.TextIOWrapper acquired a new "write_through" argument for 3.3, but that is
not exposed as a documented attribute.
This is needed so that a text wrapper can be replaced with an equivalent that
only alters selected settings (such as the Uni
Nick Coghlan added the comment:
Updating issue title, since I realised this doesn't work in 3.2 either (the
"newline" argument also isn't available for introspection - "newlines" is not
the same thing)
Possible API signature:
_missing = object()
def
New submission from Nick Coghlan :
A couple of issues have arisen where features were added to str.format without
similarly being added to string.Formatter.
This is only possible because the test cases for the two are currently almost
entirely separate.
A common set of tests defined as (fmt
Nick Coghlan added the comment:
Agreed that this is a bug in string.Formatter rather than a new feature.
There's already a separate bug for the autonumbering problem:
http://bugs.python.org/issue13598
And I created a new issue about unifying some of the tests:
http://bugs.pytho
Nick Coghlan added the comment:
One potential problem with the simple approach to fixing this is that up until
now, string.Formatter has been thread safe. Because all the formatting state
was held in local variables and passed around as method arguments, there was no
state on the instance
New submission from Nick Coghlan :
Currently, test_cmd_line_script only checks sys.argv[0] is set correctly.
It should pass some extra values after the script name, then include an
appropriate check in the output of the launched script.
--
components: Tests
keywords: easy
messages
Nick Coghlan added the comment:
I just remembered that many of the urllib.urlparse tests are guilty of only
reporting the first case that fails, instead of testing everything and
reporting all failures:
http://hg.python.org/cpython/file/default/Lib/test/test_urlparse.py
IMO, it would make a
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file22738/version33_links.patch
___
Python tracker
<http://bugs.python.org/issue12627>
___
___
Python-bug
Nick Coghlan added the comment:
I removed the 3.3 patch, since all the previous version did was change symbolic
links to hard links, and the latest round of discussions favoured retaining the
symlinks since they're much easier to introspect.
However, it turns out there is still one c
Nick Coghlan added the comment:
Actually, the Python 3 Makefile.pre.in is currently broken if $(EXE) is ever
non-empty - in a few places it uses "$(PYTHON)$(VERSION)$(EXE)" and
"$(PYTHON)3$(EXE)".
Those are wrong, because the definition of $(PYTHON) at the top of the f
Nick Coghlan added the comment:
New patch that aims to create the appropriate symlinks in "make bininstall". I
don't currently have a sacrificial VM set up to test it in though.
--
Added file: http://bugs.python.org/file24530/pep394_python2
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file22737/version27_links.patch
___
Python tracker
<http://bugs.python.org/issue12627>
___
___
Python-bug
New submission from Nick Coghlan :
I've just started using the argparse subparser feature, and it's very nice.
However, I'd love to be able to group the different subparser commands into
different sections the way I can group ordinary arguments with
add_argument_group().
Init
New submission from Nick Coghlan :
Currently, using add_subparsers() means that the entire list of subcommands is
added to the main usage message. This gets rather unwieldy when there are a lot
of subcommands.
It would be nice if the add_subparsers() method accepted a "metavar" argu
Nick Coghlan added the comment:
I realised that my initial idea doesn't play nicely with my other suggestion of
allowing a "metavar" argument to add_subparsers() (see #14039).
A better model may be to mimic the add_argument_group() directly by offering an
add_parser_group(
Nick Coghlan added the comment:
Keeping module references implicitly in import_fresh_module will leak
references like crazy in the test suite. The onus is on the code referencing
module contents to ensure that the module globals remain valid.
If we get rid of the explicit clearing of module
Nick Coghlan added the comment:
In #14035, Florent pointed out the current behaviour potentially causes
problems for some uses of import_fresh_modules() in the test suite (with
globals sometimes being set to None if there's no indepenent reference to the
module).
GC based module cl
Nick Coghlan added the comment:
In the case of *dependencies* that get refreshed, no they're *not* kept in
sys.modules - they get overwritten by the originals when the sys.modules state
gets restored.
The problem almost certainly arises because something, somewhere is doing "from
Nick Coghlan added the comment:
No automatic link, since I neglected to mention the issue number in the checkin
messages:
2.7: http://hg.python.org/cpython/rev/a65a71aa9436
3.3: http://hg.python.org/cpython/rev/dc721f28f168
I deliberately *didn't* make the change in 3.2. As the choi
Nick Coghlan added the comment:
Could you provide some failing examples?
The suggestion also seems to run slightly at odds with itself - in one part,
silently replacing an invalid port specification with a different value, in
another adding additional validation checks.
Also, rather than
Nick Coghlan added the comment:
For the purposes of this test (i.e. running the same script several different
ways and making sure it always behaves as expected), I wouldn't even worry
about making it configurable.
Just define a list of example args as a module global, append them t
Nick Coghlan added the comment:
Also, since this issue was last updated, Antoine devised a scheme to test some
of the embedding functionality (mainly to test subinterpreters, IIRC). Perhaps
that could be harnessed to check GC-based shutdown is working correctly (it
might even do it already
Nick Coghlan added the comment:
The other thing that came out of the rambling Unicode thread on python-ideas is
that we should clearly articulate the options for processing files in a
task-based fashion and describe the trade-offs for the different alternatives.
I started writing up my notes
Nick Coghlan added the comment:
On Sat, Feb 18, 2012 at 10:10 PM, Francisco Martín Brugué
wrote:
> ./python ./Tools/scripts/patchcheck.py
> Getting the list of files that have been added/changed ... 0 files
> Fixing whitespace ... 0 files
> Fixing C file whitespace ... 0 files
&
Nick Coghlan added the comment:
The second instance is inside the source code string that's written out as the
script to be run in the subprocess. Not a bad idea actually:
- it avoids writing the example args twice (which is what I was thinking of
doing)
- it avoids turning the test_s
Nick Coghlan added the comment:
Purging __file__ of relative references isn't a problem - they're *supposed* to
always be absolute. The import.c version just stuffs it up sometimes (mainly
due to the way it handles the empty string in the path).
IOW, while the importlib beh
Nick Coghlan added the comment:
Just noticed one minor nit with the patch: the pure Python version of
functools.partial should support "func" as a keyword argument that is passed to
the underlying object. The trick is to declare a positional only argument like
this:
def f(*ar
Nick Coghlan added the comment:
Also, the closure based implementation should be decorated with @staticmethod
(see http://bugs.python.org/issue11704) and the tests updated accordingly.
--
___
Python tracker
<http://bugs.python.org/issue12
Nick Coghlan added the comment:
FWIW, I doubt you'd get many objections if you ended up wanting to make time a
builtin module and inject it into the bootstrapping namespace.
While I don't think the delay in noticing filesystem changes is reasonable as
the default behaviour, i
Nick Coghlan added the comment:
Latest version looks good to me - I vote for landing it whenever you're ready :)
--
___
Python tracker
<http://bugs.python.org/is
New submission from Nick Coghlan :
Currently, setting maxsplit for the default "any whitespace" behaviour requires
the following cryptic incantation:
'do re mi fa'.split(None, 1)
That would be significantly more comprehensible as:
'do re mi fa'.split(max
New submission from Nick Coghlan :
Currently, datetime.timezone requires that the offset be specified explicitly.
It would be more convenient if the local offset was used by default.
Since the time module already exposes the offset details for the local
timezone, this would just make
Nick Coghlan added the comment:
Marking as a duplicate of #9527.
If that API is added, the local fixed offset timezone will be accessible as
datetime.datetime.localtime().tzinfo which would be simple enough.
--
resolution: -> duplicate
superseder: -> Add aware local time supp
Changes by Nick Coghlan :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14083>
___
___
Python-bugs-list mailing list
Unsubscri
1401 - 1500 of 6301 matches
Mail list logo
