Eric Appelt <eric.app...@gmail.com> added the comment:
Yes, thanks. I failed to see the duplicate searching for open issues, closing.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker <rep.
Change by Eric Appelt <eric.app...@gmail.com>:
--
nosy: +Eric Appelt
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32625>
___
_
New submission from Eric Appelt <eric.app...@gmail.com>:
The documentation for the EXTENDED_ARG instruction in the dis module
documentation refers to the way the opcode worked before 3.6:
https://docs.python.org/3.6/library/dis.html#opcode-EXTENDED_ARG
As I understand, since moving to
Change by Eric Appelt <eric.app...@gmail.com>:
--
keywords: +patch
pull_requests: +5788
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Eric Appelt added the comment:
> 2b - I propose to take a simple protocol like Memcache or
> Redis and simply implement it using the streams API. We’ll only
> need two methods: set and get; and in the end we’ll teach the user
> how things really work and how to design async APIs
Changes by Eric Appelt <eric.app...@gmail.com>:
--
nosy: +Eric Appelt
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30145>
___
_
Eric Appelt added the comment:
I added a PR to fix these two (in my opinion) spurious failure conditions in
the lib2to3.tests.test_parser.TestParserIdempotency test_parser test with the
following changes to the test:
1. Use the same encoding found in the initial file to write a temp file
Changes by Eric Appelt <eric.app...@gmail.com>:
--
pull_requests: +1360
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30117>
___
Eric Appelt added the comment:
I created a PR to update the documentation to use this pattern and follow
Raymond's suggestion of showing both ways to define an abc.
In order to make the examples comprehensible when read from beginning to end, I
reordered the classes so that abc.ABC
Changes by Eric Appelt <eric.app...@gmail.com>:
--
pull_requests: +1343
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30096>
___
Eric Appelt added the comment:
Thank you for the review and suggestions Nick, Serhiy, and all. I believe that
I have implemented the suggestions here and on github into a new commit on my
pull request which moves the test into an existing module and removes the
notion of a table in favor
Changes by Eric Appelt <eric.app...@gmail.com>:
--
pull_requests: +91
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29026>
___
_
Eric Appelt added the comment:
I added PR #54 with a test as Nick describes for checking magic number changes
and explaining to the developer the procedure to follow if this is required in
a maintenance release.
--
nosy: +Eric Appelt
pull_requests: +49
Eric Appelt added the comment:
As we have moved to GitHub and mandatory reviews with Pull Requests, I have
created a new patch in PR#34 which incorporates Victor's suggestions.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
Eric Appelt added the comment:
I had some checks performed on a Windows platform using the following snippet:
# valid for 2016
import time
def check():
t = time.gmtime()
print(46*86400*365 + 11*86400 + (t.tm_yday-1)*86400 + t.tm_hour*3600 +
t.tm_min*60 + t.tm_sec)
print(time.time
Eric Appelt added the comment:
I looked at the documentation and implementation and made a patch to hopefully
clarify the issue. I also have some comments:
- The term "epoch" is actually defined at the top of the page with instructions
for how to determine it, i.e. run "gmtime(
Eric Appelt added the comment:
I would be happy to work on a documentation patch for this - I'll try to have
something up by tomorrow evening if no one beats me to it.
--
nosy: +Eric Appelt
___
Python tracker <rep...@bugs.python.org>
Eric Appelt added the comment:
Thanks for the explanations and example code in the review! Working on this
issue is really helping to improve my understanding of a number of tricky
things like finalization.
I *think* that I have all the comments implemented in the attached patch.
I also
Eric Appelt added the comment:
I believe that I addressed all the comments in the previous review (although
its always possible I missed something), and have a new patch with the
improvements and fixes.
I also noticed that in asyncio, loop.shutdown_asyncgens() is a coroutinemethod
and fixed
Eric Appelt added the comment:
Yes - I'll work on the patch tonight.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28091>
___
__
Eric Appelt added the comment:
I think this needs considerable checking and polishing, but I am submitting
this "Work In Progress" patch for the PEP525 and PEP530 documentation so that I
can get some general feedback since I am new to this, and to ensure that if
this is not gene
New submission from Eric Appelt:
While testing my understanding in order to document PEP525 asynchronous
generators in the Language Reference (issue 28091) I noticed that the
implemented behavior deviates from PEP525, specifically the PEP states that:
"When an asynchronous gene
Eric Appelt added the comment:
Hi Yury - Yes, I am excited about doing this and getting to work on it. Today
was pretty busy but I have some time blocked out tomorrow to really dig in. I
was planning to give myself a deadline of Friday afternoon if that works for
the review/release schedule
Eric Appelt added the comment:
Hi, I'm a new contributor trying to get started with documentation and testing.
I have been following and testing PEP525 and PEP530 and feel familiar enough to
try to work on adding this to the Python Language Reference if it would not be
redundant with work
Eric Appelt added the comment:
Here are my test results - I'll re-describe the issue and test so people don't
have to read through all the previous text and for completeness.
-
The basic test case ("letter test"):
Consider the set of the f
Eric Appelt added the comment:
I made a copy/paste error on the second to last paragraph of the previous
comment, it should be:
Rehashing with the configured algorithm to shuffle the XORed result of the
entry and size hashes to finish computing the frozenset hash resulted in an
ideal
Eric Appelt added the comment:
If I understand the reporting properly all tests so far have used SipHash24:
Python 3.7.0a0 (default:5b33829badcc+, Oct 30 2016, 17:29:47)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin
Type "help", "copyright", "credi
Eric Appelt added the comment:
Ugh... so I think I made a mental error (i.e. confused myself) in the last
comment. The result looked a bit "to good to be true" and I think that there is
at least one error in my thinking about the problem.
I tried testing with the width set to 2
Eric Appelt added the comment:
I spent some time looking at the Objects/setobject.c code where the hashing
scheme for frozensets, which essentially works by XOR-ing together the hashes
from all its entries. Significant care is taken to shuffle bits at various
stages, and the algorithm seems
Eric Appelt added the comment:
I also looked at hashes of strings themselves rather than frozensets to check
the hashing of strings directly.
For example, n=3:
['', 'a', 'b', 'c', 'ab', 'ac', 'bc', 'abc']
rather than:
[frozenset(), frozenset({'a'}), frozenset({'b'}), frozenset({'c
Eric Appelt added the comment:
I dug into this failure a little bit and verified that it is specifically the
"letter_range" portion of the test that sporadically fails. The hash of any
frozenset constructed from floats, ints, or the empty frozenset, as well as
frozensets r
Eric Appelt added the comment:
I was able to inspect the review, and implemented your suggestions. This is
attached as a new patch. Please let me know if this is not the correct workflow.
Thank you for the prompt review and help as I learn the python tracking and
review process
Eric Appelt added the comment:
Thanks for the feedback. I agree that the comment is incorrect for several
iterations of the loop that really don't need to be tested at all for '5'. I
read the previous issue 17909 more carefully along with RFC 4627, 7159, and
EMCA 404 to properly understand
Eric Appelt added the comment:
I looked back and something is clearly wrong with my coverage reporting setup,
sorry :(
When I move the test introduced in issue 17909, 'test_bytes_decode' from the
module Lib/test/test_json/test_unicode.py to Lib/test/test_json/test_decode.py
that particular
New submission from Eric Appelt:
Increase test coverage of the json library, specifically the detect_encoding()
function in the __init__ module, which is used to handle the autodetection of
the encoding of a bytes object passed to json.loads().
This function was added in issue 17909 which
35 matches
Mail list logo
