Tal Einat added the comment:
New changeset 3b0047d8e982b10b34ab05fd207b7d513cc1188a by Tal Einat (Alexey
Izbyshev) in branch 'master':
bpo-34482: test datetime classes' handling of non-UTF-8-encodable strings
(GH-8878)
https://github.com/python
Tal Einat added the comment:
Ned, should this also be added to the 2.7 What's New? Or perhaps reverted on
the 2.7 branch?
--
___
Python tracker
<https://bugs.python.org/is
Tal Einat added the comment:
Thanks for the PR, Alexey!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: -Python 3.6
___
Python tracker
<https://bugs.python.or
Change by Tal Einat :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Tal Einat :
--
pull_requests: +9406
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
See PR GH-10072 for reverting in 2.7.
--
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Python-bugs-list mailin
Change by Tal Einat :
--
pull_requests: +9407
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
See PR GH-10073 adding mention in "What's New".
--
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Change by Tal Einat :
--
pull_requests: +9408
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Tal Einat :
--
pull_requests: +9409
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
Thanks for helping with the fallout from this, Gregory.
--
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Pytho
Change by Tal Einat :
--
nosy: +taleinat
___
Python tracker
<https://bugs.python.org/issue34187>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
This doesn't strike me as a bug, or even clearly being a potential improvement.
If this about round-trip parsing/serializing not preserving order, that would
be significant. As it is, if this is only intended as a debugging tool, why
change it?
Is th
Tal Einat added the comment:
The test code should fail with the current, unfixed code, due to the bug
described here. You will need to:
1. figure out which conditions will trigger the wrong behavior
2. set up a scenario where you can detect whether the behavior is correct
3. code this as a
Tal Einat added the comment:
Thanks for the clarification, Raymond.
I've spent a few minutes searching for uses of dump(), and have only come up
with uses for debugging or printing helpful info in command line tools. So, it
seems that changing this as suggested wouldn't break muc
Tal Einat added the comment:
Shivank, your last comment is unclear. Are you asking a question or just
reporting some progress?
--
___
Python tracker
<https://bugs.python.org/issue35
Change by Tal Einat :
--
versions: -Python 2.7
___
Python tracker
<https://bugs.python.org/issue33899>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
New changeset 1487b651caa62647f8f8c9e8432e475e3566130c by Tal Einat (Andrés
Delfino) in branch '3.7':
[3.7] bpo-34789: xml.sax.make_parser expects a list not just any sequence
(GH-9542)
https://github.com/python/cpyt
Tal Einat added the comment:
I'm not sure that the resolution currently suggested, changing
compiler.set_executables(), is the right way to go.
This change to distutils is a break of backwards compatibility. Though it is a
minor change, it could still break existing code.
F
Tal Einat added the comment:
New changeset a6dc531063efe3a8d47ff4639729060c72a3688c by Tal Einat (Andrés
Delfino) in branch 'master':
bpo-34789: make xml.sax.make_parser accept iterables of all types (GH-9576)
https://github.com/python/cpython/commit/a6dc531063efe3a8d47ff463972906
Tal Einat added the comment:
Thanks for reporting the issue and making the PRs, Andrés!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Tal Einat added the comment:
Shivank, there is currently technically no "error to solve", since we have no
test that causes this erroneous behavior and catches it. We've only found what
appears to be a bug by looking at the code, but we need to *verify* that it is
indeed a
Tal Einat added the comment:
Looking at the code in Lib/xml/dom/minidom.py, this exact typo is also found in
DocumentType.cloneNode(). That should be tested and fixed too.
--
___
Python tracker
<https://bugs.python.org/issue35
Tal Einat added the comment:
Shivank, I recommend taking a look at some of the existing tests for this
module, found in Lib/test/test_minidom.py. See how they are built and how
various functionality is tested. This should give you a good idea of what a
test for this bug would look like
Tal Einat added the comment:
Shivank, indeed it seems you're now in the right direction.
A bit of clarification:
* The test shouldn't test _clone_node() directly, since that is an internal
function. Rather, the test code should be as near as possible to what a user
of the mini
Tal Einat added the comment:
There is also a middle ground: Keep .write() as it is *and* have .dump()
preserve the order in which the parameters were supplied in the constructor.
They could both use a common *internal* method with a flag to select the
desired ordering
Tal Einat added the comment:
The search and replace dialogs are also broken by "Prefer tabs when opening
documents" being active: they as separate tabs rather than a dialog window.
--
___
Python tracker
<https://bugs.python.o
New submission from Tal Einat :
On macOS, Command-M simultaneously minimizes the window and opens the "Open
Module..." dialog. This happens with a very confusing sequence of visual
effects (see attached animated gif).
This doesn't happen when activating either of the menu i
Tal Einat added the comment:
This is a great, easy, doc-only issue for a new contributor to handle.
--
keywords: +easy
nosy: +taleinat
versions: +Python 3.6, Python 3.7, Python 3.8 -Python 3.2, Python 3.3
___
Python tracker
<ht
Tal Einat added the comment:
I agree that mentioning that IDLE won't work 100% with that setting on is a
good idea. I also agree that at this point it's not worth the effort to do
anything more than that.
--
___
Python track
Change by Tal Einat :
--
versions: +Python 2.7, Python 3.6, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34864>
___
___
Python-bugs-list mailin
Change by Tal Einat :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue34864>
___
___
Python-bugs-list mailing list
Unsubscrib
Tal Einat added the comment:
> I think for starters we should document the behavior of strptime when no
> year, month or day are specified. As part of that documentation, we can add a
> footnote about Feb 29th.
This sounds good to me.
We could also improve the exception rais
Tal Einat added the comment:
`not cmd` will but true if cmd is None, so it is completely equivalent to `cmd
is None or not cmd`. This is a purely stylistic change which doesn't alter the
logic.
To get a clear understanding of what's going on, I recommend reading the short
&q
Tal Einat added the comment:
`not cmd` will be true if cmd is None, so it is completely equivalent to `cmd
is None or not cmd`. This is a purely stylistic change which doesn't alter the
logic.
To get a clear understanding of what's going on, I recommend reading the short
&q
Change by Tal Einat :
--
Removed message: https://bugs.python.org/msg329154
___
Python tracker
<https://bugs.python.org/issue34897>
___
___
Python-bugs-list m
Tal Einat added the comment:
I agree with Ned's analysis. The shortcut for macOS should be changed, or
simply removed if there's no good candidate for a shortcut.
Terry, what do you suggest?
--
___
Python tracker
<https://bu
Tal Einat added the comment:
Indeed Command-M has been in use for a while.
+1 for Shift-Command-o. I don't see it used in the default key config
(Lib/idlelib/config-keys.def).
We already use Shift-Command-s for "Save As...", so this would be a consistent
use of a Shift-C
Tal Einat added the comment:
Terry, does Shift-Command-s trigger "Save" or "Save As" for you? If "Save As",
then surely this is something that can be worked out?
--
___
Python tracker
<h
Tal Einat added the comment:
Michael, please read more about comparisons[1] and the None object[2].
[1] https://docs.python.org/3/library/stdtypes.html#comparisons
[2] https://docs.python.org/3/library/stdtypes.html#the-null-object
--
___
Python
Tal Einat added the comment:
Is this supposed to work at all? Does multiprocessing support sharing resources
between processes forked outside of its own abstractions?
Reading the docs[1], calling os.fork() directly doesn't seem to be the way that
the multiprocessing module is supposed
Tal Einat added the comment:
> The squeezed text is impairing IDLE's usability for teaching purposes.
I sincerely hoped it would achieve the opposite! I'm happy to do any work
necessary to improve its usability in this context.
The auto-squeezing can be "disabled"
Tal Einat added the comment:
> If you write to stdout by small chunks, it adds a large overhead to every
> write() call.
While I agree that there is great room for optimization in Squeezer's
interception of write(), it doesn't appear to have a noticeable effect in such
ca
Tal Einat added the comment:
> Serhiy's first comment is about 500 very short lines (experiment 2) not being
> squeezed. This surprised me. Tal?
Indeed, this is not currently supported. This is possible, it would just
complicate the write() interceptor and require the new
Tal Einat added the comment:
> On my machine, 2.7.15 (without squeezing) and 3.7.1 (with squeezing) IDLE
> results (average seconds).
>
> from timeit import timeit
> timeit("print('nnn '*500)", number=10) # Exp1: .0357, .0355
> timeit("for i in ran
New submission from Tal Einat :
Squeezing a single long line with a newline, e.g. 'a'*200, results in "Squeezed
text (1 lines)".
Also, changing the width of the window (even to very small widths) doesn't
affect the number of lines reported when squeezing (when squ
Change by Tal Einat :
--
keywords: +patch
pull_requests: +9724
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35208>
___
___
Python-
Tal Einat added the comment:
See PR GH-10449 with a fix.
--
___
Python tracker
<https://bugs.python.org/issue35208>
___
___
Python-bugs-list mailing list
Unsub
Tal Einat added the comment:
>> ISTM that the coverage tests as currently written aren't good tests.
> Hi, I'd like to remind everyone to be open, respectful, and considerate.
> There are ways to describe hos things that can be improved. There is no need
> to deni
Change by Tal Einat :
--
keywords: +patch
pull_requests: +9729
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35196>
___
___
Python-
Tal Einat added the comment:
Raymond, thanks for bringing up all of these issues. This kind of input from
people using IDLE extensively for teaching is extremely useful. I'll leave it
to Terry to decide how to manage this list, but I promise to do my best (with
my limited time) to re
Tal Einat added the comment:
Can we detect whether this system preference is enabled? If so, perhaps
IDLE should display a prominent warning.
--
___
Python tracker
<https://bugs.python.org/issue34
Change by Tal Einat :
--
pull_requests: +9737
___
Python tracker
<https://bugs.python.org/issue34864>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
See PR GH-10464, which warns if "Prefer tabs when opening documents" is set to
"Always".
--
___
Python tracker
<https://bug
Tal Einat added the comment:
> By the way, I really appreciate the work you all are putting into IDLE. It
> can definitely benefit from some love and attention.
Thanks for the kind words, Raymond!
--
___
Python tracker
<https://bugs.p
Tal Einat added the comment:
On Win10 I've also failed to reproduce the reported issue with the supplied
script. I tried with Python versions 3.6.3, 3.7.0, and a recent build of the
master branch (to be 3.8).
Can someone try to reproduce this on F
Tal Einat added the comment:
+1 for closing this either way, preferably with a note in the docs.
I'd add the notes about extensions in one set of parenthesis at the end, but
that's likely just a matter of taste.
--
___
Python track
Tal Einat added the comment:
The following benchmarks were run with the second version of the patch
(so2.diff), once before and once after.
OSX 10.8 on a Macbook Pro, 2.5 GHz Core i5, two cores each with 256kb L2 cache,
3MB L3 cache:
1.32% less time for first benchmark (7.07 before, 6.98
Tal Einat added the comment:
Because of the unusually low differences, I tried running the benchmarks again
on the MacBook (OSX 10.8). The first time was actually with so.diff, this time
was with so2.diff.
0.69% less time for first benchmark (7.30 before, 7.25 after)
8.08% less time for
Tal Einat added the comment:
Sorry to be pedantic, but while 19.67sec is about 11.2% less than 22.16sec, it
is actually about 12.6% faster (22.16/19.67 - 1).
Regardless, that's a good result! And I'm happy that the modified benchmark
Tal Einat added the comment:
I"m considering updating SearchBar and posting a patch.
Marco, any chance you could detail the quirks and bugs you experienced when
using SearchBar?
--
nosy: +taleinat
___
Python tracker
<http://bugs.py
Tal Einat added the comment:
Thanks for the kind words, Francisco! And also for taking the time to get
SearchBar working on Python3 and giving it a try.
I agree that SearchBar is a huge improvement over IDLE's simple find and
replace dialogs. And by now every potential user is used to
Tal Einat added the comment:
Indeed, redemo.py does include this feature. But it is a completely different
application with a very specific goal - testing regular expressions.
On the other hand, IDLE's search is meant to be used to find pieces of code in
the editor, which is a signific
Tal Einat added the comment:
Changes LGTM.
This module could certainly use some cleanup and updates. For example,
last_changed should be a property and always accessed one way (instead of
either .mtime() or .last_changed) and should be initialized to None instead of
zero to avoid ambiguity
Tal Einat added the comment:
Regarding the handling of time_t arguments which can be None, I agree that the
second version (without custom convertors) is simpler and clearer while having
no disadvantage that I can see.
I'd like to review the rest of the patches, but you mention changes t
Tal Einat added the comment:
Regarding Roger Serwy's comment, we could either:
1) normalize the event descriptions using MultiCall's _parse_sequence() and
_triplet_to_sequence() functions
2) remove any Shift-Tab bindings from <>
I suggest #2.
Regarding the patch itself:
1)
Tal Einat added the comment:
Thanks for reviewing this Terry! See two small comments in the review of your
patch.
Indeed, I would very much like for this to be my first commit. Thanks for the
pointer WRT backporting to 2.7. Just to make sure, I should commit to 3.5
(default) and then
Tal Einat added the comment:
What do you mean with the comment regarding pep8?
--
___
Python tracker
<http://bugs.python.org/issue20577>
___
___
Python-bugs-list m
Tal Einat added the comment:
Ned, many thanks for the review and detailed feedback!
Here are responses to your comments
1. Thanks for the code suggestion regarding the menudefs! That's a good catch.
I have an OSX box for such testing.
2. I'll check this out. Could you perhaps
Tal Einat added the comment:
I'll be damned. 72 it is, then.
What about using the 'default' parameter for GetOption() instead of "or 72"?
--
___
Python tracker
<http:
Tal Einat added the comment:
I don't think the patch should currently be committed.
I agree with Terry: we should first fix the issue whereby the key config is
read repeatedly. Given such a fix, the problematic "known_invalid" workaround
in the patch would no longer be necess
Tal Einat added the comment:
Which lines are not hit?
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/issue21686>
___
___
Python-bugs-list mailin
Tal Einat added the comment:
I can take a look at get_surrounding_brackets() if you like, since I've worked
with that code before.
--
nosy: +taleinat
___
Python tracker
<http://bugs.python.org/is
Tal Einat added the comment:
I've done a thorough review of the tests. The overall structure and tests are
fine, but I found quite a few issues that should be addressed.
Saimadhav, considering these are some of the first tests you've written, please
know that I am impressed! I
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 statemen
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 :
--
type: -> behavior
___
Python tracker
<http://bugs.python.org/issue21756>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Tal Einat:
Originally reported on issue #21694.
Regarding, for example, the following code:
(3 +
4 - 1)
Placing the cursor after the opening parenthesis and invoking the "Show
surrounding parens" event causes just the first line to be highlighted.
Obvi
Tal Einat added the comment:
I've opened a separate issue for the issue raised by Terry, #21756. Patch is
included there.
--
Added file:
http://bugs.python.org/file35627/taleinat.20140614.IDLE_parenmatch_multiline_statement.patch
___
Python tr
Changes by Tal Einat :
Removed file:
http://bugs.python.org/file35627/taleinat.20140614.IDLE_parenmatch_multiline_statement.patch
___
Python tracker
<http://bugs.python.org/issue21
Tal Einat added the comment:
Here are details how to trigger all of the uncovered code lines and branches,
listed by line.
Uncovered lines:
Line 159: This catches would-be identifiers (variable names) which are keywords
or begin with a character that can't be first (e.g. a digit). We s
Tal Einat added the comment:
Regarding lines 32 & 42, a test could also set editwin.num_context_lines to
allow triggering with smaller code blocks. It's value needs to be a list of
integers, the last of which is incredibly large, perhaps s
Tal Einat added the comment:
With very minor changes (just use default=72 instead of "or 72" and added a
comment explaining why 72 is the default - see attached), I ran the entire test
suite (which is a must according to the dev guide). On current default I'm
getting consist
Tal Einat added the comment:
Also, this seems like a small change. Should I mention it in Misc/NEWS?
--
___
Python tracker
<http://bugs.python.org/issue20
Tal Einat added the comment:
Note that the patch changes the behavior only for
ParenMatch.flash_paren_event(). Other uses, such as in CallTips, are not
affected.
The only possibly unwanted effect that I can think of is in an editor window,
on a line missing a closing parenthesis, triggering
Tal Einat added the comment:
Terry, I'm not sure what you mean but your last comment.
HyperParser.get_surrounding_brackets() will return a previous opening bracket,
even if no closing bracket is found for it. CallTips depends on that behavior
to find the previous opening parenthesis ev
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 = normali
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 {"
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
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 q
Tal Einat added the comment:
Well, I was wrong. I can't find anything of the sort in my old IDLE files.
--
___
Python tracker
<http://bugs.python.org/is
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
<http://bugs.py
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&quo
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.
> Howev
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
definiti
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 to
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 travelin
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 is a
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
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
1101 - 1200 of 1452 matches
Mail list logo