It would be nice if this simple fix could be included (main branch and 2.5.1):
https://sourceforge.net/tracker/?func=detail&aid=1598181&group_id=5470&atid=105470
[ 1598181 ] subprocess.py: O(N**2) bottleneck
I submitted the trivial fix almost two months ago, but apparently nobody feels
respon
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 featu
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 except
I just wanted to share an observation in case Python developers are
interested:
Python 2.7.1 doesn't build with the current gcc 4.6 svn.
Note that gcc 4.6 is now in "bug-fix only" mode.
Some details:
Fedora 14 64-bit.
The first time I noticed the problem was in Nov or early Dec 2010;
I'm pretty
> 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
Python-Dev@python.o
> 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
W
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 han
Brett C. wrote:
> Ralf W. Grosse-Kunstleve wrote:
> > Brett C. wrote:
> >
> > >I have been mulling over this proposal and I think I am finally
> > >settling on +0 as long as it can be shown that it does not hurt
> > >performance at all (yes, it
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 com
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 w
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 di
--- "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.)
--- 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 danger
--- 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*
--- 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
--- 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
--- 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,
--- "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 warni
--- "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,
> >
--- 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 rem
--- 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
> > > alternati
--- "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
--- "Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote:
> Michael Hudson wrote:
>
> > Benji York <[EMAIL PROTECTED]> writes:
> >
> >> Nick Coghlan wrote:
> >>> Perhaps ImportWarning should default to being ignored, the same way
> >>> PendingDeprecationWarning does?
> >>>
> >>> Then -Wd would be
--- "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
&g
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
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):
http://phenix-online.org/cctbx_sources/scitbx/scitbx
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])
W
Josiah Carlson wrote:
> Now, don't get me wrong, definining __slots__ can be a pain in the
> tookus, but with a proper metaclass, that metaclass can define the
> __slots__ attribute based on the argument list for __init__().
>
> There you go.
Where? The meta-class idea sounds interesting. Could y
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 he
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
http
--- 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
--- 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 u
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
--- "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,
--- 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 th
--- 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
--- "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 compil
--- "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 insigh
--- "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
--- 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 signifi
--- 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
>
--- 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 b
--- 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 variabl
--- 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 an
46 matches
Mail list logo
