Tal Einat added the comment:
Good catches, Terry and Serhiy!
--
___
Python tracker
<http://bugs.python.org/issue20167>
___
___
Python-bugs-list mailing list
Unsub
Tal Einat added the comment:
FYI, with some help from Roger answering various questions, I've cooked up a
version of ClearWindow supporting the current version of IDLE. This includes
integration with the Squeezer extension.
I haven't tested it, however, nor written appropriate tes
Tal Einat added the comment:
Attaching a patch adding a ClearWindow extension for IDLE.
I took some ideas from Roger's version in IdleX, but I wrote this version from
scratch and it is significantly different in many aspects.
This patch includes extensive tests with 98% covera
Tal Einat added the comment:
Attached another patch which adds support for the Squeezer extension to
ClearWindow. This is necessary in case the Squeezer extension is added to IDLE.
This patch allows ClearWindow to properly remove "squeezed text" buttons
created by Squeezer, and als
Tal Einat added the comment:
Serhiy, which warnings?
Some of the tests use Tk GUI elements, so they include "requires('gui')". You
need to run the tests with a proper environment so that these tests are run;
otherwise you get a warning that the 'gui
Tal Einat added the comment:
See related issue6143 "IDLE - an extension to clear the shell window", where
special support for Squeezer is required in that extension (patch included
there).
--
___
Python tracker
<http://bugs.python.org
Tal Einat added the comment:
Regarding the last patch, see issue1529353 which proposes adding the Squeezer
IDLE extension (including patches).
--
___
Python tracker
<http://bugs.python.org/issue6
Tal Einat added the comment:
Terry, please do give Squeezer a try before making a decision! Squeezer may be
slightly more complex than ClearWindow in concept and in code, but IMO it is
simpler and more appropriate for use by a novice user.
I'm attaching a screenshot to give a feeling of
Tal Einat added the comment:
See msg212020 for a Python-style explanation of the utility of the Squeezer
extension.
--
___
Python tracker
<http://bugs.python.org/issue1529
Tal Einat added the comment:
Added screenshot of what working with the IDLE shell with the Squeezer
extension looks like (on Windows).
Note that the second squeezed text is the very long "Max recursion depth"
exception traceback, which I manually squeezed after it w
Tal Einat added the comment:
While we're bikeshedding, how about the more verbose PY_DECREF_AND_ASSIGN? That
makes it clearer that an INCREF is not done.
Regarding Kristján's suggestion of PY_ASSIGN and a complementary PY_STORE, IMO
these names are too similar and the difference be
Tal Einat added the comment:
PY_ASSIGN_AND_DECREF could seem to imply that the assigned value is DECREF-ed.
I think PY_DECREF_AND_ASSIGN makes it clearer that the original value is
DECREF-ed.
I like PY_ASSIGN_NULL_AND_DECREF, though for the same reason as above, I'd nam
Tal Einat added the comment:
The whole point of this patch is to make the EditorWindow's Text widget
the default master/parent for its dialogs!
IMO this makes sense, since this is a reasonable and intuitive default
for such methods of the EditorWindow object. I understand the "e
Tal Einat added the comment:
This should be dropped in favor of issue #1529142, which proposes a
simpler and better solution.
--
___
Python tracker
<http://bugs.python.org/issue1201
Tal Einat added the comment:
To recreate use BeautifulSoup 3.0.4 and run the following:
>>> from BeautifulSoup import BeautifulSoup
>>> soup = BeautifulSoup("aa>> x = soup.find('html').contents[0]
>>> x
u'aa'
>>> print x
Tr
Tal Einat added the comment:
Sending a code object back to the parent process and having it deal with
the situation sounds very unpleasant indeed! I think a completely
different type of solution may be possible.
In general, I can't think of any reason for IDLE to pickle "user
objects
Tal Einat added the comment:
"Test needed"? I'll need a bit of guidance on this.
Has there been a change of policy of which I'm not aware, that patches
to IDLE not going to be accepted unless comprehensive tests are included?
Much of IDLE doesn't include tests, e.g
Tal Einat added the comment:
Daniel, Thanks for clearing that up :)
--
___
Python tracker
<http://bugs.python.org/issue1529353>
___
___
Python-bugs-list mailin
Tal Einat added the comment:
First of all I think that the Squeezer (issue #1529353) extension is
more useful and solves most of the problems that this proposed feature
is set to solve, e.g. issue #1442493.
IMO the second method you offer - temporarily moving "iomark" - is
prefer
Tal Einat added the comment:
I'd like to implement this for 2.x, if there's any chance of this being
accepted. Is there still a chance of getting this into 2.7?
This will be my first patch for the Python core, so please tell me if I'm
missing something. Currently I'm thin
Tal Einat added the comment:
I'd really like to have this in 2.7. Is there no chance of getting it into 2.7
after rc1 is released?
If so, I can have the patch ready by Friday 14:00 GMT, but if nobody will have
time to review (and possibly commit) in time for RC1 I guess I'll ta
Tal Einat added the comment:
In my mind, the reason for this patch is that xrange/range can be thought of as
a lazy list of integers. However without this patch, membership checking was
done trivially instead of in a "smart/lazy" manner, which is unexpected for
users. Finally,
Tal Einat added the comment:
This goes down into _json.scanstring. Looking at the C code for
scanstring_unicode, the strict parameter allow control characters inside
strings: "if strict is zero then literal control characters are allowed". From
the code itself (current py3k head, r
Tal Einat added the comment:
This goes down into _json.scanstring. Looking at the C code for
scanstring_unicode, strict=False allows control characters inside strings: "if
strict is zero then literal control characters are allowed". From the code
itself (current py3k head, r81032)
Tal Einat added the comment:
Documentation patch attached against py3k branch.
Changes are:
* Added to documentation of JSONDecoder:
If *strict* is ``False`` (``True`` is the default), then control characters
will be allowed inside strings. Control characters in this context are those
Tal Einat added the comment:
Similar patch against trunk; same changes as for the py3k branch.
--
Added file: http://bugs.python.org/file17561/json_docs_trunk.diff
___
Python tracker
<http://bugs.python.org/issue4
Changes by Tal Einat :
--
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue4785>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
I can consistently reproduce this with Python 3.0.1 by setting IDLE to start in
editing mode and using Ctrl+o to open the Open dialog. Doesn't happen when
using the menu item in the File menu.
This leads me to believe it has something to do with keypress
Tal Einat added the comment:
Attaching patch against current py3k branch.
I simply replaced the occurrences of [rRuU] in the relevant regexps to [rRbB].
--
keywords: +patch
nosy: +taleinat
Added file: http://bugs.python.org/file17568/IDLE_py3k_string_highlighting.diff
Changes by Tal Einat :
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue7166>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
AFAIK submitting patches in general is covered well enough in several places.
What I'm missing specifically regarding patches for documentation is
instructions on how to preview them before submitting them. Editing reST is
easy, but making sure you'
Tal Einat added the comment:
Joseph, please mention which version of Python you are trying this with. If
2.6.4, please try with 2.6.5 to see if it still happens.
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue8
Tal Einat added the comment:
I believe IDLE runs modules via execfile(), so I would expect the behavior to
be similar, and execfile() does not set __file__. Doing "Run Module" is also
IMO equivalent to doing execfile(), so this behavior retains consistency.
However, I would expec
Tal Einat added the comment:
Why doesn't execfile() set __file__? I would be surprised if this is due to an
oversight by the Python devs. In both execfile and IDLE's "Run Module" I can't
think of a reason not to set __file__, but perhaps this was intentional?
Googlin
Tal Einat added the comment:
Apparently so. Those instructions are thorough and to the point, just what I
was looking for.
Adding a mention of this somewhere obvious, such as the links I mentioned
earlier, would be very helpful (this would have save me 30 minutes of futile
searching
Tal Einat added the comment:
Also, try renaming/moving the directory C:\Documents and
Settings\\.idlerc, and then try to start IDLE.
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue9
Tal Einat added the comment:
Wow, this has been on hold for ages! I know I could have used this information
in the past, and several people have asked me about this.
Perhaps there should be a place in the documentations which explains how
sys.path is populated, with detailed explanations for
Tal Einat added the comment:
Let's focus on the problem you're having with Python 2.6, with which you said
IDLE won't launch.
Please try to run IDLE using Python 2.6.5:
1) Install Python 2.6.5, say to C:\Python26
2) Rename/move your .idlerc directory so there isn't any suc
Tal Einat added the comment:
Because of the method of implementation, a dialog can be created without
specifying a parent. There was at least one instance of this in IDLE before my
patch. This is a bug, since the behavior of the dialog in this instance is
obviously incorrect (the user can
Tal Einat added the comment:
At this point I would prefer that this patch just be rejected rather than
continue discussing it.
I can understand IDLE being a low priority, but someone could have just stated
that to begin with and I wouldn't have bothered working for hours to work up a
Tal Einat added the comment:
IDLE should be accessible and easy to use for beginners who have never used a
command line. Therefore I don't think up/down should scroll through the history
by default. Since IDLE looks like a text editor (even the shell window) it is
more intuitive tha
Tal Einat added the comment:
Regarding passing on letter/number key-presses to the command line, I'm -0 on
this. Note that not only letter/number keys should be passed on.
I've often found myself wanting to type in the command line after looking at
previous code, to see that my k
Changes by Tal Einat :
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue1524639>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
I agree with Guilherme: shortcuts don't need to appear in the context menu.
Guilherme's patch looks pretty good overall, but I have a few remarks:
1) Pasting should be disabled in the Shell window when the cursor is before the
I/O mark. (the behavior f
Changes by Tal Einat :
Added file: http://bugs.python.org/file18090/IDLE_rmenu_py3k.patch
___
Python tracker
<http://bugs.python.org/issue1207589>
___
___
Python-bug
Tal Einat added the comment:
I agree that the wrapping of these in IDLE should be as transparent as possible.
It would be helpful if you could specify what other "quirks" you have found
regarding sys.stdin, sys.stdout and sys.stderr, preferably describing use cases
where
Tal Einat added the comment:
(Note: there has recently been some discussion of this on idle-dev and
python-dev.)
This may be nice to have but has complications. I think there are currently
more pressing issues regarding IDLE that require our attention.
Also, just adding tabs isn&#
Tal Einat added the comment:
On Windows, I can't think of any common reason to want to save a file edited in
IDLE without the .py extension. On the other hand, accidentally forgetting the
.py extension is annoying, and users have come to expect a default extension
being added by applica
Changes by Tal Einat :
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue6378>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tal Einat :
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue7676>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
Just to get this on the table: What is the benefit of having it opened in the
same instance of IDLE rather than a new instance?
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue5
Tal Einat added the comment:
+1 on renaming it "New File".
Patch attached for py3k.
--
keywords: +patch
nosy: +taleinat
Added file: http://bugs.python.org/file18092/IDLE_new_file_py3k.patch
___
Python tracker
<http://bugs.python.
Tal Einat added the comment:
You're right Terry, my bad, I got the issues mixed up.
--
___
Python tracker
<http://bugs.python.org/issue9222>
___
___
Pytho
Tal Einat added the comment:
On Windows, I can't think of any common reason to want to save a file edited in
IDLE without the .py extension. On the other hand, accidentally forgetting the
.py extension is annoying, and users have come to expect a default extension
being added by applica
Tal Einat added the comment:
I'm quite sure that issue has already been addressed. Specifically r71126 made
it so that running IDLE with -e always opens just an editor window. "Edit with
IDLE" runs IDLE with -e.
With which version of Python do you see this hap
Tal Einat added the comment:
I agree on this. Unfortunately that change in r71126 wasn't commented on or
documented in any way.
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/i
Tal Einat added the comment:
That makes sense. I think this issue can be closed.
For future reference, the original feature request has a benefit beyond not
having a shell window open for every editor window. Opening different files in
the same instance of IDLE allows running them in the
Tal Einat added the comment:
Note that at one point discussion of this issue was continued on the tracker
page for issue1252.
--
___
Python tracker
<http://bugs.python.org/issue1
Tal Einat added the comment:
I'm sorry I let this die out. This should stay closed.
For the time being I have given up on developing the ShellLogger extension (for
the time being) so this change is not needed as far as I am conc
Tal Einat added the comment:
After looking through the code and experimenting a bit, I propose the following:
The "editor-on-startup" config option should be removed. Running IDLE without
arguments should open a shell. If IDLE is asked to open any files for editing,
it should
Tal Einat added the comment:
My question is, when IDLE is run without arguments (as is the case for
IDLE.app), what is the benefit opening an empty editor window as opposed to a
shell window?
In both cases if you just want to edit a file you must open it via the menus
(e.g. File->Open
Tal Einat added the comment:
I'm +1 on adding such an option to the menu, if only to be able to highlight
files including only Python code which don't happen to have the .py extension.
If support for files including not only Python code is important to anyone,
some examples of
Tal Einat added the comment:
In the last paragraph of my previous post, instead of "is a different matter"
read "may be problematic".
--
___
Python tracker
<http://bu
Tal Einat added the comment:
I think we are in agreement :)
Regarding the warning message, I was referring only to the case that the syntax
highlighter fails completely and raises an exception. I'm not even sure if that
can happen, but in case it does an informative message would be b
Tal Einat added the comment:
Unfortunately, I won't be able to review this due to lack of time.
--
___
Python tracker
<http://bugs.python.org/issue20180>
___
___
Tal Einat added the comment:
Serhiy, no apology is required. On the contrary, thank you for the taking the
time to review this and commit, I don't have time available for this these days.
--
___
Python tracker
<http://bugs.python.org/is
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
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
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 into a
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
<http://bugs.py
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 extra
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
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:
@Stefan: Well, this seems to already be the situation with the rest of the math
module:
>>> math.isinf(Decimal("1e999"))
True
>>> math.sqrt(Decimal("1e999"))
inf
Properly handling other types which are convertible to flo
Tal Einat added the comment:
Alright then, but is anyone going to review this so that it can go in? The
actual code to review is very short, the documentation is clearly written and
not too long, and the tests are easy to read!
--
___
Python
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
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 Overflo
Tal Einat added the comment:
It's Chris.Barker. I've added him to the nosy list.
--
nosy: +Chris.Barker
___
Python tracker
<http://bugs.python.o
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
<http://bugs.python.o
Tal Einat added the comment:
Indeed, it should be.
--
___
Python tracker
<http://bugs.python.org/issue24270>
___
___
Python-bugs-list mailing list
Unsubscribe:
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:
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
<http://bugs.pyt
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.
--
Adde
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
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 is
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/issue2018
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
<http://bugs.python.org/issue20
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.pytho
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 compell
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
<http://bugs.python.org/issue23
Tal Einat added the comment:
Here's another version of the _operator patch, with another small change after
Serhiy's latest review.
--
Added file: http://bugs.python.org/file39656/issue20186._operator.v4.patch
___
Python trac
Tal Einat added the comment:
This patch was applied in changeset 57a27aae7836.
--
resolution: duplicate -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
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
<http://bugs.python.org/issue24
Tal Einat added the comment:
There is a dangling "If you" at the end of the 3rd paragraph under "Creating
Virtual Environments".
--
___
Python tracker
<http://bug
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:
(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
Tal Einat added the comment:
+1 for keeping the current behavior and fixing the docs.
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue24
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 fac
Tal Einat added the comment:
Is there any way that this could break existing code?
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue24
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 l
1301 - 1400 of 1452 matches
Mail list logo
