[issue2517] Error when printing an exception containing a Unicode string
Antoine Pitrou [EMAIL PROTECTED] added the comment: Shouldn't it be an exception rather than a warning? The fact that an exception can be downgraded to a warning (and thus involuntarily silenced) is a bit disturbing IMHO. Another possibility would be to display the warning, and *then* to encode the exception message again in replace or ignore mode rather than strict mode. That way exception messages are always displayed, but not always properly. The ASCII part of the message is generally useful, since it gives the exception name and most often the reason too. -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2517 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Brett Cannon [EMAIL PROTECTED] added the comment: After all the threats about checking in code that break stuff, I am not about to check this in. =) I will get to the changes when I can and then commit after the alpha. -- assignee: nnorwitz - brett.cannon _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1631171 _ ___ 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
Changes by Hirokazu Yamamoto [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9044/vc6-trunk-ver4.patch _ 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
[issue2526] str.format() :n format does not appear to work
New submission from Mark Summerfield [EMAIL PROTECTED]:
# Py30a3
import locale
locale.setlocale(locale.LC_ALL, en_US.UTF8)
'en_US.UTF8'
locale.format(%d, 12345, True)
'12,345'
{0:n}.format(12345)
'12345'
According to the docs the 'n' format should use the locale-dependent
separator, so I expected both strings to be '12,345'.
Also, it is a pity that locale.format() uses the old deprecated % syntax
rather than the much nicer and better str.format() syntax.
--
components: Interpreter Core
messages: 64804
nosy: mark
severity: normal
status: open
title: str.format() :n format does not appear to work
type: behavior
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2526
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
New submission from Peter Otten [EMAIL PROTECTED]: I'd like to suggest a different approach than the one taken in rev. 54348 to improve timeit's scripting interface: allow passing it a namespace. Reasons: - It has smaller overhead for functions that take an argument: def f(a): pass ... # trunk min(ht.Timer(lambda f=f: f(42)).repeat()) 0.54068493843078613 # my patch min(mt.Timer(f(42), ns=dict(f=f)).repeat()) 0.29009604454040527 - it is more flexible. Example: # working code, requires matplotlib from timeit import Timer from time import sleep def linear(i): sleep(.05*i) def quadratic(i): sleep(.01*i**2) x = range(10) y = [] for a in x: y.append([min(Timer(f(a), ns=dict(f=f, a=a)).repeat(1, 1)) for f in linear, quadratic]) from pylab import plot, show plot(x, y) show() The above code works unaltered inside a function, unlike the hacks using from __main__ import - the implementation is simpler and should be easy to maintain. The provided patch is against 2.5.1. If it has a chance of being accepted I'm willing to jump through the necessary hoops: documentation, tests, etc. -- components: Library (Lib) files: diff_against_2_5_1.txt messages: 64805 nosy: potten severity: normal status: open title: Pass a namespace to timeit type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file9916/diff_against_2_5_1.txt __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2527 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Jason Tishler [EMAIL PROTECTED] added the comment: If the version is guaranteed to be x.y or x.y.z, then the patch seems correct. Note I am not set up to test this patch and it has been years since I have looked at this part of the code base. Sorry, that I can't be more helpful. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2234 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2517] Error when printing an exception containing a Unicode string
Benjamin Peterson [EMAIL PROTECTED] added the comment: Have you looked at PyErr_Display? There are many, many possible exceptions, and it ignores them all because too many callers rely on this. So, I think all we can do is warn. I will look into encoding the message differently. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2517 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Brett Cannon [EMAIL PROTECTED] added the comment: Neal's issues are addressed in this patch. I also finally filled out warnings.h. The only thing that I didn't deal with is Neal's worry of exposing _PyWarnings_Init(). It is not explicitly exported anywhere as part of the API so I am not sure what he is worrying about. The attached patch is finished for CPython. I do want to go back and put back in the pure Python code that _warnings.c replaces so that alternative VMs don't have to implement any part of warnings if they don't want to. Added file: http://bugs.python.org/file9917/c_warnings.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1631171 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2527 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2506] Line tracing of continue after always-taken if is incorrect
Ned Batchelder [EMAIL PROTECTED] added the comment: It's hard for me to agree with your assessment that for no practical good would come from disabling the optimizer. Broadly speaking, there are two types of code execution: the vast majority of the time, you execute the code so that it can do its work. In this case, speed is most important, and the peephole optimizer is a good thing. But another important case is when you need to reason about the code. This second case includes coverage testing, debugging, and other types of analysis. Compiled languages have long recognized the need for both types of compilation, which is why they support disabling optimization entirely. As Python becomes more complex, and more broadly deployed, the needs of the two types of execution will diverge more and more. More complex optimizations will be attempted in order to squeeze out every last drop of performance. And more complex tools to reason about the code will be developed to provide rich support to those using Python for complex development. I see discussion here of moving the optimizer to the AST level instead of the bytecode level. This won't change the situation. The optimizer will still interfere with analysis tools. As a developer of analysis tools, what should I tell my users when their code behaves mysteriously? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2506 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Changes by Brett Cannon [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9761/c_warnings.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1631171 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2528] Change os.access to check ACLs under Windows
New submission from Tim Golden [EMAIL PROTECTED]: At present, os.access under Windows simply calls GetFileAttributes to determine the readonly attribute (ignoring directories). The patch attached combines this with the use of the AccessCheck API to compare the user's permissions with those required for the path. I'm assuming that ATTRIB and CACLS will be available for use in the unit tests included. I haven't altered the structure of the posix_access function at all although I suspect that it could now be simplified now that we're not supporting Win9x. -- components: Library (Lib) files: os_access-r62091.patch keywords: patch messages: 64811 nosy: tim.golden severity: normal status: open title: Change os.access to check ACLs under Windows versions: Python 2.6 Added file: http://bugs.python.org/file9919/os_access-r62091.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2528 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2522] locale.format() problems with decimal separator
Andrii V. Mishkovskyi [EMAIL PROTECTED] added the comment:
I've uploaded a patch that fixes this concrete issue, though
locale.format() continues to silently ignore other types of malformed
strings (e.g. locale.format('%fSPAMf')).
I don't think this is correct behavior. Maybe there should be reg-exp
that locale.format() will use to avoid such issues.
--
components: +Library (Lib)
keywords: +patch
Added file: http://bugs.python.org/file9918/locale.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2522
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Alexander Belopolsky [EMAIL PROTECTED] added the comment: A more general approach would be to add both 'locals' and 'globals' to be used by exec. At least, I would change 'ns' to 'locals'. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2527 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue643841] New class special method lookup change
John Krukoff [EMAIL PROTECTED] added the comment: I assume when you say that the documentation has already been updated, you mean something other than what's shown at: http://docs.python.org/dev/reference/datamodel.html#new-style-and- classic-classes or http://docs.python.org/dev/3.0/reference/datamodel.html#new-style-and- classic-classes ? As both of those claim to still not be up to date in relation to new style classes, and the __getattr__ __getattribute__ sections under special names make no reference to how magic methods are handled. Additionally, the Class Instances section under the type heirachy makes mention of how attributes are looked up, but doesn't mention the new style differences even in the 3.0 documentation. Sure, there's this note under Special Method Names: For new-style classes, special methods are only guaranteed to work if defined in an object’s class, not in the object’s instance dictionary. But that only helps you figure it out if you already know what the problem is, and it's hardly comprehensive. I'm not arguing that this is something that's going to change, as we're way past the point of discussion on the implementation, but this looks far more annoying if you're looking at it from the perspective of proxying to container classes or numeric types in a generic fashion. My two use cases I've had to convert are for lazy initialization of an object and for building an object that uses RPC to proxy access to an object to a remote server. In both cases, since they are generic proxies that once initialized are supposed to behave exactly like the proxied instance, the list of magic methods to pass along is ridiculously long. Sure, I have to handle __copy__ __deepcopy__, and __getstate__ __setstate__ to make sure that they return instances of the proxy rather than the proxied object, but other than that there's over 50 attributes to override for new style classes just to handle proxying to numeric and container types. It's hard to get fancy about it too, as I can't just dynamically add the needed attributes to my instances by looking at the object to be proxied, it really has to be a static list of everything that python supports on the class. Additionally, while metaclasses might help here, there's still the problem that while my old style proxy class has continued to work fine as magic attributes have been added over python revisions, my new style equivalent will have to be updated work currectly as magic methods are added. Which, given the 2.x track seems to happen pretty frequently. Some of the bugs from that would have been quite tricky to track down too, such as the __cmp__ augmentation with the rich comparison methods. None of the solutions really seem ideal, or at least as good as what old style classes provided, which is why I was hoping for some support in the 3.0 standard library or the conversion tool. Tracker [EMAIL PROTECTED] http://bugs.python.org/issue643841 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On the second thought, I actually wanted Timer to mimic eval without realizing that eval uses positional rather than keywords arguments. 'locals' is obviously a bad choice for the keyword parameter because it masks locals() builtin. Maybe 'local_namespace'? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2527 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2234] cygwinccompiler.py fails for latest MinGW releases.
Lenard Lindstrom [EMAIL PROTECTED] added the comment: distutils.version.StrictVersion.parse does not handle x.y.z.n . That is why there is an exception. I have tested the patch both with binutils-2.18.50-20080109 (*), the latest version (a Technology Preview), and its predecessor binutils-2.18.50-20071123, which also works without the proposed patch. I use MinGW to build Pygame. Finally, there should be no reason to use earlier versions of binutils with Python 2.4 and up as msvcr71 support was introduced only a couple of years ago. (*) The MinGW binutils bundle contains both ld and dllwrap __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2234 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Antoine Pitrou [EMAIL PROTECTED] added the comment: Generally, when I use timeit from the interpreter prompt, I use from __main__ import * as the setup code string. Then I can use all currently defined global symbols directly :) -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2527 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2519] Typing 'modules' in the interactive help system fails when imports fail
Dennis Kaarsemaker [EMAIL PROTECTED] added the comment: pydoc.py from head actually does work around it in some places, but not all. Will send a patch. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2519 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2529] list/generator comprehension parser doesn't match spec
New submission from Nick Guenther [EMAIL PROTECTED]: I think I've found a bug in python's list comprehension parser. Observe: [e for i in j in ['a','b','c']] Traceback (most recent call last): File stdin, line 1, in module NameError: name 'j' is not defined Now, according to the grammar at http://docs.python.org/ref/lists.html, a list comprehension is (condensed for clarity): list_comprehension ::= expression list_for list_for::= for target_list in old_expression_list [list_for] So a list comprehension should always be [ for ... in for ... in ... for ... in ...] (that is, alternating 'for's and 'in's) but here I have a test case that python happily tries to run that looks like [... for ... in ... in ] -- components: Interpreter Core messages: 64818 nosy: kousu severity: normal status: open title: list/generator comprehension parser doesn't match spec type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2529 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Changes by Brett Cannon [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9917/c_warnings.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1631171 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Brett Cannon [EMAIL PROTECTED] added the comment: Attached should have everything, including a pure Python fallback. As soon as the next alpha is out I will apply. -- status: open - pending Added file: http://bugs.python.org/file9920/c_warnings.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1631171 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2529] list/generator comprehension parser doesn't match spec
Robert Lehmann [EMAIL PROTECTED] added the comment: Your example is parsed as [e for i in (j in ['a','b','c'])] and since `j` is not defined, you get a NameError. If it was defined, you would still be iterating a boolean (which is not defined). Grammatically, this is the following (just the important parts, again): list_comprehension ::= expression list_for list_for ::= for target_list in old_expression_list old_expression_list ::= old_expression old_expression ::= stripped test hierarchy... comparison comparison ::= or_expr ( comp_operator or_expr )* comp_operator ::= in So your basic misconception is that both `in` keywords are belonging to the list comprehension syntax -- the former does while the latter is simply an operator. -- nosy: +lehmannro __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2529 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
Ralf Schmitt [EMAIL PROTECTED] added the comment: Of course the signal handler may raise an exception, so my last argument isn't that good. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1068268 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2530] Document IO module
New submission from Benjamin Peterson [EMAIL PROTECTED]: The IO module currently has some docs strings but no official RST docs. I'm willing to work on this. -- assignee: benjamin.peterson components: Documentation messages: 64822 nosy: benjamin.peterson, georg.brandl priority: critical severity: normal status: open title: Document IO module type: feature request versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2530 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2529] list/generator comprehension parser doesn't match spec
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Indeed; your sample is equivalent to: temp = (j in ['a','b','c'])# the contains operator [e for i in temp] # basic list comprehension Even if not meaningful, this code is syntactically correct. -- nosy: +amaury.forgeotdarc resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2529 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2510] Bazaar ignore file
Benjamin Peterson [EMAIL PROTECTED] added the comment: Georg, Ralf, and Jeroen, are you ok with me checking this in now? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2510 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: Hi Mark, I hope this patch makes it into 2.6. One thing I'm curious about is the version of Visual Studio 2008 that is needed to support this kind cross-compilation and which version will be or is used to build the Python versions on 64-bit Windows. -- nosy: +lemburg __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2513 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: Nevermind, diving deep into the MSDN, I found the answer: http://msdn2.microsoft.com/en-us/library/hs24szh9.aspx So for cross-compilation, the Visual Studio 2008 Standard Edition is sufficient. Is the Professional Edition used for the standard Python binaries ? Does it generate faster code ? A bit off-topic, I know, but it's really hard to find this important information elsewhere and may well be of use for other Python extension authors as well. Thanks. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2513 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2531] float compared to decimal is silently incorrect.
New submission from Jeremy Dunck [EMAIL PROTECTED]:
Within python 2.5.2:
from decimal import Decimal
x = 3.0
y = Decimal('0.25')
x y
False (expected error, as in 2.4, or True)
--
components: Library (Lib)
messages: 64827
nosy: jdunck
severity: normal
status: open
title: float compared to decimal is silently incorrect.
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2531
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
Changes by Gregory P. Smith [EMAIL PROTECTED]: -- nosy: +gregory.p.smith _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1068268 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Mark Hammond [EMAIL PROTECTED] added the comment: Hi Marc-Andre, The PCBuild/README.txt file has some info about compatibility with VS versions (but probably needs to say more about x64 builds). There is also talk about releasing Profile Guided Optimization built binaries, which does require a professional version. I believe, but am not sure, that Martin uses the professional versions to make the official binaries. Either way, this might be getting off-topic for this patch. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2513 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2532] file that breaks 2to3 (despite being correct python)
New submission from Maciek Fijalkowski [EMAIL PROTECTED]: Infinite recursion problem. I know this file is obscure, but it's still pretty valid python. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) files: ssl.py messages: 64829 nosy: collinwinter, fijal severity: normal status: open title: file that breaks 2to3 (despite being correct python) Added file: http://bugs.python.org/file9921/ssl.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2532 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2533] Invalid TypeError with class method decorator and class method parameter
New submission from Thomas Dimson [EMAIL PROTECTED]: Having a peculiar issue (exception raised despite being valid) when defining a decorator that takes a class method as a callback. Here is a cooked example: def decorator( callback ): def inner(func): def application( *args, **kwargs ): callback(*args,**kwargs) func(*args,**kwargs) return application return inner class DecorateMe: @decorator( callback=DecorateMe.callback ) def youBet( self ): pass def callback( self ): print Hello! DecorateMe().youBet() Traceback (most recent call last): File pyshell#0, line 1, in module DecorateMe().youBet() File C:\Python25\badpython.py, line 4, in application callback(*args,**kwargs) TypeError: unbound method callback() must be called with DecorateMe instance as first argument (got DecorateMe instance instead) If you change the line callback=DecorateMe.callback to callback=lambda x: DecorateMe.callback(x) python gives you: DecorateMe().youBet() Hello! Mysteriously, I did encounter this during my coding with a non-cooked decorator. -- components: None messages: 64830 nosy: tdimson severity: normal status: open title: Invalid TypeError with class method decorator and class method parameter type: behavior versions: Python 2.4, Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2533 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Neal Norwitz [EMAIL PROTECTED] added the comment: On Tue, Apr 1, 2008 at 6:14 AM, Brett Cannon [EMAIL PROTECTED] wrote: Brett Cannon [EMAIL PROTECTED] added the comment: Neal's issues are addressed in this patch. I also finally filled out warnings.h. The only thing that I didn't deal with is Neal's worry of exposing _PyWarnings_Init(). It is not explicitly exported anywhere as part of the API so I am not sure what he is worrying about. I wasn't so worried about exposing it, I didn't like the name pollution (we're talking about init_warnings, right?). I know that we have other modules that use init*, but those are broken too. I'm not sure we should fix those in 2.6, but 3.0 we should. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1631171 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2531] float compared to decimal is silently incorrect.
Changes by Diego Manenti Martins [EMAIL PROTECTED]: -- keywords: +patch versions: +Python 2.6 Added file: http://bugs.python.org/file9922/decimal.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2531 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1068268] subprocess is not EINTR-safe
Jeffrey Yasskin [EMAIL PROTECTED] added the comment: I think the proper behavior on EINTR may depend on which subprocess call we're in. For example, the user can easily loop on .wait() herself if she wants to ignore EINTR. But it's a lot harder to loop on Popen() if the read() in _execute_child is interrupted. So my inclination would be to let EINTR be raised in the first case, and use a loop to handle it in the second. Regarding the patch, a wrapper function called as retry_on_eintr(obj.write, data) might be a cleaner way to do it. -- nosy: +jyasskin _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1068268 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2531] float compared to decimal is silently incorrect.
Changes by Jeremy Dunck [EMAIL PROTECTED]: -- type: - behavior __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2531 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2518] smtpd.py to handle huge email
Changes by HiroakiKawai [EMAIL PROTECTED]: Added file: http://bugs.python.org/file9923/smtpd.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2518 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2518] smtpd.py to handle huge email
Changes by HiroakiKawai [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9910/smtpd.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2518 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2510] Bazaar ignore file
Jeroen Ruigrok van der Werven [EMAIL PROTECTED] added the comment: Go ahead. I'm not a committer, merely a person on the side. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2510 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Trent Nelson [EMAIL PROTECTED] added the comment: Hi guys, have been on holiday since PyCon ended, only getting back into the swing of things now. With regards to the x64 Windows build, indeed, PCbuild/readme.txt is definitely in need of an update, especially with the details of the slightly new build system I checked in a few weeks ago. As it currently stands, the Professional version of Visual Studio 2008 is required for a complete x64 build, however, this is because a cross- compilation 'vsvars32.bat'-type file needs to be called in order to do command line (i.e. nmake) x64 builds. (The particular file I'm referring to is C:\Program Files (x86) \Microsoft Visual Studio 9.0\VC\vcvarsall.bat, which needs to be invoked with 'x86_amd64' as the first parameter. This is only shipped with the Professional version of Visual Studio 2008 -- the buildbots currently rely on it to produce x64 builds, see http://svn.python.org/projects/python/trunk/Tools/buildbot/build- amd64.bat.) We need to invoke this particular batch file in order to build x64 versions tcl/tk and openssl because we're currently reliant on the nmake-oriented builds each of these projects ship with. That said, the next step in my build-related improvements is to remove this reliance and mimick the nmake-oriented builds with custom .vcproj builds that inherit all of our property sheets -- this is the approach I took with bsddb and sqlite3 and it worked *very*, *very* well. (See _bsddb44.vcproj and sqlite3.vcproj in the PCbuild directory.) There are many advantages with this approach. To name a few: the release versions of the modules will benefit from profile guided optimisation, just like the rest of the python build, the modules are significantly easier to debug, and there is no chance for conflicting compiler/linker flags (which was a continual source of pain with bsddb/sqlite3 when they were built with the vendor-supplied build system). So, eventually, you should be able to build and entire release version of Python x64 with just the Express edition of Visual Studio 2008 (note that the Express edition won't support a PGO build though). The 'official' release though will be built with a Professional version though, as Mark states, thus allowing us to take advantage of profile guided optimisation. Hopefully this isn't too much off topic. (I can't comment on the patches Mark has provided just yet as I haven't had a chance to review them -- just wanted to clear up the x64 cross-compilation questions.) Perhaps I should create a separate issue to track the work needed to cross compile an x64 build with the Express edition only. Any objections? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2513 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Christian Theune [EMAIL PROTECTED] added the comment: Mark, I think you mixed me up with Christian Heimes, so I'm removing myself here (at least for now). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2513 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2513] 64bit cross compilation on windows
Trent Nelson [EMAIL PROTECTED] added the comment: Humm, just saw the MSDN page Marc-Andre referred to, which indeed seems to indicate the Express edition doesn't support x64 cross-compilation *at all*. AFAICT the latest Platform SDK (6.1) ships with an x64 cross compilation environment, but it's command line only, so unless there's a way to hook it up such that 'vcbuild' uses it with the Express edition as well -- it seems like you do need Standard edition or higher for x64 builds. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2513 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2422] Automatically disable pymalloc when running under valgrind
James Henstridge [EMAIL PROTECTED] added the comment: There are probably a few other performance optimisations that would be good to turn off when running under valgrind. A big one is the tuple cache: if there are tuple reference counting issues, they won't necessarily be seen by valgrind if the tuple is kept and reused rather than being freed. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2422 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
