Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue20177>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue20187>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
So 3.8 then, or should this be closed?
FWIW I'm -1. IMO this should be a code recipe somewhere, no need for it to be
in the stdlib.
--
___
Python tracker
<https://bugs.python.org/issue24
Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue24009>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue20341>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue24145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
My main laptop is currently Windows 10, I use it for most CPython work.
I also have PCs running OSX, Ubuntu and Windows 7.
Terry, let me know what and when you'd like me to run on which OSs, and I'll
get it done
Tal Einat added the comment:
It would be extremely helpful to have some test cases that actually work for
users but fail with smtplib. So far we have no actual examples, likely due to
these being passwords.
> Note: it is definitely the case, regardless of what the RFC says, that bin
Tal Einat added the comment:
Additional feature discussion:
> 10. The button for 'a'*1 says '(nn lines)'. It should say '(1
> chars)' or '(1 line, 1 chars)'.
IMO that's too much, it leads to "information overload". Since the number of
lines shown is the nu
Tal Einat added the comment:
Once the ToolTip is ready, I'll begin working on this.
Summarizing what appear to be agreed-upon changes to be made (keeping original
numbering for reference):
1. Avoid expanding large output accidentally / too easily. Current suggestions
are expanding part
Tal Einat added the comment:
Attaching coverage report for tooltip.py.
The uncovered lines are required to avoid exceptions when closing a windows
with a tooltip shown. These are not currently reproduced by test_tooltip.py
because my attempts to exercise them in automated tests have all
Tal Einat added the comment:
The refactoring is done, manual testing with the htests works, and I've added
automated tests with ~92% code coverage.
Terry, I'd be happy for your review!
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Tal Einat :
--
keywords: +patch
pull_requests: +7296
stage: test needed -> patch review
___
Python tracker
<https://bugs.python.org/issue33839>
___
_
Tal Einat added the comment:
IMO both approaches sound better than the existing implementation. Better to
choose one than to do nothing.
--
nosy: +taleinat
___
Python tracker
<https://bugs.python.org/issue25
Tal Einat added the comment:
I've started work on this. My progress can be followed on the bpo-33839 branch
on my GitHub repo: https://github.com/taleinat/cpython/tree/bpo-33839
--
___
Python tracker
<https://bugs.python.org/issue33
Change by Tal Einat :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6
___
Python tracker
<https://bugs.python.or
Tal Einat added the comment:
New changeset 63dd1f70c1aa57494802c9b68f9db4918620fc8f by Tal Einat (Miss
Islington (bot)) in branch '3.6':
bpo-27397: Make email module properly handle invalid-length base64 strings
(GH-7583) (GH-7665)
https://github.com/python/cpython/commit
Tal Einat added the comment:
New changeset 7b82281c80d0064559866afe92f19cae5978c841 by Tal Einat (Miss
Islington (bot)) in branch '3.7':
bpo-27397: Make email module properly handle invalid-length base64 strings
(GH-7583) (GH-7664)
https://github.com/python/cpython/commit
Tal Einat added the comment:
New changeset c3f55be7dd012b7e92901627d0b31c21e983ccb4 by Tal Einat in branch
'master':
bpo-27397: Make email module properly handle invalid-length base64 strings
(#7583)
https://github.com/python/cpython/commit/c3f55be7dd012b7e92901627d0b31c21e983ccb4
Tal Einat added the comment:
Cheryl, thanks for testing this and writing up your thoughts!
There is certainly much room for improvement.
Since it seems that you and Terry like the approach, I'll start working on the
tooltips as Terry asked, and wait for more input from him before beginning
Tal Einat added the comment:
I ended up fixing this independently of #33770.
AFAIK this should just work with 3.6.
--
___
Python tracker
<https://bugs.python.org/issue27
Tal Einat added the comment:
Thanks for the warm welcome, Terry :)
> 3.5 only gets security fixes.
Yup, my mistake.
> 'Large text' has two meanings: long lines and lots of lines. [...]
Squeezer handles both long lines and/or large numbers of lines.
> As the comment a
Tal Einat added the comment:
Since this is a small enhancement proposal that is not sure to be approved, and
there has been no followup for years, I vote to close this.
--
___
Python tracker
<https://bugs.python.org/issue24
Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue24403>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue1927>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
I suggest that we close this issue. IMO the potential benefit is too small
relative to the work required, and the interest is too low.
--
___
Python tracker
<https://bugs.python.org/issue2
Tal Einat added the comment:
New PR ready for review.
I've updated the code for recent master and cleaned up the deprecation warnings
from the tests.
--
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8 -Python 3.4
___
Python tracker
Change by Tal Einat :
--
pull_requests: +7245
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue1529353>
___
___
Python-
Change by Tal Einat :
--
nosy: -taleinat
___
Python tracker
<https://bugs.python.org/issue24356>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tal Einat added the comment:
The change is not entirely backward-compatible, so not back-porting before 3.7
seems good to me. IMO this should be closed.
--
___
Python tracker
<https://bugs.python.org/issue33
Tal Einat added the comment:
PR ready for review.
--
nosy: +taleinat
___
Python tracker
<https://bugs.python.org/issue33573>
___
___
Python-bugs-list mailin
Change by Tal Einat :
--
keywords: +patch
pull_requests: +7209
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue33573>
___
_
Tal Einat added the comment:
We definitely need an expert to weigh in on this.
--
nosy: +giampaolo.rodola
___
Python tracker
<https://bugs.python.org/issue33
Tal Einat added the comment:
Moving the linecache check up before the two others seems like a simple and
safe optimization. On the other hand, I'm not sure calling getmodule() before
checking if the file exists would be faster in many cases.
Pankaj, could you also include the script you ran
Tal Einat added the comment:
Is this a bug? Are passwords containing non-ASCII characters supposed to be
supported? If so, which encoding should be assumed for the password? Since it
needs to be base64-encoded, it must be encoded into bytes.
--
nosy: +taleinat
Tal Einat added the comment:
New changeset 4ab4695388fb9ec03a14d93e90ce50d832a920ec by Tal Einat in branch
'master':
bpo-33748: fix tests altering sys.path and sys.modules (GH-7433)
https://github.com/python/cpython/commit/4ab4695388fb9ec03a14d93e90ce50d832a920ec
Tal Einat added the comment:
New changeset 1b85c71a2136d3fa6a1da05b27b1fe4e4b8ee45e by Tal Einat in branch
'master':
bpo-33770: improve base64 exception message for encoded inputs of invalid
length (#7416)
https://github.com/python/cpython/commit/1b85c71a2136d3fa6a1da05b27b1fe4e4b8ee45e
Change by Tal Einat :
--
keywords: +patch
pull_requests: +7205
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue27397>
___
_
Tal Einat added the comment:
PR is ready with an improved exception message and raising binascii.Incomplete
rather than binascii.Error. A final review would be welcome!
--
___
Python tracker
<https://bugs.python.org/issue33
Tal Einat added the comment:
Code using only a2b_base64() would likely not be expecting this exception.
We have at least one such example in the stdlib: decode_b() in
Lib/email/_encoded_words.py (which needs to be fixed regardless; see #27397
Tal Einat added the comment:
It is more a correction than a clarification.
After looking through the module some more, I'm considering using
binascii.Incomplete for this case, since it seems appropriate enough that it's
worth using it rather than adding another, separate exception
Tal Einat added the comment:
See #33770, which will make recognizing and handling this case straightforward.
--
nosy: +taleinat
___
Python tracker
<https://bugs.python.org/issue27
Change by Tal Einat :
--
keywords: +patch
pull_requests: +7059
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33748>
___
___
Python-
Tal Einat added the comment:
Would an exception message as following be acceptable? "Invalid base64-encoded
string: length cannot be 1 more than a multiple of 4"
--
___
Python tracker
<https://bugs.python.o
Tal Einat added the comment:
It seems that adding a directory to sys.path is the intended behavior of
`loader.discover()`. Should the test be restoring sys.path back to it original
value when it's done?
Also, shouldn't this test (and some others) be restoring sys.modules when
they're done
Tal Einat added the comment:
They're not the same.
When the encoded string's length modulu 4 is 2 or 3, there just need to be (at
least) 2 or 1 padding characters ('=') for decoding to be successful, due to
our decoder being rather strict. Less strict decoders may ignore the missing
Tal Einat added the comment:
Oops: when I wrote "length can only have a remainder of ..." I meant remainder
upon division by 4.
--
___
Python tracker
<https://bugs.python.o
Tal Einat added the comment:
A base64-encoded string's length can only have a remainder of 0, 2 or 3, but
never 1. This is why the padding you get when encoding can only be '=' or '=='
but never '==='.
--
nosy: +taleinat
___
Python tracker
Change by Tal Einat :
--
keywords: +patch
pull_requests: +7040
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue33770>
___
_
Tal Einat <talei...@gmail.com> added the comment:
Also see discussion in GitHub PR 4265 for #31938.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Tal Einat <talei...@gmail.com>:
In 2fb9ae9dfc5a6830d902332ba93b13387e292ddb, select.epoll() was changed to
reject sizehint=-1, despite that still being documented as the default value.
Would it be possible to reverse this change, making -1 a special value
sig
Tal Einat <talei...@gmail.com> added the comment:
My apologies, I seem to have been the source of the confusion. I misunderstood
your original meaning.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Tal Einat <talei...@gmail.com> added the comment:
Argument Clinic currently doesn't support input parameter type annotations
either, though for this it has more relevant information in many cases.
I think it would be a great boon for AC to enable declaring type annotations,
both for
Tal Einat <talei...@gmail.com> added the comment:
I'm not sure that the current concept of return converters in AC is can be used
for specifying return value annotations.
For example, what if I want to annotate the return value type with using a
return converter?
Another example: The c
Change by Tal Einat <talei...@gmail.com>:
--
keywords: +patch
pull_requests: +4228
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Tal Einat <talei...@gmail.com> added the comment:
See PR 4265.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31938>
___
_
Tal Einat <talei...@gmail.com> added the comment:
See issue #31938 regarding Modules/selectmodule.c.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Tal Einat <talei...@gmail.com>:
--
pull_requests: +4229
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20182>
___
_
New submission from Tal Einat <talei...@gmail.com>:
Continuing the work begun as part of issue #20182, this is regarding the
Argument Clinic conversion of Modules/selectmodule.c.h.
I have a complete conversion ready and will create a PR momentarily.
--
components: Argument
Tal Einat <talei...@gmail.com> added the comment:
As the author of all of the updated patches, I wouldn't mind opening new issues
separately for each of the remaining modules. Actually I would prefer it :)
--
___
Python tracke
Change by Tal Einat <talei...@gmail.com>:
--
pull_requests: +4215
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31926>
___
_
Tal Einat <talei...@gmail.com> added the comment:
See issue #31926 and PR 4230 regarding the aforementioned argument clinic bug
and a fix for it.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Tal Einat <talei...@gmail.com> added the comment:
See PR 4230.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31926>
___
_
Change by Tal Einat <talei...@gmail.com>:
--
keywords: +patch
pull_requests: +4199
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Tal Einat <talei...@gmail.com>:
I'm converting Modules/selectmodule.c.h as part of issue #20182.
After converting the code and running Tools/clinic/clinic.py, compilation is
failing on Windows due to the following block *not* being generated by in the
Modules/
Tal Einat <talei...@gmail.com> added the comment:
I have a complete, up-to-date AC conversion of Modules/selectmodule.c ready on
a branch in my GitHub CPython fork:
https://github.com/taleinat/cpython/tree/bpo-20182_AC_selectmodule
I haven't created a PR because there's currently an
Tal Einat <talei...@gmail.com> added the comment:
To enable progressing with this in smaller steps, I created PR 4170 which
converts only itertools.groupby and the intertnal _grouper with minimal
required changes.
--
___
Python tracke
Change by Tal Einat <talei...@gmail.com>:
--
pull_requests: +4139
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20180>
___
_
Tal Einat <talei...@gmail.com> added the comment:
Regarding the select module, the existing patch moves typedefs and object type
declarations to the top of the file with the #include clinic/selectmodule.c.h
statement can come afterwards. Should I keep it this way, or instead move the
Tal Einat <talei...@gmail.com> added the comment:
I understand that there is a workaround. I'm just thinking about the many
existing large codebases where re-writing thousands of imports because of this
is unlikely to be done, yet having somewhat longer process launch times
Tal Einat <talei...@gmail.com> added the comment:
I can't say I agree that the performance here is practically insignificant.
This will affect the startup time of Python process, and adding even 10% to
that in some cases is significant.
In some of the larger codebases I've worked on
Tal Einat <talei...@gmail.com> added the comment:
See PR 4117 on GitHub with the itertools AC conversion.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Tal Einat <talei...@gmail.com>:
--
pull_requests: +4087
stage: needs patch -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Tal Einat <talei...@gmail.com> added the comment:
As far as I can tell, with the creation of a separate clinic/itertools.c.h, the
typedefs etc. need to be moved to the top of the file so that the #include can
come after the typedefs and before the rest of the code which references
Tal Einat <talei...@gmail.com> added the comment:
What about islice? Does AC now support complex enough signatures to support it?
If not, should I leave the comment as is?
--
___
Python tracker <rep...@bugs.python.org>
<https://
Tal Einat <talei...@gmail.com> added the comment:
I'd be happy to update the patches.
I asked for a bit of clarification on what this entails in msg304931 on issue
#20180, once that's clear I'll do the same for these patches and crea
Tal Einat <talei...@gmail.com> added the comment:
Id be happy to update the itertools patch.
I haven't been following AC work for quite a while. I would expect this to
entail:
1. applying the patch to the master branch
2. merging any conflicts
3. running the clinic.py script again
4.
Change by Tal Einat <talei...@gmail.com>:
--
nosy: +taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31810>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22083>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue6143>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue21696>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue1350>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue694339>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue21787>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue11437>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue24412>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue21880>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue6858>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue18875>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue17535>
___
__
Change by Tal Einat <talei...@gmail.com>:
--
nosy: -taleinat
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20827>
___
__
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 <rep...@bugs.python.org>
Tal Einat added the comment:
Unfortunately, I won't be able to review this due to lack of time.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Tal Einat added the comment:
Regarding the name "IsoCalendarDate", see for example this question on Stack
Overflow[1] where both of the leading answers suggest beginning with "Iso" or
"iso" rather than "ISO". However, taking a look at the relatively new
New submission from Tal Einat:
I just wanted to mention that I once added this feature to IDLE and it's really
great for interactive work, especially with data structures such as tables or
JSON. If there's ever interest, I can try to hunt down my old code.
--
components: IDLE
messages
Tal Einat added the comment:
Regarding your questions about completion behavior:
You don't have to scroll, you can continue typing and the completion list will
filter itself to options that match the additional characters. Deleting
characters works too (options reappear in the list
Tal Einat added the comment:
My patches haven't been looked at for a while, anyone considering them should
make sure they still apply cleanly and don't break anything. Here their status
as far as I can tell:
Quite a bit of work went into Modules/_operator.c, and it got an "LGTM" fr
Tal Einat added the comment:
It turns out that staying with str.translate in PyParse payed off! An
optimization in 3.5 (issue21118) has made it much much faster on ASCII-only
inputs, which are the vast majority in this case.
--
___
Python tracker
Tal Einat added the comment:
The entire test suite passes with the v2 patch on my OSX 10.10.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Tal Einat added the comment:
I'll commit #3 (unicodeobject.c) when I first get the chance, which should be
in a few days.
I'll be happy to improve the rest as needed if someone can find the time to
review them!
--
___
Python tracker rep
1001 - 1100 of 1433 matches
Mail list logo
