Re: [Python-Dev] Accepting PEP 434, Idle Enhancement Exception

2013-03-30 Thread Antoine Pitrou 
On Sat, 30 Mar 2013 08:33:38 +0200
Simon Cross  wrote:

> Having a standalone version of IDLE might be really useful to
> alternative Python implementations.

Why?


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython (2.7): Fix typos and clear up one very odd bit of wording as pointed out by

2013-03-30 Thread Antoine Pitrou 
On Sat, 30 Mar 2013 09:39:00 +0100 (CET)
gregory.p.smith  wrote:
>  
>  The workarounds and modifications are not included in patch releases as they
>  break backward compatibility.

This is not entirely true. It was perfectly possible to give the
*options* to change behaviour, but the patch wasn't ready.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 434, Idle Enhancement Exception

2013-03-30 Thread Maciej Fijalkowski 
On Sat, Mar 30, 2013 at 5:26 AM, Antoine Pitrou  wrote:
> On Sat, 30 Mar 2013 08:33:38 +0200
> Simon Cross  wrote:
>
>> Having a standalone version of IDLE might be really useful to
>> alternative Python implementations.
>
> Why?

I don't think it's worth discussing - tkinter does not work on any
other implementation than CPython and it seems it won't work. It's a
bit pity, but I guess if I felt really bad about it, I should just
make it work.

PS. are there idle projects in SoC? Maybe we should put a more
pypy-friendly one there too?

Cheers,
fijal
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 434, Idle Enhancement Exception

2013-03-30 Thread Daniel Holth 
Yes, it would probably make more sense to split the editor and shell
processes as many Python IDEs do, with IDLE running in CPython and the
user's computation running in the chosen interpreter.

On Sat, Mar 30, 2013 at 8:35 AM, Maciej Fijalkowski  wrote:
> On Sat, Mar 30, 2013 at 5:26 AM, Antoine Pitrou  wrote:
>> On Sat, 30 Mar 2013 08:33:38 +0200
>> Simon Cross  wrote:
>>
>>> Having a standalone version of IDLE might be really useful to
>>> alternative Python implementations.
>>
>> Why?
>
> I don't think it's worth discussing - tkinter does not work on any
> other implementation than CPython and it seems it won't work. It's a
> bit pity, but I guess if I felt really bad about it, I should just
> make it work.
>
> PS. are there idle projects in SoC? Maybe we should put a more
> pypy-friendly one there too?
>
> Cheers,
> fijal
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/dholth%40gmail.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 434, Idle Enhancement Exception

2013-03-30 Thread [email protected] 
On Fri, Mar 29, 2013 at 11:33 PM, Simon Cross  wrote:

> Having a standalone version of IDLE might be really useful to
> alternative Python implementations.

I suspect it's too hard. I remember seeing some work on "anygui.py" that
looked like an attempt to make these sorts of things work across various
windowing platforms, but I don't think it made it very far.

-Frank
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Accepting PEP 434, Idle Enhancement Exception

2013-03-30 Thread Antoine Pitrou 
On Sat, 30 Mar 2013 13:36:39 -0700
"[email protected]"  wrote:
> On Fri, Mar 29, 2013 at 11:33 PM, Simon Cross  > wrote:
> 
> > Having a standalone version of IDLE might be really useful to
> > alternative Python implementations.
> 
> I suspect it's too hard. I remember seeing some work on "anygui.py" that
> looked like an attempt to make these sorts of things work across various
> windowing platforms, but I don't think it made it very far.

Instead of "anygui.py", one could probably start with Qt or wxWidgets.
But that would add a dependency to a very large 3rd party library.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] py2.7: dictobject not properly resizing

2013-03-30 Thread Micha Gorelick 
I was taking a look at dictobject.c and realized that the logic
controlling whether a resizedict will occur in
dict_set_item_by_hash_or_entry disallows for the shrinking of a
dictionary.  This is contrary to what the comments directly above say:

(http://hg.python.org/cpython/file/f3032825f637/Objects/dictobject.c#l771)
771 /* If we added a key, we can safely resize. Otherwise just return!
772 * If fill >= 2/3 size, adjust size. Normally, this doubles or
773 * quaduples the size, but it's also possible for the dict to shrink
774 * (if ma_fill is much larger than ma_used, meaning a lot of dict
775 * keys have been * deleted).

The "bug" occures in the following conditional since we exit out of
the function without checking the relative magnitudes of ma_filled to
ma_used. Instead, we only check if we still have a correct loading
factor (and the "don't resize on modification" bit).

This can be fixed by changing the following conditional on line 785 to:

if (mp->ma_used <= n_used || (mp->ma_fill*3 < (mp->ma_mask+1)*2 &&
mp->ma_used*5 > mp->ma_fill))

The factor of 5 was chosen arbitrarily... I'm sure with some
benchmarking we could tune it to an optimal value for the internal use
of dictionaries.  However, before I put this effort in I was wondering if
this is in fact desired behavior or if it is indeed a bug.  At the
very least, the comments should be updated to reflect the actual
resizing dynamics of the dictionary.

Micha
-
http://micha.gd/
http://github.com/mynameisfiber/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] py2.7: dictobject not properly resizing

2013-03-30 Thread Antoine Pitrou 
On Sat, 30 Mar 2013 17:31:26 -0400
Micha Gorelick  wrote:
> I was taking a look at dictobject.c and realized that the logic
> controlling whether a resizedict will occur in
> dict_set_item_by_hash_or_entry disallows for the shrinking of a
> dictionary.  This is contrary to what the comments directly above say:

Also in 3.4:

>>> d = {i: i for i in range(1000)}
>>> sys.getsizeof(d)
49264
>>> for i in range(900): del d[i]
... 
>>> sys.getsizeof(d)
49264
>>> for i in range(900, 1000): del d[i]
... 
>>> sys.getsizeof(d)
49264
>>> len(d)
0
>>> d.clear()
>>> sys.getsizeof(d)
88


Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] py2.7: dictobject not properly resizing

2013-03-30 Thread Armin Rigo 
Hi Antoine,

On Sat, Mar 30, 2013 at 10:37 PM, Antoine Pitrou  wrote:
> On Sat, 30 Mar 2013 17:31:26 -0400
> Micha Gorelick  wrote:
>> I was taking a look at dictobject.c and realized that the logic
>> controlling whether a resizedict will occur in
>> dict_set_item_by_hash_or_entry disallows for the shrinking of a
>> dictionary.

It doesn't disallow shrinking.  If you take a dictionary of size 1000,
remove of its elements, and continue to use it (write and delete more
items) for long enough, then eventually it is shrinked.  It just takes
a while because it needs to fill 2/3 of the slots of the big table
with "deleted" markers before it happens.

Python 3.3.0b1 (default:07ddf5ecaafa, Aug 12 2012, 17:47:28)
[GCC 3.4.6 (Gentoo 3.4.6-r2, ssp-3.4.6-1.0, pie-8.7.10)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> d = {i:i for i in range(1000)}
>>> sys.getsizeof(d)
24624
>>> for i in range(1000): del d[i]
...
>>> sys.getsizeof(d)
24624
>>> for j in range(1001, 2000):
...d[j] = 0; del d[j]
...
>>> sys.getsizeof(d)
144
>>>


A bientôt,

Armin.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] py2.7: dictobject not properly resizing

2013-03-30 Thread Micha Gorelick 
True, but your example mechanism of getting a shrink event is purely
based on ma_fill.  This is happening because your last loop is
increasing ma_fill to the point where it thinks it needs to resize
because of the load factor and then it calculates the new size based
on ma_used.  The comment that I pointed out from the code seems to
imply that simply having ma_fill >> ma_used will trigger a resize.
The two conditions for a resize are definitely not equivalent!

Micha
-
http://micha.gd/
http://github.com/mynameisfiber/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Idle, site.py, and the release candidates

2013-03-30 Thread Terry Jan Reedy 

While trying to test the patch for
http://bugs.python.org/issue5492
on Windows, I discovered that quit() and exit() in the Idle Shell are 
now disabled, it seems, for all versions on all systems rather than just 
sometimes on Linux.


The problem is a change in idlelib that invalidated an assumption made 
in site.py. Revs 81718-81721 for

http://bugs.python.org/issue9290
changed idlelib.PyShell.PseudoFile (line 1277 in 3.3) to subclass 
io.TextIOBase, which subclasses IOBase. This gave PseudoFile and its 
subclasses a .fileno instance method attribute that raises 
io.UnsupportedOperation: fileno.


This is not a bug since the doc for io.IOBase.fileno says:
"Return the underlying file descriptor (an integer) of the stream if it 
exists. An OSError is raised if the IO object does not use a file 
descriptor."

(the particular error raised is not an issue here).

This is the code for Quitter.__call__ in site.py (line 368 in 3.3):

def __call__(self, code=None):
# Shells like IDLE catch the SystemExit, but listen when
# stdin wrapper is closed.
try:
fd = -1
if hasattr(sys.stdin, "fileno"):
fd = sys.stdin.fileno()
if fd != 0:
# Don't close stdin if it wraps fd 0
sys.stdin.close()
except:
pass
raise SystemExit(code)

The incorrect assumption is that if sys.stdin.fileno exits but raises, 
the call did not come from a shell that needs .close called.


I do not know enough about other circumstances in which stdin.fileno 
would do something other than return 0 to be sure of what the proper fix 
would be.  (I increasingly dislike bare excepts as they hide the 
thinking and knowledge of the original programmer. What exception was 
expected that should be passed away?)


Given that the callable constants exit and quit  and are optionally 
suppressed on startup and are not standard builtins

http://docs.python.org/3/library/constants.html#constants-added-by-the-site-module
it would be alright with me to ignore this regression and release as 
scheduled. But I though people should be aware of it.


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Idle, site.py, and the release candidates

2013-03-30 Thread Nick Coghlan 
On Sun, Mar 31, 2013 at 12:34 PM, Terry Jan Reedy  wrote:

> While trying to test the patch for
> http://bugs.python.org/**issue5492 
> on Windows, I discovered that quit() and exit() in the Idle Shell are now
> disabled, it seems, for all versions on all systems rather than just
> sometimes on Linux.
>
> The problem is a change in idlelib that invalidated an assumption made in
> site.py. Revs 81718-81721 for
> http://bugs.python.org/**issue9290 
> changed idlelib.PyShell.PseudoFile (line 1277 in 3.3) to subclass
> io.TextIOBase, which subclasses IOBase. This gave PseudoFile and its
> subclasses a .fileno instance method attribute that raises
> io.UnsupportedOperation: fileno.
>
> This is not a bug since the doc for io.IOBase.fileno says:
> "Return the underlying file descriptor (an integer) of the stream if it
> exists. An OSError is raised if the IO object does not use a file
> descriptor."
> (the particular error raised is not an issue here).
>
> This is the code for Quitter.__call__ in site.py (line 368 in 3.3):
>
> def __call__(self, code=None):
> # Shells like IDLE catch the SystemExit, but listen when
> # stdin wrapper is closed.
> try:
> fd = -1
> if hasattr(sys.stdin, "fileno"):
> fd = sys.stdin.fileno()
> if fd != 0:
> # Don't close stdin if it wraps fd 0
> sys.stdin.close()
> except:
> pass
> raise SystemExit(code)
>
> The incorrect assumption is that if sys.stdin.fileno exits but raises, the
> call did not come from a shell that needs .close called.
>
> I do not know enough about other circumstances in which stdin.fileno would
> do something other than return 0 to be sure of what the proper fix would
> be.  (I increasingly dislike bare excepts as they hide the thinking and
> knowledge of the original programmer. What exception was expected that
> should be passed away?)
>

The other problem is that making *two* function calls inside a broad
try/except is almost always a terrible idea. It seems to me that the
intended logic is more like this:

try:
# Close stdin if it wraps any fd other than 0
close_stdin = (sys.stdin.fileno() != 0)
except (AttributeError, OSError, io.UnsupportedOperation):
# Also close stdin if it doesn't expose a file descriptor
close_stdin = True
if close_stdin:
try:
sys.stdin.close()
except Exception:
pass
raise SystemExit(code)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com