Nick Coghlan ncogh...@gmail.com added the comment:
Sorry, my last review wasn't right and the patch is incorrect as it stands.
After digging a little deeper, there is still a case that isn't covered
correctly in __build_class__.
Specifically, the case where the most derived class has
Nick Coghlan ncogh...@gmail.com added the comment:
This last point sounds like an error in PEP 3115 rather than an error
in the implementation - as the exception says, the metaclass of a
derived class must be the same as or a subclass of the metaclasses of
all of its bases. Since that rule
Nick Coghlan ncogh...@gmail.com added the comment:
I think PEP 3115 is OK - the error about all metaclasses inheriting from type
was a mistake on my part (I thought the ability to create non-type metaclasses
went away along with old-style classes, but I was simply wrong on that point
Nick Coghlan ncogh...@gmail.com added the comment:
As near as I can tell, the only visible behavioural change with Daniel's patch
(updated as per my last comment) will be that the two error cases noted above
(i.e. when an explicit metaclass or the first parent type's metaclass is not
the most
Nick Coghlan ncogh...@gmail.com added the comment:
Commenting on the latest patch here, since the Rietveld integration isn't
coping with the hg extdiff output (I would guess that the revision numbers in
the pathnames are confusing the script that attempts to determine the base
revision
Nick Coghlan ncogh...@gmail.com added the comment:
That's not correct - we've merely pointed out that it isn't as easy as most
people seem to think.
For the POSIX world, there is a version management scheme based on symlinks in
/usr/bin (or /usr/local/bin) and it is easy to add and remove
Nick Coghlan ncogh...@gmail.com added the comment:
Reopening this issue since #9228 was closed as a duplicate of this one. Given
the significant level of user demand for this behaviour, it should NOT be
closed again until a PEP has been written and either accepted or rejected. If
such a PEP
Nick Coghlan ncogh...@gmail.com added the comment:
If it is being requested every few months, then we should reconsider rejecting
it. I have now reopened #3561 instead of this one.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
Now, another factor to consider is that Windows 7 makes manipulating the system
PATH even more difficult to do correctly (e.g. see
http://www.symantec.com/connect/forums/wise-7-win-7-problems-updating-environment-variable-current-user).
I
Nick Coghlan ncogh...@gmail.com added the comment:
Sounds good. I still have that embedded pickle module issue to deal with, and
this should let me actually add a test for it along with the fix.
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
Reopening, as a 2.7 backport of this would be a nice thing to have.
--
assignee: rhettinger -
status: closed - open
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
It's because it isn't a true Mercurial clone-and-update - it's a patch queue,
which the review generation code doesn't know how to interpret.
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
It's not just hiding the real error, it's also saying something that isn't
true. If you remove the deliberate error from the generator definition, it is
clear that generators are perfectly acceptable as *arg inputs:
def g(): yield 1, 2
New submission from Nick Coghlan ncogh...@gmail.com:
The question of the way Python handles NaN came up again on python-dev
recently. The current semantics have been assessed as a reasonable compromise,
but a poorly explained and inconsistently implemented one.
Based on a suggestion from
Nick Coghlan ncogh...@gmail.com added the comment:
Actually, based on the NumPy precedent [1], array.array should be fine as is.
Since it uses raw C floats and doubles internally, rather than Python objects,
there is no clear concept of object identity to use to enforce reflexivity.
[1] http
Nick Coghlan ncogh...@gmail.com added the comment:
The status quo works. Proposals to change it on theoretical grounds have a
significantly higher bar to meet than proposals to simply document it clearly.
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
By works I merely meant that you can currently achieve both of the following:
1. Write fully conformant implementations of IEEE754 floating point types,
including the non-reflexive NaN comparisons (keeping in mind that, as a
value-based
Nick Coghlan ncogh...@gmail.com added the comment:
After further discussion on python-dev, it is clear that this identity checking
behaviour handles more than just NaNs - it also allows containers to cope more
gracefully with objects like NumPy arrays that make use of rich comparisons
Nick Coghlan ncogh...@gmail.com added the comment:
Scratch the first half of that last comment - Guido pointed out that false
positives rear their ugly head almost immediately if you try to store rich
comparison objects in other containers
Nick Coghlan ncogh...@gmail.com added the comment:
Rather than fiddling with the warnings filters, wouldn't it be easier to just
catch BytesWarning and return False in that case?
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http
New submission from Nick Coghlan ncogh...@gmail.com:
http://nedbatchelder.com/code/coverage/subprocess.html describes how to
instruct a test suite that spawns subprocesses to correctly report coverage
data for code covered only in those subprocesses.
regrtest currently doesn't do this, so
Nick Coghlan ncogh...@gmail.com added the comment:
I'm OK with that - I'd actually suggest explicitly *emitting* a warning when
the error is suppressed under -bb, as Ezio is right that even tests should be
keeping their bytes/str separation straight. I don't like completely
suppressing
Nick Coghlan ncogh...@gmail.com added the comment:
A quick eyeball of the test doesn't reveal anything obvious:
- if the subprocess is failing, it is doing so in such a way that it is still
returning a 0 error code and isn't writing anything to stdout (as those
assertions are before the check
Nick Coghlan ncogh...@gmail.com added the comment:
Hmm, I probably should have revised the first half of my comment after I had
the thought about simple regex + random directory name being potentially
problematic. I don't think that theory really counts as obvious, though
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: -ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10775
___
___
Python-bugs-list
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: docs@python - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11690
___
___
Python
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
versions: +Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11647
Nick Coghlan ncogh...@gmail.com added the comment:
The core bug has been fixed for 3.2.1 and forward ported to 3.3.
I credited the patch to Ysj Ray in ACKS and NEWS, let me know if you'd prefer
a different attribution.
Leaving the issue open for now, since _recreate_cm() should be renamed
Nick Coghlan ncogh...@gmail.com added the comment:
Python should still work reliably even if the temp directory is on a
case-insensitive filesystem. Since that isn't an easy thing to determine, -1 on
restoring the uppercase characters to the filenames.
As for it not being fixed previously
Nick Coghlan ncogh...@gmail.com added the comment:
The number of characters in the filename is hardcoded in the guts of tempfile
(in _RandomNameSequence.__next__ to be exact). Increasing that to 7 (or even 8)
would be a straightforward change at the library level, but it can't be done
from
Nick Coghlan ncogh...@gmail.com added the comment:
Basically, adding the uppercase letters back in would provide no gain in
entropy on a case-insensitive filesystem (as the upper and lower case letters
will collide). Increasing the length of the random sequence would provide a
consistent gain
Nick Coghlan ncogh...@gmail.com added the comment:
Minor clarification: after my first comment, I realised that the original
change in the character set didn't actually fix anything, it just propagated
the effectively smaller sample space on case-insensitive filesystems to all
filesystems
Nick Coghlan ncogh...@gmail.com added the comment:
Oh, you mean the security risk if the temporary names can be guessed? My
recollection is that it is more of a problem for temporary directories than it
is for temporary files, since the module can't control how files inside a temp
directory
Nick Coghlan ncogh...@gmail.com added the comment:
The challenge with C functions is that this becomes *additional* metadata that
somehow needs to be provided to the method and function creation process. None
of our APIs are set up to accept that information (and obviously no code is set
up
Nick Coghlan ncogh...@gmail.com added the comment:
It still works fine for me (as do test_imp, test_import and test_importlib).
Did you provide any arguments to ./configure, or provide any interesting
options to regrtest to get it to fail
Nick Coghlan ncogh...@gmail.com added the comment:
Oh, that's the other question - is there any chance you are passing -B or have
PYTHONDONTWRITEBYTECODE set? (I'm not sure that would affect make_legacy_pyc,
but all the errors you posted relate to unexpectedly absent pyc files and
directories
Nick Coghlan ncogh...@gmail.com added the comment:
Several of these could be handled just by having test.support.make_legacy_pyc()
fall back to compiling from source if sys.dont_write_bytecode is set.
The others may need to be skipped in that situation
Nick Coghlan ncogh...@gmail.com added the comment:
This topic came up again on python-ideas:
http://mail.python.org/pipermail/python-ideas/2011-May/010293.html
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
Just to articulate the rationale, I'm guessing the reasoning behind this is to
make it feasible for source-AST-source translators to retain the original
grouping?
--
___
Python tracker rep
Nick Coghlan ncogh...@gmail.com added the comment:
Visual scan of the patch in Reitveld looks fine to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12106
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12182
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +jnoller, ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12174
___
___
Python-bugs
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12191
___
___
Python-bugs-list
New submission from Nick Coghlan ncogh...@gmail.com:
A complete build on Ubuntu currently requires fiddling with LDFLAGS before
invoking configure (otherwise the build process fails to find the necessary
pieces to build some modules):
http://www.technobits.net/articles/8919/christian-heimes
Nick Coghlan ncogh...@gmail.com added the comment:
In the time since 2.3, pydoc.visiblename() has been updated to use the correct
definition of visibility.
A developer mode that exposes internal details doesn't make sense. When
you're developing something and want to see internal details
Nick Coghlan ncogh...@gmail.com added the comment:
From my review:
One genuine problem with a stale assert and comment in ast.c, and a small
objection to style in compile.c (I'd like a new compile_try() function to match
the new AST node).
Otherwise looked good in a desk review
Nick Coghlan ncogh...@gmail.com added the comment:
The AST version changed, and, more importantly, if other implementations pick
up our AST changes without updating their compilers accordingly, their symbol
table analysis and code compilation processes will break.
So yes, the test suite does
Nick Coghlan ncogh...@gmail.com added the comment:
One other thing I should mention is that in a later checkin, Benjamin did add a
couple of explicit with statement examples to test_ast. These will fail if
other implementations don't update the front end of their compilation processes
Nick Coghlan ncogh...@gmail.com added the comment:
Looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12199
___
___
Python-bugs
Nick Coghlan ncogh...@gmail.com added the comment:
Some comments on the follow-up changes I just committed:
- It's an illustration of the fact that coverage data is only step 1 in
improving tests.
- I added additional assertions regarding the error message contents to a
couple of tests
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11505
Nick Coghlan ncogh...@gmail.com added the comment:
Note that Yaniv Aknin (author of the Python's Innards series of blog posts) has
a recursive dis variant that may be useful for inspiration:
https://bitbucket.org/yaniv_aknin/pynards/src/c4b61c7a1798/common/blog.py
As shown
Nick Coghlan ncogh...@gmail.com added the comment:
Hmm, that behaviour looks unrelated to the specific problem Michael reported.
The initial problem in this space was that defining __dir__() completely
determined the result of dir() calls, but object.__dir__() didn't actually
work, so you
Nick Coghlan ncogh...@gmail.com added the comment:
The 'using docs' are, oddly enough, the part of the docs called 'using' :)
In particular, the part about the command line components (including the
'script' argument):
http://docs.python.org/using/cmdline.html
Nick Coghlan ncogh...@gmail.com added the comment:
(just reviewing the idea here, not the current patch)
The problem of stale code (i.e. what was executed doesn't match what is
displayed in the traceback) is a tricky and subtle one. There are a few
different cases:
1. Source displayed does
Nick Coghlan ncogh...@gmail.com added the comment:
No, the naming problem had occurred to me as well. Given the 'vars' builtin,
perhaps 'getclosurevars' would do as the name?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nick Coghlan ncogh...@gmail.com added the comment:
In reviewing Meador's patch (which otherwise looks pretty good), I had a
thought about the functionality and signature of getclosurevars().
Currently, it equates closure to nonlocal scope, which isn't really true -
the function's closure
Nick Coghlan ncogh...@gmail.com added the comment:
Don't feel bad about not recognising the context - this stuff wasn't documented
at all for a long time, and it wasn't until Georg pointed me to the usage docs
that I realised adding it there would be the right place. I should have
remembered
Nick Coghlan ncogh...@gmail.com added the comment:
This is the same problem that all from x import y circular imports have - it
isn't specific to relative imports.
Closing as a duplicate of issue 992389
--
resolution: - duplicate
status: open - closed
superseder: - attribute error
Nick Coghlan ncogh...@gmail.com added the comment:
Changed the issue title to state clearly that the core issue is with circular
imports that attempt to reference module contents at import time, regardless of
the syntactic form used. All of the following module level code can fail due
Nick Coghlan ncogh...@gmail.com added the comment:
It's fairly easy to check this is still a problem:
$ ./python
Python 3.3.0a0 (default:a06ef7ab7321, Sep 22 2011, 13:41:29)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type help, copyright, credits or license for more information.
import
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8060
___
___
Python-bugs-list mailing
Nick Coghlan ncogh...@gmail.com added the comment:
They were removed because adding new methods to builtin types violated the
language moratorium.
Now that the language moratorium is over, the transform/untransform convenience
APIs should be added again for 3.3. It's an approved change
Nick Coghlan ncogh...@gmail.com added the comment:
Sorry, I meant to state my rationale for the unassignment - I'm assuming this
issue is covered by MAL's recent decision to step away from Unicode and codec
maintenance issues. If that's incorrect, MAL can reclaim the issue, otherwise
Nick Coghlan ncogh...@gmail.com added the comment:
Some further comments after getting back up to speed with the actual status of
this problem (i.e. that we had issues with the error checking and reporting in
the original 3.2 commit).
1. I agree with the position that the codecs module itself
Nick Coghlan ncogh...@gmail.com added the comment:
Oops, typo in my second error example. The command should be:
b'a'.decode('rot_13')
(Since str objects don't offer a decode() method any more)
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
On Thu, Oct 20, 2011 at 8:34 AM, STINNER Victor rep...@bugs.python.org wrote:
str.transform('bz2') == CodecLookupError
A lookup error is surprising here. It may be a TypeError instead. The bz2 can
be used with .transform, but not on str. So
Nick Coghlan ncogh...@gmail.com added the comment:
Features looks good, but the current patch doesn't handle keyword arguments
correctly (more details in the Reitveld review).
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
I'm fine with people needing to drop down to the lower level lookup() API if
they want the filtering functionality in Python code. For most purposes,
constraining the expected codec input and output formats really isn't a major
issue - we
New submission from Nick Coghlan ncogh...@gmail.com:
I needed a depth-limited, filtered search of a directory tree recently and came
up with the following wrapper around os.walk that brings in a few niceties like
glob-style filtering, depth limiting and symlink traversal that is safe from
Nick Coghlan ncogh...@gmail.com added the comment:
Looks good to me (although it took me longer than it should have to figure out
why you didn't need to store the keyword argument names a second time)
--
___
Python tracker rep...@bugs.python.org
New submission from Nick Coghlan ncogh...@gmail.com:
Many typical subprocess use cases can now be handled simply via the convenience
functions:
subprocess.call()
subprocess.check_call()
subprocess.check_output()
However, readers of the documentation could be forgiven for not realising
New submission from Nick Coghlan ncogh...@gmail.com:
I've been doing a few systems administration tasks with Python recently, and
shell command invocation directly via the subprocess module is annoyingly
clunky (even with the new convenience APIs).
Since subprocess needs to avoid the shell
Changes by Nick Coghlan ncogh...@gmail.com:
--
title: subprocess docs should use emphasise convenience functions - subprocess
docs should emphasise convenience functions
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13237
Nick Coghlan ncogh...@gmail.com added the comment:
And that's exactly the problem - a web developer's or security auditor's shell
injection is a system administrator's this language sucks.
These wrappers are the kind of thing you want for shell invocations when using
Python as a replacement
Nick Coghlan ncogh...@gmail.com added the comment:
Perhaps a better idea would be to use different names, so it's clearer at the
point of invocation that the shell is being invoked (and hence shell injection
attacks are a potential concern). For example:
shell_call
check_shell_call
Nick Coghlan ncogh...@gmail.com added the comment:
Of the 3 available options (mod style, string.Template and str.format), yes,
str.format is the best choice.
If people want the shell meaning of the braces, they can escape them by
doubling them up in the command string
Nick Coghlan ncogh...@gmail.com added the comment:
Initially, because I was suggesting the names shadow the subprocess convenience
functions so they *had* to live in a different namespace.
However, even after changing the names to explicitly include shell, I'd like
to keep them away from
Nick Coghlan ncogh...@gmail.com added the comment:
You couldn't just move them - you'd need to change the wording of how they
cross-link to each other, since the explanations of the convenience function
currently assume you understand how Popen works. I'd like us to get to the
point where you
Nick Coghlan ncogh...@gmail.com added the comment:
It's a flow thing. This idea was kicked off by the process of translating a
large Perl script to Python and paying attention to what the translation made
*worse*.
One of the big things it made worse was the translation of qx (quoted
Nick Coghlan ncogh...@gmail.com added the comment:
That's a fair point, but I think it actually *improves* the argument for better
helper functions, since we can have them automatically invoke shlex.quote() on
all of the arguments:
def _shell_format(cmd, args, kwds):
args = map
Nick Coghlan ncogh...@gmail.com added the comment:
The devguide actually did align with what I said in my email, but this wasn't
clear if you only read the Forward Porting section (you had to read the
Porting Between Major Versions section further down the page as well).
I added a new
Nick Coghlan ncogh...@gmail.com added the comment:
Fix has been applied to 3.x and hence will be in 3.3 and the next 3.2 release.
I have adjusted the issue metadata to reflect the fact 2,7 still exhibits the
problem, but the patch requires significant work to account for the 3.x vs 2.x
Nick Coghlan ncogh...@gmail.com added the comment:
OK, looking at the code I realised what you're trying to get at is the idea of
reporting the differences between values in a series, such that:
x = list(accumulate(seq))
assert x == list(accumulate(differences(x)))
I don't think the use cases
Nick Coghlan ncogh...@gmail.com 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
300M
Nick Coghlan ncogh...@gmail.com 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
series
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: docs@python - ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13237
___
___
Python
Nick Coghlan ncogh...@gmail.com 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
fail
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
New submission from Nick Coghlan ncogh...@gmail.com:
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
Nick Coghlan ncogh...@gmail.com 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 suggest
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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 versions
Nick Coghlan ncogh...@gmail.com 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 though
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
Nick Coghlan ncogh...@gmail.com 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
shutil.shell_call(du -hs {!q}, ../py
901 - 1000 of 6264 matches
Mail list logo
