Tal Einat added the comment:
See documentation patch for this issue attached to issue20346 (a duplicate of
this).
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20332
Tal Einat added the comment:
I thought AC was how all new modules were supposed to be written. If so, the
example modules should definitely use AC!
Also note that once the generated code is in separate files, the code in the
origin files will be simpler and clearer
Tal Einat added the comment:
Thanks, Stefan. I hadn't realized that the xx files were targeted mainly a
third-party developers. In this case, I can see the sense in not converting
them.
I only wish someone had said something *before* I went ahead and converted
them
Tal Einat added the comment:
The new patch still uses NULLABLE_PY_SSIZE_T_INITIALIZE instead of
NULLABLE_INT_T_INITIALIZE in one place in int_converter.converter_init.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20341
New submission from Tal Einat:
In Objects/bytes.c, the strip methods need a self converter so that
they get a PyBytesObject* instead of PyObject*. However, having set
this in bytes.strip and cloning that clinic definition for
bytes.lstrip and bytes.rstrip, it appears that the self converter
New submission from Tal Einat:
It would be useful for conversion of existing function to be able to set the
name of the C variable for arguments which is different than the Python
argument name.
For example, not being able to do so makes converting bytes.translate much
harder
Tal Einat added the comment:
Never mind my previous comment; I realize it would create to much of a mess.
Sorry for the noise.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20187
Tal Einat added the comment:
While converting Objects/stringlib/transmogrify.h as part of issue20180 (Derby
#11), some changes to Objects/bytesobject.c and Objects/bytearrayobject.c were
required. Those changes are included in the relevant patch attached to that
issue.
--
nosy
Tal Einat added the comment:
I've been working on converting unicode, bytes and bytearray, but their files
are separated into Derby groups #10, #11 and #12. Could we create a new issue
and move the relevant files to it?
The files I'd like to move:
From Derby #10 (issue20179):
Objects
Tal Einat added the comment:
Attached patch for AC conversion of Objects/bytesobject.c and
Objects/bytearrayobject.c.
This is one patch because there are changes that must be done in
bytes_methods.h and bytes_methods.c that affect both of bytesobject.c and
bytearrayobject.c. Those changes
Tal Einat added the comment:
See nearly complete conversion of Objects/bytearrayobject.c in patch attached
to issue20179.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20181
Tal Einat added the comment:
+1 for this. It would save a bit of manual conversion work, and would
significantly reduce the size and complexity of the resulting patches.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20227
Tal Einat added the comment:
Attached updated patch for bytes and bytearray.
In the previous patch I missed the 'clear' and 'copy' bytearray methods. This
patch is a replacement for the previous one, with the additional conversion of
these two methods.
--
Added file: http
Tal Einat added the comment:
Attaching a new patch for complete conversion of Objects/unicodeobject.c.
This is to replace the previous patch for this file.
This new patch also converts all other possible unicode methods,
including those not using PyArg_* functions. This includes various
methods
Tal Einat added the comment:
Attaching patch for complete conversion of Objects/unicodeobject.c.
Notes:
* maketrans() was already converted
* converting the lstrip, rstrip and strip methods required a small, non-trivial
change to the code, since they used a common function for argument parsing
Tal Einat added the comment:
Attached patch for AC conversion of Objects/stringlib/transmogrify.h.
Converting the functions in this file required changes to Objects/bytesobject.c
and Objects/bytearrayobject.c. Those changes are in the patch as well. The
conversion of those files is part
Tal Einat added the comment:
While converting Objects/stringlib/transmogrify.h as part of issue20180 (Derby
#11), some changes to Objects/bytesobject.c and Objects/bytearrayobject.c were
required. Those changes are included in the relevant patch attached to that
issue.
--
nosy
New submission from Tal Einat:
For example, in `Object/stringlib/transmogrify.h`, the methods `ljust` and
`rjust` have an argument named `fillchar` of type char. It's Python default
value should be b' ', but the only way I've found to do that is by setting
`py_default = b
Tal Einat added the comment:
Additionally, the char converter doesn't create valid c defaults. For example,
I got instead of ' ' for fillchar, which has type char, so I had to
manually set c_default = ' '.
--
___
Python tracker rep
Tal Einat added the comment:
I'm attaching my conversion of deque.rotate and _count_elements in
Modules/_collectionsmodule.c.
There remain 3 other functions in that module to be converted.
One is deque_init which returns int; Larry said (on IRC) to hold off with that
for now.
The other two
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
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 is
useful
Changes by Tal Einat talei...@gmail.com:
--
nosy: -taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8285
___
___
Python-bugs-list mailing
Tal Einat talei...@gmail.com added the comment:
I'd just like to weigh in and say that this is a major issue for me at the
moment. Not being able to indiscriminately pickle/unpickle exceptions is making
my parallel-processing work very painful, because of problematic stdlib
exceptions.
I'm
Changes by Tal Einat talei...@gmail.com:
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12590
___
___
Python-bugs-list mailing
Tal Einat talei...@gmail.com added the comment:
The patch seems broken to me.
In cgi.parse_multipart(), the 'boundary' variable can be a string even though
it is concatenated to bytes. Its default value is a string, and a string can be
given via the pdict argument. There is no validity check
Tal Einat talei...@gmail.com added the comment:
Yes, please submit the other additional tests in a separate issue.
The default value for boundary should surely be b. A simple test should be
added where cgi.parse_multipart() uses the default boundary.
If valid_boundary() is used only
Tal Einat talei...@gmail.com added the comment:
Note that some discussion about this issue is taking place on the idle-dev
mailing list.
Bruce Sherwood found the line root.bind('close-all-windows',
flist.close_all_callback), which seems to be an unsuccessful attempt to
achieve the wanted
Tal Einat talei...@gmail.com 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
Tal Einat talei...@gmail.com 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
Tal Einat talei...@gmail.com 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
Tal Einat talei...@gmail.com added the comment:
Note that at one point discussion of this issue was continued on the tracker
page for issue1252.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1253
Tal Einat talei...@gmail.com 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 talei...@gmail.com 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
Tal Einat talei...@gmail.com 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
Tal Einat talei...@gmail.com 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
Changes by Tal Einat talei...@gmail.com:
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1524639
___
___
Python-bugs-list mailing
Tal Einat talei...@gmail.com 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
Changes by Tal Einat talei...@gmail.com:
Added file: http://bugs.python.org/file18090/IDLE_rmenu_py3k.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1207589
Tal Einat talei...@gmail.com 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 talei...@gmail.com 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
Tal Einat talei...@gmail.com 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
Changes by Tal Einat talei...@gmail.com:
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6378
___
___
Python-bugs-list mailing
Changes by Tal Einat talei...@gmail.com:
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7676
___
___
Python-bugs-list mailing
Tal Einat talei...@gmail.com 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 rep...@bugs.python.org
http
Tal Einat talei...@gmail.com 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 rep...@bugs.python.org
Tal Einat talei...@gmail.com added the comment:
You're right Terry, my bad, I got the issues mixed up.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9222
Tal Einat talei...@gmail.com 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
Tal Einat talei...@gmail.com 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 happening, Michael
Tal Einat talei...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org/issue6698
Tal Einat talei...@gmail.com 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
Tal Einat talei...@gmail.com 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net added the comment:
Also, try renaming/moving the directory C:\Documents and
Settings\username\.idlerc, and then try to start IDLE.
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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 rep
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Changes by Tal Einat talei...@users.sourceforge.net:
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7166
___
___
Python-bugs
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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 rep...@bugs.python.org
http
Changes by Tal Einat talei...@users.sourceforge.net:
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4785
___
___
Python
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net 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 talei...@users.sourceforge.net added the comment:
Daniel, Thanks for clearing that up :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1529353
Tal Einat talei...@users.sourceforge.net added the comment:
To recreate use BeautifulSoup 3.0.4 and run the following:
from BeautifulSoup import BeautifulSoup
soup = BeautifulSoup(htmlaa/html)
x = soup.find('html').contents[0]
x
u'aa'
print x
Traceback (most recent call last):
File
Tal Einat talei...@users.sourceforge.net 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
Tal Einat talei...@users.sourceforge.net added the comment:
This should be dropped in favor of issue #1529142, which proposes a
simpler and better solution.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1201569
Tal Einat [EMAIL PROTECTED] added the comment:
First of all, the multiprocessing module doesn't work fully in an
interactive shell.
From the Python2.6 docs:
Note Functionality within this package requires that the __main__
method be importable by the children. This is covered in Programming
Tal Einat [EMAIL PROTECTED] added the comment:
Attaching a new patch against a more recent revision (resolved minor
conflict).
Only 3 extremely minor changes from previous patch: fixed two more
places where the parent was being passed explicitly (no longer required)
and changed two tabs
Tal Einat [EMAIL PROTECTED] added the comment:
Will this be back-ported to 2.5.3? (please say yes...)
--
nosy: +taleinat
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3640
Tal Einat [EMAIL PROTECTED] added the comment:
What if this message was made part of the error message which is
displayed when the connection to the subprocess fails? This way only
users in situations where it is likely that the warning is relevant will
see it.
I suggest this since the original
New submission from Tal Einat [EMAIL PROTECTED]:
Just minor code cleanup.
Only one instance of zip(count(), ...) in EditorWindow.py, where I also
changed 'file' to 'file_name' to avoid overriding the built-in 'file' class.
--
files: IDLE_EditorWindow_minor.patch
keywords: patch
New submission from Tal Einat [EMAIL PROTECTED]:
Attaching a patch for a straightforward extension config dialog, largely
based on configDialog.py.
This uses the multiple-tab-rows feature of the TabbedPageSet widget from
the tabbedPages module, as well as the included VerticalScrolledFrame
Changes by Tal Einat [EMAIL PROTECTED]:
Removed file:
http://bugs.python.org/file10560/IDLE_configExtensionsDialog.080609.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3068
Tal Einat [EMAIL PROTECTED] added the comment:
I forgot to mention:
This patch also removes the paragraph width option from the General
tab in the normal IDLE config, since that configures a parameter of the
FormatParagraph extension, which can now be done in the extension config
dialog.
Added
Changes by Tal Einat [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file8641/IDLE_CallTips.071028.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1350
Changes by Tal Einat [EMAIL PROTECTED]:
Removed file:
http://bugs.python.org/file8960/IDLE_CallTips.071214.incremental.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1350
Tal Einat [EMAIL PROTECTED] added the comment:
After more testing, I discovered a bug which broke Goto Line. Attaching
a fixed patch.
Added file:
http://bugs.python.org/file10555/IDLE_standardize_dialogs.080609.patch
___
Python tracker [EMAIL PROTECTED
Changes by Tal Einat [EMAIL PROTECTED]:
Removed file:
http://bugs.python.org/file10555/IDLE_standardize_dialogs.080609.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2053
Tal Einat [EMAIL PROTECTED] added the comment:
uploaded a single comprehensive patch file
Added file:
http://bugs.python.org/file10140/IDLE_standardize_dialogs.080429.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2053
Tal Einat [EMAIL PROTECTED] added the comment:
Thanks for taking the time to review this patch, Guilherme. For the
record, on which OS+Python have you tested this?
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1529142
Tal Einat [EMAIL PROTECTED] added the comment:
I really, really wish we could get this in for Python2.6 - this issue is
a major drawback for beginners, for whom IDLE is mostly intended.
Perhaps not this specific patch; I am willing to work on cleaning up the
code and getting it tested by users
Tal Einat added the comment:
Umm, that's me being silly and forgetting to remove some backwards
compatibility stuff.
Revised (simpler) version attached.
Added file:
http://bugs.python.org/file9439/IDLE_AutoComplete_path_separators.080216.patch
__
Tracker
Tal Einat added the comment:
After fixing the aforementioned bug and testing as thoroughly as I can,
here is a revised patch.
Added file:
http://bugs.python.org/file9426/IDLE_AutoComplete_complete_string_optimization.080214.patch
__
Tracker [EMAIL PROTECTED
Tal Einat added the comment:
First of all, installing Python on Windows creates a 'Edit with IDLE'
context-menu item whenever you right-click a .py file, which opens IDLE
without a subprocess. The reason for this is that there is still a
problem regarding having several instances of IDLE, each
Tal Einat added the comment:
Well, I admit, I haven't tested this enough. Specifically, there is a
bug in this patch (both versions); please delete it.
I accept your criticism of my latest patches, they truly are of inferior
quality. I deeply apologize for having taken up more of your time
Tal Einat added the comment:
I agree that the interface should be kept as simple as possible, but
this is a meaningful and important addition, which will help clarify to
the users how to work with the subprocess. The point of this change is
avoid surprising the user, while also making
New submission from Tal Einat:
This patch makes the auto-completion of file names support possible
alternate separator characters (e.g. '/' in windows).
--
components: IDLE
files: IDLE_AutoComplete_path_separators.080211.patch
messages: 62263
nosy: kbk, taleinat
severity: minor
status
New submission from Tal Einat:
Improve the code in AutoCompleteWindow._complete_string to be more
efficient.
(this is to be followed up by a more extensive patch, which builds on
this change to support case-insensitive completion)
--
components: IDLE
files
1301 - 1400 of 1433 matches
Mail list logo
