[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria added the comment: I updated my GitHub username. For the record, it used to be mikez302, and now it is elias6. -- ___ Python tracker <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment: Mark, you have some good points. I didn't fully think about the implications of my change. I undid the change to _operator_fallbacks. I updated the tests to expect 1.0 // 1/10 to equal 9.0 and 1.0 % 1/10 to equal 0.09995. That latter number seems a bit awkward though. Can I expect the result to always come out like that, or could it depend on the hardware the test is run on? If we can't depend on that result, do you have any suggestions? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment: Mark, I tried `Fraction(10**23) // 1e22`, and I got 10. Your `10**23 // 1e22` example was strange, but then `int(1e23)` and got 1611392. That is kind of unexpected but I think it is rare for anyone to do something like that with numbers that big. I think the fact that floating-point rounding error sometimes causes strange results is not a reason to do really unexpected things like making 1.0 // 1/10 equal 9.0, if that can be reasonably avoided. I updated my pull request with my change, which you suggested, to make __rfloordiv__ and __rmod__ return a float, but with a small change to _operator_fallbacks to avoid the rounding error, so 1.0 // 1/10 is 10.0. You can see it at https://github.com/python/cpython/pull/5956/commits/1020bb219c1a4fad575ee2309c930ce82a4777fb#diff-14d03bfb59581367725b00781e6f802fL391. What do you think? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment:
Mark, what you described (operator_fallbacks for both __rfloordiv__ and
__floordiv__, and for both __rmod__ and __mod__) was my initial approach. But
that broke one test (which floor-divides 1.0 by 1/10 and expects the result to
be an integer). I thought about fixing it, to make the behavior more
consistent, but I thought that was a bit risky.
Just now, I tried the change again, as you suggested, but I fixed the test to
expect a result of 10.0 (a float) instead of 10 (an integer). I got a strange
result from that test, saying the result was 9.0.
It seems like this is caused by rounding error, since operator_fallbacks
converts both numbers to floats if one of them is a float, and 1/10 can't be
represented exactly as a float, so it gets rounded to slightly more than 1/10:
>>> float(Fraction(1, 10)).as_integer_ratio()
(3602879701896397, 36028797018963968)
>>> Decimal.from_float(float(Fraction(1, 10)))
Decimal('0.155511151231257827021181583404541015625')
So yes, I can make that change, but I'm not sure if it would be a good idea. Do
you have any thoughts?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32968>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment: Done. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment: Any suggestions as to what I should do? I can either update my pull request with my floordiv change, or create a new pull request, or wait a while to see if anyone else has any opinion on changing the behavior. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment: I added the pull request. It includes only my changes to modulo, and not the ones to floordiv. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Change by Elias Zamaria <mikez...@gmail.com>: -- keywords: +patch pull_requests: +5721 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment: Mark, you said "if there's a test that's explicitly checking that `my_fraction // my_float` returns something of type `int`, then the behaviour is clearly intentional". I see exactly that. See https://github.com/python/cpython/blob/bf63e8d55fd2853df3bb99d66de7f428107aadb3/Lib/test/test_fractions.py#L404 In fact, when I said I made floordiv return a float, and "changed one test to make sure that it works", it was that test. So maybe that means we should be more cautious about changing the behavior of floordiv, if we decide to change it. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
Elias Zamaria <mikez...@gmail.com> added the comment: Mark, you have some good ideas. A fraction modulo a float is a float, and an integer modulo infinity produces itself as a float, so it seems reasonable that a fraction modulo infinity should be itself converted to a float. I tried assigning __mod__ and __rmod__ using _operator_fallbacks, like most of the binary operators, and calculations involving infinity behaved as I expected, but one test failed (1.0 % Fraction(1, 10) was no longer 0 because of rounding error). But then I tried assigning only __mod__ using _operator_fallbacks, and leaving __rmod__ alone, and all the tests passed (including some ones I added to make sure that modulo calculations involving infinity behave like both of us think they should). As for the floordiv operator, I'm not sure what to think. It would be a bit strange if mod with a float returns a float and floordiv with a float returns an int. It wouldn't be a big deal IMO but it may be easy to change. I tried a simple change to make floordiv with a float to return a float, and changed one test to make sure that it works, and all of the tests passed. I can make a pull request if anyone wants. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32968] Fraction modulo infinity should behave consistently with other numbers
New submission from Elias Zamaria <mikez...@gmail.com>:
Usually, a positive finite number modulo infinity is itself. But modding a
positive fraction by infinity produces nan:
>>> from fractions import Fraction
>>> from math import inf
>>> 3 % inf
3.0
>>> 3.5 % inf
3.5
>>> Fraction('1/3') % inf
nan
Likewise, a positive number modulo negative infinity is usually negative
infinity, a negative number modulo infinity is usually infinity, and a negative
number modulo negative infinity is usually itself, unless the number doing the
modding is a fraction, in which case it produces nan.
I think fractions should behave like other numbers in cases like these. I don't
think this comes up very often in practical situations, but it is inconsistent
behavior that may surprise people.
I looked at the fractions module. It seems like this can be fixed by putting
the following lines at the top of the __mod__ method of the Fraction class:
if b == math.inf:
if a >= 0:
return a
else:
return math.inf
elif b == -math.inf:
if a >= 0:
return -math.inf
else:
return a
If that is too verbose, it can also be fixed with these lines, although this is
less understandable IMO:
if math.isinf(b):
return a if (a >= 0) == (b > 0) else math.copysign(math.inf, b)
I noticed this in Python 3.6.4 on OS X 10.12.6. If anyone wants, I can come up
with a patch with some tests.
--
components: Interpreter Core
messages: 313045
nosy: elias
priority: normal
severity: normal
status: open
title: Fraction modulo infinity should behave consistently with other numbers
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32968>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria <mikez...@gmail.com> added the comment: INADA, what is ML? How do I restart the discussion? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria <mikez...@gmail.com> added the comment: What else needs to be done with this issue? Can someone merge my pull request? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria <mikez...@gmail.com> added the comment: Can someone here merge my pull request? If not, then what else needs to be done for my change to be included in 3.7? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Changes by Elias Zamaria <mikez...@gmail.com>: -- pull_requests: +3279 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29076] Py 3.6 Mac installer doesn't update "python3" shell command
Elias Zamaria added the comment: Ned, that sounds plausible. I think I started using fish after I installed Python 3.5, but before I installed Python 3.6. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29076] Python 3.6 installer doesn't update "python3" shell command
Elias Zamaria added the comment: I just ran "ls -le ~/.bash_profile" and got this result: -rw-r--r--+ 1 Elias staff 1057 Jul 2 11:04 /Users/Elias/.bash_profile 0: user:_spotlight inherited allow read,execute,readattr,readextattr,readsecurity -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29076] Python 3.6 installer doesn't update "python3" shell command
Elias Zamaria added the comment: I just ran "ls -l ~/.bash_profile" and got the following output: -rw-r--r--+ 1 Elias staff 1057 Jul 2 11:04 /Users/Elias/.bash_profile -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29076] Python 3.6 installer doesn't update "python3" shell command
New submission from Elias Zamaria: I have a Mac running OS X 10.11.6, Python 3.5.2, and fish 2.3.1. I installed Python 3.6.0, and everything seemed to work fine. However, I typed "python3" in my shell and it started Python 3.5.2. I restarted my shell and typed "python3", and it still started Python 3.5.2. I ran "which python3" and it told me "/Library/Frameworks/Python.framework/Versions/3.5/bin/python3". I ran "echo $PATH" and it told me "/Library/Frameworks/Python.framework/Versions/3.5/bin", among other directories that seem unrelated to Python. I thought that maybe the installer updated my ~/.bash_profile, assuming that I am using bash like most people, but I looked in that file, and the only things affecting my path that look Python-related are adding the directories "/Library/Frameworks/Python.framework/Versions/2.7/bin" and "/Library/Frameworks/Python.framework/Versions/3.5/bin". I re-ran the installer, clicked the "Customize" button, made sure that the "Shell profile updater" checkbox was checked, and ran "python3", and it started Python 3.5.2. I can probably fix this by adding the right directory to my $PATH, but I think it is a bug if the installer doesn't make that change for me, or even try to make the change. -- components: Installation, macOS messages: 284036 nosy: elias, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python 3.6 installer doesn't update "python3" shell command versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29076] Python 3.6 installer doesn't update "python3" shell command
Changes by Elias Zamaria <mikez...@gmail.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators
Elias Zamaria added the comment: I tried my code in Python 3.6.0b3 and got the same result. -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators
New submission from Elias Zamaria:
I have the following code:
from multiprocessing import Pool
def double(x):
return 2 * x
def get_numbers():
raise Exception("oops")
yield 1
yield 2
print(list(Pool(processes=2).imap(double, get_numbers(
I would expect it to raise an exception, but instead it just prints "[]",
seeming to indicate that imap ran fine and produced no values.
This seems similar to the behavior described in bugs 23051 and 26333, but this
happens if the iterator directly raises an exception before yielding anything.
If I move the raise statement below one or both of the yields, I get an
exception from imap as expected.
I am experiencing this with Python 3.5.2 on OS X 10.11.6. I haven't tried it
with any other versions.
--
components: Library (Lib)
messages: 280146
nosy: elias
priority: normal
severity: normal
status: open
title: multiprocessing.Pool.imap swallows exceptions thrown by generators
type: behavior
versions: Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28625>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: Ethan, by "Ned", I am guessing that you are referring to Ned Batchelder. Is that right? If so, do we need to put him on the nosy list or do anything else to bring this to his attention? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: I looked through the email thread. I can remove the DeprecationWarnings, but before I do that, I would like to ask something: How "official" are the things discussed in the thread? Are they supposed to be part of the PEP? Are they supposed to be final, definite decisions, or are they things that may change soon? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: Martin, I made another attempt to understand what you are trying to tell me about the patch, and I'm still confused. It seems that to make the patch merge cleanly, I need to get the patch URL from this page, and to get the patch URL, I need to upload the patch, and to upload the patch, I need to produce the patch, and to produce a patch that merges cleanly, I need to get the patch URL. That sounds like a catch-22. Where am I supposed to start? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: Martin, where am I supposed to get the patch URL from? Also, is it too soon to issue DeprecationWarnings? Would it be more appropriate if they are PendingDeprecationWarnings instead? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: Here is a patch with all of my latest changes, including the changes that Martin suggested for the tests. -- Added file: http://bugs.python.org/file44332/pep467_attempt2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: I tried running `hg import --no-commit "$(xclip -o)"` and got the following result: bash: xclip: command not found abort: need at least one patch to import I am using OS X 10.11.6 and Mercurial 3.8.2. I did a bit of quick research on xclip, but it looks like yet another unfamiliar tool, and I don't know exactly what it does or how it is supposed to help me. I looked at your suggestions for my patch, and I am working on them. I am planning to look at the tutorial, and to look for, and maybe fix, deprecated calls, but so far, I don't have a clear idea how long it will take me, or if it is realistic for one person to do it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: @martin.panter, I am familiar with Mercurial, and with the concept of rebasing, but I don't understand what you are trying to tell me. I made these changes in several local branches, and then merged them all together in one branch. How can I rebase it onto a public revision? Can I just do it, or do I need some sort of special privileges? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
Elias Zamaria added the comment: Here is a patch with some changes to the docs. I don't know if the descriptions are good enough, but it should hopefully identify what parts of the docs need to be changed. -- Added file: http://bugs.python.org/file44313/pep467_doc_changes.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27923] PEP 467 -- Minor API improvements for binary sequences
New submission from Elias Zamaria: This is my attempt at implementing PEP 467. I am not an expert in the details of the Python interpreter, and this is my first time working on a big project in C, so I am not sure if I am doing things in the most elegant or efficient way, but it seems to work fine, as far as I can tell. I have added some tests for the new functionality. I am planning to work on changes to the documentation some time in the next few days. I noticed a lot of places that are using the deprecated integer-argument bytes and bytearray constructors. I left most of them alone, although I changed a few of them to the zeros constructors to prevent certain tests from failing. -- components: Interpreter Core files: pep467.patch keywords: patch messages: 274082 nosy: mikez302 priority: normal severity: normal status: open title: PEP 467 -- Minor API improvements for binary sequences type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file44312/pep467.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19980] Improve help('non-topic') response
Elias Zamaria added the comment:
Sorry for the late response but I have been busy with various things. I may
be able to work on this but I don't know when or how long it will take me.
I would suggest that someone else work on it if anyone wants it done any
time soon. I am sorry about this.
On Mon, Apr 14, 2014 at 7:43 AM, Jessica McKellar rep...@bugs.python.orgwrote:
Jessica McKellar added the comment:
Elias, thanks for your patch!
I think it's important to add the second part of Terry's suggestion which
gives the user a specific next step to take, namely:
Try help('help') for information on recognized strings or help(str) for
help on the str class.
Can you add that to your patch?
Additionally, we'll want to make sure we don't accidentally break this new
functionality. Can you add a few test cases, for example what happens when
you run help on a module (e.g. help(os), 2) help on an instance of a
class (e.g. help(1)), and help on a string that doesn't have a special
meaning, (e.g. help(abcxyz))?
I don't see any existing tests for help(), but it is an instance of
site._Helper (as reported by type(help)), and site tests live in
Lib/test/test_site.py. It also gets loaded into builtins, so tests could
also live in Lib/test/test_builtins.py.
--
nosy: +Jessica.McKellar, jesstess
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19980
___
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19980
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20849] add exist_ok to shutil.copytree
Elias Zamaria added the comment: I am not sure. I am not on the python-ideas mailing list, and I am not sure what adding and maintaining the discussion would entail, or if I would have the time to do it or want to deal with the clutter in my inbox. I just committed this patch because it seemed like it would be quick and easy. I can start the discussion if anyone specifically wants me to, but I don't want to let anyone down. On Fri, Mar 7, 2014 at 1:41 PM, Éric Araujo rep...@bugs.python.org wrote: Éric Araujo added the comment: Contrary to makedirs, there could be two interpretations for exist_ok in copytree: a) if a directory or file already exists in the destination, ignore it and go ahead b) only do that for directories. The proposed patch does b), but the cp tool does a). It's not clear to me which is best. Can you start a discussion on the python-ideas mailing list? -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20849 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19980] Improve help('non-topic') response
Elias Zamaria added the comment: Here is a patch that addresses the empty string problem described by @BreamoreBoy. I am not sure if this is the best way to handle it but it is better than what we have now. -- Added file: http://bugs.python.org/file34281/empty-help-response.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20849] add exist_ok to shutil.copytree
Elias Zamaria added the comment: Here is a patch that adds the option. I am not very familiar with the internals of shutil and os so I would recommend that someone else review it. I haven't added any tests. I can try to if anyone wants but I am not sure how long it will take me or if I will find the time any time soon. -- keywords: +patch nosy: +mikez302 Added file: http://bugs.python.org/file34282/shutil-copytree-exist_ok.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20849 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19980] Improve help('non-topic') response
Elias Zamaria added the comment: I have created a patch that fixes this issue that terry.reedy described. It does not fix the problem described BreamoreBoy involving the empty string. Please note that this is my first patch for Python so let me know if I am missing something or if I can do anything else to help. -- keywords: +patch nosy: +mikez302 Added file: http://bugs.python.org/file33251/help-response.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19980 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11705] sys.excepthook doesn't work in imported modules
New submission from Elias Zamaria mikez...@gmail.com: I am trying to design a Python program that logs all uncaught exceptions using the logging module. I am doing this by using the sys.excepthook function to override the default exception handling. I noticed that if I run the program directly from the command line, it works fine, but if I try to import the file, it doesn't work. It seems like the sys.excepthook function is unaware of the logging module. Here is an example: #! /usr/bin/env python2.7 import logging, sys logger = logging.getLogger() logger.setLevel(logging.DEBUG) logger.addHandler(logging.FileHandler(test.log)) print outside of exception handler: logger = %s % logger def handleException(excType, excValue, traceback): #global logger # this function doesn't work whether or not I include this line print inside exception handler: logger = %s % logger logger.error(Uncaught exception, exc_info=(excType, excValue, traceback)) sys.excepthook = handleException logger.debug(starting) asdf# create an exception If I run this from the command line (`./loggingTest.py`), it works fine. The exception gets logged, and I see this output: outside of exception handler: logger = logging.RootLogger object at 0x7f2022eab950 inside exception handler: logger = logging.RootLogger object at 0x7f2022eab950 However, if I run the Python interpreter and try to import the file (`import loggingTest`), it acts strangely. The exception doesn't get logged and I see this: outside of exception handler: logger = logging.RootLogger object at 0x7f8ab04f3ad0 inside exception handler: logger = None Error in sys.excepthook: Traceback (most recent call last): File loggingTest.py, line 13, in handleException logger.error(Uncaught exception, exc_info=(excType, excValue, traceback)) AttributeError: 'NoneType' object has no attribute 'error' Original exception was: Traceback (most recent call last): File stdin, line 1, in module File loggingTest.py, line 18, in module asdf# create an exception NameError: name 'asdf' is not defined I can maybe work around this problem by importing the logging module again within sys.excepthook, but I am still curious: why is this happening? The above text was copied from my question on Stack Overflow (http://stackoverflow.com/questions/5451746/sys-excepthook-doesnt-work-in-imported-modules). Someone on there (Jochen Ritzel) has mentioned that he noticed this bug in Python 2.7.1 but not 2.7. To me, it seems like the sys.excepthook function is unaware of any imported modules, unless those modules are imported from inside the function. -- components: Library (Lib) files: loggingTest.py messages: 132437 nosy: mikez302 priority: normal severity: normal status: open title: sys.excepthook doesn't work in imported modules type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file21446/loggingTest.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11705] sys.excepthook doesn't work in imported modules
Elias Zamaria mikez...@gmail.com added the comment: Andreas, your explanation seems plausible. What has changed between 2.7 and 2.7.1 such that doing the same thing produces different results? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11705] sys.excepthook doesn't work in imported modules
Elias Zamaria mikez...@gmail.com added the comment: Is my issue a bug or is it expected behavior? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10592] pprint module doesn't work well with OrderedDicts
New submission from Elias Zamaria mikez...@gmail.com: If I try to pretty-print an ordered dictionary, it doesn't show nicely. Instead of having each key-value pair on its own line, the whole thing shows up on one long line, which wraps many times and is hard to read. I can provide an example if you want. Is there a way to make it print nicely, like the old unordered dictionaries? -- components: Library (Lib) messages: 122963 nosy: mikez302 priority: normal severity: normal status: open title: pprint module doesn't work well with OrderedDicts type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10592 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10592] pprint module doesn't work well with OrderedDicts
Elias Zamaria mikez...@gmail.com added the comment: I forgot to mention, someone came up with this suggestion (http://stackoverflow.com/questions/4301069/any-way-to-properly-pretty-print-ordered-dictionaries-in-python/4303996#4303996). It is not the best, but the output is better than how it is now. Can it be somehow integrated into the PrettyPrinter.format method? -- resolution: duplicate - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10592 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
