Changes by Terry J. Reedy tjre...@udel.edu:
--
versions: -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10652
___
___
Python-bugs-list
Georg Brandl added the comment:
I could, but the checked-in 1.0.1d is different from the tarball in some
respects, so it's better for Martin to do this.
--
assignee: - loewis
___
Python tracker rep...@bugs.python.org
Georg Brandl added the comment:
Sorry, this was not clear to me. 3.2 users will have to live with the bug.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17838
___
Georg Brandl added the comment:
Interesting observation :) However, the alignment in the PEP is in prose, not
code.
--
assignee: docs@python -
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17966
Changes by paul j3 ajipa...@gmail.com:
Removed file: http://bugs.python.org/file29880/mixed.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14191
___
Changes by paul j3 ajipa...@gmail.com:
--
title: argparse does not dest.replace('-', '_') for postionals - argparse
does not dest.replace('-', '_') for positionals
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17965
Yogesh Chaudhari added the comment:
@Stinner:
1. While I agree with your idea of what you have done in test_os,
(particularly, for determining if platform is supported or not) there seems to
be no reason(AFAIK) to have a shutil for cpu_count. I agree with neologox there.
2. Also I am not
Paul Jurczak added the comment:
Correct, it is in mixed prose and code. However, the underlying principle in
this PEP is: guidelines provided here are intended to improve the readability
of code. The author used vertical alignment (for mixed prose and code),
because of its superior
Yogesh Chaudhari added the comment:
I would like to take a crack at it. Would it be possible(I mean permission
wise)? How can I proceed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17962
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file30243/nt_module.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17941
Yogesh Chaudhari added the comment:
+1 to Terry for If its class does not override .__format__, then it seems that
it should act the same as a direct object instance
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9856
Antoine Pitrou added the comment:
I don't know how much work there is. Perhaps you want to produce a diff between
the current external 1.0.1d and the upstream version. Otherwise just let
Georg or Martin handle it ;)
--
___
Python tracker
Antoine Pitrou added the comment:
Here is an alternative patch raising RuntimeError on executing frames.
Please tell which one you prefer :)
--
Added file: http://bugs.python.org/file30244/frame_clear_alt.patch
___
Python tracker
Claudiu.Popa added the comment:
There is a regression with the latest patch, `getparams` output is no longer
picklable. The attached patch fixes this issue. Also, I renamed the internal
namedtuple to something more meaningful.
--
Added file:
Changes by Claudiu.Popa pcmantic...@gmail.com:
--
status: closed - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17487
___
___
Antoine Pitrou added the comment:
I think the logic is slightly wrong in remove_subclass. When you encounter
Py_None, you can't be sure it's the weakref for the current type;
theoretically, it could be any other one (depending on oddities in cleanup
order, cycle collection, etc.). So you have
Yogesh Chaudhari added the comment:
Modified patch based on further comments and review.
1. Removed *everything* from os.py
2. removed typecasting for ncpu where not required.
3. removed redundant comments
--
Added file: http://bugs.python.org/file30246/issue17914-5.patch
Antoine Pitrou added the comment:
Attaching an alternative implementation for remove_subclass().
--
Added file: http://bugs.python.org/file30247/subtype2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17936
New submission from Antoine Pitrou:
os.listxattr() leaks its internal buffer when the first call to C listxattr()
fails with ERANGE. This wasn't caught by the refleak bot, probably because
xattrs are not enabled on it.
--
files: listxattr_leak.patch
keywords: patch
messages: 189114
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +gvanrossum
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17966
___
___
Python-bugs-list
Antoine Pitrou added the comment:
I agree with Nick here, there's no reason to auto-number constants in Python.
This is not C :-)
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
Antoine Pitrou added the comment:
To be honest I can't find much to say about this proposal, but I think it would
be good if the time function were configurable (both for test purposes, and to
allow passing e.g. time.monotonic). I suppose this could be an executor option.
--
Kristján Valur Jónsson added the comment:
Basically the logic is this: When the class goes away, it _always_ calls
remove_subclass(). Now, this may be before or after the weakref has been clear
so that it will either find itself in a weakref, or a clear weakref.
In case this logic is
Antoine Pitrou added the comment:
In case this logic is flawed, we know that when remove_subclass() is
called, exactly one child is removed. Whether it is us, or some
previous class, is irrelevant.
remove_subclass() is called when __bases__ is assigned to, so it is
not irrelevant:
class
Kristján Valur Jónsson added the comment:
There are two cases when remove_subclass is called:
One when we are changing base classes(the original use of this function), and
in this case we must find the correct one.
The second one is when the class is being deleted, for housekeeping of the
Antoine Pitrou added the comment:
The second one is when the class is being deleted, for housekeeping
of the weakrefs.
I worry that your alternative will cause us to walk the entire list
in the second case because it will be called when the weakref has
been cleared, so it will never find
Kristján Valur Jónsson added the comment:
Actually, in a program that dynamically creates a class, and then deletes it,
you would expect a O(1) complexity. adding children at the end, and searching
from the end, is a way to achieve this.
While I admit that I oversaw the exact requirement for
Antoine Pitrou added the comment:
While I admit that I oversaw the exact requirement for __bases__, I think
that allowing for a None to be sufficient when the class is being deleted
is an important improvement.
You can't be sure the None corresponds to the type being deleted and not
New submission from Kristján Valur Jónsson:
We have observed this crash with some frequency when running our compilation
scripts using multiprocessing.Pool()
By analysing the crashes, this is what is happening:
1) The Pool has a daemon thread managing the pool.
2) the worker is asleep, waiting
Changes by Richard Oudkerk shibt...@gmail.com:
--
nosy: +sbt
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17969
___
___
Python-bugs-list mailing
Kristján Valur Jónsson added the comment:
Yes I am sure. Please see the previous reasoning. Igoring assigning to
__bases__ for the moment...
Every class deletion will try to remove itself from the list. Either it will
a) find an existing reference in the weakref and remove it
b) find a
Changes by Martin Morrison m...@ensoft.co.uk:
--
nosy: +isoschiz, pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17950
___
___
Georg Brandl added the comment:
I don't know what there is to do, so I can give no instructions. It's best to
let Martin handle it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17962
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17950
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
Here is a patch for 3.4 based on Matt's patch with additional optimizations. It
speeds up body_encode() and header_encode().
$ ./python -m timeit -s from email.quoprimime import body_encode as encode; x
= open('Lib/decimal.py').read()[:10] encode(x)
Serhiy Storchaka added the comment:
LGTM
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17968
___
___
Python-bugs-list
Yogesh Chaudhari added the comment:
@Antoine and @Georg:
You are right. There is nothing much to be done. The only difference is those
of auto-generated files like Makefile and other config files created after
running ./config script.
This just needs a simple add/commit from the openssl
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17950
___
___
Python-bugs-list
Changes by STINNER Victor victor.stin...@gmail.com:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17963
___
___
Python-bugs-list
Guido van Rossum added the comment:
This is a silly argument.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17966
___
Eli Bendersky added the comment:
For external APIs visible to user code, this can cause some compatibility
problems and users may need to at the very least re-compile this code. So -1
here.
For new external APIs, having const wherever appropriate should be considered
on a case by case basis.
New submission from mrDoctorWho0 .:
Linux i386, Python 2.7.4. Multithread xml parsing via pyexpat cause
segmentation fault
--
components: XML
files: pyexpat_crash_multithread.py
messages: 189131
nosy: mrDoctorWho0..
priority: normal
severity: normal
status: open
title: Mutlithread XML
Barry A. Warsaw added the comment:
On May 13, 2013, at 10:10 AM, Antoine Pitrou wrote:
I agree with Nick here, there's no reason to auto-number constants in
Python. This is not C :-)
Why should they be strings? Why not object()?
Why is `x.value == str(x)` a useful invariant to hold?
Benjamin Peterson added the comment:
LGTM
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17968
___
___
Python-bugs-list mailing list
Antoine Pitrou added the comment:
I agree with Nick here, there's no reason to auto-number constants
in
Python. This is not C :-)
Why should they be strings? Why not object()?
Because strings are readable, I'd say.
--
___
Python tracker
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17966
___
___
Python-bugs-list mailing
Antoine Pitrou added the comment:
I don't want guaranteed O(1) behaviour, just O(1) for the common case
of creating a class, or a few classes, and then removing them.
Then just make sure you call remove_subclass() before PyObject_ClearWeakRefs()
in type_dealloc().
Really, this thing should
Barry A. Warsaw added the comment:
It's not *particularly* silly[1], but I think that with Government backing, he
could make it very silly.
[1] I mean, the right hand side isn't silly at all and the left hand side
merely does a forward aerial half turn every alternative assignment.
Nick Coghlan added the comment:
On 14 May 2013 00:06, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou added the comment:
I agree with Nick here, there's no reason to auto-number constants
in
Python. This is not C :-)
Why should they be strings? Why not object()?
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17959
___
___
Python-bugs-list mailing
Barry A. Warsaw added the comment:
On May 12, 2013, at 06:51 AM, Nick Coghlan wrote:
class Shape(Enum):
... square = 2
... diamond = 1
... circle = 3
... alias_for_square = square
I see Guido pronounced against it, but I'm just registering that I kind of
like this. You could probably
Richard Oudkerk added the comment:
In general, deallocators should have no side effects, I think.
Releaseing the GIL is certainly a side effect.
Notice that socket and file objects also release the GIL when being
deallocated. At least for sockets close() can block (e.g. if you you use the
Ethan Furman added the comment:
So the repr will look like:
Color.red: 'red'
?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17961
___
___
Alejandro Rodas added the comment:
I have merged the two patches: Now it queries the font size as I did in the
original patch, and it also stores the position of the cursor based on Abhishek
Kumar's modification of ZoomFont.py.
--
Added file:
Barry A. Warsaw added the comment:
On May 13, 2013, at 02:06 PM, Antoine Pitrou wrote:
Antoine Pitrou added the comment:
I agree with Nick here, there's no reason to auto-number constants
in
Python. This is not C :-)
Why should they be strings? Why not object()?
Because strings are
Barry A. Warsaw added the comment:
On May 13, 2013, at 02:24 PM, Nick Coghlan wrote:
Yep. Since we no longer have a compelling reason for it to be anything
else, it may as well be the human readable string.
Again, why does it matter? That's the whole point of having a human readable
str() and
Charles-François Natali added the comment:
To be honest I can't find much to say about this proposal,
Hum, OK, I thought it would be a useful addition :-)
but I think it would be good if the time function were configurable (both for
test purposes, and to allow passing e.g. time.monotonic).
Kristján Valur Jónsson added the comment:
I think that socket.close() is the exception rather than the rule here.
What kind of handle is this? It can't be a socket, since that would require
closesocket.
Also, even though an IO call _can_ block, that doesn't mean that we _must_
release the
Charles-François Natali added the comment:
Also, even though an IO call _can_ block, that doesn't mean that
we _must_ release the gil for the duration.
Yes, otherwise some people will complain when the whole interpreter is stuck
while a socket/NFS file handle/whatever is shutdown.
This
Antoine Pitrou added the comment:
To be honest I can't find much to say about this proposal,
Hum, OK, I thought it would be a useful addition :-)
It's probably useful, but I'd have to take a closer look. It's been
a long time I haven't used separate threads for timers...
Note that the
Antoine Pitrou added the comment:
Yes, I think it's too delicate to change in 2.7 right now. As Charles-François
said, daemon threads should be much less crashy in 3.3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17969
Antoine Pitrou added the comment:
Updated patch addressing some of Nick's comments.
--
Added file: http://bugs.python.org/file30252/frame_clear_alt2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17934
Changes by Daniel Urban urban.dani...@gmail.com:
--
nosy: +daniel.urban
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17950
___
___
Kristján Valur Jónsson added the comment:
Well, knowing that they crash less in 3.3 doesn't really fix the problem now,
does it?
We can consider two options then:
1) A multiprocessing specific fix. Removing this handle close gil release
(which is superfluous, since these calls aren't
Changes by Phil Connell pconn...@gmail.com:
--
nosy: +isoschiz, pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17947
___
___
Guido van Rossum added the comment:
A downside of using this is that some extended traceback printers (such as
cgitb.py in the stdlib, or and some things I've seen in web frameworks) won't
be able to print the locals. And pdb's pm() function would lose its value too.
So it'll remain a
Kristján Valur Jónsson added the comment:
That is not sufficient. The weakrefs may have been cleared already if the
deletion comes as a result of garbage collection (which is currently the only
way classes get deleted.)
It is still easily demonstratably correct:
The previous version _only_
Antoine Pitrou added the comment:
Le lundi 13 mai 2013 à 16:14 +, Kristján Valur Jónsson a écrit :
I don't see the point of having 2.7 in bug fix mode if we can't fix
bugs.
Delicate bug fixes may entail regressions, and we've had enough of them
in 2.7.4. You've already patched your own
Richard Oudkerk added the comment:
We can consider two options then:
1) A multiprocessing specific fix. Removing this handle close gil
release (which is superfluous, since these calls aren't blocking in any
real sense) will certainly remove _this_ instance of the crash. An
alternative
Antoine Pitrou added the comment:
One thing: int i should be Py_ssize_t i.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17936
___
___
Antoine Pitrou added the comment:
Should be fixed now.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17968
Roundup Robot added the comment:
New changeset 2187cf880e5b by Antoine Pitrou in branch '3.3':
Issue #17968: Fix memory leak in os.listxattr().
http://hg.python.org/cpython/rev/2187cf880e5b
New changeset 1fa1a021ed23 by Antoine Pitrou in branch 'default':
Issue #17968: Fix memory leak in
Paul Jurczak added the comment:
I admit, it is somewhat silly, but not entirely silly.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17966
___
Amaury Forgeot d'Arc added the comment:
Expat is not thread-safe at the object level, a single Parser cannot be used
from multiple threads.
Pyexpat could add locks to Parser objects.
--
nosy: +amaury.forgeotdarc
stage: - needs patch
___
Python
Guido van Rossum added the comment:
Here's the promised explanation why I want to keep the getframe hack. I'm sure
it won't satisfy everyone, but this will have to do.
There are two parts to my argument. TL;DR: (a) by implementing this hack, we
will maximize user happiness; (b) I expect
Alex Gaynor added the comment:
It could also track tids and raise an error if you attempt to use it from
multiple threads.
--
nosy: +alex
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17970
Amaury Forgeot d'Arc added the comment:
But this would break working code which already uses locks correctly (or some
kind of pool of cached parsers)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17970
Guido van Rossum added the comment:
As I explained in issue 17947, I think that any Python implementation worth its
salt should be able to implement sys.get_calling_module_name() (*), at least
for the case where the caller is top-level code in a module body. That is a
much weaker requirement
Alex Gaynor added the comment:
From PyPy's perspective we don't really care what you name this particular
bikeshed, and it's probably not that important to us (in this particular case).
As far as I know IronPython is the only Python VM that doesn't have _getframe()
support by default (you
Changes by Antoine Pitrou pit...@free.fr:
--
versions: +Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17970
___
___
Guido van Rossum added the comment:
I think turning the __mro__ tuple into a getter is fine. As long as this works
I'm okay:
class C: ...
mro = C.__mro__
del C
assert mro[0].__name__ == 'C'
(The last assert stands in for asserting that the class object must stay alive
as long as the tuple
Mark Lawrence added the comment:
Can this issue to confined to the small round filing cabinet, mainly on the
grounds that I find some of the wording undecipherable?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
Guido van Rossum added the comment:
I'd like to propose one slight tweak to the patch. (Also to enum.py.)
If no module name was passed and _getframe() fails, can you set the __module__
attribute to something that will cause pickling the object to fail? That would
be much better than letting
Richard Oudkerk added the comment:
When pickling a class (or instance of a class) there is already a check
that the invariant
getattr(sys.modules[cls.__module__], cls.__name__) == cls
holds.
import pickle
class A: pass
...
A.__module__ = 'nonexistent'
pickle.dumps(A())
Traceback
Charles-François Natali added the comment:
Just for giggles, here's the glibc default implementation on non Linux
platforms:
http://sourceware.org/git/?p=glibc.git;a=blob;f=misc/getsysstats.c;hb=HEAD
int
__get_nprocs ()
{
/* We don't know how to determine the number. Simply return always 1.
Antoine Pitrou added the comment:
And on Linux, 1 is returned as a fallback when you don't have the
right /sys or /proc entry:
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c
(The enum discussion enlighted me, endless discussions are so fun!)
Do you
Guido van Rossum added the comment:
Great, forget I said anything then.
LGTM to the patch, feel free to commit (with update to Misc/NEWS please).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17941
Eric V. Smith added the comment:
I say close it. Any shell detection is likely to be fragile, and any changes
are likely to break something. It's not worth the risk.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6208
Ned Batchelder added the comment:
Python's goal is not to emulate the suboptimal parts of other languages. We
have dynamic typing, and so can return None from the same function that returns
1. And we have compact expressions like `cpu_count() or 1`, so we don't have
to make unfortunate
Gregory HOULDSWORTH added the comment:
The Text instance created by the last patch has the same parent -in
the Python w hierarchy- as the model widget regardless of the actual
parent implied by the given pathname. Further, pathname is really a tk
level construct: in Python this hierarchy is
Zachary Ware added the comment:
I've come across something in the implementation here that I'd like some
clarification on. What is the purpose of overriding __dir__ in Enum and
EnumMeta? It doesn't change any behavior that I'm aware of, just makes things
look a little nicer when someone
Terry J. Reedy added the comment:
The resolution should be 'This is a gawd-awful mess created by Microsoft 30
years ago and we already do the best we sensibly can to deal with it' ;-) (and
sensible people know it would be a mess from the first day).
To put is another way, the answer to the
Barry A. Warsaw added the comment:
LGTM too. Needs test and docs.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17941
___
___
Python-bugs-list
Antoine Pitrou added the comment:
For external APIs visible to user code, this can cause some
compatibility problems and users may need to at the very least
re-compile this code.
Can you explain exactly which compatibility problems this would cause?
Actually, the point is precisely to make
Charles-François Natali added the comment:
Python's goal is not to emulate the suboptimal parts of other languages.
Well, I'm sure they could have returned -1 or 0, which are valid C
long distinct from any valid integer representing a number of CPUs. If
the libc guys (and many other APIs out
Antoine Pitrou added the comment:
Python's goal is not to emulate the suboptimal parts of other languages.
Well, I'm sure they could have returned -1 or 0, which are valid C
long distinct from any valid integer representing a number of CPUs. If
the libc guys (and many other APIs out there
Eli Bendersky added the comment:
Antoine, I was referring to the discussion linked earlier
(http://mail.python.org/pipermail/python-dev/2006-February/060689.html). Users
of the C API needed to recompile their code and also add preprocessor hacks to
make things compatible with C and C++,
Antoine Pitrou added the comment:
Antoine, I was referring to the discussion linked earlier
(http://mail.python.org/pipermail/python-dev/2006-February/060689.html).
Ok, I've read it through. The problem is specifically with
pointers-to-pointers:
New submission from Eric Promislow:
While much of Komodo's source code has been released under MIT/GPL/LGPL, the
Python debugger hasn't, so I can't post it here. We can work out an
arrangement later, although it might not be necessary once I describe
the problem:
Komodo's Python debugger
Yogesh Chaudhari added the comment:
Based on the last 3 messages by Ned, Charles and Antoine, I keep thinking that
arguments made by Charles are very valid ones and that it would be better to
return 1. I say this (partly from the 'type' argument, but), mainly, *if* its
known that the
1 - 100 of 117 matches
Mail list logo
