[issue2053] IDLE - standardize dialogs
Tal Einat added the comment: Going through the code more thoroughly, found additional places where the standardized dialogs should be used. Also fixed remaining places where these dialogs are used but the parent widget was still being explicitly set to be the text widget, which is now the default. (should be easy to apply both patches in any order without conflicts) Added file: http://bugs.python.org/file9396/IDLE_standardize_dialogs.080209_2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2053 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2051] PYO file permission problem
stocker81 added the comment: Christian Heimes [EMAIL PROTECTED] wrote: I haven't removed it from the listing. Look under priority high a few pages up. I'm sorry, my mistake. Regards, Marcin __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2051 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2021] Turn NamedTemporaryFile into a context manager
Changes by Nick Coghlan: -- assignee: - ncoghlan nosy: +ncoghlan __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2021 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2012] Add migration step for DictMixin - collections.MutableMapping
Nick Coghlan added the comment: Perhaps the best we can do is a warning from the DictMixin constructor in 2.6 when the -3 flag is specified? -- nosy: +ncoghlan __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2012 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Mark Dickinson added the comment: Guido: Correct -- the thing is that you can't know the signature of the subclass's constructor so you can't very well blindly call that. Jeffrey, is it okay for me to change the three class methods (from_float, from_decimal, from_continued_fraction) to static methods, and call Rational instead of cls as the constructor? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Nick Coghlan added the comment: I thought WINVER defaulted to something like 0x0400 (i.e. you can't use things specifically defined for even Win2k without setting it, let alone things first defined for XP). I know I had to force it to 0x0500 recently for a non-Python project to get access to the function that permits a non-blocking attempt to acquire a critical section. That project is stuck using VC6 though - current MS compilers may default it to something more recent. -- nosy: +ncoghlan __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2021] Turn NamedTemporaryFile into a context manager
Nick Coghlan added the comment: I've changed the issue type from rfe to behaviour. NamedTemporaryFile actually provides __enter__ and __exit__ methods in 2.5, they just don't work (it tries to use the methods from the underlying file object directly which turns out to be a doomed exercise for a couple of different reasons). Fixed on the trunk in r60695. Leaving issue as pending until the NamedTemporaryFile fix is backported to 2.5 (or we decide not to backport it). P.S. Alexander's patch worked as written, but in figuring out *why* it worked I ended up moving things around a bit (main change was to only override __exit__ when it was actually necessary to do so) and adding some more test cases (e.g. to also cover 2.6's new SpooledTemporaryFile). -- resolution: - fixed status: open - pending type: rfe - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2021 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Changes by Nick Coghlan: __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Martin v. Löwis added the comment: The defaulting of WINVER is indeed a compiler things; the problems started when we moved to VS 2008 (so VC6 would certainly have a different default). Setting WINVER for extension modules wouldn't have helped with the Tcl problem: Tcl/Tk itself gets compiled independent of Python - Py_BUILD_CORE had no effect here. It *does* have effect on _tkinter, since _tkinter is part of Py_BUILD_CORE. Setting WINVER for all extension modules would be bad style. Some modules may fail to compile - it's up to the module author to decide what API level to build against. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Guido van Rossum added the comment: Jeffrey: Yay for measurements! I was going to say that __add__ is inefficient because it makes so many function calls, but it turns out that, as you say, the cost of constructing a new Rational instance drowns everything else. On my 2.8GHz iMac, Rational(2,3) costs ~80 usec. This goes down to 50 usec if I make it inherit from object -- the ABC machinery costs 30 usecs! If I then also comment out all the typechecking of numerator and denominator and go straight into the gcd(), the constructor costs go down to 6 (six!) usecs. Beyond that it's slim pickings; replacing super() with object or inlining gcd wins perhaps half an usec. But once the constructor is down to 5-6 usec, the half usec for going through the constructor (times 6 for 6 constructor calls in _add()!) might be a significant gain to also try and inline the common case of the binary operators. In the mean time I have two recommendations if you want to make the constructor faster without losing functionality: (a) remove the direct inheritance from RationalAbc (using virtual inheritance instead); (b) special-case the snot out of the common path in the constructor (called with two ints). An alternative might be to have a private class or static method to construct a Rational from two ints that is used internally; it could use object.__new__ instead of super() so as to save the ABC overhead. But I'm not sure if this will always work. Unrelated issue: I just realized for the first time that we have two classes named 'Rational': the ABC and the concrete implementation. That's going to be awfully confusing. Perhaps it's not too late to rename rational.py/Rational to fractions.py/Fraction? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2055] test_fcntl.py converted to unittest
New submission from Giampaolo Rodola': In attachment. All existing tests are unchanged. -- components: Tests files: test_fcntl.diff messages: 62225 nosy: facundobatista, giampaolo.rodola, tiran severity: normal status: open title: test_fcntl.py converted to unittest type: rfe versions: Python 2.6 Added file: http://bugs.python.org/file9397/test_fcntl.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2055 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Nick Coghlan added the comment: I just checked the current PC/pyconfig.h: with the current settings in that file, the core is already limited to using NT4 compatible Win32 API calls. Unless the specific source file takes steps to override it (i.e. setting WINVER before including python.h), no Win2k or XP API calls should be permitted outside the 64-bit builds (as those only became possible with the advent of 64-bit support in XP, they set WINVER to 0x0501). The reason this didn't avoid the Tcl/Tk problem is because the actual setting of WINVER and _WIN32_WINNT is guarded by the Py_BUILD_CORE preprocessor definition - which isn't set for separately built extension modules like _tkinter. Would setting these by default for extension modules (i.e. removing the Py_BUILD_CORE guard) really be such a bad thing? The individual #ifdef guards would still be there to allow extension module authors to override it if they know what they're doing, but the default behaviour would be to require that extension modules be compatible with every version of Windows that that particular version of Python is compatible with. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Nick Coghlan added the comment: Given that whether or not Py_BUILD_CORE is defined flips the direction of the DLL exports/import for the main python DLL, I don't see how it could be defined for the separately compiled extension modules like _tkinter, _sqlite3, _ctypes, _socket, _ssl, etc. As far as I can tell (not having a VS2008 installation set up), that means the build process for those other DLLs is currently going to be using whatever setting for WINVER and _WIN32_WINNT the compiler decides to provide. Perhaps it would be worth having an additional Py_SET_WINVER definition to make it easy for an extension module to request that Python set those two values? And then set that for the modules that are part of the normal Windows build? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Martin v. Löwis added the comment: Given that whether or not Py_BUILD_CORE is defined flips the direction of the DLL exports/import for the main python DLL, I don't see how it could be defined for the separately compiled extension modules like _tkinter, _sqlite3, _ctypes, _socket, _ssl, etc. You are right, it's not. As you found, the original issue reported here could be closed: WINVER *is* already defined in pyconfig.h. I'm still -1 for defining it generally. So to define WINVER for the extension modules that are part of the core, it would be best to define it in pyd.vsprops, and pyd_d.vsprops, not in a header file. Regards, Martin __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Christian Heimes added the comment: Nick Coghlan wrote: I know I had to force it to 0x0500 recently for a non-Python project to get access to the function that permits a non-blocking attempt to acquire a critical section. That project is stuck using VC6 though - current MS compilers may default it to something more recent. I assume they don't. I wasn't able to access a Win2k+ API method with VS2008. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Christian Heimes added the comment: Martin v. Löwis wrote: As you found, the original issue reported here could be closed: WINVER *is* already defined in pyconfig.h. I'm still -1 for defining it generally. So to define WINVER for the extension modules that are part of the core, it would be best to define it in pyd.vsprops, and pyd_d.vsprops, not in a header file. I require WINVER set to Win2k for patch #1763 (os.path.get_shellfolders()). The necessary API methods aren't declared for the standard WINVER. What do you think about a new macro Py_BUILD_CORE_MODULE for the pyd property file? #if defined(Py_BUILD_CORE) || defined(Py_BUILD_CORE_MODULE) #define NTDDI_VERSION NTDDI_WIN2KSP4 #define WINVER 0x0500 #define _WIN32_WINNT WINVER #endif __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Martin v. Löwis added the comment: Ah, so you propose raise WINVER, compared to what it is currently; I now eventually understand this issue. Raising it to 0x0500 is fine with me. Please add a note to PEP 11 that NT 4 and older won't be supported anymore from 2.6 on. NT4 extended support ended on 31.12.2004, so we probably don't need a phase with advance warnings. +1 on Py_BUILD_CORE_MODULE. -- assignee: loewis - tiran resolution: - accepted __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2012] Add migration step for DictMixin - collections.MutableMapping
Raymond Hettinger added the comment: We should hold off on this one for a bit until I can get feedback on whether UserDict, UserString, and UserList should all be in the same place (in the own modules or rolled into collections). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2012 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
Jeffrey Yasskin added the comment: Mark: Coming from C++, I don't have any intuition on static vs. class methods. It might be strange to write MyRationalSubclass.from_float() and get a Rational back, but it might also be strange to write a subclass with a different constructor and get an error. So go ahead. Guido: It would be a shame to decide that classes shouldn't inherit from ABCs for performance reasons. Issue 1762 tracks the problem, but I haven't paid much attention to it. Let's see if we can fix that before using virtual inheritance for Rational. Special-casing ints in the constructor sounds like a good idea, and we can cache the results of .numerator and .denominator in _add, etc, without having to change the overall logic, which should save 2μs (leaving 1 on the table). It could be useful to declare a private constructor that expects ints that are already in lowest terms, sort of like decimal._dec_from_triple(). __add__ couldn't use it directly, but __abs__ could. I don't think it's too late to rename one of the classes. I'm using RationalAbc inside of rational.py to refer to numbers.Rational, which is one reason I was positive on adding a suffix to the ABCs, but renaming this class is fine with me too. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1706] Force WINVER 0x0500 (Windows 2000)
Christian Heimes added the comment: Applied in r60695 (trunk). I've updated the PEP, too. -- resolution: accepted - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1706 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2055] test_fcntl.py converted to unittest
Benjamin Peterson added the comment: I converted this for GHOP: http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=292can=1q=completedcolspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summarystart=100 -- nosy: +gutworth __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2055 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1700463] VC6 build patch for trunk
Hirokazu Yamamoto added the comment: Please don't apply this patch now. VC6 build fails from rev.60696 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1700463 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABC slows Decimal down.
Jeffrey Yasskin added the comment: I measured various implementations of __instancecheck__ using `./python.exe -m timeit -s 'from rational import Rational; r = Rational(3, 2)' '...'` on my 2.33 GHz MacBook, with ... replaced by either isinstance(r, Rational) or isinstance(3, Rational) to measure both the positive and negative cases. The big win comes from avoiding the genexp and the set. Then we win smaller amounts by being more careful about avoiding extra calls to __subclasscheck__ and by inlining the cache checks. # Current code return any(cls.__subclasscheck__(c) for c in set([instance.__class__, type(instance)])) isinstance(3, Rational): 4.65 usec isinstance(r, Rational): 7.47 usec # The best we can do simply in Python return cls.__subclasscheck__(instance.__class__) isinstance(3, Rational): 2.08 usec isinstance(r, Rational): 1.72 usec # Preserve behavior, simply return (cls.__subclasscheck__(instance.__class__) or cls.__subclasscheck__(type(instance))) isinstance(3, Rational): 3.03 usec isinstance(r, Rational): 1.8 usec # Preserve behavior, complexly ic = instance.__class__ if cls.__subclasscheck__(ic): return True t = type(instance) return t is not ic and cls.__subclasscheck__(t) isinstance(3, Rational): 2.38 usec isinstance(r, Rational): 1.86 usec # Inlined for new-style classes subclass = instance.__class__ if subclass in cls._abc_cache: return True type_ = type(instance) if type_ is subclass: if (cls._abc_negative_cache_version == ABCMeta._abc_invalidation_counter and subclass in cls._abc_negative_cache): return False return cls.__subclasscheck__(subclass) return (cls.__subclasscheck__(subclass) or cls.__subclasscheck__(type_)) isinstance(3, Rational): 2.26 usec isinstance(r, Rational): 1.49 usec __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1762 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1762] Inheriting from ABC slows Decimal down.
Raymond Hettinger added the comment: Whoa! I thought we had arrived at a decision to leave decimal alone. Please do not infect this module with numbers.py. -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1762 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2056] install command rejects --compiler option
New submission from Lenard Lindstrom: The install command returns the following error when the --compiler option is provided on the command line: python setup.py install --compiler=mingw32 usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...] or: setup.py --help [cmd1 cmd2 ...] or: setup.py --help-commands or: setup.py cmd --help error: option --compiler not recognized This is problematic on Windows when MinGW is being used in place of Visual C. A package can be built with --compiler=mingw32, but if no compiler is specified for install the following error occurs: python setup.py install running install running build running build_py running build_ext error: Python was built with Visual Studio 2003; extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2003 was not found on this system. If you have Cygwin installed, you can try compiling with MingW32, by passing -c mingw32 to setup.py. The work-around is to specify compiler=mingw32 in a setup.cfg file under a [build] or [build_ext] heading. But this would be inconvenient for someone who has both Visual C and MinGW and wants to choose. -- components: Distutils messages: 62241 nosy: kermode severity: normal status: open title: install command rejects --compiler option versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2056 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1763] Winpath module - easy access to Windows directories like My Documents
Hirokazu Yamamoto added the comment: Sorry for interruption. I'm a little doubtful this is really needed. We can get My Documents path by following 5 lines of code. import ctypes dll = ctypes.windll.shell32 buf = ctypes.create_string_buffer(300) dll.SHGetSpecialFolderPathA(None, buf, 0x0005, False) print buf.value And if this patch goes in, I'm using clipboard in my several python scripts, is it also possible to add clipboard support? (I implemented ocean/clipboard.py under PYTHONPATH and now using it personally) # And, well, r60696 blocks me from building python on VC6, if this change # (WINVER = 0x500) is required for this issue only, I'm happy if this # would be reverted but... I cannot claim it loudly. I'm using win2000, # and latest free compiler doesn't support it :-( -- nosy: +ocean-city __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1763 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2016] Crash when modifying the **kwargs passed to a function.
Changes by Gregory P. Smith: -- nosy: +gregory.p.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2016 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2056] install command rejects --compiler option
Martin v. Löwis added the comment: Could you try whether setup.py build --compiler=mingw32 install works? -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2056 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2057] difflib: add patch capability
New submission from anatoly techtonik: difflib alone and bundled Tools\Scripts\diff.py utility are both very useful, esp. on windows platforms where standard unix diffutils are absent. However, python difflib still doesn't have a patch counterpart to apply at least unified diff format. -- components: Demos and Tools messages: 62244 nosy: techtonik severity: normal status: open title: difflib: add patch capability type: rfe versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2057 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2056] install command rejects --compiler option
Lenard Lindstrom added the comment: Yes, setup.py build --compiler=mingw32 install works. It is good enough for me. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2056 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
