Does that version of gcc emit any warnings during compilation?
Yes, there are a few:
http://cci.lbl.gov/~rwgk/tmp/gcc_trunk_168695_fc14_py271/
This is with:
g++ (GCC) 4.6.0 20110112 (experimental)
Ralf___
Python-Dev mailing list
FWIW: I didn't have much luck translating segfaults into exceptions. It
(seemed) to work on
some platforms, but not others; this was in the context of C++.
In my experience, it is more useful to generate Python and C stack traces and
bail out.
I also do this for floating-point exceptions. The
The tests for float.__format__ are breaking on Windows, because of this
issue: http://bugs.python.org/issue1600. Basically, Windows is using 3
digits for exponents 100, and Linux (and at least MacOS) are using 2.
Yes, this is very annoying and I once lost of lot of time because of the
Hi Raymond,
Thanks for the detailed explanation!
I'm not sure what your code was doing where the bugfix would cause
breakage. If its __getitem__() override returned a meaningful value
for each element in obj.keys(), then it should have worked fine. Of
course, if it was raising an exception
When pickling instances of an object derived from dict, the pickle in Python
2.5.1c1 calls the object's __getitem__() method. In contrast, earlier versions
of Python incl. 2.5 don't call that method. Below is a minimal example with
outputs. Is the difference in behavior an oversight or new
It would be nice if this simple fix could be included (main branch and 2.5.1):
https://sourceforge.net/tracker/?func=detailaid=1598181group_id=5470atid=105470
[ 1598181 ] subprocess.py: O(N**2) bottleneck
I submitted the trivial fix almost two months ago, but apparently nobody feels
--- Martin v. L�wis [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
If there is a consenus, I'd create a new exception
ImportErrorNoModule(name)
that is used consistently from all places. This would ensure uniformity of
the
message in the future.
A correction proposal
--- Martin v. L�wis [EMAIL PROTECTED] wrote:
So spend some of the money to come up with an alternate solution for
2.5b2. With a potential damage of a million dollars, it shouldn't be
too difficult to provide a patch by tomorrow, right?
My share is only 10 man hours, payed for by the US
--- Guido van Rossum [EMAIL PROTECTED] wrote:
On 6/25/06, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Sunday 25 June 2006 20:48, Greg Ewing wrote:
BTW, when that was being discussed, did anyone consider
allowing a directory to be given a .py suffix as an
alternative way to mark
--- Martin v. L�wis [EMAIL PROTECTED] wrote:
The specific question was
Is there a way to set the warning options via an environment variable?
This has nothing to do with beta1; the warnings module was introduced
many releases ago, along with all the mechanics to disable warnings.
Due
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
I don't know. Whether a warning is a problem is a matter of attitude, also.
Our users will think our applications are broken if they see warnings like
that. It is not professional.
__
Do You Yahoo!?
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Scott David Daniels wrote:
I am not sure about your compiler, but if I remember the standard
correctly, the following code shouldn't complain:
PyObject_CallFunction((PyObject*) (void *) PyRange_Type,
lll,
--- Jean-Paul Calderone [EMAIL PROTECTED] wrote:
I think it is safe to say that Twisted is more widely used than anything
Google has yet released. Twisted also has a reasonably plausible
technical reason to dislike this change. Google has a bunch of engineers
who, apparently, cannot remember
--- Tim Peters [EMAIL PROTECTED] wrote:
[Ralf W. Grosse-Kunstleve]
Thanks! This does the trick for me:
#if PY_VERSION_HEX = 0x0203
PyObject_CallFunction(
(PyObject*) PyRange_Type, lll, start, start+len*step, step)
Note that this is extremely lax about possible
--- Scott David Daniels [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
Thanks! This does the trick for me:
#if PY_VERSION_HEX = 0x0203
PyObject_CallFunction(
(PyObject*) PyRange_Type, lll, start, start+len*step, step)
#else
PyRange_New(start
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
Is there a way to set the warning options via an environment variable?
This is off-topic for python-dev,
What is the channel I should use? (I am testing a beta 1.)
but: why don't switch off the warnings
--- Georg Brandl [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
http://docs.python.org/dev/whatsnew/ports.html says:
The PyRange_New() function was removed. It was never documented, never
used
in the core code, and had dangerously lax error checking.
I use
--- Georg Brandl [EMAIL PROTECTED] wrote:
Well, PyRange_New *was* undocumented,
Yes, that was clear.
However, it would perhaps be helpful to add a note to the whatsnew document
for users like yourself. Andrew, does that make sense?
I am worried about using an alternative that is *again* not
--- Bob Ippolito [EMAIL PROTECTED] wrote:
I am sure I can get this to work with some digging, but I am
posting here to
highlight a communication problem. I feel if a function is removed the
alternative should be made obvious in the associated documentation; in
particular if there is
http://docs.python.org/dev/whatsnew/ports.html says:
The PyRange_New() function was removed. It was never documented, never used
in the core code, and had dangerously lax error checking.
I use this function (don't remember how I found it; this was years ago),
therefore my code doesn't compile
http://docs.python.org/dev/whatsnew/other-lang.html says:
One error that Python programmers sometimes make is forgetting to
include an __init__.py module in a package directory. Debugging this
mistake can be confusing, and usually requires running Python with the
-v switch to log all the
--- Guido van Rossum [EMAIL PROTECTED] wrote:
On 6/21/06, Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote:
I am getting tons of ImportWarning: Not importing directory. See below
for
examples. It is impractical for me to reorganize our directory structure.
I'd
be busy for a week or more
Congratulations to the Python 2.5a1 release! I started adjusting Boost.Python
to work with this new release and it is going very well. I noticed this #define
in pyport.h:
#define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)1))
However, I couldn't find a corresponding PY_SSIZE_T_MIN which would come
--- Alexander Kozlovsky [EMAIL PROTECTED] wrote:
What do you think about this?
I (who writes Python code for a living) love it! See also:
http://cci.lbl.gov/~rwgk/python/adopt_init_args_2005_07_02.html
***Please*** make Python more selfish. Note that this is also an obvious avenue
for
--- Fredrik Lundh [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
***Please*** make Python more selfish. Note that this is also an obvious
avenue
for significant performance increases. If self is implicit you don't have
to do
the dictionary lookup for self all the time
--- Guido van Rossum [EMAIL PROTECTED] wrote:
On 1/6/06, Armin Rigo [EMAIL PROTECTED] wrote:
On Fri, Jan 06, 2006 at 12:56:01AM +0300, Alexander Kozlovsky wrote:
There are three different peculiarity in Python 2.x
in respect of 'self' method argument:
Yuk! This has been discussed
--- Thomas Wouters [EMAIL PROTECTED] wrote:
The main difference isn't the lookup of 'self', it's the attribute retrieval
of 'x' from 'self'.
I see. Thanks!
If you put 'self' into a special category (with corresponding C code), couldn't
you use the same indexing tricks as for local variables
--- Fredrik Lundh [EMAIL PROTECTED] wrote:
Please try the code below to see the performance impact.
oh, please. do you seriously think that if you don't have to type self
yourself, Python will suddenly be able to turn all instance variables into
local function variables without any
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Out of curiosity: can you please try invoking this enum_print to stdout
with your VS2005-built boost module? I see it uses fprintf, so I would
expect it to crash.
After beating on this for half an hour I am coming to the conclusion that there
is no
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
P.P.S. You do know that this configuration (extension compiled
with VS2005, Python compiled wit VS.NET2003) is not supported,
right?
Thanks to Adal's help I got all our C++ extensions (about 50) to work with VC8.
I am using Python 2.4.2 compiled
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Well, yes: the areas are
- memory management
- stdio
- locales
for the C library; for the C++, I'm not so sure, but I think one of the
areas is
- static members of class templates, in particular in STL containers
Thanks for the insight! For
--- Martin v. Löwis [EMAIL PROTECTED] wrote:
Ralf W. Grosse-Kunstleve wrote:
I am using a Visual Studio 2005 Professional installation. I also ran
vcredist_x86.exe. Moving msvc[mpr]80.dll to a directory on PATH didn't
help. However, standalone executables work OK without any gymnastics
--- Adal Chiriliuc [EMAIL PROTECTED] wrote:
Python uses LoadLibraryEx with the LOAD_WITH_ALTERED_SEARCH_PATH flag
which means that DLLs used by the extension will be searched
IN THE EXTENSION FOLDER and not on PATH.
Try putting msvcp80.dll right next to your extension DLL.
I tried that
--- Adal Chiriliuc [EMAIL PROTECTED] wrote:
Then you need to run mt.exe to embedd the manifest:
mt.exe /outputresource:cctbx_math_ext.pyd;#2 /manifest
cctbx_math_ext.pyd.manifest
That is the magic trick! After applying the mt command to all our extensions
most of our unit tests work even with
We have a bunch of C++ extensions (Boost.Python) that work fine under
Windows when compiled with Visual C++ 7.1. With a few minor tweaks
all extensions also compile with Visual C++ 8.0, but trying to import
any of the extensions fails with this message (shown in a pop-up box):
This application
--- David Abrahams [EMAIL PROTECTED] wrote:
Christoph Ludwig [EMAIL PROTECTED] writes:
I do not claim the 2 TUs test will cover all possible scenarios. I am not
even
sure this decision should be left to an automated test. Because if the test
breaks for some reason then the user is left
For those who didn't like my proposal a week ago, please have another
look:
http://mail.python.org/pipermail/python-list/2005-July/289446.html
Please reply only to python-list.
Cheers,
Ralf
___
Python-Dev mailing list
Python-Dev@python.org
--- David Abrahams [EMAIL PROTECTED] wrote:
Yes, all the tests are passing that way.
(On ELF based Linux/x86, at least.) That leaves me wondering
* when is --with-cxx really necessary?
I think it's plausible that if you set sys.dlopenflags to share
symbols it *might* end up being
Aahz wrote:
This is off-topic for python-dev. Please take it to comp.lang.python.
(It's not immediately obvious that this is off-topic, I know, but please
take my word for it.)
Done:
http://mail.python.org/pipermail/python-list/2005-July/288292.html
Sorry for creating so much noise
Hi,
I often find myself writing:
class grouping:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
I hate it, and every time I show this to a Python newcomer I get that
skeptic look. How about this for a change?
class grouping:
def
I am happy to see that others agree we need something better
than self.x=x; self.y=y; self.z=z.
Phillip J. Eby wrote:
class grouping:
def __init__(self, x, y, z):
initialize(self, locals())
Been there (older code):
Jp Calderone wrote:
If you use vars(self).update(locals()), it even looks halfway
pleasant ;) I'm not sure what python-dev's current opinion of
vars(obj) is though (I'm hoping someone'll tell me).
http://docs.python.org/lib/built-in-funcs.html#l2h-76 is pretty clear:
vars([object])
42 matches
Mail list logo
