[issue34006] Windows HTML Help (chm) has fixed line length
gladman added the comment: I cannot build the Windows chm file but I am happy to test any versions that others can produce. -- ___ Python tracker <https://bugs.python.org/issue34006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34006] Windows HTML Help (chm) has fixed line length
gladman added the comment: You are exactly right Steve - that is very close to what I am seeing and it is often quite hard to read. For example, where function prototypes are displayed on two lines, it takes me a lot longer to parse and understand them when compared with a situation where they are displayed on a single line. Although I agree with those who claim that there is an ideal line length for readability, I really don't think this can be predicted in advance since it is inevitably varies widely from one user to another. So I remain convinced that it is better to use a design that dynamically adjusts to the width available. Brian -- ___ Python tracker <https://bugs.python.org/issue34006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34006] Windows HTML Help (chm) has fixed line length
gladman added the comment:
Comparing the basic.css files for the 3.6.5 chm file and the 3.6.6 chm file
shows that the latter has the following body style definition that the earlier
versions don't have:
/* -- general body styles - */
div.body {
min-width: 450px;
max-width: 800px;
}
So it seems that the later versions set a maximum width that is not present in
the earlier versions.
--
___
Python tracker
<https://bugs.python.org/issue34006>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34006] Windows HTML Help (chm) has fixed line length
gladman added the comment: I too much prefer the old behaviour since the fixed width is too narrow on my high resolution display -- nosy: +gladman ___ Python tracker <https://bugs.python.org/issue34006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26525] Documentation of ord(c) easy to misread
New submission from gladman:
It is very easy to misread the greek 'nu' used in the ord(c) documentation as
ord('v') (i.e. an alphabetic 'v'). This can lead the reader to draw a wrong
conclusion about the behaviour of the function.
Would it not be better if this example used a greek letter that is less easy to
misread in this way? Or, perhaps, add extra text indicating that the greek
letter 'nu' is being referenced?
--
assignee: docs@python
components: Documentation
messages: 261485
nosy: docs@python, gladman
priority: normal
severity: normal
status: open
title: Documentation of ord(c) easy to misread
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26525>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24843] 2to3 not working
gladman added the comment: I have now got it working using the command line: C:\Program Files\Python35\Tools\scriptsC:\Program Files\Python34\python 2to3.py --help I am not sure why the default Windows invocation of Python doesn't work with 2to3 as this works fine with other python scripts that I have tried. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24843 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24843] 2to3 not working
New submission from gladman: when I try to use the 2to3 script on the command line on Windows x64, I get the response: C:\Program Files\Python34\Tools\scripts2to3 C:\Users\brian\Downloads\puzzles.py At least one file or directory argument required. Use --help to show usage. When I ask for help I get: C:\Program Files\Python34\Tools\scripts2to3 --help At least one file or directory argument required. Use --help to show usage. In fact this is always the response I obtain irrespective of what I enter after '2to3' on the command line. Python 3.5rc1 also behaves in the same way. -- components: 2to3 (2.x to 3.x conversion tool) messages: 248396 nosy: gladman priority: normal severity: normal status: open title: 2to3 not working type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24843 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24843] 2to3 not working
gladman added the comment: Thanks for the explanation. My apologies for this posting, which I will now close -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24843 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24843] 2to3 not working
gladman added the comment: Hi Steve, The behaviour I reported was the same on Python 3.4 and 3.5rc1. But eryksun was correct in suggesting that this was a problem in the way my file association for Python was set up. My py_auto_file association was set to: C:\Program Files\Python34\python.exe %1 adding %* on the end fixed the problem. (by the way, thank you for your work on _msvccompiler.py). best regards, Brian -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24843 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24798] Issue in the MSVC compiler class in distutils on Python 3.5
New submission from gladman:
I have been using _msvcompiler.py from Python 3.5 to build some executables but
I have been unable to get it to generate and embed a manifest.
When I looked into this I found that the subroutine that sets up the parameters
for generating a manifest ('manifest_get_embed_info' at around line 471) has
the line:
ld_args.append('/MANIFESTFILE:' + temp_manifest)
to set the manifest's name but doesn't actually ask for a manifest to be
generated. Here is what is said about /MANIFESTFILE on MSDN:
/MANIFESTFILE will have no effect if you do not also link with /MANIFEST.
After adding:
ld_args.append('/MANIFEST')
before the above line, I then succeed in obtaining the manifest.
--
components: Distutils
messages: 248050
nosy: dstufft, eric.araujo, gladman
priority: normal
severity: normal
status: open
title: Issue in the MSVC compiler class in distutils on Python 3.5
type: behavior
versions: Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24798
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: I notice on the documentation for Python 3.5 that this proposed addition is not mentioned. Is it still the intention to add this proposed change to Python 3.5? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: You might be right that it is not worth adding the ability to handle a variable number of parameters in the new gcd. But this depends on whether you are right that this would add a significant burden to the implementation. I am not sure that it would. But for pure Python implementations of gcd and gcdm: def gcd(a, b): while b: a, b = b, a % b return a def gcdm(a, *r): for b in r: while b: a, b = b, a % b return a using the second of these alone when compared with the first plus reduce on a 1 length sequence of random numbers in 0 = r 10 ** 12 gives speed improvement of over 25%. And, since we are looking for speed improvements, a further possible 25% is a worthwhile gain for a common pattern of gcd use. Which is why I believe it is worth asking the question. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22486] Add math.gcd()
gladman added the comment: I am inclined to think that a maths.gcd() makes sense as this would be where I would go first to find this function. And the prospect of better performance is attractive since the gcd is an important operation in work with number theory algorithms. Would it co-exist with fractions.gcd(), with identical semantics? Or would it co-exist with fractions.gcd(), with the 'less surprising' semantics that are under discussion in the 'GCD in Fractions' thread? Would it take on the suggestion of operating on one or more input parameters? -- nosy: +gladman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22486 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 25/09/2014 15:55, Matthew Barnett wrote: Matthew Barnett added the comment: After some thought, I've come to the conclusion that the GCD of two integers should be negative only if both of those integers are negative. The basic algorithm is that you find all of the prime factors of the integers and then return the product of the common subset (multiset, actually). For example, to calculate the GCD of 6 and 15: 6 = [2, 3] 15 = [3, 5] The largest common subset is [3]. Therefore the GCD is 3. What about negative integers? Well, what you could do is make one of the factors -1. For example, to calculate the GCD of -6 and 15: -6 = [-1, 2, 3] 15 = [3, 5] The largest common subset is [3]. Therefore the GCD is 3. Another example, to calculate the GCD of -6 and -15: -6 = [-1, 2, 3] -15 = [-1, 3, 5] The largest common subset is [-1, 3]. Therefore the GCD is -3. But should the computation of the GCD of two integers by finding the intersection of their prime factors include -1 or 1 given that neither of these is a prime? :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 25/09/2014 17:02, Matthew Barnett wrote: Matthew Barnett added the comment: As it appears that there isn't general agreement on how to calculate the GCD when negative numbers are involved, I needed to look for another way of thinking about it. Splitting off the sign as another factor was what I came up with. Pragmatism beats purity, and all that! :-) I understand :-) But I think we now know that we are not going to get agreement here on grounds of principles for what the gcd should return for negative integers. First, in order to preserve my sanity, I am going to concede Mark's point that returning a negative value from GCD is not wrong :-) For negative integers we have now amassed quite a few alternatives: 1) return the GCD that is non-negative (my preference) 2) return the GCD that is negative (your suggestion) 3) return the GCD that has the same sign as its first input 4) return the GCD that has the same sign as its second input (as now) and, I suspect, a few more I haven't thought of. I may be wrong here, but I suspect that if we were starting from scratch the first of these would quickly be adopted for several reasons: 1) it yields the least surprising results and the one that most users probably both want and expect. 2) For me, Wolfgang Maier's point about the commutative properties of the gcd is rather important since finding that gcd(a, b) != gcd(b, a) is a real loss, not just an inconvenience. 3) Its supports a common idiom for checking for co-prime numbers by testing if the gcd is equal to 1. But we are not starting from scratch and it is hard to see that it makes much sense to change the GCD in fractions given the backwards compatibilty issues that this might create. So, it would seem that we should eiher do nothing or we should introduce a gcd in, say math, that adopts approach (1) above and document its difference when compared with that in fractions, allowing both to co-exist. We can, hopefully speed it up (see the related threads) and it might over time come to be the gcd that people come to use as the norm (also nothing would stop its internal use in fractions). We might also allow one or more inputs. Last but not least I hope I have not done anyone a disservice in this summary. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 25/09/2014 17:44, Mark Dickinson wrote: Mark Dickinson added the comment: IMHO, the most straight forward way for a new gcd() function to work would be to always, predictably return a non-negative value. Yes. Any new gcd implementation (in the math module, for example) should definitely return the unique nonnegative gcd of its inputs. In an effort to concentrate the discussion a bit, here's a specific proposal, deliberately limited in scope: 1. Add a new (faster) math.gcd function for Python 3.5, taking two integral arguments, and returning the unique nonnegative greatest common divisor of those arguments. 2. Deprecate fractions.gcd in Python 3.5 (with a message suggesting that math.gcd should be used instead), but don't change its behaviour. (The fractions module would likely be using math.gcd by this point.) 3. Remove fractions.gcd in Python 3.6. I'd suggest that tangents about gcd of more than two arguments, gcd of rational / Decimal / float inputs, etc. be discussed elsewhere. Those are all things that can be added later if there's a real use-case. My summary crossed with this plan from Mark, which I support (minus the bit he subsequently retracted). +1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 25/09/2014 17:44, Mark Dickinson wrote: Mark Dickinson added the comment: IMHO, the most straight forward way for a new gcd() function to work would be to always, predictably return a non-negative value. Yes. Any new gcd implementation (in the math module, for example) should definitely return the unique nonnegative gcd of its inputs. In an effort to concentrate the discussion a bit, here's a specific proposal, deliberately limited in scope: 1. Add a new (faster) math.gcd function for Python 3.5, taking two integral arguments, and returning the unique nonnegative greatest common divisor of those arguments. 2. Deprecate fractions.gcd in Python 3.5 (with a message suggesting that math.gcd should be used instead), but don't change its behaviour. (The fractions module would likely be using math.gcd by this point.) 3. Remove fractions.gcd in Python 3.6. I'd suggest that tangents about gcd of more than two arguments, gcd of rational / Decimal / float inputs, etc. be discussed elsewhere. Those are all things that can be added later if there's a real use-case. I don't know much about performance issues in the Python interpreter but one point I would make here is implementing a multiple integer gcd on top of a two input one will involve calling gcd and abs for each parameter. In contrast a gcd that operates on one or more parameters (e.g of the sort that I posted earlier under the name mgcd) can avoid these extra calls and any consequent overheads and _might_ do so with little additional overhead of its own making (i.e. loops vs calls). I also felt that this could be implemented on top of the work going on on the faster gcd. So, while I don't think we need to consider a rational gcd, it might be worth at least considering how a 'one or more parameter' gcd compares on performance grounds with a two parameter one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
New submission from Brian Gladman: There is a discussion of this issue on comp.lang.python The function known as 'the greatest common divisor' has a number of well defined mathematical properties for both positive and negative integers (see, for example, Elementary Number Theory by Kenneth Rosen). In particular gcd(a, b) = gcd(|a|, |b|). But the Python version of this function in the fractions module doesn't conform to these properties since it returns a negative value when its second parameter is negative. This behaviour is documented but I think it is undesirable to provide a function that has the well known and widely understood name 'gcd', but one that doesn't match the behaviour normally associated with this function. I hence believe that consideration should be given to changing the behaviour of the Python greatest common divisor function to match the mathematical properties expected of this function. If necessary a local function in the fractions module could maintain the current behaviour. -- components: Library (Lib) messages: 227410 nosy: b...@gladman.plus.com priority: normal severity: normal status: open title: GCD in Fractions type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 24/09/2014 08:58, Mark Dickinson wrote: Mark Dickinson added the comment: The current `gcd` definition is almost accidental, in that it just happens to be what's convenient for use in normalisation in the Fraction type. If people are using it as a standalone implementation of gcd, independent of the fractions module, then defining the result to be always nonnegative is probably a little less surprising than the current behaviour. BTW, I don't think there's a universally agreed definition for the extension of the gcd to negative numbers (and I certainly wouldn't take Rosen's book as authoritative: did you notice the bit where he talks about 35-bit machines being common?), so I don't regard the fraction module definition as wrong, per se. But I do agree that the behaviour you propose would be less surprising. I only quoted Rosen because I had it immediately to hand. I will willingly supply more references if you need them. Sadly even some maths books don't cover this at all but then go on to rely on the co-prime test gcd(a, b) == 1 even when a and/or b can be negative. So I would agree that it is easy to conclude that the gcd is not defined for negative numbers. But, of those maths texts that explicitly cover the behaviour of the gcd for negative numbers, I do not know of any that do not define gcd(a, b) to be gcd(|a|, |b|). One other thought: if we're really intending for gcd to be used independently of the fractions module, perhaps it should be exposed as math.gcd. (That would also give the opportunity for an optimised C version.) To me it makes more sense to put this in math as this is where I would expect to find it. But a comment on comp.lang.python was not in favour of this. -- nosy: +gladman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 24/09/2014 10:13, Mark Dickinson wrote: Mark Dickinson added the comment: I will willingly supply more references if you need them. I don't. :-) I've taught more elementary number classes and reviewed more elementary number theory texts (including Rosen's) than I care to remember, and I have plenty of my own references. I stand by my assertion that the fractions module gcd is not wrong: it returns 'a' greatest common divisor for arbitrary integer inputs. Well we will just have to agree to disagree on this :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 24/09/2014 11:54, Mark Dickinson wrote: Mark Dickinson added the comment: Well we will just have to agree to disagree on this :-) Sure. In the mean time, would you be interested in writing a patch targeting Python 3.5? (Irrespective of the arguments about the definition, I don't think this is a change that could be applied in a 3.4 bugfix release.) Yes, I am very willing to contribute. But I have never contributed to Python before and I almost certainly have a lot to learn in any attempt to do this. In particular, I need advice on where any gcd should go (fractions or math or ...). And if it goes in math and/or we want to speed it up, I would have to learn how to integrate Python and C code (I have done almost none of this before). So I would much appreciate further discusssion of this possible change and how best to implement it (if there is a consensus to do so). Of course, there is the very simple change of adding abs(x) to the return value for the current gcd and adjusting its single use in fractions accordingly. But since there is already concern about the impact of the gcd on the performance of fractions, it deserves more careful consideration than this approach would involve. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 24/09/2014 19:01, Mark Dickinson wrote: Mark Dickinson added the comment: The negative of the greatest common divisor is the least common divisor in an integer range. That depends on your choice of definitions: it's perfectly reasonable to see it as another greatest common divisor, if you interpret greatest as being with respect to the divisibility lattice, not the total ordering of Z. That's in some sense the correct interpretation, because it's the one that generalises to other interesting rings: for example, the Gaussian integers have a well-defined and useful notion of greatest common divisor, but aren't ordered, and the ring Z[sqrt 3] similarly has well-defined greatest common divisors (defined up to multiplication by a unit, as usual) *and* a total ordering, but greatest *can't* be interpreted in the ordering sense in that case (because there are infinitely many units). Many textbooks will talk about a greatest common divisor rather than the greatest common divisor. In that sense, -3 *is* a greatest common divisor of 6 and -15. Then the Python documentation should say 'a greatest ...', not 'the greatest ...' since those who deny that the integer gcd is non-negative can hardly deny that a positive alternative value exists :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22477] GCD in Fractions
gladman added the comment: On 24/09/2014 17:24, Wolfgang Maier wrote: Wolfgang Maier added the comment: [snip] An aspect that hasn't really been discussed so far on the mailing list is that this is *not* only about whether the gcd of negative integers should be negative or positive, but also about the fact that in the current implementation the result of gcd is dependent on the order of the arguments: gcd(-3,6) == gcd(6,-3) False which I think is clearly unexpected. Yes, that's another interesting surprise. Ironically, though, the proposed new gcd would make this slower than it has to be since it would do the abs() repeatedly, when abs(reduce(_gcd, (3,6,9))) would suffice. So, I guess that's the tradeoff coming with the proposed change: I must admit to being more than a little hazy about what is fast and what isn't in the Python interpreter but wouldn't the use of reduce to repeatedly call _gcd be slower than an alternative that avoids this? Taking on board one of Steven D'Aprano's thoughts about multiple inputs, I had envisaged something like this: def mgcd(a, *r): # multiple gcd for b in r: while b: a, b = b, a % b return abs(a) which gives: mgcd(0) 0 mgcd(7, 0) 7 mgcd(0, 7) 7 mgcd(-3, -7) 1 mgcd(-3, 7) 1 mgcd(7, -3) 1 mgcd(-21, -91, 707) 7 So it has the properties that I believe it should have (yes, I know we don't agree on this). I am not sure I would extend it to rationals, although I don't feel strongly about this. This could be introduced elsewhere without changing what is done in fractions. Having two 'gcd's that return different results in some circumstances might be a source of confusion for some - but not more than already exists about what values the gcd should return :-) PS I just know that I am going to regret posting code 'on the hoof' - it's almost certain to be wrong :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22477 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
gladman added the comment:
On IDLE this:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit
(AMD64)] on win32
Type copyright, credits or license() for more information.
from datetime import datetime
datetime(1878, 12, 31).strftime('%d %b %y')
causes a crash on Windows. I am surprised that this bug still exists as it is
not far off two years old now.
--
nosy: +gladman
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13674
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
gladman added the comment: On 30/09/2013 12:39, STINNER Victor wrote: STINNER Victor added the comment: I am surprised that this bug still exists as it is not far off two years old now. You should report the bug to Microsoft who distributes a buggy C runtime library. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ Thank you for your suggestion. But, given that this bug has been present for some two years, I would hope that Python developers would have already done what you suggest and this leads me to doubt that any approach that I made to Microsoft would achieve any practical benefit. In practice it is pretty well always necessary in building applications on top of widely used compilers and libraries to have to workaround the many bugs that they contain. Since there is evidently no workaround for this issue in the Python 3.3.2 code, I have to assume that one is not considered to be necessary, presumably because Microsoft has fixed (or intends to fix) this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13674] crash in datetime.strftime
gladman added the comment: On 30/09/2013 13:14, Tim Golden wrote: Tim Golden added the comment: In reality (as I'm sure you can guess) it's just that no-one's got to the point of fixing it. I did start off, but it's not a trivial fix and clearly it got sidelined (with no-one shouting). Sometimes that's just the way it is. I'll see if I can dig out whatever code I had managed to change. I'm certainly happy to review and apply a patch if someone wants to supply one. Thank you for your comment Tim. To be honest, Python is just so reliable that I was genuinely very surprised to find something that actually crashes it :-) It's hardly a priority but I thought it might be worth a comment in case it was a bug that had simply been forgotten about. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13674 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
