[issue6104] OSX framework builds fail after r72861 move of _locale into core library

[Ned Deily]

New submission from Ned Deily :

Undefined symbols:
 "_CFStringConvertEncodingToIANACharSetName", referenced from:
_PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
 "_CFStringGetSystemEncoding", referenced from:
_PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)
 "_CFStringGetCStringPtr", referenced from:
   _PyLocale_getdefaultlocale in libpython3.1.a(_localemodule.o)

SOLUTION:
   add "-framework CoreFoundation" to Makefile target
   "$(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK)"
   build of temporary minimal framework bootstrap

--
components: Build
files: patch-nad0025-py3k.txt
messages: 88304
nosy: benjamin.peterson, nad, ronaldoussoren
severity: normal
status: open
title: OSX framework builds fail after r72861 move of _locale into core library
type: compile error
versions: Python 3.1
Added file: http://bugs.python.org/file14066/patch-nad0025-py3k.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5756] idle pydoc et al removed from 3.1 without versioned replacements

[Ned Deily]

Ned Deily  added the comment:

Yep, r72866 does restore 2to3.  And r72857, which removes the fullinstall 
target, also fixes the problem of unversioned "python" and "python-config" 
files being created in bin.  Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5272] OS X installer: fix makefile target changed for 3.x

[Ned Deily]

Ned Deily  added the comment:

Issues update:

1. Benjamin fixed this in r72857.

2. Also fixed in r72857.

3. Fixed in r72866.

4. open - all that is needed is to add a NEWS item about smtpd.py no 
longer being installed as script

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine, I have explained the reasons for rejecting the patch. In short,
it violates a design principle behind the Unicode implementation.

If you want to change such a basic aspect of the Unicode implementation,
then write a PEP which demonstrates the usefulness on a larger set of
more general tests and comes up with significant results (10% speedup in
some micro benchmarks is not significant; memory tests need to be run
without pymalloc and require extra care to work around OS malloc
optimization strategies).

Like I said: The current design of the Unicode object implementation
would benefit more from advances in pymalloc tuning, not from making it
next to impossible to extend the Unicode objects to e.g. 

 * reuse existing memory blocks for allocation, 
 * pointing straight into memory mapped files, 
 * providing highly efficient ways to tokenize Unicode data,
 * sharing of data between Unicode objects,
 etc.

The reason I chose this design was to make the above easily
implementable and it was a conscious decision to use a PyObject
rather than a PyVarObject, like the string object, since I knew 
that the Unicode object was eventually going to replace the string
object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5653] OS X Installer: by default install versioned-only links in /usr/local/bin for 3.x

[Ned Deily]

Ned Deily  added the comment:

With the recent py3k changes to ensure that the bin directory only has 
versioned file names (and 2to3), the submitted patch can be simplified as 
the file name check is no longer needed.  Re-enabling the Unix Command 
Line Tools package by default is still appropriate, particularly now that 
there are no conflicts in /usr/local/bin between py2 and py3 file names 
(other than 2to3 which is OK).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1943] improved allocation of PyUnicode objects

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Looking at the comments, it seems that the performance gain comes from
the removal of the double allocation which is needed by the current design.

Was the following implementation considered:
- keep the current PyUnicodeObject structure
- for small strings, allocate one chunk of memory:
sizeof(PyUnicodeObject)+2*length. Then set self->str=(Py_UNICODE*)(self+1);
- for large strings, self->str may be allocated separately.
- unicode_dealloc() must be careful and not free self->str if it is
contiguous to the object (it's probably a good idea to reuse the
self->state field for this purpose).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1943] improved allocation of PyUnicode objects

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Amaury Forgeot d'Arc wrote:
> Amaury Forgeot d'Arc  added the comment:
> 
> Looking at the comments, it seems that the performance gain comes from
> the removal of the double allocation which is needed by the current design.
> 
> Was the following implementation considered:
> - keep the current PyUnicodeObject structure
> - for small strings, allocate one chunk of memory:
> sizeof(PyUnicodeObject)+2*length. Then set self->str=(Py_UNICODE*)(self+1);
> - for large strings, self->str may be allocated separately.
> - unicode_dealloc() must be careful and not free self->str if it is
> contiguous to the object (it's probably a good idea to reuse the
> self->state field for this purpose).

AFAIK, this was not yet been investigated.

Note that in real life applications, you hardly ever have to
call malloc on small strings - these are managed by pymalloc as
pieces of larger chunks and allocation/deallocation is generally
fast. You have the same situation for PyUnicodeObject itself
(which, as noted earlier, could be optimized in pymalloc even further,
since the size of PyUnicodeObject is fixed).

The OS malloc() is only called for longer strings and then only
for the string buffer itself - the PyUnicodeObject is again completly
managed by pymalloc, even in this case.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6105] json.dumps doesn't respect OrderedDict's iteration order

[Wang Chun]

New submission from Wang Chun :

PEP-0372 and Issue 5381 both say json.dumps respect OrderedDict's 
iteration order, but the example in them do not work on my latest trunk 
build.

$ uname -a
Linux 12.38 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 
x86_64 x86_64 GNU/Linux
$ python2.7
Python 2.7a0 (trunk, May 21 2009, 08:00:00) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import json
>>> from collections import OrderedDict
>>> items = [('one', 1), ('two', 2), ('three', 3), ('four', 4), ('five', 
5)]
>>> json.dumps(OrderedDict(items))
'{"four": 4, "three": 3, "five": 5, "two": 2, "one": 1}'

--
components: Library (Lib)
messages: 88311
nosy: wangchun
severity: normal
status: open
title: json.dumps doesn't respect OrderedDict's iteration order
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Marc-André, the problem is that all your arguments are fallacious at
best. Let me see:

> Like I said: The current design of the Unicode object implementation
> would benefit more from advances in pymalloc tuning, not from making it
> next to impossible to extend the Unicode objects to e.g. [...]

Saying that is like saying "we shouldn't try to improve ceval.c because
it makes it harder to write a JIT". You are dismissing concrete actual
improvements in favour of pie-in-the-sky improvements that nobody has
seemed to try (you're welcome to prove me wrong) in 10 years of
existence of the unicode type.

Besides, if someone wants to experiment with such improvements, it is
not difficult to switch back to the old representation (my patch is very
short if you discard the mechanic replacement of "self->length" with
"PyUnicode_GET_SIZE(self)", which doesn't have to be undone to switch
representations). So, I fail to see the relevance of that argument.

> Antoine, I have explained the reasons for rejecting the patch. In short,
> it violates a design principle behind the Unicode implementation.

You seem to be the only one thinking this while, AFAIK, you haven't been
the only one to work on that datatype.

> (10% speedup in
> some micro benchmarks is not significant; memory tests need to be run
> without pymalloc and require extra care to work around OS malloc
> optimization strategies).

Actually, running performance or resource consumption tests without
pymalloc is pointless since it makes the test completely artificial and
unrelated to real-world conditions (who runs Python without pymalloc in
real-world conditions?).

>  * reuse existing memory blocks for allocation, 
>  * pointing straight into memory mapped files, 
>  * providing highly efficient ways to tokenize Unicode data,
>  * sharing of data between Unicode objects,
>  etc.

By the way, I haven't seen your patches or experiments for those. Giving
guidance is nice, but proofs of concept, at the minimum, are more
convincing. None of the suggestions above strike me as very /easy/
(actually, they are at least an order of magnitude harder than the
present patch), or even guaranteed to give any tangible benefits.

To be clear, I don't think this proposal is more important than any
other one giving similar results (provided these exist). But your
arguments are never factual and, what's more, while I already did the
same replies as I did here in other messages, you never bothered to be
more factual. I would accept your refusal if your arguments had some
semblance of concrete support for them.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1943] improved allocation of PyUnicode objects

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

> The OS malloc() is only called...
I know this. But pymalloc has its own overhead, and cache locality will
certainly be better if string data is close to the string length.

The goal is to improve the current usage of strings, and not rely on
hypothetical enhancements to the generic pymalloc.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5670] Speed up pickling of dicts in cPickle

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks!

> Committed as r72909 (trunk), r72910 (py3k).
> 
> --
> resolution: accepted -> fixed
> status: open -> closed

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6101] SETUP_WITH

[Antoine Pitrou]

Antoine Pitrou  added the comment:

SETUP_WITH3.patch looks good to me.

--
resolution:  -> accepted
stage:  -> commit review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6099] HTTP/1.1 with keep-alive support for xmlrpclib.ServerProxy

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

I attach another patch, keepalive.patch, which includes the fixes from 
http://bugs.python.org/issue6096 and including a test for the keepalive 
mecahinsm in the test suite.

Updated http://codereview.appspot.com/63144

--
Added file: http://bugs.python.org/file14067/keepalive.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6105] json.dumps doesn't respect OrderedDict's iteration order

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6101] SETUP_WITH

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Applied in r72912.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6104] OSX framework builds fail after r72861 move of _locale into core library

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r72913.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4547] Long jumps with frame_setlineno

[Amaury Forgeot d'Arc]

Changes by Amaury Forgeot d'Arc :


--
assignee:  -> amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6106] read_until

[Pal Subbiah]

New submission from Pal Subbiah :

The telnet-read_until does not read the pattern and returns b'' for 
line 15 in the file given.

--
components: Library (Lib)
files: telnet_n.py
messages: 88319
nosy: ps
severity: normal
status: open
title: read_until
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file14068/telnet_n.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1707753] get status output fix for Win32

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

The 'commands' module is deprecated, and has been removed in Python 3.0:
http://docs.python.org/dev/library/commands.html

The recommended (and portable) method is to use subprocess:
p = subprocess.Popen(command, stdout=PIPE, stderr=STDOUT, shell=True)
output = p.communicate()[0]

I suggest closing this issue.

--
nosy: +amaury.forgeotdarc
versions:  -Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6106] read_until

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee:  -> jackdied
nosy: +jackdied

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable

[Marco]

Marco  added the comment:

TO georg.brandl:
I remembered that Windows wasn't POSIX compliant, but...I thought they
used the same sys/stat.h constants.
I was wrong :P

TO loewis:
ok, I've added a new patch.
Since I've never written any code for Windows, can you check if it works
fine now?
I've added a simple #ifdef WINDOWS,...

--
keywords: +patch
Added file: http://bugs.python.org/file14069/import_patch2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable

[Marco]

Changes by Marco :


Removed file: http://bugs.python.org/file14069/import_patch2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable

[Marco]

Changes by Marco :


Added file: http://bugs.python.org/file14070/import_patch2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5794] pickle/cPickle of recursive tuples create pickles that cPickle can't load

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Looks good to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6022] test_distutils leaves a 'foo' file behind in the cwd

[Roumen Petrov]

Roumen Petrov  added the comment:

I think that one difference is build outside source tree. Not sure that
this is problem - the linker flags contain "... -L. -lpython2.7 ..." and
after change into another directory(temp) library is no more in current
directory.

Right now I'm too busy to look again into details.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1761028] pickle - cannot unpickle circular deps with custom __hash__

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Checked this out more throughly and I came to the conclusion this cannot
be fixed without a considerable amount of work.

The problem is pickle adds an Node instance stub in the next_nodes set
before its attributes are ready. Since the stub doesn't have any
attribute at the time its added to the set, the __hash__ method fails
with an AttributeError exception.

To fix this, pickle would need to detect cyclic objects with a custom
__hash__ method; and when it would see one, it would need to emit POP
opcodes to revert the parts of the object already pickled. And then,
pickle would have to re-pickle the cyclic object using a special
procedure that would delay the use of __hash__ until all the attributes
of the object are ready to be used.

I do not believe the bug arises frequently enough to justify adding more
tricky code to pickle. So, I will not fix this myself (feel free to
write a patch, however).

Finally, you can workaround the bug using the __getstate__/__setstate__
mechanism as follow:

class Node(object):
  def __init__(self, i):
self.i = i
self.next_nodes = set()
  def __cmp__(self, other):
return cmp(self.i, other.i)
  def __hash__(self):
return hash(self.i)
  def __getstate__(self):
next_nodes = self.next_nodes.copy()
next_nodes.discard(self)
return {'i': self.i,
'self_in_next_nodes': self in self.next_nodes,
'next_nodes': next_nodes}
  def __setstate__(self, state):
if state.pop('self_in_next_nodes'):
self.__dict__.update(state)
state['next_nodes'].add(self)
else:
self.__dict__.update(state)

n = Node(12)
n.next_nodes = set([n])

--
assignee: alexandre.vassalotti -> 
resolution:  -> wont fix
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6070] Python 2.6 makes .pyc/.pyo bytecode files executable

[Martin v . Löwis]

Martin v. Löwis  added the comment:

The patch of file 14070 doesn't compile, but I get the idea. I won't
have time to test it in the next few days or weeks, though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6107] Pipes fail to return subprocess output on Windows

[Alex James]

Changes by Alex James :


--
components: IO, Windows
nosy: ac.james
severity: normal
status: open
title: Pipes fail to return subprocess output on Windows
type: behavior
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5103] ssl.SSLSocket timeout not working correctly when remote end is hanging

[Vitaly Babiy]

Vitaly Babiy  added the comment:

Why not just remove the removal of the timeout.

--
nosy: +vbabiy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6107] Subprocess.Popen output fails on Windows

[Alex James]

New submission from Alex James :

When calling p=subprocess.Popen(findstr "string" filename, stdout=PIPE)
both p.stdout.read() and p.communicate()[0] are returning None even when
the shell process has output (ie string was found in filename).  
Further, redirecting stdout to a file will write an empty file.  

I've got this result from running in script and on IDLE command line
with Python 2.6.2 on windows Vista home premuim and windows XP SP2
systems.  

Thinking this may be related to issue 1707753 or 1124861 I tried the
putting all streams to pipes workaround, but that also failed here.  

Using subprocess.call with stdout to file did work.  

This issue is primarily about the lack of cross-platform compatability
that the subprocess module was supposed to have, on unix systems the
base program I'm working with can call grep from any of os.popen,
popen2, or subprocess.Popen and work just fine.

--
title: Pipes fail to return subprocess output on Windows -> Subprocess.Popen 
output fails on Windows

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1559298] test_popen fails on Windows if installed to "Program Files"

[Philip Jenvey]

Philip Jenvey  added the comment:

subprocess also needs this fix applied

Does the w9xopen command line below not need this?

--
nosy: +pjenvey

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6107] Subprocess.Popen output fails on Windows

[Philip Jenvey]

Philip Jenvey  added the comment:

Exactly what command line are you passing to subprocess? Does stderr 
contain anything?

--
nosy: +pjenvey

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6108] unicode(exception) behaves differently on Py2.6 when len(exception.args) > 1

[Ezio Melotti]

New submission from Ezio Melotti :

On Python 2.5 str(exception) and unicode(exception) return the same text:
>>> err
UnicodeDecodeError('ascii', '\xc3\xa0', 0, 1, 'ordinal not in range(128)')
>>> str(err)
"'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in
range(128)"
>>> unicode(err)
u"'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in
range(128)"

On Python 2.6 unicode(exception) returns unicode(exception.args):
>>> err
UnicodeDecodeError('ascii', '\xc3\xa0', 0, 1, 'ordinal not in range(128)')
>>> str(err)
"'ascii' codec can't decode byte 0xc3 in position 0: ordinal not in
range(128)"
>>> unicode(err)
u"('ascii', '\\xc3\\xa0', 0, 1, 'ordinal not in range(128)')"

This seems to affect only exceptions with more than 1 arg (e.g.
UnicodeErrors and SyntaxErrors). KeyError is also different (the '' are
missing with unicode()).

Note that when an exception like ValueError() is instantiated with more
than 1 arg even str() returns str(exception.args) on both Py2.5 and Py2.6.

Probably __str__() checks the number of args before returning a specific
message and if it doesn't match it returns str(self.args). __unicode__()
instead seems to always return unicode(self.args) on Py2.6.

Attached there's a script that prints the repr(), str() and unicode() of
some exceptions, run it on Py2.5 and Py2.6 to see the differences.

--
components: Interpreter Core
files: unicode_exceptions.py
messages: 88330
nosy: ezio.melotti
severity: normal
status: open
title: unicode(exception) behaves differently on Py2.6 when len(exception.args) 
> 1
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file14071/unicode_exceptions.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6105] json.dumps doesn't respect OrderedDict's iteration order

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
priority:  -> critical

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6109] IDLE rendering issue with oriental characters on OSX

[Ronald Oussoren]

New submission from Ronald Oussoren :

IDLE has problems rendering some oriental characters on OSX.

One way to reproduce this:

* Start IDLE
* Open the "Preferences..." menu
* Scroll down in the list of fonts until you reach the 'Osaka' font

The font just below the Osaka font has a number of oriental characters 
in its name. Some of those characters are rendered as squares instead of 
the correct character.

The same problem crops up when you print oriental characters. I started 
looking into this because a user on the pythonmac-sig asked a question 
about this. I have a file that demonstrates the problem when you open 
it, but don't know yet if I can post that to the tracker.

--
components: IDLE, Macintosh, Tkinter
messages: 88331
nosy: ronaldoussoren
severity: normal
status: open
title: IDLE rendering issue with oriental characters on OSX
versions: Python 2.6, Python 2.7, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6110] IDLE has two "Preferences..." menu's on OSX

[Ronald Oussoren]

New submission from Ronald Oussoren :

With Python 2.7, but not 3.1 or 2.6, IDLE has two "Preferences..." menu's 
on OSX. 

This is on a OSX 10.5 system, with an installation of Tcl/Tk 8.4 in 
/Library/Frameworks.

--
components: IDLE, Macintosh
messages: 88332
nosy: ronaldoussoren
severity: normal
status: open
title: IDLE has two "Preferences..." menu's on OSX
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6111] Impossible to change preferences in IDLE

[Ronald Oussoren]

New submission from Ronald Oussoren :

It seems to be impossible to actually change preferences in IDLE when 
using Python 3.1, there are no problems with 2.6, 2.7 and 3.1.

How to reproduce:
* Open the "preferences menu"
* Pick a different font
* Choose "apply": nothing changes
* Choose "ok": dialog doesn't close
* Choose "cancel": dialog closes, but obviously no settings were changed.

--
components: IDLE, Macintosh
messages: 88333
nosy: ronaldoussoren
severity: normal
status: open
title: Impossible to change preferences in IDLE
versions: Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6111] Impossible to change preferences in IDLE

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Changed into release blocker because this is a very visible and annoying 
issue.

--
priority:  -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com