Re: [Python-Dev] SyntaxError: can't assign to function call

Neal Becker schrieb: >> No. Array references (x[i]) and attribute references (x.a) represent >> "locations". Function calls represent values. This is no different >> than the distinction between lvalues and rvalues in C. >> > > Except this syntax is valid in c++ where X() is a constructor call: >

Re: [Python-Dev] Unicode Data in Python2.5 is missing a ucd_4_1_0 object

Armin Ronacher schrieb: > Right, I didn't know that. From that old bug report it sounded like a > programmer > should be able to select a specific UCD version. Well, my comment was that _IDNA_ needs to access _3.2_. This isn't as general as "any application needs to access any version". We likely

Re: [Python-Dev] SyntaxError: can't assign to function call

Phillip J. Eby schrieb: > Actually, this isn't as hard as you're implying. In at least the > "compiler.ast" package, such an operation would be represented as a > CallFunc node as the child of an Assign node. Wrapping the call node's > main child expression in a Getattr for __setcall__ would then

Re: [Python-Dev] Dict suppressing exceptions

Michael Chermside schrieb: > Not broken, but perhaps wrongheaded. The recipe went out of its way > to ensure that it would raise an exception of enum values from different > enumerations were compared. There's nothing out there saying that this > is a bad thing to do. And it's actually fine for th

Re: [Python-Dev] Dict suppressing exceptions

Guido van Rossum schrieb: >> >__eq__ methods should always return True or False. They should >> >only raise an exception if there is some internal error within >> >one of the objects being compared -- they should never raise >> >an exception because the other object is of an unexpe

Re: [Python-Dev] Dict suppressing exceptions

Jim Jewett schrieb: > hash was just changed to support the common use of id, even though > some people argued it was *really* a bug in the classes themselves. > This is a similar situation. Similar still different. In the case of __hash__ returning id(), it is very clear what the intention of the

Re: [Python-Dev] 2.6 idea: a 'function' builtin to parallel classmethod and staticmethod

Nick Coghlan schrieb: > It would be nice if there was a similar mechanism for normal instance methods > as well: > >method = function(some_callable) > If you know you have to put something around it, what's wrong with writing method = lambda *args:some_callable(*args) If that happens of

Re: [Python-Dev] What is the status of file.readinto?

Alexander Belopolsky schrieb: > I know that it is a subject of an annual discussion, but since I could > not find any mention of it in the last year, let me ask this question > again: why is file.readinto "Undocumented"? It is quite useful, > particularly with numpy. > > Would a patch adding "read

Re: [Python-Dev] Type of range object members

Alexander Belopolsky wrote: > The range object is currently defined in Objects/rangeobject.c as > > typedef struct { > PyObject_HEAD > longstart; > longstep; > longlen; > } rangeobject; > > Is this consistent with PEP 353, or should Py_ssize_t be used instead o

Re: [Python-Dev] Type of range object members

Alexander Belopolsky wrote: > Since on most platforms ssize_t is the same as long, the choice > between the two is just a matter of self-documenting code. No, it would be an actual change: on Win64, sizeof(Py_ssize_t)>sizeof(long). > Speaking > of which, I find it unfortunate that the name Py

Re: [Python-Dev] Arlington VA sprint on Sept. 23

Fred L. Drake, Jr. wrote: > I can guess at Martin's thinking, but I'd rather let him speak for himself, > since I'm not a trained channeller. ;-) Essentially, I want to give patches more attention, since they are larger contributions. I don't care if bug reports get unnoticed for years; I do wor

Re: [Python-Dev] Arlington VA sprint on Sept. 23

Georg Brandl wrote: >>> I can guess at Martin's thinking, but I'd rather let him speak for himself, >>> since I'm not a trained channeller. ;-) >> Essentially, I want to give patches more attention, since they are >> larger contributions. I don't care if bug reports get unnoticed for >> years; I

Re: [Python-Dev] no remaining issues blocking 2.5 release

Guido van Rossum schrieb: > I am sympathetic to this case. Is there any advantage to the *users* > of distutils of the dynamic version number? This series of commits was triggered by a user who wondered why Python 2.4.3 ships with distutils 2.4.1, yet Python 2.5bsomething ships with the older 2.4.

Re: [Python-Dev] Type of range object members

Alexander Belopolsky schrieb: > Another reason is that POSIX interprets negative values of ssize_t as > "an error indication", not as an offset from the end. A better POSIX > analogy would be off_t (as used in lseek). That's subtle. By this reasoning, ptrdiff_t would be wrong, as well, since i

Re: [Python-Dev] Type of range object members

Guido van Rossum schrieb: > FWIW, I propose that in py3k, the int type uses Py_ssize_t instead of long. This is really a py3k issue, but: shouldn't the int and long types really get unified into a single type in Py3k? I suppose the "i" parameter to PyArg_ParseTuple would continue to parse int? R

Re: [Python-Dev] no remaining issues blocking 2.5 release

M.-A. Lemburg schrieb: > I find it important to maintain distutils compatibility with > a few Python versions back. Even if I can't volunteer to > maintain distutils, like Martin suggested, due to lack of time, > I don't really see the requirement to use the latest and greatest > Python features in

Re: [Python-Dev] Type of range object members

Guido van Rossum schrieb: > From the Python *user*'s perspective, yes, as much as possible. But > I'm still playing with the thought of having two implementation types, > since otherwise we'd have to devote 4 bytes (8 on a 64-bit platform) > to the single *bit* telling the difference between the tw

Re: [Python-Dev] no remaining issues blocking 2.5 release

M.-A. Lemburg schrieb: >> It's either an official feature, with somebody maintaining it, >> or people should expect to break it anytime. > > I'll let you know when things break - is that good enough ? That can't be an official policy; you seem to define "breaks" as "breaks in my (your) personal u

Re: [Python-Dev] Type of range object members

James Y Knight schrieb: > But it's the short int that you probably really want to make size > efficient. Only if you have many of them. And if you do, you have the problem of the special-cased allocator: when the many ints go away, Python will hold onto their memory forever. Regards, Martin ___

Re: [Python-Dev] Type of range object members

Greg Ewing schrieb: > Martin v. Löwis wrote: >> We had this discussion before; if you use ob_size==0 to indicate >> that it's an int, this space isn't needed in a long int. > > What about int subclasses? It's what Guido proposes. It would still leave two type

Re: [Python-Dev] Type of range object members

Greg Ewing schrieb: > Guido van Rossum wrote: >> I worry that dropping the special allocator will be too slow. > > Surely there's some compromise that would allow > recently-used ints to be kept around, but reclaimed > if memory becomes low? Hardly. The efficiency of the special-case allocator al

Re: [Python-Dev] Type of range object members

Greg Ewing schrieb: >> There isn't? Actually a lot of APIs currently assumen that. > > Also it means you'd pay a penalty every time you > access it, whereas presumably short ints are the > case we want to optimise for speed as well. That penalty is already paid today. Much code dealing with ints

Re: [Python-Dev] Type of range object members

[EMAIL PROTECTED] schrieb: > Guido> I worry that dropping the special allocator will be too slow. > > Greg> Surely there's some compromise that would allow recently-used ints > Greg> to be kept around, but reclaimed if memory becomes low? > > Martin> Hardly. The efficiency of the

Re: [Python-Dev] Type of range object members

Guido van Rossum schrieb: > I'm not sure that subclassing ints gives us much. We could make int > and long "final" types, and then all we have to do is tweak type() and > __class__ so that they always return the 'int' type. I don't think this can work - there would be too many ways for the "real"

Re: [Python-Dev] Benchmarking the int allocator (Was: Type of range object members)

[EMAIL PROTECTED] schrieb: > Wouldn't use of obmalloc offset much of that? Before obmalloc was > available, the int free list was a huge win. Is it likely to be such a huge > win today? I have now some numbers. For the attached t.py, the unmodified svn python gives Test 1 3.25420880318 Test 2 1

Re: [Python-Dev] Benchmarking the int allocator (Was: Type of range object members)

Guido van Rossum schrieb: > I think the test isn't hardly focused enough on int allocation. I > wonder if you could come up with a benchmark that repeatedly allocates > 100s of 1000s of ints and then deletes them? The question is: where to store them? In a pre-allocated list, or in a growing list

Re: [Python-Dev] Type of range object members

Neal Norwitz schrieb: > I was playing around with a little patch to avoid that penalty. It > doesn't take any additional memory, just a handful of bits we aren't > using. :-) There are common schemes that allow constant-time issubclass tests, although they do require more memory: 1. give each ba

Re: [Python-Dev] Type of range object members

Greg Ewing schrieb: >>> Also it means you'd pay a penalty every time you >>> access it >> That penalty is already paid today. > > You'd still have that penalty, *plus* the > overhead of bit masking to get at the value. No, the penalty gets smaller if there is only a single type. For example, abst

Re: [Python-Dev] Type of range object members

Neal Norwitz schrieb: > It would change the CheckExact()s from: op->ob_type == > global-variable, to: op->ob_type & CONSTANT == CONSTANT. Check would > be the same as the CheckExact, just with different constants. The > Check version would then drop the || condition. Hmm. I don't see the for the

Re: [Python-Dev] [Python-checkins] TRUNK IS UNFROZEN, available for 2.6 work if you are so inclined

Anthony Baxter schrieb: > Right now, I don't really care about the trunk - although if you break the > buildbot [...] Thanks for reminding me. I just added a buildbot builder for the 2.5 branch (actually, the builder was already there, but I connected it with the web server), so you can now see t

[Python-Dev] Fixing 2.5 windows buildbots

I'd like to fix the two build failures that the Windows buildbots show for the 2.5 trunk. I'm not quite sure what the OpenSSL failure is, yet, but the sqlite error should be fixable with the patch below. Ok to work on this? Martin Index: Tools/buildbot/external.bat ===

[Python-Dev] uuid tests failing on Windows

test_uuid1 and test_uuid4 fail consistently on Windows; apparently, the generated universally-unique identifiers aren't even unique within a set of 1000 identifiers. Can somebody please fix that? If not, should we remove the uuid module as being immature? Regards, Martin _

Re: [Python-Dev] uuid tests failing on Windows

Georg Brandl schrieb: >> Can somebody please fix that? If not, should we remove the uuid module >> as being immature? > > Patch #1541863 supposedly solves this. Ah, good. I think it should go in. Regards, Martin ___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] uuid tests failing on Windows

[EMAIL PROTECTED] schrieb: >>> Patch #1541863 supposedly solves this. >> Ah, good. I think it should go in. > > Uh, I may be misunderstanding here, but that patch looks like it > changes that part of the test for test_uuid4 to stop calling uuid4 > and call uuid1 instead? You misunderstand indeed:

Re: [Python-Dev] ctypes and win64

Thomas Heller schrieb: > I suggest that it should be removed from the 2.5 win64 msi installers, so that > at least, when it is ready, can be installed as separate package. Unfortunately, I won't be able to work on this until the release is made. Feel free to work on it, but I suggest to just not w

Re: [Python-Dev] ctypes and win64

Thomas Heller schrieb: >> There are many other problems with Win64 still, e.g. the test suite >> doesn't pass. > > And tons of compiler warnings, IIRC. If the state is still experimental, > IMO it should be marked as such. Most of the compiler warnings are irrelevant for most of the applications

Re: [Python-Dev] ctypes and win64

Steve Holden schrieb: > Reasonable enough, but I suspect that Thomas' suggestion might save us > from raising false hopes. I'd suggest that the final release > announcement point out that this is the first release containing > specific support for 64-bit architectures (if indeed it is) It isn't

Re: [Python-Dev] distutils patch

Russell E. Owen schrieb: > A colleague stumbled across distutils bug/misfeature that he found had > been reported with an associated patch: > d=5470&atid=305470> > > and I'm wondering if there's any plans to accept the pa

Re: [Python-Dev] Unicode Imports

Steve Holden schrieb: >> As this can't be considered a bugfix (that I can see), I'd be against it >> being >> checked into 2.5. >> > Are you suggesting that Python's inability to correctly handle Unicode > path elements isn't a bug? Not sure whether Anthony suggests it, but I do. > Or simply

Re: [Python-Dev] Unicode Imports

Steve Holden schrieb: >>> I agree it's a relatively large patch for a release candidate but if >>> prudence suggests deferring it, it should be a *definite* for 2.5.1 and >>> subsequent releases. >> >> Possibly. I remain unconvinced. >> > > But it *is* a desirable, albeit new, feature, so I'm sur

Re: [Python-Dev] Unicode Imports

Nick Coghlan schrieb: >> But it *is* a desirable, albeit new, feature, so I'm surprised that you >> don't appear to perceive it as such for a downstream release. > > And unlike 2.2's True/False problem, it is an *environmental* feature, rather > than a programmatic one. Not sure what you mean b

Re: [Python-Dev] Unicode Imports

Steve Holden schrieb: > I don't regard this as the provision of a new feature but as the removal > of an unnecessary restriction (which I would prefer to call a bug). You got the definition of "bug" wrong. Primarily, a bug is a deviation from the specification. Extending the domain of an argument

Re: [Python-Dev] Unicode Imports

Giovanni Bajo schrieb: > +1, but I would love to see a more formal definition of what a "bugfix" is, > which would reduce the ambiguous cases, and thus reduce the number of times > the > release managers are called to pronounce. > > Other projects, for instance, describe point releases as "open f

Re: [Python-Dev] Unicode Imports

Nick Coghlan schrieb: > So this is taking something that *already works properly on POSIX > systems* and making it work on Windows as well. I doubt it does without side effects. For example, an application that would go through sys.path, and encode everything with sys.getfilesystemencoding() curre

Re: [Python-Dev] Unicode Imports

David Hopwood schrieb: >> I doubt it does without side effects. For example, an application that >> would go through sys.path, and encode everything with >> sys.getfilesystemencoding() currently works, but will break if the patch >> is applied and non-mbcs strings are put on sys.path. > > Huh? It

Re: [Python-Dev] Unicode Imports

Nick Coghlan schrieb: > I think MvL is looking at it from the point of view of consumers of the list > of strings in sys.path, such as PEP 302 importer and loader objects, and > tools > like module_finder. Currently, the list of values in sys.path is limited to: That, and all kinds of inspectio

Re: [Python-Dev] Interest in a Python 2.3.6?

Barry Warsaw schrieb: > Thoughts? I don't want to waste my time if nobody thinks a 2.3.6 would > be useful, but I'm happy to do it if there's community support. I'll > also need the usual help with Windows installers and documentation updates. I personally would consider it a waste of time. Sinc

Re: [Python-Dev] Unicode Imports

David Hopwood schrieb: > On Windows, file system pathnames can contain arbitrary Unicode characters > (well, almost). Despite the existence of "ANSI" filesystem APIs, and > regardless of what 'sys.getfilesystemencoding()' returns, the underlying > file system encoding for NTFS and FAT filesystems i

Re: [Python-Dev] Unicode Imports

David Hopwood schrieb: > Elements of sys.path can be Unicode strings in Python 2.5, and should be > pathnames supported by the underlying OS. Where is it documented that there > is any further restriction on them? And why should there be any further > restriction on them? It's not documented in th

[Python-Dev] Subversion 1.4

As many of you probably know: Subversion 1.4 has been released. It is safe to upgrade to this version, even if the repository server (for us svn.python.org) stays at an older version: they can interoperate just fine. There is one major pitfall: Subversion 1.4 changes the format of the working cop

Re: [Python-Dev] Signals, threads, blocking C functions

Nick Maclaren schrieb: >> (coment by Arjan van de Ven): >> | afaik the kernel only sends signals to threads that don't have them >> blocked. >> | If python doesn't want anyone but the main thread to get signals, it >> should just >> | block signals on all but the main thread and then by nature, al

Re: [Python-Dev] Signals, threads, blocking C functions

Michael Hudson schrieb: >> According to [1], all python needs to do to avoid this problem is >> block all signals in all but the main thread; > > Argh, no: then people who call system() from non-main threads end up > running subprocesses with all signals masked, which breaks other > things in very

Re: [Python-Dev] Thank you all

Dan Eloff schrieb: > I just want to say thank you, very much, from the bottom of my heart, > to everyone here who chooses to spend some of their free time working > on improving Python. Hi Dan, I can't really speak for all the other contributors (but maybe in this case I can): Thanks for the kind

[Python-Dev] Testsuite fails on Windows if a space is in the path

The test suite currently (2.5) has two failures on Windows if Python is installed into a directory with a space in it (such as "Program Files"). The failing tests are test_popen and test_cmd_line. The test_cmd_line failure is shallow: the test fails to properly quote sys.executable when passing it

Re: [Python-Dev] python, lipo and the future?

Ronald Oussoren schrieb: > One problem is that python's configure script detects the sizes of > various types and those values will be different on 32-bit and 64-bit > flavours. FWIW, the PC build "solves" this problem by providing a hand-crafted pyconfig.h file, instead of using an autoconf-gener

Re: [Python-Dev] python, lipo and the future?

Josiah Carlson schrieb: > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Out of curiosity: how do the current universal binaries deal with this >> issue? > > If I remember correctly, usually you do two completely independant > compile runs (optionally on t

Re: [Python-Dev] python, lipo and the future?

Ronald Oussoren schrieb: > The sizes of basic types are the same on PPC32 and x86 which helps a > lot. Ah, right. This was the missing piece of the puzzle. The byteorder is different, but we can use GCC feature checks > there. The relevant bit of pyconfig.h.in: > > #ifdef __BIG_ENDIAN__ > #defi

Re: [Python-Dev] python, lipo and the future?

Jack Jansen schrieb: > Just wondering: is it a good idea in the first place to create a > universal 32/64 bit Python on MacOSX? I wonder about the same thing. > For extension modules it's different, though: there it would be nice > to be able to have a single module that could load into any P

Re: [Python-Dev] python, lipo and the future?

Ronald Oussoren schrieb: > BTW. several sites on the interweb claim that x86-64 runs faster than > plain x86 due to a larger register set. All my machines are 32-bit so I > can't check if this is relevant for Python (let alone Python on OSX). That is plausible. OTOH, the AMD64 binaries will often

Re: [Python-Dev] Before 2.5 - More signed integer overflows

> BTW, did anyone try compiling Python with -fwrapv on a box where it > matters? I doubt that Python's speed is affected one way or the > other, and if adding wrapv makes the problems go away, that would be > an easy last-second workaround for all possible such problems (which > of course could ge

Re: [Python-Dev] Before 2.5 - More signed integer overflows

Neal Norwitz schrieb: > I also tested the fix (see patch below) for the abs() issue and it > seemed to work for 4.1.1 on 64-bit. I'll apply the patch to head and > 2.5 and a test after 2.5 is out. Please also add it to 2.4. > Index: Objects/intobject.c > =

Re: [Python-Dev] Before 2.5 - More signed integer overflows

Neal Norwitz schrieb: > I'm getting a crash when running test_builtin and test_calendar (at > least) with gcc 4.1.1 on amd64. It's happening in pymalloc, though I > don't know what the cause is. I thought I tested with gcc 4.1 before, > but probably would have been in debug mode. Can't really ch

Re: [Python-Dev] Testsuite fails on Windows if a space is in the path

Jean-Paul Calderone schrieb: > You can find the quoting/dequoting rules used by cmd.exe documented on msdn: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_Parsing_C.2b2b_.Command.2d.Line_Arguments.asp > > Interpreting them is something of a challenge (m

Re: [Python-Dev] Testsuite fails on Windows if a space is in the path

Tim Peters schrieb: > These are the MS docs for cmd.exe's inscrutable quoting rules after /C: > > """ > If /C or /K is specified, then the remainder of the command line after > the switch is processed as a command line, where the following logic is > used to process quote (") characters: > >

Re: [Python-Dev] deja-vu .. python locking

Martin Devera schrieb: > RCU like locking > Solution I have in mind is similar to RCU. In Python we have quiscent > state - when a thread returns to main loop of interpreter. There might be a terminology problem here. RCU is read-copy-update, right? I fail to see the copy (copy data structure

Re: [Python-Dev] deja-vu .. python locking

Martin Devera schrieb: > It is based on assumption that an object is typicaly used by single > thread. You must lock it anyway just for case if another thread steps > on it. The idea is that each object is "owned" by a thread. Owner can > use its objects without locking. If a thread wants to use f

Re: [Python-Dev] deja-vu .. python locking

Martin Devera schrieb: > I measured it. Lock op in futex based linux locking is of the same > speed as windows critical section and it is about 30 cycles on my > P4 1.8GHz in uncontented case. > As explained in already mentioned http://www.linuxjournal.com/article/6993 > it seems due to pipeline fl

Re: [Python-Dev] Download URL typo

Michael Walter schrieb: > in case noone didn't notice yet: the "Windows MSI Installer" link at > http://www.python.org/download/releases/2.5/ points to Python 2.4! Why is this a problem? The link is actually correct: The MSI documentation is the same. Regards, Martin _

Re: [Python-Dev] Download URL typo

Martin v. Löwis schrieb: > Michael Walter schrieb: >> in case noone didn't notice yet: the "Windows MSI Installer" link at >> http://www.python.org/download/releases/2.5/ points to Python 2.4! > > Why is this a problem? The link is actually correct: The

Re: [Python-Dev] deja-vu .. python locking

Martin Devera schrieb: > Just from curiosity, would be a big problem removing refcounting and live > with garbage collection only ? I'm not sure if some parts of py code > depends on exact refcnt behaviour (I guess it should not). Now, this gives a true deja-vu. Python applications often rely on r

Re: [Python-Dev] Download URL typo

Steve Holden schrieb: > That links to > >http://www.python.org/download/releases/2.5/msi/ > > which *also* has a block at the top right whose last link is "Windows > MSI installer". Unfortunately that takes you to > >http://www.python.org/download/releases/2.5/msi/msi I noticed, but my

Re: [Python-Dev] Exceptions and slicing

Thomas Heller schrieb: > 1. The __str__ of a WindowsError instance hides the 'real' windows > error number. So, in 2.4 "print error_instance" would print > for example: > > [Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten. > > while in 2.5: > > [Error 22] Das Fens

Re: [Python-Dev] GCC 4.x incompatibility

Georg Brandl schrieb: > Is it noted somewhere that building Python with GCC 4.x results in > problems such as abs(-sys.maxint-1) being negative? Yes, it's in the README (although it claims problems only exist with 4.1 and 4.2; 4.0 seems to work fine for me). > I think this is something users may

Re: [Python-Dev] win32 - results from Lib/test - 2.5 release-maint

Please submit a patch to sf.net/projects/python. > - *.txt files for unicode tests are downloaded from internet - I don't > like this. What files specifcally? Could it be that you passed -u urlfetch or -u all? If so, then just don't. > - init_types is declared static in python/python-ast.c and

Re: [Python-Dev] test_itertools fails for trunk on x86 OS X machine

Jack Diederich schrieb: > Faced with the choice of believing in a really strange platform specific > bug in a commonly used routine that resulted in exactly the failure caused > by one of the two files being updated or believing a failure occurred in the > long chain of networks, disks, file syst

Re: [Python-Dev] Pep 353: Py_ssize_t advice

David Abrahams schrieb: > #if PY_VERSION_HEX < 0x0205 > typedef int Py_ssize_t; > #define PY_SSIZE_T_MAX INT_MAX > #define PY_SSIZE_T_MIN INT_MIN > #endif > > I just wanted to point out that this advice could lead to library > header collisions when multiple 3rd parties decide to fol

[Python-Dev] GCC patch for catching errors in PyArg_ParseTuple

I wrote a patch for the GCC trunk to add an __attribute__((format(PyArg_ParseTuple, 2, 3))) declaration to functions (this specific declaration should go to PyArg_ParseTuple only). With that patch, parameter types are compared with the string parameter (if that's a literal), and errors are reporte

Re: [Python-Dev] Pep 353: Py_ssize_t advice

David Abrahams schrieb: > b. We were using C++, which IIRC does not allow such redefinition You remember incorrectly. 16.3/2 (cpp.replace) says # An identifier currently defined as a macro without use of lparen (an # object-like macro) may be redefined by another #define preprocessing # directive

Re: [Python-Dev] GCC patch for catching errors in PyArg_ParseTuple

Giovanni Bajo schrieb: > A way not to maintain this patch forever would be to devise a way to make > format syntax "pluggable" / "scriptable". There have been previous discussions > on the GCC mailing lists. Perhaps. I very much doubt that this can or will be done, in a way that would support PyAr

Re: [Python-Dev] Maybe we should have a C++ extension for testing...

[EMAIL PROTECTED] schrieb: > One of our C++ gurus (that's definitely not me!) patched the Python source > to include at the top of Python.h. That seems to have solved our > problems, but seems to be a symptomatic fix. Indeed. The right fix is likely different, and relates to the question what AP

Re: [Python-Dev] Maybe we should have a C++ extension for testing...

[EMAIL PROTECTED] schrieb: > Martin> The problem you have is specific to Solaris, and specific to > Martin> using GCC on Solaris. > > So can we fix this in pyport.h or with suitable Configure script > machinations? Even though the current patch we're using is trivial I'd > really like to

Re: [Python-Dev] Need help with C - problem in sqlite3 module

Gerhard Häring schrieb: > Apparently at least gcc on Linux exports all symbols by default that are > not static. Correct. Various factors influence run-time symbol binding, though. > This creates problems with Python extensions that export > symbols that are also used in other contexts. For examp

Re: [Python-Dev] Need help with C - problem in sqlite3 module

Jeremy Kloth schrieb: > GCC's symbol visibility is supposed to address this exact problem. It would > be nice if -fvisibility=hidden was used to build Python (and its extensions) > by default on supported platforms/compilers. It shouldn't be much of an > issue wrt. exported symbols as they alr

Re: [Python-Dev] Pep 353: Py_ssize_t advice

David Hopwood schrieb: >>> (C++ allows restating of typedefs; if C allows it, that should be >>> something like): >> C also allows this; [...] > > This is nitpicking, since you agreed the change to the PEP, but are you > sure that C allows this? I was sure, but I was also wrong. Thanks for pointi

Re: [Python-Dev] Minipython

Milan Krcmar schrieb: > Can you give me any information to start with? I would prefer stripping > current version of Python rather than returning to a years-old (but > smaller) version and remembering what of the new syntax/functionality to > avoid. I would start with dropping support for dynamic

Re: [Python-Dev] List of candidate 2.4.4 bugs?

A.M. Kuchling schrieb: > Is anyone maintaining a list of candidate bugs to be fixed in 2.4.4? I don't think so. Also, I see little chance that many bugs will be fixed that aren't already. People should really do constant backporting, instead of starting backports when a subminor release is made.

Re: [Python-Dev] openssl - was: 2.4.4c1 October 11, 2.4.4 final October 18

Jim Jewett schrieb: > OpenSSL should probably be upgraded to 0.9.8.c (or possibly 0.9.7.k) > because of the security patch. > >http://www.openssl.org/ >http://www.openssl.org/news/secadv_20060905.txt > > I'm not sure which version shipped with the 2.4 windows binaries, but > externals (fo

Re: [Python-Dev] List of candidate 2.4.4 bugs?

A.M. Kuchling schrieb: > One reason I often don't backport a bug is because I'm not sure if > there will be another bugfix release; if not, it's wasted effort, and > I wasn't sure if a 2.4.4 release was ever going to happen. After > 2.4.4, will there be a 2.4.5 or is that too unlikely? The "tradi

Re: [Python-Dev] Tix not included in 2.5 for Windows

Christos Georgiou schrieb: > Does anyone know why this happens? I can't find any information pointing to > this being deliberate. It may well be that Tix wasn't included on Windows. I don't test Tix regularly, and nobody reported missing it during the beta test. Please submit a bug report to sf.

Re: [Python-Dev] Caching float(0.0)

Bob Ippolito schrieb: > My guess is that people do have this problem, they just don't know > where that memory has gone. I know I don't count objects unless I have > a process that's leaking memory or it grows so big that I notice (by > swapping or chance). Right. Although I do wonder what kind of

Re: [Python-Dev] Caching float(0.0)

Nick Coghlan schrieb: >> Right. Although I do wonder what kind of software people write to run >> into this problem. As Guido points out, the numbers must be the result >> from some computation, or created by an extension module by different >> means. If people have many *simultaneous* copies of 0.

Re: [Python-Dev] Caching float(0.0)

Kristján V. Jónsson schrieb: > Well, a lot of extension code, like ours use PyFloat_FromDouble(foo); > This can be from vectors and stuff. Hmm. If you get a lot of 0.0 values from vectors and stuff, I would expect that memory usage is already high. In any case, a module that creates a lot of copi

Re: [Python-Dev] Caching float(0.0)

Kristján V. Jónsson schrieb: > I can't see how this situation is any different from the re-use of > low ints. There is no fundamental law that says that ints below 100 > are more common than other, yet experience shows that this is so, > and so they are reused. There are two important difference

Re: [Python-Dev] Caching float(0.0)

Michael Hudson schrieb: >> 1. it is possible to determine whether the value is "special" in >>constant time, and also fetch the singleton value in constant >>time for ints; the same isn't possible for floats. > > I don't think you mean "constant time" here do you? Right; I really wonder

Re: [Python-Dev] Caching float(0.0)

Nick Craig-Wood schrieb: > Even if 0.0 is allocated and de-allocated 10,000 times in a row, there > would be no memory savings by caching its value. > > However there would be > a) less allocator overhead - allocation objects is relatively expensive > b) better caching of the value > c) less cache

Re: [Python-Dev] Caching float(0.0)

Nick Maclaren schrieb: >> The total count of floating point numbers allocated at this point is 985794. >> Without the reuse, they would be 1317145, so this is a saving of 25%, and >> of 5Mb. > > And, if you optimised just 0.0, you would get 60% of that saving at > a small fraction of the cost and

Re: [Python-Dev] Caching float(0.0)

Nick Maclaren schrieb: > That was the point of a previous posting of mine in this thread :-( > > You shouldn't, despite what IEEE 754 says, at least if you are > allowing for either portability or numeric validation. > > There are a huge number of good reasons why IEEE 754 signed zeroes > fit ext

Re: [Python-Dev] Caching float(0.0)

Nick Maclaren schrieb: > So distinguishing -0.0 from 0.0 isn't really in Python's current > semantics at all. And, for reasons that we could go into, I assert > that it should not be - which is NOT the same as not supporting > branch cuts in cmath. Are you talking about "Python the language speci

Re: [Python-Dev] Caching float(0.0)

Nicko van Someren schrieb: > It's only a semantic change on platforms that "happen to" use IEEE > 754 float representations, or some other representation that exposes > the sign of zero. Right. Later, you admit that this is vast majority of modern machines. > It would be instructive to unders

Re: [Python-Dev] Caching float(0.0)

[EMAIL PROTECTED] schrieb: > If C90 doesn't distinguish -0.0 and +0.0, how can Python? Can you give a > simple example where the difference between the two is apparent to the > Python programmer? Sure: py> x=-0.0 py> y=0.0 py> x,y (-0.0, 0.0) py> hash(x),hash(y) (0, 0) py> x==y True py> str(x)==

<    12   13   14   15   16   17   18   19   20   21   >