Tal Einat added the comment:
Summary of the current state of this AC conversion derby group:
1) The collections, itertools and random modules should not be converted (at
least for now).
2) The three example modules should not be converted (Modules/xxlimited.c,
Modules/xxmodule.c and Modules
Tal Einat added the comment:
+1 for removal.
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13884
___
___
Python-bugs-list
Tal Einat added the comment:
Ping? Let's not miss the final 3.5 beta.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24483
___
___
Python-bugs
Tal Einat added the comment:
See also issue #24402: input() uses sys.__stdout__ instead of sys.stdout for
prompt
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1927
Tal Einat added the comment:
The patch is very simple, but this needs tests. At the very least, a simple tar
file which reproduces this issue could be added to the tests.
Taking this a step further would be writing some unit tests for the internal
nti() and itn() functions, and perhaps also
Tal Einat added the comment:
With clru_cache_known_hash_4.patch on the current default branch, the entire
test suite passes here (OSX 10.10).
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24483
Tal Einat added the comment:
I'm convinced. +1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24412
___
___
Python-bugs-list mailing list
Tal Einat added the comment:
Adding Thomas Wouters to the nosy list, since he's listed on the Experts Index
under autoconf/makefiles as an interest area. Hopefully he can help move this
forward.
--
nosy: +twouters
___
Python tracker rep
Changes by Tal Einat talei...@gmail.com:
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23020
Tal Einat added the comment:
Is this really needed? One can use try/except/raise, and since
addClassCleanup() would only be called from setUpClass(), I don't quite see the
utility of it.
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
Tal Einat added the comment:
Confirmed on OSX 10.10. Here's my output:
running build
running build_ext
building 'cmath' extension
./slow-cc.py -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement
-I./Include
Tal Einat added the comment:
I'm not convinced this would be worth the effort required to implement and
maintain it.
Can someone find examples from existing test suites where this would clearly be
useful? For example, a setUpClass() or setUpModule() function with multiple
try/finally clauses
Tal Einat added the comment:
See the existing issue and discussion about this on the six library's issue
tracker (opened nearly a year ago):
https://bitbucket.org/gutworth/six/issue/94/introduce-sixround
--
nosy: +taleinat
___
Python tracker rep
Tal Einat added the comment:
Ahh, that makes sense. Sounds good to me!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24412
___
___
Python-bugs
Tal Einat added the comment:
Okay, so the change is straightforward. With this change the entire test suite
passes on my machine.
We'll need a test for this for the test suite, and that's far less
straightforward. It seems that test.test_builtin.BuiltinTest.check_input_tty()
could
Tal Einat added the comment:
Attached is a revised patch for Modules/mathmodule.c incorporating changes
suggested by Serhiy in his review.
The major change is the reformatting of the doc-strings of most of the
functions in the module to use the same format as doc-strings generated by AC
Tal Einat added the comment:
Here's a patch with just the required fix (no tests).
--
keywords: +patch
Added file: http://bugs.python.org/file39697/issue24402.fix_only.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24402
Tal Einat added the comment:
How about IsoCalendarDate?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24416
___
___
Python-bugs-list mailing
Tal Einat added the comment:
So, is this in any ways different than NumPy's s_?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24379
Tal Einat added the comment:
(This should probably be discussed on the Python Ideas mailing list...)
I definitely like the idea of being able to construct slices etc. using []
syntax. I think this should be considered even if it is decided not to change
the repr() of slices.
An important
Tal Einat added the comment:
First, if pickle a namedtuple, it can't be unpickled in previous versions.
True, but I don't think Python goes as far as to promise that objects pickled
in one version can be unpickled in previous versions.
Second, namedtuple is slower and larger than tuple, so
Tal Einat added the comment:
(see https://mail.python.org/mailman/listinfo/python-ideas)
But for x = [1,2,3,4], how will x[y] work for all of the following values of y?
y = slice.literal[0]
y = slice.literal[1:2]
y = slice.literal[0:1, ..., 3]
NumPy's s_ magic object is a factory, returning
Tal Einat added the comment:
Is there any way that this could break existing code?
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24416
Tal Einat added the comment:
You can take a look at lru_cache_cache_info in Modules/_functoolsmodule.c for
an example of namedtuple instantiation in C code. But that code gets the
namedtuple class as a parameter.
This is not my area of expertise, but you could try using PyObject_CallFunction
Tal Einat added the comment:
Now for the color of the bike-shed: What should the namedtuple returned by
date.isocalendar() be named? Perhaps CalendarDate or DateTuple?
Baptiste's patches use ISOCalendarResult. In my opinion that is a poor name
since it does not tell you anything about what
Tal Einat added the comment:
See also the recent addition of a section on venv to the Tutorial section of
the docs (Doc/tutorial/venv.rst, issue23891). The wording there and in the
module docs should at least be consistent with each other.
--
nosy: +taleinat
Tal Einat added the comment:
There is a dangling If you at the end of the 3rd paragraph under Creating
Virtual Environments.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23891
Tal Einat added the comment:
You should post this on the python-ideas mailing list if you think this should
be added to the stdlib. Make sure to reference this issue if you do so.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Tal Einat added the comment:
I tried running the pystone benchmark, but the results were inconclusive. I saw
very large differences (up to 20%) between runs at different times, with no
clear differences with or without the patch.
However, a quick search shows that the operator module
Tal Einat added the comment:
Attached is a patch for all of _operator except for itemgetter, attrgetter and
methodcaller. The entire test suite passes after applying this patch.
Using AC has allowed the removal of all of the cryptic spam*() macros in the
code, making it much more
Tal Einat added the comment:
Attached a slightly revised patch thanks to Serhiy's review.
In addition to Serhiy's remarks, I used _operator._compare_digest =
_operator.eq to reduce a bit more boilerplate.
--
Added file: http://bugs.python.org/file39654/issue20186._operator.v2.patch
Tal Einat added the comment:
I just ran such microbenchmarks for operator.add and operator.not_, and saw no
significant difference with or without the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20186
Tal Einat added the comment:
Here's another complete conversion patch for _operator.
As suggested by Serhiy, I changed the comparison operators to copy the
signature from _operator.eq() instead of _operator.lt(), which is easier to
understand.
--
Added file: http://bugs.python.org
Tal Einat added the comment:
modules.patch and tutorial.patch LGTM.
venv.patch is looking good; I posted two relatively minor comments on Rietveld.
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23891
Tal Einat added the comment:
Your second suggestion of adding a 'threshold' parameter to quick_ratio() is a
bad idea in my opinion, since it would then be two significantly different
functions crammed into one.
The separate function would be possible. However, is there a compelling reason
Tal Einat added the comment:
Should Argument Clinic conversion patches still be against the 'default'
branch, and not 3.5, even though they don't include any functionality changes?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Tal Einat added the comment:
Indeed, it should be.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24270
___
___
Python-bugs-list mailing list
Tal Einat added the comment:
Attached is an updated patch for Modules/mathmodule.c.
This is based on Georg's patch, updated to apply to current 3.5, with several
improvements:
* replaced legacy converters
* converted math.ceil() and math.floor() functions
* converted the new math.gcd
Tal Einat added the comment:
Attached is an AC conversion patch for Objects/enumobject.c.
Note that this file contains the implementations of the 'enumerate' and
'reversed' classes, but *not* the 'Enum' class.
This is based on the 3.5 branch.
--
Added file: http://bugs.python.org
Tal Einat added the comment:
I've just committed this into 3.5 and 3.6.
(I accidentally included the wrong issue number in the commit message, so the
bot hasn't posted here about it. Sorry!)
--
___
Python tracker rep...@bugs.python.org
http
Tal Einat added the comment:
It's Chris.Barker. I've added him to the nosy list.
--
nosy: +Chris.Barker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24270
Tal Einat added the comment:
@Stefan K.: I tend to agree, but still think that's a separate issue.
math.isclose() certainly shouldn't be checking the type of its arguments.
While we're on the subject, though, trying to convert a very large int to float
fails with an OverflowError. Perhaps
Tal Einat added the comment:
Hopefully final patch attached. This adds cmath.isclose() along with relevant
tests and documentation.
Note that cmath.isclose() rejects complex tolerances -- only the values may be
complex.
--
Added file: http://bugs.python.org/file39532/isclose.patch
Tal Einat added the comment:
Indeed, those are major reasons for differences.
I avoided using Argument Clinic for math.isclose() because there is a pending
conversion patch for the entire math module and I didn't want to cause
unnecessary merge conflicts.
Is Paul's okay enough for me
Tal Einat added the comment:
Attached yet another revised version of the math.isclose() patch.
This patch fixes a problem with the tests in the previous patch which causes
them to fail when the full test suite is run.
I've also slightly reworded the doc-string.
Hopefully this is ready to go
Tal Einat added the comment:
Attached is a revised patch including changed due to the reviews by Berker and
Yuri.
The significant changes from the previous patch are:
1. The rel_tol and abs_tol parameters have been made keyword-only.
2. The tests have been extracted into a separate TestCase
Tal Einat added the comment:
Significant questions brought up by Berker Peksağ in his review of the latest
patch (thanks for the review!):
1. Should the tolerance parameters be keyword-only? Berker suggests that they
should be. I agree.
2. Should the math.isclose() tests be split
Tal Einat added the comment:
Regarding the tests, I now realize that most of them should be reused for
testing cmath.isclose(), which means they'll have to be defined outside of
test_math.MathTests.
--
___
Python tracker rep...@bugs.python.org
http
Tal Einat added the comment:
Attached is a slightly revised patch.
This mostly fixes minor documentation wording and formatting issues, including
those pointed out by Chris Barker on the python-dev mailing list.
Also, since it has been decided to support complex values only in a separate
Changes by Tal Einat talei...@gmail.com:
--
nosy: +mark.dickinson, rhettinger, stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24270
Tal Einat added the comment:
Attached is a patch based on Chris Barker's implementation on github[1]. This
includes only the C implementation, as well as tests, documentation and entries
in NEWS and whatsnew.
I had to keep the (PyCFunction) cast in the module method list in
Modules
Tal Einat added the comment:
I have a question regarding complex values. The code (from Chris Barker)
doesn't support complex values (only things that can be converted into
doubles). However, the PEP states the following under Non-float types:
complex : for complex, the absolute value
Tal Einat added the comment:
I'm now working this into a patch against current default.
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24270
Tal Einat added the comment:
Here's a patch just for Modules/sysmodule.c (and related files), based on
Georg's patch, updated to apply against current default, including fixes thanks
to Serhiy's review.
Despite Serhiy's suggestions, I've not used parameter groups, due to Larry's
statement
Tal Einat added the comment:
Serhiy: Indeed, you're right about sys.getsizeof(). I'm tending towards
changign it to use an optional group and per Serhiy's suggestion. Larry?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Tal Einat added the comment:
Attached in a conversion patch for Modules/_hashopenssl.c.
Since it appear that zlib has already been converted, that's the last file to
convert in this batch!
All tests pass on my OSX 10.10 (after running touch Modules/hashlib.h to get
make to recompile things
Tal Einat added the comment:
Well, the main reasons I'm +1 on the |= feature (regardless of specific
syntax) are:
1) the intent is much clearer: e.g. also accept None, nothing else special
going on
2) much easier maintenance if the default set of accepted types ever changes
Also, this is one
Tal Einat added the comment:
Do you mean the v2.patch file, or the one before it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20182
Tal Einat added the comment:
Sorry, my mistake, got mixed up with selectmodule.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20182
Tal Einat added the comment:
If I was writing a function/method with a conceptually boolean parameter
(True/False), I wouldn't want that to accept any Python object. For example, I
would want passing a tuple or list to raise a TypeError. But according to the
docs[1], that's what the 'p
Tal Einat added the comment:
+1. I was recently trying to use the C API for a 3rd party library, and all of
these subtly different string parameter formats made things surprisingly
confusing.
These are part of the Python C API, so removing them could break 3rd party
code. Simply searching
Tal Einat added the comment:
If this was for internal use only, intended to ease the transition to Argument
Clinic, then extensibility isn't an issue.
An upside to this is that it would make it easy in the future to find all of
the places in the stdlib using integers instead of bools
Tal Einat added the comment:
Here's a slightly modified version of the most recent patch for
Modules/selectmodule.c. The only difference relative to the previous version is
that I've set the epoll method function names back to what they used to be. My
reasoning is to stay consistent
Tal Einat added the comment:
Here's a new patch for Objects/unicodeobject.c with all of Serhiy's suggestions
integrated.
--
Added file: http://bugs.python.org/file39190/unicodeobject.c.v4.patch
___
Python tracker rep...@bugs.python.org
http
Tal Einat added the comment:
Hurrah!
And that seems to be it for this group, since collections, itertools and random
are not to be converted at this point, as well as the Modules/xx*.c files, and
the stringlib files probably require overly extensive changes for conversion
Tal Einat added the comment:
Version of patch with PyUnicodeObject * warnings fixed.
--
Added file: http://bugs.python.org/file39191/unicodeobject.c.v5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20180
Tal Einat added the comment:
Here's a patch just for Modules/signalmodule.c (and related files), based on
Georg's patch, updated to apply against current default, including fixes thanks
to Serhiy's review.
This include one minor doc change, since I changed the name of the second
parameter
Tal Einat added the comment:
Here's a patch just for Modules/selectmodule.c (and related files), based on
Georg's patch, updated to apply against current default, including fixes thanks
to Serhiy's review.
It took a while since I had to get a Linux VM up to run the epoll tests
Tal Einat added the comment:
Serhiy, I agree on both points. I can easily replace all of the converters and
upload it as three separate patches. If you haven't started reviewing the patch
yet, let me know and I'll do these things ASAP
Tal Einat added the comment:
I'm working on a new version of Georg's patch which applies to the current
default branch.
I'm having trouble with AC output going into a separate file, since this
requires a lot of things to be declared before the #include of the .c.h file.
Should I move all
Tal Einat added the comment:
Here's a new version of Georg's patch which applies to the current default
branch. On my OSX 10.8, CPython compiles fine and all tests pass, though
test_devpoll and test_epoll were skipped.
I haven't made additional changes, so there is still AC-related work
Tal Einat added the comment:
Note: Despite not appearing in any of these patches, the zlib module seems to
have already been converted.
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20182
Tal Einat added the comment:
Attaching new patch for unicodeobject.c, which supersedes the previous patches.
I've changed the name of the parameter of str.join() to iterable to match the
docs. (In the previous patch I had changed it from seq to
iterable_of_strings.)
I also fixed two minor
Tal Einat added the comment:
I'll test on OSX tomorrow or during the weekend at the latest.
However, on OSX there are three different versions of Tk available, and I'm
still not sure how to test with all of them. I'll try with one, at least, and
see if I can figure out how to try the others
Tal Einat added the comment:
@Ned: Great! Please keep me posted.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3068
___
___
Python-bugs-list
Tal Einat added the comment:
Fix committed to 3.4 and merged to default. (My first commit!)
Not back-porting this to 2.7 despite PEP 434, because support for non-ASCII
identifiers only exists in 3.x.
Close this issue as fixed!
--
___
Python
Tal Einat added the comment:
Bah, my original message was truncated!
I could use some help figuring out how to test with various Tk versions. I have
a Mac with OSX 10.8, and I've found the IDLE and tkinter with Tcl/Tk on Mac OS
X page[1], but I'm still not sure how to actually go about
Tal Einat added the comment:
I'm attaching a patch which really fixes this issue, along with additional
tests for idlelib.HyperParser.
I did indeed have to fix PyParse as well. I got it working with re.subn() as
Martin suggested, but the performance was much worse (between 100x and 1000x
Changes by Tal Einat talei...@gmail.com:
Removed file:
http://bugs.python.org/file35959/taleinat.20140716.IDLE_HyperParser_unicode_ids.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21765
Changes by Tal Einat talei...@gmail.com:
Added file:
http://bugs.python.org/file35960/taleinat.20140716.IDLE_HyperParser_unicode_ids_v2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21765
Tal Einat added the comment:
I've reviewed the patch and made my remarks in the review tool.
These tests don't test the central functionality of Percolator nearly enough.
We should test, at least:
1) That the text actually went through the filter (and not directly to the Text
widget).
2
Tal Einat added the comment:
I don't think this is a major issue. Most users only use one version of IDLE
with one version of Python.
IDLE's user config is indeed shared between all versions. This is an
unfortunate design mistake, and could perhaps be fixed in 3.5.
Regarding this issue, we
Tal Einat added the comment:
If you think ColorDelegator and UndoDelegator should be fixed as well, I'd be
happy to take a look, but we should open a separate tracker issue for it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Tal Einat added the comment:
So is that a go-ahead to commit to the 2.7 and 3.4 branches (as well as
default)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20577
Tal Einat added the comment:
@Martin:
1. This issue is only about identifiers. So processing of
string literals is technically out of scope.
I added a test with a non-ASCII string literal only for good measure, while I
was already adding a test with a non-ASCII identifier. The patch doesn't
Tal Einat added the comment:
Indeed, I seem to have been misinterpreting the grammar, despite taking care
and reading it several times. This strengthens my opinion that we should use
str.isidentifier() rather than attempt to correctly re-implement just the parts
that we need.
Attached
Tal Einat added the comment:
I've been waiting to commit this for some time. I'd really like to do this
myself, if you don't mind.
I'm just waiting for my SSH key to be added, which is taking a long time since
apparently all three people who could do so are traveling and unable to help
Tal Einat added the comment:
Note that the proposed patch only manages to replicate the
ID_Start and ID_Continue properties.
Is this just because of the mishandling of the Other_ID_Start and
Other_ID_Continue properties, or something else as well? I based my code on the
definitions
Tal Einat added the comment:
Many IDEs do show line numbers by default. And it does make discussing code
with others simpler, e.g. when teaching. But I tend to agree with Raymond that
it would be better to keep the default interface clean. Anyone who will want
line numbers will be able
Tal Einat added the comment:
Alright, so I'm going to use the equivalent of the following code, unless
someone can tell me that something is wrong:
from keyword import iskeyword
from unicodedata import category, normalize
_ID_FIRST_CATEGORIES = {Lu, Ll, Lt, Lm, Lo, Nl
Tal Einat added the comment:
What's the reason for checking if the ord is = 128?
It's an optimization. Assuming the majority of characters will be ASCII, most
non-identifier characters will fail this test, thus avoiding the more involved
generic Unicode check.
However, I would propose
Tal Einat added the comment:
Ouch. I hadn't thought about the Ellipsis literal!
That would be sensibly possible, yes, but not simple. I think opening a
separate issue for this would be prudent.
--
___
Python tracker rep...@bugs.python.org
http
Tal Einat added the comment:
It seems that the unicodedata module already supplies relevant functions which
can be used for this. For example, we can replace char in
self._id_first_chars with something like:
from unicodedata import normalize, category
norm_char = normalize(char)[0
Tal Einat added the comment:
Bah, I messed up the code sample in my previous message. It was supposed to be:
from unicodedata import normalize, category
norm_char_first = normalize(char)[0]
is_id_first_char = (
norm_char_first == '_' or
category(norm_char_first) in {Lu, Ll, Lt, Lm, Lo
Tal Einat added the comment:
AutoComplete isn't doing hidden checks. My concern is that auto-completion
happens automatically and the parsing is done synchronously, so if the parsing
takes a significant amount of time it can cause a delay long enough to be
noticeable by users. We should also
Tal Einat added the comment:
I like the idea, though it's really just nice to have. This is a very common in
IDEs these days, and whoever finds it annoying will be able to disable it.
If we do this, we should go all the way and close square and curly brackets,
parenthesis, and quotes
Tal Einat added the comment:
Well, I was wrong. I can't find anything of the sort in my old IDLE files.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18875
Tal Einat added the comment:
ParenMatch is indeed failing when the cursor is after the first parenthesis of
the following code:
(3 +
4 - 1)
This happens both in Shell and Editor windows.
I've traced the problem down to HyperParser. It doesn't properly support
multi-line statements, as can
Tal Einat added the comment:
Progress: As a hack for exploring this issue, I fixed this in the Shell window
by having ParenMatch instantiate HyperParser in such a way that it parses the
entirety of the current input. In ParenMatch.flash_paren_event(), I added:
from idlelib.PyShell import
Changes by Tal Einat talei...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21756
___
___
Python-bugs-list mailing
1101 - 1200 of 1433 matches
Mail list logo
