New submission from Nick Henderson :
In both Python 3.8.3 and 3.9.0b3, using zipfile.Path to write a file in a
context manager results in an attempt to write to the zip file after it is
closed.
In Python 3.9.0b3:
import io
from zipfile import ZipFile, Path
def make_zip():
""
New submission from Nick Gaya :
The documentation for the `async for` statement incorrectly states that "An
asynchronous iterable is able to call asynchronous code in its iter
implementation". Actually, this behavior was deprecated in Python 3.6 and
removed in Python 3.7. As of
Nick Gaya added the comment:
@msg358296:
> IMO, it seems rather counter-intuitive to have to specify
> `concurrent.futures.TimeoutError` when using a timeout for the future
> returned by `run_coroutine_threadsafe()`.
I think that's expected, given that the func
Change by Nick Coghlan :
--
superseder: -> unittest overrides more serious warnings filter added before
unittest.main()
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
Issue #42186 now covers the request to have a way to tell unittest to leave the
warnings filter alone even if it's set programmatically rather than by
modifying ``sys.warnoptions``.
(Changing version to 3.7 to indicate when the interaction with `-bb
Nick Coghlan added the comment:
Closing the old one as partially fixed, and linking here as a superseder makes
sense to me, so I went ahead and did that.
--
___
Python tracker
<https://bugs.python.org/issue42
Nick Coghlan added the comment:
I *think* the lnotab one is the compiler failing to detect that the pointer has
been updated to point inside the body of a Python object, but I'm also not 100%
sure that it's a false alarm.
--
nosy:
New submission from Nick Coghlan :
While working on the PEP 642 reference implementation I removed the "default:"
case from the switch statement in astfold_expr as part of making sure the new
SkippedBinding node was being handled everywhere it needed to be.
This change pick
Change by Nick Coghlan :
--
assignee: -> ncoghlan
___
Python tracker
<https://bugs.python.org/issue42282>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Nick Coghlan :
--
keywords: +patch
pull_requests: +22093
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23190
___
Python tracker
<https://bugs.python.org/issu
Nick Coghlan added the comment:
New changeset 8805a4dad201473599416b2c265802b8885f69b8 by Nick Coghlan in
branch 'master':
bpo-42282: Fold constants inside named expressions (GH-23190)
https://github.com/python/cpython/commit/8805a4dad201473599416b2c265802
Change by Nick Coghlan :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue42282>
___
___
Python-bugs-list
Nick Coghlan added the comment:
Since this was only a performance issue, I'm not planning to backport it to
earlier releases.
--
stage: patch review -> resolved
___
Python tracker
<https://bugs.python.org
Change by Nick Coghlan :
--
nosy: +ncoghlan
___
Python tracker
<https://bugs.python.org/issue42260>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nick Crews :
--
nosy: +NickCrews
nosy_count: 5.0 -> 6.0
pull_requests: +22316
pull_request: https://github.com/python/cpython/pull/23424
___
Python tracker
<https://bugs.python.org/issu
Nick Crews added the comment:
I re-did this at https://github.com/python/cpython/pull/23424, let me know what
you think. This is my first PR here, so I may have pooched something.
--
___
Python tracker
<https://bugs.python.org/issue15
Nick Coghlan added the comment:
Committed for 3.3: http://hg.python.org/cpython/rev/d64ac9ab4cd0
Thanks to Greg for the initial effort on the PEP and reference implementation
and to all involved in updating the original patch for 3.3 and getting the
tests and documentation to an acceptable
New submission from Nick Coghlan :
Georg noted that the PEP 380 patch added a couple of new C interfaces without
documenting them. These interfaces need to be either:
1. Documented;
2. Made private; or
3. Removed (if they're completely trivial)
PyGen_FetchStopIterationValue: probably doc
Nick Coghlan added the comment:
The current use of PyStopIteration_Create in genobject.c can probably be
replaced with PyErr_SetObject(PyExc_StopIteration, value) anyway.
--
___
Python tracker
<http://bugs.python.org/issue13
Nick Coghlan added the comment:
Also check any GetAttr and CallMethod operations to see if they should be moved
over to the new *Id variants.
--
___
Python tracker
<http://bugs.python.org/issue13
New submission from Nick Coghlan :
Currently, there's no straightforward way to create new classes in Python that
delegate the PEP 3118 buffer APIs to another object that supports them (e.g.
bytes, bytearray, memoryview, array.array, a NumPy array).
I see a few possible ways to go about
Changes by Nick Coghlan :
--
dependencies: +Problems with Py_buffer management in memoryobject.c (and
elsewhere?)
title: Add a __buffer__ special method to retrieve a PEP 3118 object -> Add a
Python level special method to retrieve a PEP 3118 obj
Changes by Nick Coghlan :
--
title: Add a Python level special method to retrieve a PEP 3118 object -> Allow
objects implemented in pure Python to export PEP 3118 buffers
___
Python tracker
<http://bugs.python.org/issu
Nick Coghlan added the comment:
Reviewing Stefan's work on #10181 suggests to me that option 3 is the only
feasible approach.
(Allowing memoryview subclasses will permit types to pass their own state
between __getbuffer__ and __releasebuf
Nick Coghlan added the comment:
Added 10181 as a dependency - as noted in my review comments on that issue, I
think this becomes fairly trivial to fix (and test) given Stefan's other
improvements.
--
dependencies: +Problems with Py_buffer management in memoryobject.c (and
else
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
Changes by Nick Wilson :
--
nosy: +njwilson
___
Python tracker
<http://bugs.python.org/issue13463>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
1501 - 1600 of 6501 matches
Mail list logo
