Nick Coghlan added the comment:
I think I spotted a logic bug in _not_op_and_not_eq (it uses "or" instead
of "and" in the final line) , so I suspect we still have a missing test
case in the latest patch. (My fault - I should have suggested using
coverage.py to ensure a
Nick Coghlan added the comment:
Brett's plan sounds good to me. We should also check we make sure
__main__.__file__ is always absolute.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
Agreed.
I had actually assumed this would be 3.4 only, otherwise I wouldn't have
suggested using the new subtest feature in the test case.
--
___
Python tracker
<http://bugs.python.org/is
New submission from Nick Coghlan:
The docs from PyDict_Update
(http://docs.python.org/3/c-api/dict.html#PyDict_Update) claim it is equivalent
to the Python level dict.update
(http://docs.python.org/3/library/stdtypes#dict.update)
This isn't accurate - unlike dict.update, PyDict_U
Nick Coghlan added the comment:
Thanks Katie - Raymond, the patch is ready for review now
If you're happy with it, then the only other things it should need prior to
commit are NEWS and ACKS entries (I think it's too esoteric a fix to mention in
What's New).
--
sta
Nick Coghlan added the comment:
I decided I can live with the risk of this biting someone in 3.3 - the
combination of using multiple levels of wrapping *and* using __wrapped__ for
more than merely introspection seems remote enough to make being conservative
with the behavioural change the
Nick Coghlan added the comment:
Added a version that allows the iteration to be terminated early if certain
criteria are met, which is needed for a robust implementation of
inspect.signature.
However, I'm thinking the callback based approach in this version isn't
especially Python
Nick Coghlan added the comment:
I liked Ron's suggestion of using it to improve the output of help() (by
getting access to the docstrings of the operator functions, and then enhancing
those to be a bit more informative)
--
___
Python tracker
New submission from Nick Coghlan:
A home for a couple of proposed PEP 8 updates (as per the thread starting at
http://mail.python.org/pipermail/python-dev/2013-July/127284.html)
--
messages: 193159
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: PEP 8 updates
Nick Coghlan added the comment:
Attached diff has 5 changes:
* Explicit note that this is a living document that evolves over time
* Adds another explicit reason for not complying with the style guide (i.e. the
code is old but still works and there's no other reason to change it)
*
Nick Coghlan added the comment:
Thomas Wouters made a couple of good points regarding absolute vs explicit
relative imports, so I've improved the rationale in the PEP accordingly.
--
Added file: http://bugs.python.org/file30937/issue18472_pep_8_update2
Nick Coghlan added the comment:
Tweaked the wording in the introduction to cover removal of obsolete
conventions along with adding new ones.
--
Added file: http://bugs.python.org/file30938/issue18472_pep_8_update3.diff
___
Python tracker
<h
Nick Coghlan added the comment:
Sure, I think it makes sense to put that in. I'll be running the whole
patch by python-dev, enumerating the reasons for each change before I
commit anything.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
For dis, we introduced a new rich bytecode introspection API. Ditto for
inspect.Signature. I think it makes sense to treat this as a completely new
traceback introspection API and ignore the low level details of the legacy
API
Nick Coghlan added the comment:
+1 for io as an intuitive home for a basic version that redirects the
current process output only (and is documented as doing so). While I
like the idea of offering a more sophisticated version that affects
subprocesses as well, I think that would be a very
Nick Coghlan added the comment:
A good start, but:
1. io is too low level to depend on unittest (or even contextlib), as
anything it imports will be imported automatically at interpreter startup.
The context manager will need to be written out directly as a class with
the appropriate methods
Nick Coghlan added the comment:
As Raymond noted, we should resist the temptation to generalise this too much -
generalisation almost always comes at the cost of making any *specific* case
harder (consider the difference between the complexity of the "support any URL
scheme" model
Nick Coghlan added the comment:
And reviewing my own draft - the convenience functions would need docstrings
too, and the docstrings should mention that a new StringIO instance is created
by default and that "as name" can be used to get access to t
Nick Coghlan added the comment:
OK, Raymond and I had a chat on IRC about this, and I've come back around to
the idea that the simple "contextlib.redirect_stdout" model as Raymond
originally proposed is the way to go. There are a few pieces to that rationale:
1. Why in cont
Nick Coghlan added the comment:
Yeah, the docs will need to note that it isn't thread safe. However, non
thread-safe constructs are often still incredibly useful for scripting use
cases.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
I'd prefer to keep the separate stream argument rather than duplicating the
signature of open. Separation of concerns and all that :)
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
Alexander, please read the earlier comments on the issue: we're deliberately
*not* doing that. Such functionality is more advanced, and more appropriate for
an API in the subprocess module. Anyone interested in exploring that option
further should cre
New submission from Nick Coghlan:
Currently, if a byte sequence is passed to open() as the file name, the
resulting file will have that object as its name:
>>> open(os.path.expanduser(b"~/.hgrc"))
<_io.TextIOWrapper name=b'/home/ncoghlan/.hgrc' mod
Nick Coghlan added the comment:
Can we go paint bikesheds somewhere else now, please? Raymond has persuaded me
as contextlib maintainer that this small addition is worth making as a way of
factoring out repeated calls to print with a file redirection in simple user
scripts where thread safety
Nick Coghlan added the comment:
Ouch, that complicates matters :(
It also occurs to me that given the existence of the "opener" callback,
name could be just about any type :P
--
___
Python tracker
<http://bugs.python.o
Nick Coghlan added the comment:
Just noting for the record (since it appears it was never brought back to the
comments): it is expected that programs that manipulate the AST may require
updates before they will work on a new version of Python. Preserving AST
backwards compatbility is too
Nick Coghlan added the comment:
(That was the outcome of the suggested AST discussions on python-dev that were
mentioned earlier)
--
___
Python tracker
<http://bugs.python.org/issue11
Nick Coghlan added the comment:
Switching this to a docs bugs, since
http://docs.python.org/3/library/functions.html#open doesn't mention this
behaviour at all, and http://docs.python.org/3/library/io.html#io.FileIO.name
only notes the fact it may be a file descriptor without mentionin
Changes by Nick Coghlan :
--
assignee: -> ncoghlan
title: PEP 8 updates - internal interfaces and import * -> Update PEP 8 to
encourage modern conventions
___
Python tracker
<http://bugs.python.org/i
Nick Coghlan added the comment:
Latest version is a more general cleanup patch for PEP 8 (hence the change in
the issue title). Enumerating all the changes/additions:
1. Added an intro paragraph that makes it clear this is a living document, not
"set and forget".
2. Added a c
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file30938/issue18472_pep_8_update3.diff
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Pytho
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file30937/issue18472_pep_8_update2.diff
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Pytho
Changes by Nick Coghlan :
Removed file: http://bugs.python.org/file30936/issue18472_pep_8_update.diff
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Pytho
Nick Coghlan added the comment:
Guido, if you have time to review these proposed PEP 8 changes, that would be
great. Most should be unobjectionable, but I seem to recall you disliking the
recommendation for third party function annotation experiments to use an
explicit decorator, so I'm
Changes by Nick Coghlan :
--
nosy: +gvanrossum
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
The exception one is near-and-dear to my heart at the moment, as we're in
the process of refactoring a large app that currently does various checks
in the UI layer so it can present nice errors, when it should really be
leaving those checks to the business
New submission from Nick Coghlan:
tests.script_helper provides various utilities for sensibly testing scripts in
a subprocess. It isn't easy for CPython developers to discover, since it is
isn't documented and the file is mixed in with actual tests in the main test
directory.
As di
New submission from Nick Coghlan:
test.bytecode_helper provides various utilities for sensibly testing bytecode
generation. It isn't easy for CPython developers to discover, since it isn't
documented and the file is mixed in with actual tests in the main test
directory.
As di
Nick Coghlan added the comment:
As noted in #18576 and #18578, I'd like for these relocation patches to include
the addition of documentation for the submodule in Doc/library/test.rst
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
Also, now that test.support is a subpackage, the helper should be a submodule
of that (test.support.package_helper) rather than directly in the test
directory.
--
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
test.support is now a subpackage in both 3.3 and default, but
test.support.package_helper still needs to be created (see comments on #15403)
--
versions: +Python 3.4
___
Python tracker
<http://bugs.python.
Changes by Nick Coghlan :
--
assignee: ncoghlan ->
___
Python tracker
<http://bugs.python.org/issue18578>
___
___
Python-bugs-list mailing list
Unsubscri
Nick Coghlan added the comment:
"with statements are good", basically.
--
___
Python tracker
<http://bugs.python.org/issue18472>
___
___
Python-bugs-l
Nick Coghlan added the comment:
I did see the Windows buildbot failure, but stopped scanning the log once I saw
the intermittent test_signal failure :P
With the more granular API, test_startfile is a better fit for
support.change_cwd, so we'll see how that goes on the Windows buil
Nick Coghlan added the comment:
No dice:
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/2399/steps/test/logs/stdio
Could someone with a Windows build set up try this out?
I'd like to rule out a conflict with the -j setting, since being dependent on
the cu
Nick Coghlan added the comment:
Is it possible this is indicating a real bug with faulthandler on Windows? Why
are we returning None from signal.getsignal?
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue18
Nick Coghlan added the comment:
While there are some remaining buildbot failures, they don't appear to be
related to this issue any more.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.
Nick Coghlan added the comment:
Changes in version 5:
- added a new reference pointing back to this tracker issue. I figure that's a
good precedent to set for future updates.
- I liked Barry's point about "Don't break backwards compatility" enough that I
moved it int
Nick Coghlan added the comment:
For the record, the thread where Thomas Wouters provided the feedback that led
to the current wording regarding imports:
http://mail.python.org/pipermail/python-dev/2013-July/127373.html
--
___
Python tracker
<h
Changes by Nick Coghlan :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nick Coghlan added the comment:
Heh, I just realised a correct generator definition would have needed the
loop-and-a-half internally anyway:
def itervalues(x):
while True:
value = x.getvalue()
if not value:
break
yield value
Nick Coghlan added the comment:
PEP 8 now covers the developer side of things:
http://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces
A user facing counterpart describing our backwards compatibility policy is
still desirable. Updating PEP 5 wouldn't go astray, since t
New submission from Nick Coghlan:
"python -m inspect " doesn't currently do anything.
It would be handy if this:
python -m inspect site
Was roughly equivalent to:
python -c "import inspect, site; print(inspect.getsource(site))"
Even better would be if
Nick Coghlan added the comment:
I like the new wording, but was there a missing "hg push" here? (Not seeing
the update on hg.python.org/peps)
--
___
Python tracker
<http://bugs.python.o
Changes by Nick Coghlan :
--
assignee: docs@python -> ncoghlan
___
Python tracker
<http://bugs.python.org/issue18628>
___
___
Python-bugs-list mailing list
Un
Nick Coghlan added the comment:
I applied Guido's update in http://hg.python.org/peps/rev/82e24ac40255
I'm not sure what happened with Guido's "Patch applied" above, but I wanted to
include Terry's encoding fixes from #18628, so I figured it made sense to
Nick Coghlan added the comment:
I changed the section heading in PEP 8 to "Source File Encoding" and the sole
remaining use of "a coding cookie" to "an encoding declaration". No link, since
it would need separate links for Python 2 and 3, and that just gets m
Nick Coghlan added the comment:
Yep, sounds good to me ("don't wait for PEP 432" is what I meant to imply
above, but I wasn't very clear about it)
--
___
Python tracker
<http://bug
Nick Coghlan added the comment:
I checked the getsignal docs, and indeed None is the expected return value for
"signal handler exists, but was not installed from Python". That's accurate
given the way faulthandler works:
On Linux (Python 3.3.0):
$ python3 -c "
Nick Coghlan added the comment:
I added one slight tweak to Jeremy's patch - an assertion to ensure that test
loop is checking at least some* signals, even when faulthandler is enabled.
--
___
Python tracker
<http://bugs.python.org/is
Nick Coghlan added the comment:
It occurs to me that operator.index() (without a preceding type check) is
likely the more ducktyping friendly option here.
--
___
Python tracker
<http://bugs.python.org/issue18
Nick Coghlan added the comment:
The two "isinstance" checks that bother me are the ones for int and float.
However, given that the JSON serialiser *already* includes those explicit
checks, I now think it makes sense to just do the minimal fix of coercing
subclasses to the base typ
Nick Coghlan added the comment:
It's a direct counterpart to any() and all() - first([0, [], ()]) is None for
the same reason that any([0, [], ()]) and all([0, [], ()]) are both False.
If first returned the actual first item in the iterable (regardless of truth
value), then it would ju
Nick Coghlan added the comment:
The deprecation warning version looks good to me.
Something I'll mention explicitly (regarding the PyCon discussions that Eric
mentioned above), is that we unfortunately couldn't do something like this for
the various concrete APIs with overly
Nick Coghlan added the comment:
Serhiy, Hynek covered the issue with the status quo in the original
proposal.The existing alternative are painful to try and decipher by
comparison with the named function:
filterednext([0, None, False, [], (), 42])
vs
next(filter(None, [0, None, False
Nick Coghlan added the comment:
Regarding the key parameter name, I believe this is closer to itertools.groupby
(which uses "key=" as an optional argument, akin to min, max and sorted) than
it is to filterfalse, dropwhile or takewhile (which use "pred" as the first
posit
Nick Coghlan added the comment:
(Updated the issue title to reflect the currently proposed name and location
for the functionality)
While I'm a fan of explicit iteration as well ("inside every reduce is a loop
trying to get out"), I think the fact Martin's explicit lo
Nick Coghlan added the comment:
Mark's rationale makes sense to me. I believe that would make the
latest version of the proposed API (in the itertools module):
def coalesce(iterable, default=None, pred=None):
...
--
___
Python tr
Nick Coghlan added the comment:
A wild timbot appears! :)
Tim Peters added the comment:
> As to the name, I like "first_true". Does what it says. Plain "first"
is misleading, and "coalesce" is both inscrutable and nearly impossible to
spell ;-)
A fair point,
Nick Coghlan added the comment:
I concede Tim's point about itertools already using underscores where it
improves readability of a name :)
So, the latest state of the proposal is to add the following, preferably
directly to the module, but at least as a recipe in the itertools docs:
Nick Coghlan added the comment:
Make sure to run "make" to rebuild the frozen module - editing
importlib._bootstrap.py involves a C style "edit, build, test" cycle rather
than the typical Python "edit, test" cycle.
--
___
Nick Coghlan added the comment:
It seems to me that the more appropriate change here would be to redefine
PyState_FindModule as return a *new* ref rather than a borrowed ref and have it
do the Py_INCREF before returning.
Code using it would then need to add an appropriate Py_DECREF. A
Nick Coghlan added the comment:
Figured it was worth mentioning, since I've been caught by forgetting
that myself :)
I suspect you're right that it's just a case of '.' passing the truth
test, even though it still r
Nick Coghlan added the comment:
I thought setting m_size to zero was for "No per module state, but
reinitialization is fine"? Does that not work? (I haven't actually tried it)
--
___
Python tracker
<http://bugs.pyt
Nick Coghlan added the comment:
I pitched the idea of making it possible to skip the with statement body
quite some time ago, and Guido convinced me it was a bad idea for much the
same reason he chose PEP 343 over his original PEP 340 design: allowing
suppression of exceptions from __enter__
Nick Coghlan added the comment:
Allowing a context manager to skip the statement body isn't a new proposal,
and I previously argued your side. However, with multiple context managers,
there is no invisible flow control. Two context managers are locally
visible, which means the oute
Nick Coghlan added the comment:
Looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue18668>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nick Coghlan added the comment:
It seems to me that by *not* doing that, we may have a bug if the cwd changes
and the import machinery returns a stateful importer that remembers the path
name. Using the actual filesystem path for everything other than sys.path
sounds like a much better option
Nick Coghlan added the comment:
Breaking the 1:1 interpreter <-> extension module mapping involves
adding custom types to sys.modules rather than module objects. Making
that work sensibly will involve larger changes to the extension
initialisation APIs. import-sig already has plans fo
New submission from Nick Coghlan:
One problem with Unicode in 3.x is that surrogateescape isn't normally enabled
on stdin and stdout. This means the following code will fail with
UnicodeEncodeError in the presence of invalid filesystem metadata:
print(os.listdir())
We don't r
Nick Coghlan added the comment:
Everything about surrogateescape is dangerous - we're trying to work
around the presence of bad data by at least allowing it to be
tunnelled through Python code without corrupting it further :)
--
___
Python tr
Nick Coghlan added the comment:
I think you make a good case, but I already tried and failed to convince Guido
of this in PEP 377 (see
http://www.python.org/dev/peps/pep-0377/#rationale-for-change)
More importantly, see his quoted concerns in
http://mail.python.org/pipermail/python-dev/2009
Nick Coghlan added the comment:
I realised that with the "module:qualname" syntax, it's straightforward to
expand this beyond module introspection to arbitrary objects.
What I suggest we could output:
- a header with key module info (names taken from PEP 451):
Or
Nick Coghlan added the comment:
Potentially relevant to this: we hope to have PEP 451 done for 3.4, which adds
a __spec__ attribute to module objects, and will also tweak runpy to ensure -m
registers __main__ under it's real name as well.
If pickle uses __spec__.name in preference to __n
New submission from Nick Coghlan:
After watching one of the presenters at PyTexas struggle painfully with the
fact "print value" doesn't work in Python 3, I decided I had to at least *try*
to see if a general "implicit call" syntax was feasible within the constrain
Nick Coghlan added the comment:
As Serhiy's examples show, the ambiguities this introduces get confusing fast.
A more constrained version that (for example) permitted only name references
for the callable could resolve that, but it's probably still a bad idea. Still,
interesting to
Nick Coghlan added the comment:
To clarify how my patch works: leaving out the parentheses is permitted
*only* when the call is a statement unto itself. That's how it avoids
conflicting with any existing syntax like "a *b" or "a **b": the parser
consumes those as part
Nick Coghlan added the comment:
Which reminds me: I'm curious what "ls" currently does for malformed
filenames. The aim of this change would be to get 'python -c "import os;
print(os.listdir())"' to do the best it can to work with
Nick Coghlan added the comment:
Think sysadmins running scripts on Linux, writing to the console or a pipe.
I agree the generalisation is a bad idea, so only consider the original
proposal that was specifically limited to the standard streams.
Specifically, if a system is properly configured to
Nick Coghlan added the comment:
On 21 Aug 2013 15:47, "Mark Dickinson" wrote:
>
>
> Mark Dickinson added the comment:
>
> > Shouldn't it be PendingDeprecationWarning?
>
> Hmm. Possibly. I'm not sure what the policy is any more regarding
Depreca
Nick Coghlan added the comment:
Right, I don't see any issues with backporting these fixes. One of the
reasons for the PEP 411 provisional status of the API was to ensure
there were no questions about what should be backported.
--
___
Python tr
Nick Coghlan added the comment:
Note that the specific case I'm really interested is printing on systems that
are properly configured to use UTF-8, but are getting bad metadata from an OS
API. I'm OK with the idea of *only* changing it for UTF-8 rather than for
arbitrary encodings,
Nick Coghlan added the comment:
On 23 Aug 2013 01:40, "R. David Murray" wrote:
. (I double checked, and this does indeed work...doing the equivalent of
ls >temp via python preserves the bytes with that PYTHONIOENCODING setting.
I don't quite understand, however, why I ge
New submission from Nick Coghlan:
Prompted by issue 18713 and
http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicode/, here are some
possible utilities we could add to the codecs module to help deal with/debug
issues related to surrogate escaped strings:
def has_escaped_bytes(s
Nick Coghlan added the comment:
Note: I created issue 18814 to cover some additional tools for working with
surrogate escaped strings.
For this issue, we currently have http://docs.python.org/3/howto/unicode.html,
which aims to be a more comprehensive guide to understanding Unicode issues
Nick Coghlan added the comment:
Patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue18818>
___
___
Python-bugs-list mailing list
Unsub
Nick Coghlan added the comment:
The use case is to take data from a surrogate escaped interface and either
filter it out entirely or convert it to a valid Unicode string at the point
of *input*, before letting it make its way into the rest of the
application. For example, this approach permits
Nick Coghlan added the comment:
Using tulip-inspired method names (when tulip hasn't landed) to duplicate
existing data input functionality (feed() and close()) seems a rather dubious
design decision to me.
Given how popular lxml.etree is as an alternative to the standard library
Nick Coghlan added the comment:
Reopening this as per discussion on python-dev. I haven't reverted anything at
this point, as subsequent changes mean a simple "hg backout" is no longer
sufficient.
--
resolution: fixed ->
stage: committed/rejected -> needs patch
s
Nick Coghlan added the comment:
Reopening this - rewording the issue title to cover the problem to be solved
(i.e. accounting for RFC 6598 addresses) rather than a specific solution (which
isn't appropriate, since the RFC *explicitly* states that shared addresses and
private addresses a
3001 - 3100 of 6301 matches
Mail list logo
