Re: [Python-Dev] Attribute error: providing type name
Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. He does. It is supposed to appear in 4.8. So I guess that's it, thanks a lot for your help. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python under valgrind
Probably because of the object memory allocator. It reads the start of memory pages to see if a block belongs tot the obmalloc system or not. You want to remove the following line: #define WITH_PYMALLOC 1 From pyconfig.h if you intend to run using valgrind or say, purify. K -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hrvoje Niksic Sent: 28. nóvember 2008 13:52 Cc: Python-Dev Subject: Re: [Python-Dev] Python under valgrind Amaury Forgeot d'Arc wrote: Did you use the suppressions file as suggested in Misc/README.valgrind? Thanks for the suggestion (as well as to Gustavo and Victor), but my question wasn't about how to suppress the messages, but about why the messages appear in the first place. I think my last paragraph answers my own question, but I'm not sure. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
I wonder if there's some desiderata left for future Python versions to make this standard behavior easier (for C-coded, Python-coded, and Cython-coded classes, ones made by SWIG, etc) without too much black magic... Alex On Mon, Dec 1, 2008 at 1:30 AM, Filip Gruszczyński [EMAIL PROTECTED] wrote: Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. He does. It is supposed to appear in 4.8. So I guess that's it, thanks a lot for your help. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] format specification mini-language docs...
Yep, after the thanksgiving delay I've opened bug #4482
(http://bugs.python.org/issue4482).
I either don't know how to or don't have the power to change who a bug is
assigned to so it appears to be currently unassigned.
-Original Message-
From: Eric Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 25, 2008 4:38 AM
To: Dino Viehland
Cc: python-dev@python.org dev
Subject: Re: [Python-Dev] format specification mini-language docs...
Dino Viehland wrote:
previously discussed cases deleted
Finally providing any sign character seems to cause +1.0#INF and friends to
be returned instead of inf as is documented:
10e667.__format__('+')
'+1.0#INF'
10e667.__format__('')
'inf'
Are these just doc bugs? The inf issue is the only one that seems
particularly weird to me.
I think the inf one is a bug. Would you mind opening a bug and assigning
it to me? Thanks.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] format specification mini-language docs...
Dino Viehland wrote:
Yep, after the thanksgiving delay I've opened bug #4482
(http://bugs.python.org/issue4482).
Thanks!
I either don't know how to or don't have the power to change who a bug is
assigned to so it appears to be currently unassigned.
I'll take care of it.
Eric.
-Original Message-
From: Eric Smith [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 25, 2008 4:38 AM
To: Dino Viehland
Cc: python-dev@python.org dev
Subject: Re: [Python-Dev] format specification mini-language docs...
Dino Viehland wrote:
previously discussed cases deleted
Finally providing any sign character seems to cause +1.0#INF and friends to be
returned instead of inf as is documented:
10e667.__format__('+')
'+1.0#INF'
10e667.__format__('')
'inf'
Are these just doc bugs? The inf issue is the only one that seems particularly
weird to me.
I think the inf one is a bug. Would you mind opening a bug and assigning
it to me? Thanks.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/eric%2Bpython-dev%40trueblade.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Hi all, I didn't look at the thread until this morning. The OEM ready program required that the installed force to program files. But as we preinstalled we use your msi with a normal parameter: python-2.5.2.msi TARGETDIR=c:\program files\python That why I didn't ask you about that. WE have done already few weeks of test and nothing is breaking up to now :) Now about the 2 others issues what will be the easier way to fix them properly ? - for the executable without manifest as we are on vista OS only I can add a manifest for vista outside the executable it should work. - for python_icon.exe I do not know what is calling it in start menu can you help me on that ? Gerald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin v. Löwis Sent: Sunday, November 30, 2008 2:24 PM To: [EMAIL PROTECTED] Cc: 'Nick Coghlan'; python-dev@python.org Subject: Re: [Python-Dev] Python for windows. Of course, I don't object to that and still think we should help where we can, but if that is true it would make the premise of this thread a little misleading, as obviously HP could then make *any* necessary changes without our agreement or even knowledge. Perhaps. However, help where we can is about right. If its only the changes HP discussed so far, I think we should be able to help. For the Program Files issue, without going into the discussion whether Python's defaults are good or not, I think there would be still a number of technical solutions (such as providing a merge module which changes the default). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
Mark, We do not install that on first boot. I can not tell how it is install but on first boot python is already there and installed properly Gerald -Original Message- From: Koenig, Gerald Sent: Monday, December 01, 2008 11:05 AM To: 'Martin v. Löwis'; [EMAIL PROTECTED] Cc: 'Nick Coghlan'; python-dev@python.org Subject: RE: [Python-Dev] Python for windows. Hi all, I didn't look at the thread until this morning. The OEM ready program required that the installed force to program files. But as we preinstalled we use your msi with a normal parameter: python-2.5.2.msi TARGETDIR=c:\program files\python That why I didn't ask you about that. WE have done already few weeks of test and nothing is breaking up to now :) Now about the 2 others issues what will be the easier way to fix them properly ? - for the executable without manifest as we are on vista OS only I can add a manifest for vista outside the executable it should work. - for python_icon.exe I do not know what is calling it in start menu can you help me on that ? Gerald -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin v. Löwis Sent: Sunday, November 30, 2008 2:24 PM To: [EMAIL PROTECTED] Cc: 'Nick Coghlan'; python-dev@python.org Subject: Re: [Python-Dev] Python for windows. Of course, I don't object to that and still think we should help where we can, but if that is true it would make the premise of this thread a little misleading, as obviously HP could then make *any* necessary changes without our agreement or even knowledge. Perhaps. However, help where we can is about right. If its only the changes HP discussed so far, I think we should be able to help. For the Program Files issue, without going into the discussion whether Python's defaults are good or not, I think there would be still a number of technical solutions (such as providing a merge module which changes the default). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gerald.koenig%40hp.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Alex Martelli wrote:
I wonder if there's some desiderata left for future Python versions to
make this standard behavior easier (for C-coded, Python-coded, and
Cython-coded classes, ones made by SWIG, etc) without too much black
magic...
Perhaps adding something like the following to the C API:
void PyErr_FormatAttributeError(PyObject* type, char *attr)
{
PyErr_Format(PyExc_AttributeError,
object of type %.100s has no attribute '%.200s',
type-tp_name, attr);
}
This could also be exposed as a class method of AttributeError itself
for use in Python code.
(Interestingly, I noticed that there are still quite a few attribute
errors at least in typeobject.c that don't provide any information on
the type of the object that is missing an attribute - they appeared to
mostly be obscure errors that will only turn up if something has gone
very strange, but they're there)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for windows.
The OEM ready program required that the installed force to program files. But as we preinstalled we use your msi with a normal parameter: python-2.5.2.msi TARGETDIR=c:\program files\python I think the debate was about whether it can be OEM ready, even though you still need to pass the TARGETDIR parameter. If it works for you, it works for me, of course. Now about the 2 others issues what will be the easier way to fix them properly ? - for the executable without manifest as we are on vista OS only I can add a manifest for vista outside the executable it should work. Please do submit an issue in the bug tracker atleast, asking that the files be renamed. Please confirm explicitly that renaming them would also solve the problem (assuming you are still talking about the files in distutils). for python_icon.exe I do not know what is calling it in start menu can you help me on that ? Please look in Tools/msi/msi.py for all occurrences of python_icon.exe. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Alex Martelli wrote: I wonder if there's some desiderata left for future Python versions to make this standard behavior easier (for C-coded, Python-coded, and Cython-coded classes, ones made by SWIG, etc) without too much black magic... I think the standard exception hierarchy should grow additional standard fields. E.g. AttributeError should have attributes 'type','name', or perhaps even 'object','name'. TypeError should have attributes 'expected', 'actual' (or, again, 'expected', 'object'). Also, some languages support nested exceptions (attribute 'inner'); usefulness of this concept should be reviewed. And so on - that might produce quite a large PEP. As 3.0 missed the chance to fix this, compatibility is also an issue. It might be possible to overload exception constructors on the number of parameters, or using keyword parameters for the new way of filling the exception. And no, I don't volunteer to write this PEP :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Move encoding_decl to the top of Grammar/Grammar?
Hi all, Currently, Parser/parsetok.c has a dependency on graminit.h. This can cause headaches when rebuilding after adding new syntax to Grammar/Grammar because parsetok.c is part of pgen, which is responsible for *generating* graminit.h. This circular dependency can result in parsetok.c using a different value for encoding_decl to what is used in ast.c, which causes PyAST_FromNode to fall over at runtime. It effectively looks something like this: * Grammar/Grammar is modified * build begins -- pgen compiles, parsetok.c uses encoding_decl=X * graminit.h is rebuilt with encoding_decl=Y * ast.c is compiled using encoding_decl=Y * when python runs, parsetok() emits encoding_decl nodes that PyAST_FromNode can't recognize: SystemError: invalid node XXX for PyAST_FromNode A nice, easy short term solution that doesn't require unwinding this dependency would be to simply move encoding_decl to the top of Grammar/Grammar and add a big warning noting that it needs to come before everything else. This will help to ensure its value never changes when syntax is added/removed. I'm happy to provide a patch for this (including some additional dependency info for files dependent upon graminit.h and Python-ast.h), but was wondering if there were any opinions about how this should be resolved. Cheers, Tom ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
