Ronald Oussoren added the comment:
The attached patch shows what I intent do commit after testing. This adds
a small ObjC command-line tool that sets the icon. I still have to build
the installer to check if the patch actually works.
--
resolution: -> accepted
Added file: h
Ronald Oussoren added the comment:
The effect on sys.executable is always present, the test is only valid for
a framework build because that's the only build that can find sys.prefix
without looking at sys.executable. Setting PYTHONEXECUTABLE with a non-
framework build is only valid i
Ronald Oussoren added the comment:
I'm closing this issue because I'v confirmed that the issue goes away when
I install a newer version of Tk In /Library/Frameworks.
--
resolution: -> invalid
status: open -> closed
___
Pytho
Ronald Oussoren added the comment:
I'm in favour of adding /Library/Python/x.y/ to sys.path for Python 2.7
and 3.1 and will work on that during the Pycon sprints.
/Library/Python will be added after the site-packages directory inside
the framework instead of replacing the latter dire
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5270>
___
___
Python-bugs-lis
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5271>
___
___
Python-bugs-lis
Ronald Oussoren added the comment:
The following patch explicitly mentions that os.path.normcase treats OSX
like any other Unix platform.
I'm in favor of applying this.
--
keywords: +patch
nosy: +ronaldoussoren
versions: +Python 2.6, Python 2.7, Python 3.1
Added file:
Ronald Oussoren added the comment:
Jack: do I understand you correctly when I interpret your message to mean
that libpython3.0.a inside the Python framework won't be usable as a
library that's linked using '-lpython3.0' in a future edition of Xcode?
That would be a bumm
Ronald Oussoren added the comment:
Tarek: I don't understand your comment. Both the tests and code in
distutils look correct to me, although one of them should be wrong given
the failure that Martina is seeing.
(I've check the code in Python's trunk and 3.x branch)
Ronald Oussoren added the comment:
Closing this because this is a feature request and the Carbon bindings are
deprecated.
--
nosy: +ronaldoussoren
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.p
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue1099>
___
___
Python-bugs-lis
Ronald Oussoren added the comment:
Closing because these are feature enhancements and the Carbon bindings are
deprecated.
--
nosy: +ronaldoussoren
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.p
Ronald Oussoren added the comment:
Python is just one of the many things that will fail on a case sensitive
root filesystem. I'm not particularly interested in fixing this issue.
This doesn't affect Python 3.x because the code that causes this problem
is not present in 3.x.
Settin
Ronald Oussoren added the comment:
Jack: are you planning to work on this?
I propose to close this issue if your not because bgen in the python.org
tree is basically dead at this point. Any enhancements would be better of
a separate project.
--
nosy: +ronaldoussoren
Ronald Oussoren added the comment:
I've applied these patches in revision r70713, the bugfix will be in
python 2.7.
Also backported to 2.6 in r70715.
--
nosy: +ronaldoussoren
resolution: -> accepted
status: open -> closed
___
Pyt
Ronald Oussoren added the comment:
Adding support for building an X11 version of Tkinter would require an
explicit flag to configure, defaulting to a build that uses AquaTk (which
most people would like to use).
I'm not interested in creating a patch for this, but am willing to r
Ronald Oussoren added the comment:
Fixed in r70719 (trunk) and r70720 (2.6)
--
nosy: +ronaldoussoren
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/is
Ronald Oussoren added the comment:
Floris: you can run the script from a Terminal window. Alternatively you
can use the Python Launcher tool that's location in /Applications/Python
X.Y (select it from the context-menu for a .py file)
--
resolution: -> works for
New submission from Ronald Oussoren :
the testcase test_get_platform is not entirely correct for the OSX case.
Background: OSX supports fat binary builds (Apple calls those Universal
Binaries). The testitem for OSX gives a false negative when you run the
test with a Universal Binary build of
Changes by Ronald Oussoren :
--
versions: +Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue5607>
___
___
Python-bugs-list mailing list
Unsub
Ronald Oussoren added the comment:
Fixed in r70727 (trunk), r70728 (2.6) and r70729 (3.1)
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
Committed as r70737 (trunk), r70738 (2.6), r70739 (3.1)
There is a small issue related to the bsddb3 tests with a 4-way universal
build on the trunk and 2.6, I'll look into that in the near future.
--
assignee: ronaldoussoren -> rhettin
Ronald Oussoren added the comment:
Applied in r5270 (trunk), r70743 (2.6) and r70745 (3.1)
--
resolution: -> accepted
status: open -> closed
versions: -Python 3.0
___
Python tracker
<http://bugs.python.org/
Changes by Ronald Oussoren :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue602291>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
Committed as r70746 (trunk), r70748 (2.6) and r70749 (3.1)
--
___
Python tracker
<http://bugs.python.org/issue5271>
___
___
Ronald Oussoren added the comment:
I've committed a fix for this in r70746 and ported this to 3.1 and 2.6 as
well.
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python
Changes by Ronald Oussoren :
--
resolution: -> accepted
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5271>
___
___
Python-bugs-
Ronald Oussoren added the comment:
I've clarified the readme for the 3.1 installer.
--
nosy: +ronaldoussoren
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
versions: +Python 3.1 -Python 3.0
___
Python
Ronald Oussoren added the comment:
The attached file issue763708.patch changes configure.in and disables the
toolbox glue when doing a UCS4 build.
To get this behaviour I had to move a couple of sections around inside
configure.in (--enable-toolbox-glue was checked for before the size of
Ronald Oussoren added the comment:
I don't have a PPC machine handy at the moment, but I hope the attached
copy of urllib fixes the issue. Could you please test if that's indeed the
case?
--
keywords: +patch
Added file: http://bugs.python.org/file13489/urllib
Ronald Oussoren added the comment:
This issue is still present on OSX:
Python 2.6.1+ (release26-maint:70603, Mar 26 2009, 08:38:03)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Changes by Ronald Oussoren :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue900502>
___
___
Python-bugs-
New submission from Ronald Oussoren :
The malloc warnings happen on OSX, with a fresh checkout of the python3
branch. Python was build using --enable-universalsdk=/ --with-universal-
archs=all, on a x86_64 capable laptop running Leopard.
The issue goes away when running from the commandline
Ronald Oussoren added the comment:
What's more annoying: the error goes away while running in a debugger.
The issue happens at least in tes_constructor:
test_constructor (__main__.CBufferedWriterTest) ...
python.exe(35957,0x7fff701d1720) malloc: *** mmap(size=-
9223372036854775808) f
Ronald Oussoren added the comment:
I'm not yet sure that patch is correct, I got some build failure during
later tests that went away when I reverted this patch. To be continued...
--
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
Buffer_size is set to 0x7fff in BufferedWriter_init at the end
of test_constructor.
I have no idea why this happens, but this definitly seems wrong to me.
Debugging is rather hard at the moment because the issue goes away in the
debugger
Changes by Ronald Oussoren :
--
components: -Macintosh
___
Python tracker
<http://bugs.python.org/issue4892>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ronald Oussoren added the comment:
Closing this as won't fix. Nobody else complained and changing this might
break existing code.
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Ronald Oussoren :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue1113328>
___
___
Python-bugs-list mailing list
Unsubscri
Ronald Oussoren added the comment:
I propose closing this as won't fix, the issue is caused by a limitation
in the Carbon APIs (which assume you're running an eventloop and won't
notice changes when you don't).
--
nosy: +ronaldoussoren
resolution: -> wont fix
Ronald Oussoren added the comment:
Although this might be seen as a bug in the Python build machinery, I'm
closing this as a won't fix feature request.
The Carbon bindings are deprecated and will not be updated in the future,
hence the state of bgen is basically irrelevant.
-
Ronald Oussoren added the comment:
I don't think this is related to Python's mmap module, the message says
that malloc(3) cannot mmap some extra memory space.
I'll test with the older version of mmap just in case.
--
___
Python
Ronald Oussoren added the comment:
Committed a fix for this as r70778 (trunk), r70782 (3.1)
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
I can't believe that I completely missed that this is the purpose of the
tests, I honestly believed that I had checked everything there was to
check :-(
Disabling the test won't be necessary, I'm keeping this issue open for a
while longer
Ronald Oussoren added the comment:
I'll install 10.5 server on my PPC test machine when I'm back from PyCon,
this seem to need some serious debugging.
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
Setting issue back to "open". I'm going to install a 10.4 PPC test machine
over the weekend to try to reproduce the problem there.
Issue5413 might be related to this one, that one also seems to be about
some ctypes code that doesn't
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue4937>
___
___
Python-bugs-lis
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue3646>
___
___
Python-bugs-lis
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5267>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
I don't understand why the function-level imports cannot be removed.
Wouldn't it be possible to do something like this:
from errno import ENOENT as _ENOENT, ENOTDIR as _ENOTDIR
def _execvpe(file, args, env=None):
pass # Use _ENOENT and _ENOTD
Ronald Oussoren added the comment:
Raymond: My guess is that this is caused because the binary was build on
OSX 10.5, where 'printf("%zd")' works file for negative numbers, and the
tests was run on OSX 10.4, where the same printf statement doesn't work
correctly.
I
Ronald Oussoren added the comment:
Raymond: I had intended to assign the issue to myself but I obviously need
more training with dropdown menu's (your name is just above mine in the
assigned-to menu).
--
assignee: -> ronaldoussoren
nosy: -rhettinger
status: pending
Ronald Oussoren added the comment:
Julian: patches for 2.4 and 2.5 will not be accepted, both releases are in
"critical security fixes only" mode.
--
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
Uploading a patch is fine, my comment was just a warning that your patch
won't be applied in the repository (at least not for 2.4 and 2.5).
I will look at your patch for 2.6 in the near future.
Are you sure that the issue is fixed in 3.x? AFAIK that
Ronald Oussoren added the comment:
For 3.1 I need to check if the right files get install into the various
'bin' directories. At the languages summit at PyCon'09 the consensus
seemed to be that the command-line interpreter for Python 3.x should be
"python3" and t
Ronald Oussoren added the comment:
I intend to fix this next weekend, therefore assigning the issue to
myself.
--
assignee: loewis -> ronaldoussoren
priority: -> release blocker
stage: -> needs patch
type: -> behavior
___
Python tr
Ronald Oussoren added the comment:
Fixed in r71743 (trunk), r71744 (2.6), r71746 (3.0), r71745 (3.1)
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
I can reproduce this with a unix build of python2.5:
* Install a unix build of python 2.5 (--with-pydebug) as
/opt/python2.5-dbg
* Install pyobjc 2.2-dev (from PyObjC's subversion repository)
* Build the addressbook plugin example in pyobjc-fram
Ronald Oussoren added the comment:
The attached patch is not entirely correct, I'm not yet uploading an
updated patch because the fix is obvious.
I cannot reproduce this with a the 2.6.2 installer (build on PPC) nor
with a recent build from subversion (python-trunk, build on X86). My
Ronald Oussoren added the comment:
Couldn't we just rename them in the repository?
IIRC the name with a '3' suffix would be the official name for these tools
in Python 3.x, which would make it more natural to change the name in the
repository as well.
I don't know e
Changes by Ronald Oussoren :
--
nosy: -ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue1514420>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Ronald Oussoren :
Class zipfile.ZipFile has two methods for adding data to a zipfile:
'write' and 'writestr'.
The former has a "compression_type" argument that can be used to specify
the compression to be used. That latter doesn&
New submission from Ronald Oussoren :
Class zipfile.ZipFile has two methods for adding data to a zipfile:
'write' and 'writestr'.
The former has a "compression_type" argument that can be used to specify
the compression to be used. That latter doesn&
Ronald Oussoren added the comment:
Too impatient while submitting the report...
--
resolution: -> duplicate
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Ronald Oussoren added the comment:
I will.
I guess it's too late to merge this into 3.1 (as the first beta has
already been released).
--
___
Python tracker
<http://bugs.python.org/i
New submission from Ronald Oussoren :
The default "install" target in the toplevel makefile for python 3.x
behaves like the "altinstall" target in python 2.x. This behaviour was
choosen to avoid conflicts between python 3.x and python 2.x
installations.
IMO this is no
Ronald Oussoren added the comment:
Jack: could you please explain what the issue is? Unless you do so I
will close this issue as "won't fix".
In particular: will linking with "-lpython3.0" work with this
hypothetical future version of Xcode you're talkin
Changes by Ronald Oussoren :
--
assignee: -> ronaldoussoren
___
Python tracker
<http://bugs.python.org/issue5514>
___
___
Python-bugs-list mailing list
Un
Ronald Oussoren added the comment:
I haven't looked in this particular problem yet, but please note that the
Mac-specific libraries do not work with an UCS4 build of python.
--
nosy: +ronaldoussoren
___
Python tracker
<http://bugs.py
Ronald Oussoren added the comment:
Sorry about the noise, I mustn't have been awake this morning :-(
The fact that fullinstall still creates a "python" executable confuses me
a little though, I thought the consesus at the language summit at Pycon
was that we shouldn't do
New submission from Ronald Oussoren :
The package Lib/pydoc_data is not installed by Makefile.pre.in. Because
of this "pydoc if" won't work.
The attached patch fixes this issue. I've applied this patch to the
trunk (r72787) and py3k (r72788), and filed this issue because I
Ronald Oussoren added the comment:
Closing as won't fix because you can use "make altinstall".
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://b
Ronald Oussoren added the comment:
Closing this issue because it was fixed a while back. The bsddb test
failure I rever to in my previous message turned out to be a non-issue:
these tests just take a very long time to finish.
--
status: open -> clo
Ronald Oussoren added the comment:
"make fullinstall" is wrong, this will install a "python" executable as
well as the proper "python3" and "python3.1" executables.
I'll do a build of the 3.1 installer ASAP and fix any issues
Ronald Oussoren added the comment:
The mac issue mentioned by "karlcow" is not relevant for this discussion
and refers to the system install of Python.
The python.org maintainers cannot influence the behaviour of that
installation, especially not w.r.t. the installation of optio
Ronald Oussoren added the comment:
I've recently fixed this for 3.1, and fixed this for 2.x a while back.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python
Ronald Oussoren added the comment:
This might be useful for profiling. Debugging information is already
present in the default build of the framework.
A seperate binary for --with-pydebug won't be possible as AFAIK --with-
pydebug changes the ABI and hence having both in the same fram
Ronald Oussoren added the comment:
Skip could you please answer the questions in msg83149?
--
___
Python tracker
<http://bugs.python.org/issue4834>
___
___
Pytho
Ronald Oussoren added the comment:
The attached patch implements my proposal, including documentation and
tests. I'm not 100% happy about the tests, they may be a bit too minimal.
--
keywords: +patch
Added file: http://bugs.python.org/file14018/zipfile_writestr.
Ronald Oussoren added the comment:
Argh... The patch includes an update to configure.in, please ignore that
bit.
--
___
Python tracker
<http://bugs.python.org/issue6
Ronald Oussoren added the comment:
Ned: the 2to3 is not installed anymore by the main makefiles, I don't know
why.
I'm actually happy that smtpd.py isn't installed anymore, this always
looked more like an example that a
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
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:
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
Ronald Oussoren added the comment:
Changed into release blocker because this is a very visible and annoying
issue.
--
priority: -> release blocker
___
Python tracker
<http://bugs.python.org/iss
Ronald Oussoren added the comment:
I should have made this more clear in the description, instead of hiding
it in the components list, but this is an issue for the OSX port.
--
___
Python tracker
<http://bugs.python.org/issue6
Ronald Oussoren added the comment:
The same fontname and file display correctly in programs (such as
Textmate).
Even when both textmate and IDLE have been configured to use the same
font the text looks fine in textmate and broken in IDLE.
My gut feeling is that this is an issue with the Tk
Ronald Oussoren added the comment:
Switching to Tcl/Tk 8.5 fixes the issue for IDLE as well.
I'm leaving this bug open for future reference, and because this affects
the binary installer for python.
The big question: how to fix this in Python itself. I see the following
options:
1) I
Ronald Oussoren added the comment:
The attached file is an example of text that works fine in Textmate but
renders incorrectly in IDLE.
--
Added file: http://bugs.python.org/file14079/Chinese.txt
___
Python tracker
<http://bugs.python.
Ronald Oussoren added the comment:
This is definitly an Tk issue, the issue seems to be fixed in Tcl/Tk 8.5.
That is, when I install Tk 8.5 and rerun the Tcl scriptlet I posted
earlier the problem goes away. I'm currently rebuilding a version of the
tkinter extension that links to Tk 8
Ronald Oussoren added the comment:
The same problem is also present in IDLE 3.0.
--
___
Python tracker
<http://bugs.python.org/issue6111>
___
___
Python-bug
Ronald Oussoren added the comment:
Wrt. the question about tracebacks, I get the following exception when I
click on the Apply button:
/Applications/Python\ 3.1/IDLE.app/Contents/MacOS/IDLE
Exception in Tkinter callback
Traceback (most recent call last):
File
"/Library/Frame
Ronald Oussoren added the comment:
The fact that it seems to work on the trunk is accidental, another bug
causes the code to go into a branch for a "old" version of Tk even when
running on a newer one. The code in the "new" branch triggers the bug.
I've committed
Ronald Oussoren added the comment:
This was caused by code in macosxSupport.py that picked the branch for
the wrong Tk release because "[8, 4, 21] < (8, 4, 21)".
Committed a fix in r72946
--
resolution: -> fixed
status: open -> closed
___
Ronald Oussoren added the comment:
Supporting multiple versions of Tk sucks, and that's without trying to
support Tk 8.5 as well (at least not in the binary installers)
Appearently support for the Cocoa port of Tk requires even more
specialc
Ronald Oussoren added the comment:
Good point, especially because the file in /usr/local/bin seem to be how a
lot of users still use the framework.
I'm committing a patch later today (which will include properly installing
2to3 in a framework
Ronald Oussoren added the comment:
Checked in a fix for this in r72947.
--
___
Python tracker
<http://bugs.python.org/issue5653>
___
___
Python-bugs-list mailin
Changes by Ronald Oussoren :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5653>
___
___
Python-bugs-list
Ronald Oussoren added the comment:
You've got a point there.
Benjamin: should the removal of smtpd.py from the list of installed
scripts be listed in the NEWS file?
--
nosy: +benjamin.peterson
___
Python tracker
<http://bugs.python.org/i
Ronald Oussoren added the comment:
Sure. Done in r72948.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/
2001 - 2100 of 2445 matches
Mail list logo
