[issue12052] round() erroneous for some large arguments
New submission from Neil : round() returns incorrect results for certain large real-integer arguments. Demonstration via interpreter session: >>> x = 2.0**52+1 # Huge, odd double integer near limits of what IEEE format >>> can fully represent in its mantissa part >>> round(x) - x # Difference should be zero 1.0 >>> x = 2.0**53+1 # Even larger odd argument ... >>> round(x) - x # ... returns correct result! 0.0 >>> x = 2.0**51+1 # And a smaller argument ... >>> round(x) - x # ... also returns correct result! 0.0 Discussion: It is not sufficient to implement round(x) as ceil(x - .5) for negative x and floor(x + .5) otherwise, since large integers near the representation limits will be changed incorrectly by these operations, apparently due to internal FPU semantics. One must test the argument first to see if it is a floating-point integer (e.g., math.floor(x) == x), and only bias & truncate towards zero if it is not. C math libraries that implement round(), such as on Linux & MacOS, do this correctly. -- components: None messages: 135724 nosy: nasix priority: normal severity: normal status: open title: round() erroneous for some large arguments type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue12052> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46657] Add mimalloc memory allocator
Neil Schemenauer added the comment: Thanks, I'm indeed interested. Most credit goes to Christian for advancing this. For the missing stdatomic.h, would it be appropriate to have an autoconfig check for it? Can just disable mimalloc if it doesn't exist. -- ___ Python tracker <https://bugs.python.org/issue46657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46657] Add mimalloc memory allocator
Neil Schemenauer added the comment: My preference would be for --with-mimalloc=yes in an upcoming release. For platforms without the required stdatomic.h stuff, they can manually specify --with-mimalloc=no. That will make them aware that a future release of Python might no longer build (if mimalloc is no longer optional). A soft-landing for merging nogil is not a good enough reason to merge mimalloc, IMHO. nogil may never be merged. There should be some concrete and immediate advantage to switch to mimalloc. The idea of using the "heap walking" to improve is cyclic GC is not concrete enough. It's just an idea at this point. I think the (small) performance win could be enough of a reason to merge. This seems to be the most recent benchmark: https://gist.github.com/pablogsal/8027937b71cd30f175ef7c885d3e There is also the long-term maintenance issue. So far, mimalloc upstream has been responsive. The mimalloc code is not so huge or complicated that we couldn't maintain it (if for some reason it gets abandoned upstream). However, I think we would prefer to maintain obmalloc rather than mimalloc, all else being equal. Abandonment by the upstream seems fairly unlikely. So, I'm not too concerned about maintenance. -- ___ Python tracker <https://bugs.python.org/issue46657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46730] Please consider mentioning property without setter when an attribute can't be set
New submission from Neil Girdhar : class C: @property def f(self) -> int: return 2 class D(C): pass D().f = 2 Gives: Traceback (most recent call last): File "/home/neil/src/cmm/a.py", line 10, in D().f = 2 AttributeError: can't set attribute 'f' This can be a pain to debug when the property is buried in a base class. Would it make sense to mention the reason why the attribute can't be set, namely that it's on a property without a setter? -- components: Interpreter Core messages: 413122 nosy: NeilGirdhar priority: normal severity: normal status: open title: Please consider mentioning property without setter when an attribute can't be set versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46730] Please consider mentioning property without setter when an attribute can't be set
Neil Girdhar added the comment: Thank you, this would have saved me a lot of time! On Sat, Feb 12, 2022 at 8:37 PM Alexander wrote: > > Alexander added the comment: > > Indeed, the error message does not help to identify the problem. Moreover, > it collides with similar errors in namedtuple and DynamicClassAttribute > which may lead to even more confusion. > > I made a draft patch that could help with it ( > https://github.com/Alex-Blade/cpython/commit/06df3a72dfe462c8fe4eac60dce0ef059b1738f8), > but I have a concern related to backwards compatibility (that's why no PR). > I don't really understand if according to PEP 387 a change in an exception > message should be considered compatibility breaking? > > -- > nosy: +Alex-Blade > > ___ > Python tracker > <https://bugs.python.org/issue46730> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
New submission from Neil Girdhar : When defining a dataclass, it's possible to define a post-init (__post_init__) method to, for example, verify contracts. Sometimes, when you inherit from another dataclass, that dataclass has its own post-init method. If you want that method to also do its checks, you need to explicitly call it with super. However, if that method doesn't exist calling it with super will crash. Since you don't know whether your superclasses implement post-init or not, you're forced to check if the superclass has one or not, and call it if it does. Essentially, post-init implements an "augmenting pattern" like __init__, ___enter__, __exit__, __array_finalize__, etc. All such methods define an empty method at the top level so that child classes can safely call super. Please consider adding such an empty method to dataclasses so that children who implement __post_init__ can safely call super. -- components: Library (Lib) messages: 413283 nosy: NeilGirdhar priority: normal severity: normal status: open title: dataclasses should define an empty __post_init__ ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: On Sat, Feb 19, 2022 at 2:51 AM Vedran Čačić wrote: > > Vedran Čačić added the comment: > > That "except AttributeError" approach is a powerful bug magnet, since it > can very easily mask real attribute errors stemming from misspelled > attribute names in the __post_init__ call itself. What you should _really_ > do is > > def __post_init__(self): > with contextlib.suppress(AttributeError): > post_init = super().__post_init__ > post_init() > > But of course, nobody will ever write that. > > Great point! Raymond in his "super considered super" video ( > https://youtu.be/xKgELVmrqfs?t=2068) says the right thing to do is to > make your own root which knows exactly what classes it manages, and drops > the supercalls from them (after possibly verifying that all kwargs have > actually been used and so on). > > But in case of dataclasses, usually any class can serve as such a root, > and the main reason people use dataclasses is to avoid boilerplate code. So > I think it would be a nice compromise. > I'm not sure I understand what you're saying here. Anyone can inherit from a class C with the special root and some other class D, and then your introduced root won't catch D's super calls. > > -- > nosy: +veky > > ___ > Python tracker > <https://bugs.python.org/issue46757> > ___ > -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: > I'm not crazy about adding a method to every dataclass just for the 0.1% of > the times it's needed. I'm not sure I totally understand the cost here. You can have a single shared global function that you set on each dataclass. So the only cost would be an entry in each dataclass type's dict. Even if a user creates a thousand dataclasses, that should only be tens of killobytes in pointers. > I think using hasattr or catching the exception is a better way to go. If you choose this, then I think this should be documented under the __post_init__ saying that any time you define __post_init__, you should either be a final class, or else call super. If you call super, you musteither use hasattr(super().__post_init__) or catch the exception. I have to admit, I find this quite ugly from a user perspective. -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: > How would an arbitrary derived class know how to call this? It can't. There > has to be knowledge of the base class's requirements already. Surely knowing > "__post_init__ must be called with some_arg" isn't too different from "I know > __post_init__ doesn't exist". This is exactly the same problem you have with all other "augmenting methods" that have arbitrary parameters (e.g., __init__). When calling super on a non-final class you could simply forward keyword arguments. @dataclass class X: def __post_init__(self, **kwargs): super().__post_init__(**kwargs) ... @dataclass class Y(X): def __post_init__(self, **kwargs): super().__post_init__(**kwargs) ... > I'm still unconvinced, but I'll hold off on making a decision to see if > there's more support. Maybe taking it to python-ideas would be worthwhile. Sounds good, done: https://groups.google.com/g/python-ideas/c/-gctNaSqgew -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: @Raymond yeah I've been thinking about this some more, and there's no way to have a "top level" method with the dataclass decorator. I think I will make a case to have a class version of dataclasses that works with inheritance. Class versions of dataclasses are used in some places like here: https://github.com/google/flax/blob/main/flax/struct.py#L184 They just call dataclass on the class in __init_subclass__. If we had something like this in the standard library, then you could put your empty __post_init__ in that class. You could also make __init__ call super so that mixins would be initialized (right now the collider pattern you showed also breaks if B is not a dataclass, and has a non-trivial __init__). -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46828] math.prod can return integers (contradicts doc)
New submission from Neil Webber : The math module documentation says: Except when explicitly noted otherwise, all return values are floats. But this code returns an integer: from math import prod; prod((1,2,3)) Doc should "explicitly note otherwise" here, I imagine. The issue being wanting to know that the result on all-integer input will be an exact (integer) value not a floating value. -- assignee: docs@python components: Documentation messages: 413741 nosy: docs@python, neilwebber priority: normal severity: normal status: open title: math.prod can return integers (contradicts doc) type: behavior ___ Python tracker <https://bugs.python.org/issue46828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46757] dataclasses should define an empty __post_init__
Neil Girdhar added the comment: @eric Good thinking. Would it make sense to add to the documentation as well that the __post_init__ methods aren't collected, and you should call super's __post_init__ if there is one using something like if hasattr(super(), "__post_init__"): super().__post_init__() Noting this will make it easier to point to the docs if someone wonders when they see code like this. -- ___ Python tracker <https://bugs.python.org/issue46757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1185] py3k: Completely remove nb_coerce slot
Neil Schemenauer added the comment: I made the changes as suggest by Guido. Commited as SVN rev 58226. Thanks for the patch. -- nosy: +nas __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1185> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1134] Parsing a simple script eats all of your memory
Neil Schemenauer added the comment: It looks to me like fp_readl is no longer working as designed and the patch is not really the right fix. The use of "decoding_buffer" is tricky and I think the conversion to bytes screwed it up. It might be clearer to have a separate "decoding_overflow" struct member that's used for overflow rather than overloading "decoding_buffer". -- nosy: +nas __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1134> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1518] Fast globals/builtins access (patch)
Neil Toronto added the comment: Christian: Thanks for that, I'll have to remember DEBUG_LEAK in the future. :) It looks like it may be acting correctly since there *is* now a fastglobals object that needs collecting, and also a new tuple built from co_names + "__builtins__". I don't know why it wouldn't collect those in the shell, though. The shell does create a new stack frame for every command (where a function's commands are all run in a single stack frame), but I don't know why that would matter. I'll look further into it. Chris: The build problems should be fixed in the next patch. Thanks for spending so much time on benchmarking this. Regarding PyEval_EvalCode creating a PyFastGlobalsObject: I'm not sure whether it's right thing to do, but I think it is. PyEval_EvalCode gets called for eval, exec, running an imported module's code, and everything in the interactive prompt - basically, running any code that's not in a function or generator. (I think that covers everything.) It seems like the patch has PyEval_EvalCode doing the right thing in general, but it may suffer a bit in benchmarks. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1518> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9637] docs do not say that urllib uses HTTP_PROXY
Neil Muller added the comment: This patch is now more than a year old with no comment. What needs to happen to get this bug fixed? -- ___ Python tracker <http://bugs.python.org/issue9637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11439] subversion keyword breakage
Neil Muller added the comment: SVN_Revision.diff replaces the remaining "$Revision$" keywords in 2.7 with the values from the last SVN checkout I have. This seems the correct minimal fix for the issues caused by code parsing the revision tag in Python 2. I've left the various other keywords untouched in 2.7 (mainly $Id$ tags) untouched, since they appear to be unused. -- keywords: +patch Added file: http://bugs.python.org/file22578/SVN_Revision.diff ___ Python tracker <http://bugs.python.org/issue11439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11439] subversion keyword breakage
Neil Muller added the comment: This patch removes or replaces a number SVN keywords which aren't buried in comments. I've removed '__revision__ = "$Id$"' cases - mainly present in distutils - as no-one appears to using these. I've replaced values in tarfile.py, but they can probably be removed as well. -- Added file: http://bugs.python.org/file22579/cleanup_3.3svn_keywords.diff ___ Python tracker <http://bugs.python.org/issue11439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3605] Py_FatalError causes infinite loop
Neil Aspinall added the comment: Would it be possible for this issue's fix (PyErr_Occurred() returning null when the thread state is null) to be applied to the 2.7 branch? -- nosy: +naspinal ___ Python tracker <http://bugs.python.org/issue3605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9616] copy.deepcopy() copying pointers from a dict/dict/list, should copy values
New submission from Neil Harkins :
hi. after using deepcopy() on a nested dict/list structure,
i noticed that modifications to the deepcopied structure were
affecting the original. this looks to me like a serious bug:
>>> import copy
>>> foo = { 'a':[1,2,3], 'b':{'c':[4,5]} }
>>> bar = copy.deepcopy(foo)
>>> id(foo)
4297360512
>>> id(bar)
4297373104
>>> id(foo['a'])
4299410752
>>> id(bar['a'])
4299760200
>>> id(foo['b'])
4297371984
>>> id(bar['b'])
4297373920
>>> id(foo['b']['c'])
4299721040
>>> id(bar['b']['c'])
4299761496
>>> id(foo['b']['c'][0])
4297074656
>>> id(bar['b']['c'][0])
4297074656
--
components: Extension Modules
messages: 114007
nosy: nharkins
priority: normal
severity: normal
status: open
title: copy.deepcopy() copying pointers from a dict/dict/list, should copy
values
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue9616>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9616] copy.deepcopy() copying pointers from a dict/dict/list, should copy values
Neil Harkins added the comment: thanks for the quick response. that was just my working up a simplified repro, but you are correct: on modification there, it gets a new id() location. totally not what i would've expected (python flags it for copying when it changes, to save space?) however i am still seeing the problem in my code, so i will continue to whittle it down to a simpler repro, and hopefully add it here later today. -- ___ Python tracker <http://bugs.python.org/issue9616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9616] copy.deepcopy() copying pointers from a dict/dict/list, should copy values
Neil Harkins added the comment: learn something everyday. i have found the bug in my code, deepcopy() is not to blame. thx for your time! -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue9616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1512791] module wave does no rounding
Neil Tallim added the comment: The differences are small enough that it probably doesn't matter which one of us makes the extra changes. It'll take one step less for you to implement them while applying the fixes, so it's probably easiest if I leave that in your court. Thanks for asking if I had anything to add, though, Mark. :) The docs-update could probably be something as simple as... Wave_write.setframerate(n) Set the frame rate to n. Fractional inputs are rounded to the nearest integer. That's pretty consistent with the way the rest of the documentation for this module has been written. -- ___ Python tracker <http://bugs.python.org/issue1512791> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1512791] module wave does no rounding
Neil Tallim added the comment: I use the wave module a fair bit and never once encountered this issue, so, yeah, it's probably a pretty low priority for backporting. It's definitely an edge-case sort of thing, the likes of which anyone affected has already handled in their application-level code. This just makes expected behaviour default behaviour -- if an int is already going in, as would be the case if someone is pre-processing their inputs as a workaround in existing code, it shouldn't change anything. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue1512791> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9747] os.getresgid() documentation mentions "user ids", not "group ids"
New submission from Neil Tallim : Super-low-priority (it's obvious from context and unlike to confuse anyone who knows what they're looking at), but the os module's description for getresgid() is "Return a tuple (rgid, egid, sgid) denoting the current process’s real, effective, and saved user ids." It should be "Return a tuple (rgid, egid, sgid) denoting the current process’s real, effective, and saved group ids." -- assignee: d...@python components: Documentation messages: 115411 nosy: Red HamsterX, d...@python priority: normal severity: normal status: open title: os.getresgid() documentation mentions "user ids", not "group ids" versions: Python 2.7, Python 3.3 ___ Python tracker <http://bugs.python.org/issue9747> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1466065] base64 module ignores non-alphabet characters
Neil Tallim added the comment: I agree that it does look like RFC 3548 implicitly denies the use of \r and \n. A few *very* simple tests also makes it look like ommitting them breaks nothing, but we'd need to add a test that includes them before applying the patch. Other than that, I agree with everything and find the email6 notes intruiging. Would you like me to update the patch, or do you want to do it? -- ___ Python tracker <http://bugs.python.org/issue1466065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10120] concurrent.futures module is not installed properly
New submission from Neil Muller : with make install (r85564), lib/python3.2/concurrent is created, but the futures module is not installed there. The attached trivial patch fixes this here. -- files: futures-Makefile.diff keywords: patch messages: 118858 nosy: Neil Muller priority: normal severity: normal status: open title: concurrent.futures module is not installed properly Added file: http://bugs.python.org/file19249/futures-Makefile.diff ___ Python tracker <http://bugs.python.org/issue10120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10120] concurrent.futures module is not installed properly
Neil Muller added the comment: There isn't an entry for anyone in maintainers.rst for concurrent.futures either. That should probably also be fixed. -- nosy: +bquinlan ___ Python tracker <http://bugs.python.org/issue10120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1343] XMLGenerator: nice elements
Neil Muller added the comment: So what still needs to happen to get this in? Patch still applies to current python 3.2 trunk (r85564). -- ___ Python tracker <http://bugs.python.org/issue1343> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9011] ast_for_factor unary minus optimization changes AST
Neil Schemenauer added the comment: I'm late to the party but looks like Mark has a good handle on the issues. I would recommend not changing behavior in a bugfix release. I'm pretty sure code "in the wild" would be broken. -- ___ Python tracker <http://bugs.python.org/issue9011> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
Neil Schemenauer added the comment: Closing this bug. I don't think it makes sense to change the mhlib module in bugfix release. My patch is fairly simple but not simple enough to make me feel comfortable. -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue7759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10241] gc fixes for module m_copy attribute
New submission from Neil Schemenauer : I'm trying implement some saner module shutdown procedure (similar to issue 812369). One of the many problems I've run into is that the GC doesn't know about the m_copy attribute of modules. I think the attached patch is correct. tp_tranverse exposes m_copy if it is non-NULL. tp_clear calls Py_CLEAR on it. -- assignee: loewis components: Interpreter Core files: module_m_copy.txt messages: 119957 nosy: benjamin.peterson, loewis, nascheme priority: normal severity: normal status: open title: gc fixes for module m_copy attribute type: behavior Added file: http://bugs.python.org/file19423/module_m_copy.txt ___ Python tracker <http://bugs.python.org/issue10241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10255] refleak in initstdio
New submission from Neil Schemenauer : It looks to me like initstdio leaks a reference to "open". AFAIK, PyObject_SetAttrString() does not steal a reference. -- assignee: pitrou components: Interpreter Core files: initstdio_refleak.txt messages: 120008 nosy: nascheme, pitrou priority: normal severity: normal status: open title: refleak in initstdio type: resource usage Added file: http://bugs.python.org/file19434/initstdio_refleak.txt ___ Python tracker <http://bugs.python.org/issue10255> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10241] gc fixes for module m_copy attribute
Neil Schemenauer added the comment: Oops, my patch doesn't work since m_base can be shared by more than one module instance. I guess a different solution would be to cleanup the m_copy references on interpreter shutdown. Somehow they would have to be found though. -- ___ Python tracker <http://bugs.python.org/issue10241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10241] gc fixes for module m_copy attribute
Neil Schemenauer added the comment: The attached patch seems better. The copies of module dicts stored in the interpreter state are dereferenced when the interpreter shuts down. -- Added file: http://bugs.python.org/file19509/module_m_copy2.txt ___ Python tracker <http://bugs.python.org/issue10241> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10333] Remove ancient backwards compatibility GC API
New submission from Neil Schemenauer : I think it should be safe to remove some backwards compatibility cruft. This was introduced during the 2.3 development cycle. -- files: gc_cruft.txt messages: 120554 nosy: nascheme priority: low severity: normal status: open title: Remove ancient backwards compatibility GC API Added file: http://bugs.python.org/file19510/gc_cruft.txt ___ Python tracker <http://bugs.python.org/issue10333> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11384] Deprecate, remove or document (correctly) os.popen
Neil Muller added the comment: See issue6490 , which covers much of the same ground. -- nosy: +Neil Muller ___ Python tracker <http://bugs.python.org/issue11384> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11439] subversion keyword breakage
Neil Muller added the comment: This also affects a number of files under Lib, including some that set their version using "$Revision$". Since I stumbled on this issue by encountering some code that checks the version string in tkinker breaking, this is an issue that can break existing code. Mercurial does have the keyword extension (http://mercurial.selenic.com/wiki/KeywordExtension) which can provide something similar, but should be some sort of recommended configuration for this and there'll be discrepancies between the id's from svn and mercurial (which may or may not be an issue in practice). find ./Lib -name "*.py" | xargs grep -n '"\$Revision\$"' ./Lib/tarfile.py:32:__version__ = "$Revision$" ./Lib/pydoc.py:45:__version__ = "$Revision$" ./Lib/tkinter/__init__.py:33:__version__ = "$Revision$" ./Lib/pickle.py:26:__version__ = "$Revision$" # Code version -- nosy: +Neil Muller ___ Python tracker <http://bugs.python.org/issue11439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10465] gzip module calls getattr incorrectly
New submission from Neil Muller : gzip._PaddedFile.__getattr__ chains out to getattr, but does so incorrectly (found via running the numpy test suite). The attached patch fixes this. -- files: gzip_getattr.diff keywords: patch messages: 121607 nosy: Neil Muller priority: normal severity: normal status: open title: gzip module calls getattr incorrectly Added file: http://bugs.python.org/file19652/gzip_getattr.diff ___ Python tracker <http://bugs.python.org/issue10465> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10465] gzip module calls getattr incorrectly
Neil Muller added the comment: Add a test demonstrating the error. -- Added file: http://bugs.python.org/file19653/gzip_getattr_test.diff ___ Python tracker <http://bugs.python.org/issue10465> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6490] os.popen documentation in 2.6 is probably wrong
Neil Muller added the comment: The attached patch grabs the os.popen documentation from python 2.7, throws away the deprecation notes, and adds a pointer to subprocess.Popen for more details. -- keywords: +patch nosy: +Neil Muller Added file: http://bugs.python.org/file19674/os_popen_doc.diff ___ Python tracker <http://bugs.python.org/issue6490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9637] docs do not say that urllib uses HTTP_PROXY
Changes by Neil Muller : -- versions: +Python 3.2 -Python 2.7 ___ Python tracker <http://bugs.python.org/issue9637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9637] docs do not say that urllib uses HTTP_PROXY
Neil Muller added the comment: The problem is that the getproxies_environment function converts all environment variables to lower case before deciding whether to use the name. This means that whichever ends up last in os.environment will be used. The attached patch does two things. It changes the behaviour to prefer the all lower case version if it exists, and adds a note to the ProxyHandler description noting that the environment variable used is not case sensitive, although the all lower case version will be preferred. The behaviour change is debatable, but preferring the lower case name is likely to be less surprising in general. -- keywords: +patch nosy: +Neil Muller Added file: http://bugs.python.org/file19678/urllib_PROXY.diff ___ Python tracker <http://bugs.python.org/issue9637> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1486713] HTMLParser : A auto-tolerant parsing mode
Neil Muller added the comment: #975556 and #1046092 look like they should also be superseded by this. -- nosy: +Neil Muller ___ Python tracker <http://bugs.python.org/issue1486713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue975556] HTMLParser lukewarm on bogus bare attribute chars
Neil Muller added the comment: This should probably be solved as part of #1486713 . -- nosy: +Neil Muller ___ Python tracker <http://bugs.python.org/issue975556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1046092] HTMLParser fix to accept mailformed tag attributes
Neil Muller added the comment: I think this change is makes the parser far too lenient. Something like the explicit tolerant mode proposed in #1486713 is a better solution. -- nosy: +Neil Muller ___ Python tracker <http://bugs.python.org/issue1046092> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6490] os.popen documentation in 2.6 is probably wrong
Changes by Neil Muller : -- versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue6490> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3054] test_disutils fails
Neil Schemenauer <[EMAIL PROTECTED]> added the comment: Looks like this has exposed some ugly code. From setup.py: # Figure out the location of the source code for extension modules # (This logic is copied in distutils.test.test_sysconfig, # so building in a separate directory does not break test_distutils.) I believe the proper fix is to move some of the code from setup.py into sysconfig so that it does more than just set "python_build" when running inside a Python build directory. For example, it should also add /Include to the standard list of includes that distutils uses. The attached patch fixes test_build_ext.py to use the right source file (perhaps it should be tested on Windows). The test still fails because Python.h cannot be found. -- nosy: +nas Added file: http://bugs.python.org/file10659/test_ext_src.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3054] test_disutils fails
Neil Schemenauer <[EMAIL PROTECTED]> added the comment: I think my previous patch combined with sysconfig_builddir.patch fixes this issue. Someone will need to test on other platforms. Note that the messy code in setup.py and in the tests should still be cleaned up. BTW, distutils is a den of stinking evil. ;-) Added file: http://bugs.python.org/file10660/sysconfig_builddir.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3054] test_disutils fails
Neil Schemenauer <[EMAIL PROTECTED]> added the comment: One final patch for today (get_python_inc.patch). The patch combines my previous two patches and also cleans up some ugly code in setup.py and test_sysconfig.py. The source of the ugliness was that get_python_inc() did not work when running from within a build directory. The patch also fixes the header dependency feature introduced in svn r60287 (it assumed that builddir == srcdir and also that os.path.sep == '/'). Added file: http://bugs.python.org/file10663/get_python_inc.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3054] test_disutils fails
Changes by Neil Schemenauer <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10659/test_ext_src.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3054] test_disutils fails
Changes by Neil Schemenauer <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10660/sysconfig_builddir.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3054> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
Neil Muller <[EMAIL PROTECTED]> added the comment: The attached patch is against recent svn (r64442), and adds samwyse's refactoring of the class. The test for server responses is made less restrictive when the request isn't HTTP/1.1. -- nosy: +Neil Muller Added file: http://bugs.python.org/file10684/BaseHTTPServer_continue_2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1491> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3617] Add MS EULA to the list of third-party licenses in the Windows installer
Neil Hodgson <[EMAIL PROTECTED]> added the comment: The recommended addition includes the 'excluded license' section which appears unnecessary as Python does not distribute any source code redistributables, only the .DLL file which is a binary executable. Including this is likely to confuse those who wish to use the GPL when distributing projects which include Python since the license is trying to limit their redistributing something they will not be able to find and so remove from Python. -- nosy: +nyamatongwe ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3617> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7753] newgil backport
Neil Schemenauer added the comment: Looks like the 2.7 patch has a spurious change to /Lib/unittest/runner.py. -- nosy: +nascheme ___ Python tracker <http://bugs.python.org/issue7753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7753] newgil backport
Neil Schemenauer added the comment: Here is an updated set of patches that includes the ceval_gil.h file as well as the documentation changes. -- Added file: http://bugs.python.org/file15974/gil-2.7.txt ___ Python tracker <http://bugs.python.org/issue7753> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4698] Solaris buildbot failure on trunk in test_hostshot
Changes by Neil Schemenauer : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue4698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1220756] Re-importing embedded thread dumps core
Changes by Neil Schemenauer : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue1220756> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
New submission from Neil Schemenauer : Btrfs does not maintain a link count for directories (MacOS does the same I think). That confuses mhlib.py because it uses os.stat().st_nlinks as an optimization. The attached patch removes the optimization and make test_mhlib pass on Btrfs (and probably HFS+) filesystems. -- files: mhlib_nlinks.txt messages: 98169 nosy: nascheme priority: normal severity: normal status: open title: mhlib fails on Btrfs filesystem (test_mhlib failure) type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file15975/mhlib_nlinks.txt ___ Python tracker <http://bugs.python.org/issue7759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
Neil Schemenauer added the comment: On Sat, Jan 23, 2010 at 06:09:33PM +, Antoine Pitrou wrote: > The documentation mentions that mhlib is deprecated and mailbox > should be used instead. Is there any point in trying to fix it? It looks like Btrfs will eventually conform to traditional st_nlink behavior. However, that still leaves HFS+. Perhaps the easiest fix would be to have the unit test check for weird st_nlink behavior by creating a directory with a subdirectory. If something is weird, skip testing mhlib. The downside to that solution is that someone might use mhlib on a HFS+ filesystem and encounter buggy behavior. I can imagine that removing the optimization can make mhlib much slower for large mail boxes. Maybe that would be better than risking lost mail though. On modern machines maybe it doesn't matter much. Neil -- ___ Python tracker <http://bugs.python.org/issue7759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
Neil Schemenauer added the comment: On Sun, Jan 24, 2010 at 01:25:18AM +, Antoine Pitrou wrote: > That wasn't really my question. What I ask is: since mhlib is > deprecated, why do we need to fix it while people are encouraged to use > mailbox instead? Sorry, I don't understand what you are proposing. Do you mean we should just let the test fail for people who develop on HFS+ and Btrfs filesystems? That seems not so good. > And, besides, does mailbox show the same problem? No, it doesn't have that optimization. Neil -- ___ Python tracker <http://bugs.python.org/issue7759> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7881] Hardcoded path, unsafe tempfile in test_logging
New submission from Neil Schemenauer :
The commit for issue #7868 added the following line to test_logging:
print >> open('/tmp/tmp.txt', 'w'), type(logger)
I'm not sure if that was intentional but it should be fixed. For one, that
path does not necessarily exist. Secondly, opening a file in a world writable
directory like that is a potential security problem. A simple fix would be to
use tempfile.TemporaryFile().
--
assignee: vinay.sajip
components: Tests
messages: 99032
nosy: nascheme, vinay.sajip
severity: normal
stage: needs patch
status: open
title: Hardcoded path, unsafe tempfile in test_logging
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue7881>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7885] test_distutils fails if Python built in separate directory
New submission from Neil Schemenauer : Lib/test/test_distutils.py crashes if Python was built in a directory other than the source directory. Using a separate build directory is handy if you are building Python with different sets of configure options since you only need one copy of the source. For example, in the source directory: $ mkdir build-opt $ cd build-opt $ ../configure $ make $ cd .. $ mkdir build-debug $ cd build-debug $ ../configure --with-pydebug $ make I fixed a similar problem in rev 69304 but now it is broken again. I get: /tmp/tmpbxrmiB/xxmodule.c:17:20: error: Python.h: No such file or directory Probably it is looking in the wrong directory for Python.h (assuming that the cwd is the top-level directory of the source). -- assignee: tarek components: Tests messages: 99054 nosy: nascheme, tarek priority: normal severity: normal stage: needs patch status: open title: test_distutils fails if Python built in separate directory type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7885> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6231] ElementInclude may drop text
Neil Muller added the comment: It looks like this issue was missed in the recent ElementTree update. Attached is an updated diff for py3k. -- nosy: +flox Added file: http://bugs.python.org/file16646/ElementInclude_py3k.diff ___ Python tracker <http://bugs.python.org/issue6231> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6231] ElementInclude may drop text
Neil Muller added the comment: Similiarly updated patch against current trunk -- Added file: http://bugs.python.org/file16647/ElementInclude.diff ___ Python tracker <http://bugs.python.org/issue6231> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
Neil Muller added the comment: Poking this issue with updated patches. Patch against py3k. -- Added file: http://bugs.python.org/file16650/posixmodule_comb_py3k.patch ___ Python tracker <http://bugs.python.org/issue2768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
Changes by Neil Muller : Added file: http://bugs.python.org/file16651/posixmodule_comb.patch ___ Python tracker <http://bugs.python.org/issue2768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
Neil Muller added the comment: Poking the issue with an updated patch for trunk. -- Added file: http://bugs.python.org/file16652/BaseHTTPServer_continue_3.patch ___ Python tracker <http://bugs.python.org/issue1491> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
Neil Muller added the comment: And a py3k version (although the conversion can be improved). -- Added file: http://bugs.python.org/file16653/BaseHTTPServer_continue_3_py3k.patch ___ Python tracker <http://bugs.python.org/issue1491> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
Neil Muller added the comment: Fair enough. Possible doc patch attached. -- Added file: http://bugs.python.org/file16654/fileno_doc.diff ___ Python tracker <http://bugs.python.org/issue2768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
Neil Muller added the comment: More fleshed out doc patch. Mention caveats about using file descriptors directly, add note to ftruncate similar to that for other dangerous methods. -- Added file: http://bugs.python.org/file16655/fileno_doc.diff ___ Python tracker <http://bugs.python.org/issue2768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3409] ElementPath.Path.findall problem with unicode input
Neil Muller added the comment: With the recent ElementTree changes on trunk, this bug no longer applies, AFAICS. -- nosy: +Neil Muller, flox ___ Python tracker <http://bugs.python.org/issue3409> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1028432] Specify a source baseurl for bdist_rpm.
Neil Muller added the comment: > Is it preferable to specify a URL for the "Source" > field in a .spec file (rather than just a filename)? Fedora (see for example http://fedoraproject.org/wiki/Packaging/SourceURL ) encourages using a full url when available, so having some way of specifying the url looks like a useful addition to me. -- nosy: +Neil Muller ___ Python tracker <http://bugs.python.org/issue1028432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1560] PATCH: Attribute lookup caching
New submission from Neil Toronto: I've attached a patch to accelerate type and instance lookups using a specialized cache. It includes a benchmarking script (fastattr_test.py) that tests both successful and failing lookups on list, dict and tuple, and a simple, deep hierarchy. Benchmark results are here: http://spreadsheets.google.com/ccc?key=pHIJrYc_pnIUpTm6QSG2gZg&hl=en_US Everything tested in fastattr_test.py is faster except list.__init__ and list().__init__ (and I haven't got a clue why, so some pointers would be nice). Pybench is faster overall. TryRaiseExcept is faster for some non-obvious reason. CreateNewInstances is a little slower, which I'll discuss in a bit. Setting type attributes is slower, but I haven't benchmarked that yet. It may not happen often enough that we care as long as it's not noticeably slow in general usage. In benchmarks the patch does a little slower, it may be in part because I removed a manually inlined _PyType_Lookup from PyObject_GenericGetAttr. Something like it can be put back if it needs to be. It works in a fairly obvious way. Every type has a tp_cache, which is a custom dict type that caches the first value in a type dict in the MRO for a given name. Lazy cached lookups are done via _PyType_CachingLookup, which is a drop-in replacement for _PyType_Lookup. The only way to set an attribute on a type is via its setattr, so type's setattr notifies subclasses to invalidate specific cache entries. The cache dict is custom for two reasons: 1. The regular dict is a little slower because it's more general. The custom dict is restricted to string-exact keys (types fall back to no caching if this constraint is violated). Because it's internal to typeobject.c, it's safe for lookups to return entry pointers rather than values, so lookups only have to be done once, even on cache misses. 2. Caching missing attributes is crucial for speed on instance attribute lookups. Both type and metatype instances check all the way through the MRO for a descriptor before even trying to find an attribute. It's usually missing. Having to go through the cache machinery to find a missing attribute for every attribute lookup is expensive. However, storing all missing attribute queries in the cache is bad - it can grow unboundedly through hasattr(inst, ) calls. What's needed is a dict that knows that some of its entries are transient and doesn't copy them over on resize. It wasn't clear how to implement that efficiently with a regular dict (I suspect it's not possible), so I created a new dict type that considers entries transient (meaning the attribute is missing) when me_value == NULL. This is also very good for failing hasattr(...) calls and try...inst.method()...except style duck typing. Now, about the CreateNewInstances benchmark. It creates three classes with __init__ methods that assign a few attributes. The missing descriptors are cached, and then the cache is resized, which clears the cached missing descriptors. Increasing the minimum cache size from 4 to 8 clears up the problem. However, for any class, SOME minimum cache size will properly cache missing descriptors and some other one won't. I have some solutions for this floating around in my head, which I'll try shortly. (One idea is for missing attributes, if they're not missing on the *instance*, to be permanent in the cache.) But I'd like to get this patch off my hard drive and into other people's hands for testing, poking, prodding, and getting feedback on what's going right and what's not. -- components: Interpreter Core files: fastattr-0.patch.txt messages: 58229 nosy: ntoronto severity: normal status: open title: PATCH: Attribute lookup caching versions: Python 2.6 Added file: http://bugs.python.org/file8883/fastattr-0.patch.txt __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1560> __Index: Include/dictobject.h === --- Include/dictobject.h(revision 59362) +++ Include/dictobject.h(working copy) @@ -111,6 +111,8 @@ PyAPI_FUNC(int) PyDict_Contains(PyObject *mp, PyObject *key); PyAPI_FUNC(int) _PyDict_Contains(PyObject *mp, PyObject *key, long hash); +PyAPI_FUNC(int) PyDict_IsStringKeysOnly(PyObject *mp); + /* PyDict_Update(mp, other) is equivalent to PyDict_Merge(mp, other, 1). */ PyAPI_FUNC(int) PyDict_Update(PyObject *mp, PyObject *other); Index: Include/object.h === --- Include/object.h(revision 59362) +++ Include/object.h(working copy) @@ -391,6 +391,7 @@ PyAPI_FUNC(PyObject *) PyType_GenericNew(PyTypeObject *, PyObject *, PyObject *); PyAPI_FUNC(PyObject *) _PyType_Lookup(PyTypeObject *, PyObject *); +PyAPI_F
[issue1700288] Armin's method cache optimization updated for Python 2.6
Neil Toronto added the comment: Attribute access that happens only once or very infrequently probably shouldn't go through the cache machinery - it'll only slow things down. (Updating slots for example.) Maybe _PyType_Lookup should remain the same, with _PyType_CachingLookup added for attribute access via type/instance getattr. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1700288> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1700288] Armin's method cache optimization updated for Python 2.6
Neil Toronto added the comment: I've attached the microbenchmarks I was using for my own version of attribute caching. For list, tuple, dict, and a deep hierarchy, it tests accessing type attributes (cls.__class__), class attributes (cls.__init__), class attributes via instance (inst.__class__), and instance attributes (inst.__init__), using LOAD_ATTR and hasattr. It also tests hasattr with missing attributes. -- nosy: +ntoronto Added file: http://bugs.python.org/file8887/fastattr_test.py _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1700288> _#!/usr/bin/python import timeit, random, time, sys MULTIPLIER = 1 class A(object): def __init__(self, *args): pass class B(A): pass class C(B): pass class D(C): pass class E(D): pass class F(E): pass class G(F): pass class H(G): def __init__(self): pass class I(H): pass def test_init(tmp): tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__ def test_class(tmp): tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__ def test_has_init(tmp): hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__') hasattr(tmp, '__init__'); hasattr(tmp, '__init__
[issue1568] PATCH: Armin's attribute lookup caching for 3.0
New submission from Neil Toronto:
This is a half-port of the patches in #1685986 and #1700288 to Python
3.0. Speedups are about the same as in those patches applied to their
respective Python versions for minibenchmarks (included in the patch as
fastattr_test_py3k.py): 5%-30% or more depending on how deep the class
hierarchy is. Pybench takes 4% less time on my system, and pystone takes
6% less time.
(Pybench would do better, but SpecialClassAttribute runs long and spends
half its time setting class attributes.)
The main difference between this and the previous patches is that 3.0's
simplifications allow a smaller footprint and make it easier to analyze
its correctness. Specifically, the fact that every object in the MRO
must be a type allows us to assume that every attribute lookup is
cacheable, and allows integration into the update_subclasses mechanism
when attributes are set. The lack of compiled extension modules means
there is no flag to check to see whether a type object supports caching.
--
components: Interpreter Core
files: python30-attrcache.diff
messages: 58274
nosy: ntoronto
severity: normal
status: open
title: PATCH: Armin's attribute lookup caching for 3.0
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8889/python30-attrcache.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1568>
__Index: Python/pythonrun.c
===
--- Python/pythonrun.c (revision 59400)
+++ Python/pythonrun.c (working copy)
@@ -501,6 +501,9 @@
/* Cleanup Unicode implementation */
_PyUnicode_Fini();
+
+ /* Report counts of attribute cache hits/misses (if enabled) */
+ PyType_Fini();
/* reset file system default encoding */
if (!Py_HasFileSystemDefaultEncoding) {
Index: Include/object.h
===
--- Include/object.h (revision 59400)
+++ Include/object.h (working copy)
@@ -373,6 +373,9 @@
PyObject *tp_subclasses;
PyObject *tp_weaklist;
destructor tp_del;
+ /* Unique cache ID per type, assigned when bases change (see
+ mro_internal) */
+ PY_LONG_LONG tp_cache_id;
#ifdef COUNT_ALLOCS
/* these must be last and never explicitly initialized */
Index: Include/pythonrun.h
===
--- Include/pythonrun.h (revision 59400)
+++ Include/pythonrun.h (working copy)
@@ -141,6 +141,7 @@
PyAPI_FUNC(void) PyBytes_Fini(void);
PyAPI_FUNC(void) PyFloat_Fini(void);
PyAPI_FUNC(void) PyOS_FiniInterrupts(void);
+PyAPI_FUNC(void) PyType_Fini(void);
/* Stuff with no proper home (yet) */
PyAPI_FUNC(char *) PyOS_Readline(FILE *, FILE *, char *);
Index: fastattr_test_py3k.py
===
--- fastattr_test_py3k.py (revision 0)
+++ fastattr_test_py3k.py (revision 0)
@@ -0,0 +1,265 @@
+#!/usr/bin/python
+
+import timeit, random, time, sys
+
+MULTIPLIER = 1
+
+
+class A(object):
+ def __init__(self, *args):
+ pass
+
+class B(A): pass
+
+class C(B): pass
+
+class D(C): pass
+
+class E(D): pass
+
+class F(E): pass
+
+class G(F): pass
+
+class H(G):
+ def __init__(self):
+ pass
+
+class I(H): pass
+
+
+def test_init(tmp):
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+
+
+def test_class(tmp):
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__c
[issue1568] PATCH: Armin's attribute lookup caching for 3.0
Neil Toronto added the comment:
This patch adds the ability to invalidate all of a subclasses' cache
entries upon setattr rather than updating just one cache entry. It's not
clear which of these is the Right Thing To Do, so I've made it an #ifdef
for now. It defaults to updating.
Added file: http://bugs.python.org/file8891/python30-attrcache-1.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1568>
__Index: Python/pythonrun.c
===
--- Python/pythonrun.c (revision 59400)
+++ Python/pythonrun.c (working copy)
@@ -501,6 +501,9 @@
/* Cleanup Unicode implementation */
_PyUnicode_Fini();
+
+ /* Report counts of attribute cache hits/misses (if enabled) */
+ PyType_Fini();
/* reset file system default encoding */
if (!Py_HasFileSystemDefaultEncoding) {
Index: Include/object.h
===
--- Include/object.h (revision 59400)
+++ Include/object.h (working copy)
@@ -373,6 +373,9 @@
PyObject *tp_subclasses;
PyObject *tp_weaklist;
destructor tp_del;
+ /* Unique cache ID per type, assigned when bases change (see
+ mro_internal) */
+ PY_LONG_LONG tp_cache_id;
#ifdef COUNT_ALLOCS
/* these must be last and never explicitly initialized */
Index: Include/pythonrun.h
===
--- Include/pythonrun.h (revision 59400)
+++ Include/pythonrun.h (working copy)
@@ -141,6 +141,7 @@
PyAPI_FUNC(void) PyBytes_Fini(void);
PyAPI_FUNC(void) PyFloat_Fini(void);
PyAPI_FUNC(void) PyOS_FiniInterrupts(void);
+PyAPI_FUNC(void) PyType_Fini(void);
/* Stuff with no proper home (yet) */
PyAPI_FUNC(char *) PyOS_Readline(FILE *, FILE *, char *);
Index: fastattr_test_py3k.py
===
--- fastattr_test_py3k.py (revision 0)
+++ fastattr_test_py3k.py (revision 0)
@@ -0,0 +1,265 @@
+#!/usr/bin/python
+
+import timeit, random, time, sys
+
+MULTIPLIER = 1
+
+
+class A(object):
+ def __init__(self, *args):
+ pass
+
+class B(A): pass
+
+class C(B): pass
+
+class D(C): pass
+
+class E(D): pass
+
+class F(E): pass
+
+class G(F): pass
+
+class H(G):
+ def __init__(self):
+ pass
+
+class I(H): pass
+
+
+def test_init(tmp):
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+ tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__; tmp.__init__
+
+
+def test_class(tmp):
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__; tmp.__class__
+ tmp.__class__; tmp.__
[issue1266570] PEP 349: allow str() to return unicode
Neil Schemenauer added the comment: On Sat, Dec 08, 2007 at 05:14:45AM -, Alexandre Vassalotti wrote: > The PEP has been deferred and the patch is out of date. So, is this > change still wanted? I still think it would make things easier for people using Unicode with Python 2.x. However, there does not seem to be much community interest in the change. Neil _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1266570> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1560] PATCH: Attribute lookup caching
Neil Toronto added the comment: Yes, as well #1700288 (Armin's attribute lookup caching patch ported to 2.6) or #1685986 (Armin's original for 2.4), or whatever Raymond finds most convenient. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1560> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1560] PATCH: Attribute lookup caching
Neil Toronto added the comment: Sorry - I'll be more clear. I'd love to see 2.6 get attribute lookup caching, and Kevin's port (#1700288) of Armin's original 2.4 patch (#1685986) does that for 2.6. #1685986 (2.4) should be closed and #1700288 (2.6) should remain open. But Raymond has indicated that he's currently working on #1685986 - I think for 2.6, but it's not clear. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1560> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1604] collections.deque.__init__ doesn't initialize
New submission from Neil Cerutti: Passing an interable to the __init__ method of an existing deque appends those elements, rather than reinitializing the deque with the items. This is contrary to how list.__init__ works. test_deque.py verifies the (possibly) incorrect behavior. -- components: Library (Lib) messages: 58501 nosy: Horpner, rhettinger severity: normal status: open title: collections.deque.__init__ doesn't initialize type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1604> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1568] PATCH: Armin's attribute lookup caching for 3.0
Neil Toronto added the comment: Well horse pucky. I plum forgot about deletes. I've attached an update that properly clears the cache entry for the deleted attribute for all non-shadowing subclasses. (It was a small change.) Undef'ing ATTRCACHE_SETATTR_INVALIDATES should work now. Re: different from 2.6: It takes advantage of the lack of "classic" classes. That makes some things a lot easier. Also, I was looking into updating cache entries to see if it would be faster than invalidating all the entries for a type, among other improvements. FWIW, updating cache entries is a little faster on my box. Also: This may have the same problem with test_ctypes' test_incomplete.py as #1700288 did, though I haven't seen any ctypes tests fail. Added file: http://bugs.python.org/file9189/python30-attrcache-2.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1568> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1568] PATCH: Armin's attribute lookup caching for 3.0
Neil Toronto added the comment: There's nothing it tests that standard unit tests don't, so it shouldn't stick around as a unit test. I used it to time different types of attribute lookups and left it in as an optimization aid. The main test groups are '.' access, successful hasattr (returns True), and failing hasattr (returns False). For each group it prints a header and then four test cases for each test class: metaclass attribute access (class.__class__), class attribute access (class.__init__), class attribute access via an instance (class().__class__), and instance attribute access (class().__init__). The test classes include a few built-ins and the classes of a made-up deep hierarchy. The main thing to notice is that, when you run this using the patched source, every number is no larger than when you run it using the trunk, and most are smaller. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1568> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1984] The raw string r'\' fails
New submission from Neil Roques: Python's raw strings are supposed to prevent characters being interpreted as special. However entering the raw string r'\' into an interactive session will result in: Traceback ( File "", line 1 r'\' ^ SyntaxError: EOL while scanning single-quoted string Python seems to have escaped the close of the string, even though raw strings are not supposed to ever escape characters. -- components: Interpreter Core messages: 61936 nosy: passage severity: minor status: open title: The raw string r'\' fails type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1984> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2150] Broken Link to New Style Classes Documentation
New submission from Neil Roques: http://docs.python.org/ref/node33.html (also packaged in the Python documentation which comes with Python) links to: http://www.python.org/doc/newstyle.html for information on new style classes However, this link has moved, as should now read: http://www.python.org/doc/newstyle/ -- components: Documentation messages: 62612 nosy: passage severity: normal status: open title: Broken Link to New Style Classes Documentation type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2150> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue628842] Deprecate PyNumber_Check
Changes by Neil Schemenauer <[EMAIL PROTECTED]>: -- status: open -> closed Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue628842> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: "global a; a=5"
Neil Schemenauer <[EMAIL PROTECTED]> added the comment: On Sun, Mar 23, 2008 at 04:17:12PM +, Antoine Pitrou wrote: > Armin, if you still care about the compiler package, could you (or some > other pypy coder) take a look at #2459? As part of the patch, it > rewrites the flow graph block ordering algorithm in a cleaner way (IMHO). I'm interested to update the compiler package but I'm short of time at the moment. If you want to assign bugs and patches to me, I will try to get to them. Neil _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251748> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2250] rlcompleter raises Exception on bad input
Neil Schemenauer <[EMAIL PROTECTED]> added the comment: On Thu, Mar 20, 2008 at 08:49:32PM +, Sean Reifschneider wrote: > Is a straightforward patch, but I'd like NAS to comment on the change in > behavior. Probably would also need a documentation change, are you up > for doing that Lorenz? I doubt that people are relying on complete() to raise NameError or Attribute error. I think it would be okay just to trap them and not change the docs. A note in NEWS should be good enough. Neil __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2250> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2467] gc.DEBUG_STATS reports invalid "elapsed" times
Neil Schemenauer <[EMAIL PROTECTED]> added the comment: The original code is pretty icky. I'm attaching a patch that improves it, IMO. Before the elapsed time was only shown if garbage was found. I think it should always be shown if DEBUG_STATS is set. -- nosy: +nas Added file: http://bugs.python.org/file9843/gc_timestat.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2467> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: "global a; a=5"
Neil Schemenauer <[EMAIL PROTECTED]> added the comment: On Tue, Mar 25, 2008 at 09:18:38AM +, Armin Rigo wrote: > The situation is that by now PyPy has found many many more bugs in > trying to use the compiler package to run the whole stdlib and > real-world applications. What I can propose is to extract what we have > got and put it back into CPython's stdlib, keeping the current > documented API. I'm not sure it can go back into the stdlib since there doesn't seem to be enough energy available to keep it up-to-date with the Python release schedule. I would like to make it available as an add-on package. > This will require a little bit of work (e.g. first > finishing to add all new 2.5 and 2.6 features into PyPy's compiler) > but IMHO it's more worthwhile than going through the process of > rediscovering and fixing all the current bugs one by one. Indeed it would make no sense to redo that work. Can the version in the PyPy tree be used as a direct replacement for the stdlib version or does it need some changes? You had mentioned being able to produce a patch against the stdlib version. Is that easy or would it be better just to take the PyPy version and package it up. Neil _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1251748> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2742] example code does not work
Neil Muller <[EMAIL PROTECTED]> added the comment: The documentation says: For *host* and *port*, by passing either an empty string or ``None``, you can pass ``NULL`` to the C API, so the documentation says it should work. This doesn't work because PyString_AsString retruns an empty string, not NULL. The attached patch adds a check in socketmodule.c to fix this for host and port. It's highly debatable whether this is better than fixing the documentation, though. -- nosy: +Neil Muller Added file: http://bugs.python.org/file10238/socket_patch.c __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2742> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
Neil Muller <[EMAIL PROTECTED]> added the comment: The attached patch changes most functions in posixmodule which require a filedescriptor to use PyObjectAsDescriptor There are a few cases, where I'm not certain of the usefulness of changing the functions to support objects with fileno that I've left untouched. These are: tcgetpgrp tcsetpgrp closerange dup2 fdopen isatty The extension to these cases is trivial, though. -- keywords: +patch nosy: +Neil Muller Added file: http://bugs.python.org/file10239/posixmodule.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2768> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
Neil Muller <[EMAIL PROTECTED]> added the comment: Patches to test_posix.py to also test using file objects in os.fstat and such. Added file: http://bugs.python.org/file10243/test_posix.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2768> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1153769] String interpolation needs PEP 237 update
Neil Muller <[EMAIL PROTECTED]> added the comment: Update stdtypes.rst to note that %x, %X, %o can take signed values. Note that %u is consider obsolete (referring to PEP 237) Add a note on the length modifier description to clarify the meaning. -- keywords: +patch nosy: +Neil Muller Added file: http://bugs.python.org/file10247/stdtypes.tst.diff _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1153769> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2809] string docstring doesn't mention that ' '.split() != ' '.split(' ')
New submission from Neil Muller <[EMAIL PROTECTED]>:
split with no sep specified will not return an empty string, whereas
split with sep specified will.
The attached patch updates the docstring to reflect this for str.split
and unicode.split.
--
files: split_docstring.diff
keywords: patch
messages: 66536
nosy: Neil Muller
severity: normal
status: open
title: string docstring doesn't mention that ' '.split() != ' '.split(' ')
Added file: http://bugs.python.org/file10254/split_docstring.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2809>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2809] string docstring doesn't mention that ' '.split() != ' '.split(' ')
Changes by Neil Muller <[EMAIL PROTECTED]>: -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2809> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2736] datetime needs and "epoch" method
Neil Muller <[EMAIL PROTECTED]> added the comment: datetime has fromtimestamp already, so using totimestamp keeps naming consistency (see toordinal and fromordinal). -- nosy: +Neil Muller __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2736> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2768] os.fstat and other os.f* methods should use PyObject_AsFileDescriptor
Neil Muller <[EMAIL PROTECTED]> added the comment: This patch combines the two earlier patches, and also updates the docstrings and os.rst to reflect the changed behaviour. Added file: http://bugs.python.org/file10281/posixmodule_2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2768> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4151] Separate build dir broken
New submission from Neil Schemenauer <[EMAIL PROTECTED]>: Building in a separate directory got broken at some point. The code is hairy but it looks like the source of the problem was a lame sysconfig.get_python_inc() function. The attached patches fix things and hopefully do not introduce any new bugs. -- components: Build files: get_python_inc.patch keywords: patch messages: 74996 nosy: nas severity: normal status: open title: Separate build dir broken type: compile error Added file: http://bugs.python.org/file11837/get_python_inc.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4151> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
