Eric Snow added the comment:
with f_func (see #12857) you would get that for free:
>>> frame.f_func.__qualname__
'A.f1'
--
nosy: +eric.snow
___
Python tracker
<http://bugs
Eric Snow added the comment:
True. I wonder, though if perhaps a co_func (as a weak ref) or co_orig_func
would be better, since co_qualname would be built from the original function
anyway. Then you could call "code.co_func.func_qualname".
One sticky point is that there isn
Eric Snow added the comment:
Interesting thought, the syntax seems unnecessary. Adding new syntax to the
language is something that happens rarely and only with a _lot_ of
consideration.
As a slightly more verbose alternative, currently you can do this:
def fail_if_defined(*args
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue13562>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Promislow :
This regular expression takes a few seconds to be evaluated
against any text:
(.*?)((?:X|\s+)*)$
This reg ex is much faster:
(.*?)((?:X|\s)*)$
To be fair, Ruby's performance with the first regex is the same as Python's.
PHP and JavaScript bo
Eric Snow added the comment:
see http://docs.python.org/library/sys.html#sys.path
"As initialized upon program startup, the first item of this list, path[0], is
the directory containing the script that was used to invoke the Python
interpreter. If the script directory is not available
New submission from Eric Breck :
Consider the attached two files. A reader and writer with the same dialect
parameters (escapechar \ quotechar " doublequote False) read, then write a CSV
cell that looks like "C\\". It's written "C\". The problem is, when
dou
New submission from Eric Snow :
I found that the .py files are all 2.x. If I get a chance I will write up a
patch a little later. This is similar to issue #10224. Incidently, not having
done any documentation work before, I didn't realize that docutils isn't in t
New submission from Eric Snow :
The formatting for the title of the "Index by Category" section is different
from the formatting for the title of the "Numerical Index" section. Not sure
if there is a reason behind this, but here's a patch:
diff --git a/pep0/output.
New submission from Eric Snow :
A couple of months back I started a page on the wiki for a topical index of
PEPs from PEP 0 [1]. I got tired of reading through PEPs trying to see if one
related to what I was working on. I found myself wishing there was a topical
index of all the PEPs. The
Eric Snow added the comment:
Perhaps rather than changing ABCMeta, provide a base descriptor class that has
__isabstractmethod__ implemented to calculate the abstractness. Then property
could use that, as could any of the other relevant descriptors we have around.
The __isabstractmethod__
Eric Snow added the comment:
Didn't mean to sidetrack. :) I really appreciate the effort Darren has put
into this.
--
___
Python tracker
<http://bugs.python.org/is
Eric Snow added the comment:
Yeah, the extra space results in a different formatting. Compare "Index by
Category" with "Numerical Index".
--
___
Python tracker
<http://bug
Eric Snow added the comment:
I had considered that, but thought it would be better to leave the topical
index open for editing to a broader audience. If it's in PEP 0 then only
committers could make changes.
I do like the idea of using keywords from the PEPs themselves, but that
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue8639>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue11339>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue1294232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue5996>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12486>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue10403>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12491>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue2377>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12374>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue11435>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue11561>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue2636>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12535>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue10224>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue1559549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue11470>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue2506>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
But it is curious that the submodules were added to sys.modules even though the
package failed to import.
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue8916>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Yeah, I missed the line where he imported foo.bar in "foo/__init__.py", and
thought something else was going on.
"foo/__init__.py" does not have to finish importing (just has to be on
sys.modules) at the point foo.bar is imported.
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12531>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue11343>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue1284670>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12583>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Snow :
Several import-related sys variables are set in _PyImportHooks_Init (in
Python/import.c), which is called in Python/pythonrun.c. I have included a
patch that moves that initialization from _PyImportHooks_Init to a new
_SysImportState_Init function in Python
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue7897>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12626>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Eric Snow :
The sys.modules dict is a special object. It is the only variable of the
CPython interpreter object that is exposed in the sys module[1]. Everything
else in sys lives in the module. However, the modules dict lives in the
interpreter object and is bound to
Eric Snow added the comment:
Would an implementation detail note be inappropriate here? I only ask because
it looks like the imp module's use of interp->modules is implementation
specific.
Here's a patch for Doc/library/sys.rst that adds the note.
--
assignee: -
Eric Snow added the comment:
And this doesn't impact "if x is None", so +1.
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12647>
___
_
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12675>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
You can already get the better prefix using os.path, albeit less efficiently.
Here's an example:
def commondirname(paths):
subpath = os.path.commonprefix(paths)
for path in paths:
if path == subpath:
return subpath
Changes by Eric Snow :
--
nosy: +ericsnow
___
Python tracker
<http://bugs.python.org/issue12691>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Snow added the comment:
Eli, I interpreted it the same way you did. In the doc, "type methods" are
those that map directly to PyTypeObject. Any custom type methods go in
tp_methods. You could almost call the former "PyTypeObject methods" rather
than "typ
Eric Snow added the comment:
http://docs.python.org/dev/extending/newtypes.html
--
___
Python tracker
<http://bugs.python.org/issue12672>
___
___
Python-bug
New submission from Eric Snow :
The idea of moving the devguide into the cpython repo, presumably under Doc/,
was mentioned in a thread on python-dev[1] (related to issue 12652). Does
anyone have any objections?
I'm guessing that Brett made a separate repo (A) for simplicity and (B) be
Eric Snow added the comment:
I suppose it doesn't have to be in Doc/.
--
title: Move devguide into /Docs of cpython repo -> Move devguide into cpython
repo
___
Python tracker
<http://bugs.python.org
Eric Snow added the comment:
That's fine. The discussion had moved away from the devguide, so I figured it
would be worth following up. You guys have made some good points.
--
resolution: -> rejected
status: open -> closed
___
Pyt
New submission from Eric Snow :
Apparently docstrings for classes are immutable:
>>> class X:
... "some doc"
...
>>> X.__doc__
'some doc'
>>> X.__doc__ = "another doc"
Traceback (most recent call last):
File "", line
New submission from Eric Snow :
This patch adds f_func to PyFrameObject and sets it for functions that get
called (in PyFrame_New). For classes and modules it is set to None. The
difference in performance was not noticable, as far as I could tell. However,
I am willing to do more than just
Eric Snow added the comment:
Thanks for the review, Nick. I'll be uploading a new patch in a couple hours
with your recommended fixes.
Regarding the comments on python-ideas, would it be better to use a weakref
proxy around the function, to help with the reference cycles? That
Eric Snow added the comment:
On second thought, I probably won't be able to get an updated patch tonight. I
need to mull over the PyEval_EvalFunction implementation and the interaction
with fast_function.
--
___
Python tracker
New submission from Eric Promislow :
I see that going from Python 3.1.1 to 3.1.2
instances of io.StringIO no longer have a __dict__ field.
Why? Is this to make them unpicklable?
--
components: IO
messages: 143344
nosy: ericp
priority: normal
severity: normal
status: open
title
Changes by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<http://bugs.python.org/issue12919>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
I'll work on cleaning this up for 3.2.
Any comments on the name of the method?
--
___
Python tracker
<http://bugs.python.org/i
Eric Talevich added the comment:
This bug seems to be still present in Python 3.1.2. (Unless I'm doing something
wrong.) Was r78942 included in the 3.1.2 release?
--
___
Python tracker
<http://bugs.python.org/i
Eric Smith added the comment:
I'm not sure it has to be consistent with the shell to be useful, as long as
the behavior is documented and we possibly add a note explaining the
differences from the shell. But I agree that a discussion on python-ideas would
be helpful.
--
Eric Smith added the comment:
Since this is a feature request, it could only be added to 3.2, not the other
versions.
--
nosy: +eric.smith
type: behavior -> feature request
versions: -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue9625>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
On 8/19/2010 9:14 AM, Antoine Pitrou wrote:
> Why not provide {httplib,urllib}.{set,get}defaulttimeout() instead?
Yes, I'm assuming that's how _HTTP_DEFAULT_TIMEOUT would be set and queried.
--
___
P
Eric Smith added the comment:
It looks to me like reqarg is marked as required, since it's not in brackets.
Or am I missing something?
--
nosy: +bethard, eric.smith
___
Python tracker
<http://bugs.python.org/i
Eric Smith added the comment:
Duh. Sorry about that.
Also applies to 3.2.
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue9694>
___
___
Eric Smith added the comment:
Or "parameters:"?
--
___
Python tracker
<http://bugs.python.org/issue9694>
___
___
Python-bugs-list mailing list
Un
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue9695>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
If you add a positional parameter by adding:
parser.add_argument('foo')
then the output becomes:
$ python argparse-help-says-required-args-are-optional.py -h
usage: issue9649.py [-h] --reqarg REQARG [--optarg OPTARG] foo
Do something
positional argume
Eric Smith added the comment:
I think you mean pipe.quote in your message, not pipe.call. The subject looks
correct.
I'm not sure pipes is the best place for this, but I agree it should probably
be documented in older versions. It seems to me we've had this discussion
before abo
Eric Smith added the comment:
I can duplicate this as a segmentation fault under 2.7 on Mac OS, but not under
Windows 2.6 (ActiveState).
What platform are you using, and what output do you see?
--
nosy: +eric.smith
___
Python tracker
<h
Eric Smith added the comment:
Amaury: Good point. The Windows version is failing, too. A print statement at
the end doesn't get executed.
--
___
Python tracker
<http://bugs.python.org/i
Eric Smith added the comment:
Sorry to respond late.
The reason for this is that the parsing of the string (as delimited by "{" and
"}") happens before the results are then interpreted as format specifiers.
There's no way around it, short of the parser und
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue9805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue9807>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
I think this might be a dupe of issue 1467929.
--
___
Python tracker
<http://bugs.python.org/issue9805>
___
___
Python-bugs-list m
Eric Smith added the comment:
Manually merged to py3k in r84790. I'll leave this open until I create the 3.3
issue to change it to a DeprecationWarning.
--
keywords: -needs review
versions: -Python 3.3
___
Python tracker
<http://bugs.py
Eric Smith added the comment:
The precedence doesn't work the way you think it does. Your example with the
intermediate variable is the same as:
>>> ((0+1j)*(0+1j)).imag
0.0
>>> ((0+1j)*(0+1j)).real
-1.0
Note the extra level of parens so that .imag and .real are applie
New submission from Eric Smith :
In 3.3 the existing PendingDeprecationWarning needs to become a
DeprecationWarning. In 3.4 it will become an error.
I'll change 3.3 after 3.2 is released.
See issue 7994 for the original PendingDeprecationWarning discussion.
--
assignee: eric.
Eric Smith added the comment:
See issue 9856 for changing this to a DeprecationWarning in 3.3.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue9873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Smith :
--
nosy: +eric.smith
versions: -Python 2.5
___
Python tracker
<http://bugs.python.org/issue9869>
___
___
Python-bugs-list mailin
Eric Smith added the comment:
Raymond Chen's blog today discusses CommandLineToArgvW, which is apparently an
API that can parse command lines. It's not clear to me if this is actually
called by the MSFT CRT:
http://blogs.msdn.com/b/oldnewthing/archive/2010/09/17/10063629.aspx
Eric Smith added the comment:
I'm not sure what "fetch command does not contain literal" means. If the OP can
clarify, I'd be interested in this issue.
--
nosy: +eric.smith
status: pending -> open
___
Python tracker
Eric Smith added the comment:
Now that I think about this some more, we wouldn't want to call this API. I'd
rather this hypothetical function be available on non-Windows platforms, so
we'd have to implement the semantics of CommandLineToArgvW or whichever CRT we
Eric Smith added the comment:
There are plenty of tests that check implementation specific internal
behaviors. I don't think the presence of test alone would mean that it can't be
changed.
--
___
Python tracker
<http://bugs.python.
Changes by Eric Smith :
--
nosy: +eric.smith, jaraco
___
Python tracker
<http://bugs.python.org/issue9908>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Eric Smith :
--
nosy: +eric.smith
___
Python tracker
<http://bugs.python.org/issue9915>
___
___
Python-bugs-list mailing list
Unsubscribe:
Eric Smith added the comment:
This is well defined in Python and will not change.
--
nosy: +eric.smith
resolution: -> rejected
stage: -> committed/rejected
status: open -> closed
type: -> feature request
___
Python tr
Eric Smith added the comment:
My only concern with this is that it would cause other implementations to do
the same thing. I assume it's not hard for them, but it is work. I know that
IronPython implemented the _formatter_* methods so that they could use
string.py as-is.
But that'
Eric Smith added the comment:
Now that I start this, I see that it's complicated by the fact that the
functions actually being wrapped are in stringlib/string_format.h. That's
because in 2.x they compile as both unicode and str. Before the _string module
is created, the code should
Eric Smith added the comment:
The more I think about this, the more sense it makes to leave the module in
unicodeobject.c. Certainly all the code it's likely to ever contain would
already be in unicodeobject.c.
While I agree there's some conceptual clarity to be had by having the
Eric Smith added the comment:
>From their web page, it looks like PyScripter only runs on Windows, so I
>assume these results are generated there.
I won't be able to test on Windows until tonight.
Kiriakos: Does this only happen within PyScripter, or does it also happen when
Eric Smith added the comment:
It's interesting to note that '9' is ascii 57, and ':' is 58. It's like the
code is incrementing the wrong digit. If it's related to that, that indeed
sounds like a compiler optimization bug to me, but of course I'
Eric Smith added the comment:
I agree that in an ideal world there would not be a dependency on global flags.
There's no doubt a performance issue with doing so, although someone would have
to measure that. It may well be swamped by the memory allocation, etc. that is
going on at the
Eric Smith added the comment:
I'm okay with that. Grepping Lib shows that date/datetime/time and Decimal are
the only types that implement __format__. Decimal largely implements the same
language as float.
--
___
Python tracker
Eric Smith added the comment:
Right. It seemed like a hassle to have the str.format parser try to figure out
what a valid identifier is, so it just passes it through.
I don't see this as any different from:
>>> class X:
...def __getattribute__(self, a): return 'foo&
Eric Smith added the comment:
Ah, but I don't need to in order to comply with the PEP!
--
___
Python tracker
<http://bugs.python.org/issue10021>
___
___
Eric Smith added the comment:
I agree it should be documented as a CPython specific behavior. I should also
add a CPython specific test for it, modeled on your code (if one doesn't
already exist). I'll look into it.
--
___
Python trac
201 - 300 of 5181 matches
Mail list logo
