Greg Ewing schrieb:
> Blake Ross wrote:
>> C++ ensures that virtual bases
>> are only constructed once,
>
> As far as I remember, C++ ensures this by not calling
> the base constructors automatically at all, leaving
> you to explicitly call the constructors of all the
> virtual bases that you inhe
> Could you please point me to documentation about the new tracker? I want
> to study the best way to extract information from it (right now, I'm
> just pulling htmls from SF and parsing them, and that's not easy, fast,
> nor clean).
The tracker software is roundup. It's documentation is at
http:
Guido van Rossum schrieb:
> Sounds good to me. In 3.0 we should probably not have os.popen*(), nor
> the popen2 module at all, and do everything via the subprocess module.
> I wonder if we should even get rid of os.system(); then there should
> be a subprocess.system() instead. And do we even need
> Sure. os.fork() and the os.exec*() family can stay. But os.spawn*(),
> that abomination invented by Microsoft?
Right, I personally would not miss it. It's also not a system call,
but a library function on both Windows and Unix (the equivalent
of exposing fork would be to expose CreateProcessEx
Jason Orendorff schrieb:
> The lib ref claims that minidom supports DOM Level 1. Does anyone
> know what parts of Level 2 are not implemented?
Most prominently, minidom only implements the Core module of DOM
level 2, none of Views, Events, Style, Traversal and Range, or
HTML. Whether anything is
Jason Orendorff schrieb:
> The lib ref claims that minidom supports DOM Level 1. Does anyone
> know what parts of Level 2 are not implemented? I wasn't able to find
> anything offhand.
I now looked at it closely, and the only thing missing from DOM Level
2 Core (that I could find) is the Entit
> 1. In hindsight, what do you think about PEP 261, the Py_UNICODE_WIDE
> build option? On balance, has this been good, bad, or indifferent?
> What's good/bad about it?
Unlike MAL, I think it was good choice, primarily for political reasons.
People kept complaining that Python doesn't "really" s
> Why only 200 and 206?
This kind of question can often be answered through the revision
history. If you do 'svn annotate', you see that the line testing
for 206 was last changed in r36262. Comparing that to the
previous revision, you see that it before said
if r.status == 200:
and that am
> Right now, it's a bug. Do you think it's safe to fix this or will break
> much code?
Who am I to judge whether a fix will break much code? Personally, I
think it should treat all 2xx responses as success. Callers can
then still check the response code themselves if they need to.
Regards,
Marti
Oleg Broytmann schrieb:
> On Tue, Mar 27, 2007 at 04:12:06PM +, Facundo Batista wrote:
>> (didn't know about "annotate").
>
>It is also known under the name "blame"! ;)
Or "praise", depending on your mood :-)
Regards,
Martin
___
Python-Dev mail
Raymond Hettinger schrieb:
> [Stephen Hansen=
>> I just wanted to offer a gentle prod to see if a decision can be made;
>> if any decision requires an adjustment to patches, tests and documentation,
>> I'm willing to do them.
>
> We should get a pronouncement on this or else whatever goes out in
>> The problem is that os.kill only works in Unix and Macintosh. So,
>> there's a better way to do this? Or I shall check if I'm in one of those
>> both platforms and only execute the tests there?
>
> If you have a compilation of pywin32 (isn't it shipped by default in
> Python 2.5+?), you can kil
> I don't like the idea of rely on the private _handle and do:
>
> process = subprocess.Popen(...)
> ...
> subprocess.TerminateProcess(int(process._handle), -1)
>
> so, I'll end doing this:
>
> process = subprocess.Popen(...)
> ...
> handle =ctypes.windll.kernel32.OpenProcess(1, Fals
> Another difference I believe is that TerminateProcess on Windows
> doesn't kill the tree of processes like kill would.
I believe you are wrong here: kill on Unix would *not* kill the
tree of processes. Killing the parent process just does that:
kill the parent process.
Killing process groups i
> Martin, have you looked at this?
Only just now. I assume Andrew is right on these, although
one would have to verify each and every one, reading the spec,
reading the documentation, reading the source, testing, fixing.
Very time-consuming.
In any case, the *claim* certainly is that minidom supp
Raymond Hettinger schrieb:
> It looks like the release candidate has been held-up for a bit. If
> it is going to stay held-up for a few days, can we unfreeze it so
> some bugfixes can go in (fixing the +0/-0 problem, eliminating some
> segfaults, and fixing some exception code)?
No, the release b
> I didn't find getbuildinfo2.c in the source. Can some one tell me if
> I am missing some thing here? Are there any additional steps need to
> follow on windows?
It's a generated file. Search all build description files for that
file name to find out how it is generated, and then research why
g
Trent Mick schrieb:
> Is it generally accepted to just checkin obviously non-controversial
> fixes (*) (as long as there is no code freeze), or is it still preferred
> that I go through adding a patch to the SF tracker and getting review?
>
> Trent
>
> (*) In my case a tweak to the old VC6 Wind
> I'll be as brief as possible. The welcome message to this list suggested
> that I post a brief introduction of myself, so here it goes. I've been
> programming for about 10 years now (7 professionally). I would rank
> myself as a moderate programmer always looking to improve, and
> would like
> So if it's alright with the privledged folk - I'd like to commit
> these minor (and probably non-controversial) additions to the functools
> module.
Do you have commit access? What's your real name?
-1 on these additions. If lambda x:x would be added, it should be named
"identity", not "cat
Travis E. Oliphant schrieb:
> I'd like to ask for access to Python SVN so that I can keep the PEP 3118
> up to date as well as to eventually make the changes needed for
> implementing the extended buffer protocol.
>
> I will email my public SSH key to the appropriate place.
Please send it to me
> I tried to install the 64 Bit python version (2.5.1) and the 32 Bit
> version on my computer.
> But it is not possible because the installer complains that this
> version of python is already installed.
>
> Is it in general not possible to install both versions (in separate
> directories) ?
>
>
> I believe the idea is that if you run into a MemoryError, in particular
> on linux (whose allocator will give you a nonzero pointer well beyond
> what was actually available), you can't really trust the state of the
> interpreter, so it is expected that Python will be ending shortly.
> Forcing t
>>From Walter Beck <[EMAIL PROTECTED]> to webmaster:
>
>> I tried to install the AMD64 version of python on my new laptop, Vista
>> system. The installer said the processor was not correct. My processor
>> is a Turion64x2. 32 bit Python installed and ran fine. Is there a bug
>> in the in
> /* Temporarily disable .dll, to avoid conflicts between sqlite3.dll
>
> and the sqlite3 package. If this needs to be reverted for 2.5,
>
> some other solution for the naming conflict must be found.
>
>
>
> This temporary fix seems to have been forgotten. Isn‘t it time it
> I posted patch 1675951 a while ago that fixes a performance problem for
> small reads in the gzip stdlib module. It also removes the necessity for
> seeking while reading gzip files (allows reading from stdin now).
>
> Is there anything I can/have to do to get the patch in?
If you want to pri
Neal Norwitz schrieb:
> I just checked in a whitespace normalization change that was way too
> big. Should this task be automated?
>
> Assuming the answer is yes, these are the questions should be answered:
> 1) Which branches should this occur on: trunk, 2.5 (last release), 3k
> 2) Should the
> Well, there are editors that don't intelligently strip whitespace, so that
> people using them would be constantly pained by such a hook.
Those users can run reindent.py before checking in, or switch editors.
Regards,
Martin
___
Python-Dev mailing li
> But I would expect that this proposal will not pass the "buddy system"
> (which is a cute idea IMHO), as locking is counter to the Subversion
> Way.
>
> Also, you could accomplish what you want (a locked branch) with a
> pre-commit hook that just scans for paths in that branch.
I think "social
> Okay, attached is a pre-commit hook script for that purpose.
How does that deal with deletions? What do you think about
the attached alternative?
Regards,
Martin
#!/usr/bin/env python
from svn import repos, fs, core
import sys
from StringIO import StringIO
from reindent import Reindenter
repos
I have now installed a pre-commit hook that verifies that the code
being committed follows the formatting of reindent.py, for all files
under /python in the projects repository. Please let me know if this
causes any problems.
Regards,
Martin
___
Python-D
Khalid A. Bakr schrieb:
> 1. The bz2 archive ships with
> \Modules\collectionsmodule.c instead of the
> \Modules\_collectionsmodule.c used in the 2.5 SVN
> branch. In fact the collectionsmodule.c was removed
> some time ago.
Why do you say that?
http://svn.python.org/projects/python/branches/rele
> Or do I need to submit this through sourceforge?
Please do. Why are you checking for error 2, though,
if the error that occurs is 5?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
> I have a patch myself that creates an open file and uses that as the
> test. My reasoning is that pagefile.sys was chosen as a file that
> should always exist and be open, so its safe to test against, so we
> should just be testing against a fixture, instead. It is here, and if
> someone would re
> I'm sorry, but somehow I could not parse this. My understanding was
> that the unittest was meant to make sure an os.stat call would be
> successful on an open file, and that pagefile.sys was simply used as a
> known open file, which is no longer correct.
No. The unit test was meant to test tha
> After some googling it seems to me that this could
> likely be a User Rights Assignment issue of a systems
> file not an open file stat one, hence the Access
> denied error message (winerror 5) that I got in WinXP,
> as opposed to the File not found windows error
> (winerror 2) which one might ex
Khalid A. Bakr schrieb:
> For reference, this is the result of running the
> regression tests of the official Python 2.5.1 (final)
> on Win98. I think I saw it in the installtion screen
> that Python 2.5 is the last release to support Win98.
>
> Even though the unicode tests failing might be
> ex
> On Windows there is no guarantee that there will be a pagefile.sys on
> the C drive, or even that there exists a C drive. The test checking for
> the result of os.stat('C:\\pagefile.sys') is broken. Create a temporary
> file, open it with Python, then stat it (like you later suggest).
> Either
> Some record of this or documentation of just what conditions the tests
> are expecting to test against would probably be a good idea.
There is the sourceforge tracker item. If that is insufficient, feel
free to add more information.
Regards,
Martin
__
>> As I said - I'm not convinced that is indeed correct. Before accepting
>> a replacement test I would like confirmation that this test will fail
>> on 2.5.0. You might not get ERROR_SHARING_VIOLATION in all cases of
>> open files with 2.5.0.
>
> But i am running 2.5.0 during my entire writing of
> Since calling super with any
> arguments other than the exact same arguments you have received is
> nearly always wrong,
>
>
> Erm. Excuse me, but are you saying this code is wrong?
>
> class Rectangle:
> def __init__(self, width, height):
> self.width = width
>
>> And you saw your test pass? Then it is not a valid test case for
>> the
>> bug being test, because the bug is present in 2.5.0, so your
>> test case should fail there.
>>
>
> I think I'm a little confused. Are you saying the original test
> should fail for me or that the test I changed it to s
>> > The
>> > original test failed, my new one does not.
>>
>> Then this change is incorrect: the test should fail in 2.5.0.
>
> I think I don't get why the test _must_ fail. If it fails, I assumed
> something was broken.
Correct. That is the whole point of this patch: It fixes a bug in
2.5.0, an
Calvin Spealman schrieb:
> On 4/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Right. It shouldn't fail if the file is absent (it shouldn't
>> pass in that case, either, but regrtest has no support for INCONCLUSIVE
>> test outcomes).
>
&g
> After doing some research I found that it seems to be impossible to
> use CreateFile for a file that doesn't have SHARE_READ. I played with
> different combinations and with FLAG_BACKUP_SEMANTICS and nothing
> helped. However on Windows there's still a possibility to read
> attributes: use FindFi
Alexey Borzenkov schrieb:
> On 5/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> > After doing some research I found that it seems to be impossible to
>> > use CreateFile for a file that doesn't have SHARE_READ.
>> So what about GetFileAttrib
Kristján Valur Jónsson schrieb:
> Hm, I fail to see the importance of a special regression test for that
> peculiar file then with its special magical OS properties. Why not focus
> our attention on real, user generated files?.
Because real users really had real problems with this very real file,
> Would tests that use ctypes do do the open directly be acceptable ways
> of solving this?
If it solves it - sure.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
> I believe the GIL does not need to be held, but obviously Tim or someone
> with more memory experience should step in to say definitively.
>
> If you look at Include/pymem.h, PyMem_FREE gets defined as PyObject_FREE
> in a debug build. PyObject_Free is defined at _PyObject_DebugFree.
> That fu
> Any thoughts?
These should be fixed on a case-by-case basis. Please submit patches
to SF, and assign them to me. Changes should only go into 2.6.
As a principle, values that could exceed 2Gi in a hand-crafted Python
program should be Py_ssize_t. Values that can never exceed the int
range (becau
> If that is the case, I have two suggestions:
> a) Propagate the Windows idiom of sizeof(size_t) != sizeof(long) by keeping
> some sys.maxsize for list length, indices, etc.
> b) Elevate int to 64 bits on windows too!
> B is probably a huge change. Not only change PyIntObject but probably create
> Some more extensive testing is of course required, but it would seem
> that gains can be had from both going 64 bit and using PGO. I
> encourage you to take a look at the PGO build process. It is much
> simpler than before. I also think we ought to find out if we could
> start producing a proper
>> In general, I don't think it's a good idea to have literals
>> turn into mutable objects, since literals are normally perceived
>> as being constant.
>
> Does that mean you want list literals to be immutable too?
>
> lst = ['a', 'b', 'c']
> lst.append('d') # raises an error?
That's no
>> That's not a literal, it's a display. The difference is that
>> a literal denotes the same object every time it is executed.
>> A display creates a new object every time it is executed.
>> (another difference is that a display is a constructed thing
>> which may contain runtime-computed compone
> Now, why don't we change the semantics as follows: if a file with matching
> name
> exists (in import.c::find_module), but opening fails, ImportError is raised
> immediately with the concrete error message, and without trying the rest of
> sys.path. That shouldn't cause any working and sane setu
> How about an ImportWarning instead? That way people can have either
> have import halt immediately, or continue (with or without a message).
If I put my dislike of warnings aside: yes, that would also work.
Martin
___
Python-Dev mailing list
Python-D
Neal Norwitz schrieb:
> On 5/6/07, Calvin Spealman <[EMAIL PROTECTED]> wrote:
>> I lost the key I originally gave for commiting my summaries. Who do I
>> talk to about fixing that?
>
> Send your new key to pydotorg. -- n
In doing so, please indicate whether you just lost it, or somebody else
may
> Just curious why 2to3 would not replace range() with list(range())?
In most usages of range(), using the 3.0 range() will work just as
well, and be more efficient.
If I wanted to write code that works in both versions (which I
understand is not the 2to3 objective), then I would use range().
If
> "The Python Software Foundation officially supports the current
> stable major release and one prior major release. Currently, Python
> 2.5 and 2.4 are officially supported.
If you take "officially supported" to mean "there will be further bugfix
releases", then no: 2.4 is not anymore officia
> However, I understand the other reason (inclusion of non-ASCII
> characters in raw strings) and I reluctantly agree with it.
I actually disagree with that. It is fairly easy to include non-ASCII
characters in a raw Unicode string - just type them in. Or, if that
fails, use string concatenation w
>> I actually disagree with that. It is fairly easy to include non-ASCII
>> characters in a raw Unicode string - just type them in.
>
> That violates the convention used in many places that source code
> should only contain printable ASCII, and all non-ASCII or unprintable
> characters should be w
> We supposedly have a standard for additions to the standard lib. I cannot
> think of any other module being admitted with what amounts to an unlimited
> blank check for further additions.
xml.dom.minidom, xml.sax, posix, htmlentitydefs, Tkinter.
Regards,
Martin
__
Greg Ewing schrieb:
> Martin v. Löwis wrote:
>> why should you be able to get a non-ASCII character
>> into a raw Unicode string?
>
> The analogous question would be why can't you get a
> non-Unicode character into a raw Unicode string.
No, that would not be analogo
> This is what prompted my question, actually: in Py3k, in the
> str/unicode unification branch, r"\u1234" changes meaning: before the
> unification, this was an 8-bit string, where the \u was not special,
> but now it is a unicode string, where \u *is* special.
That is true for non-raw strings al
> Using double backslashes won't cause that reaction:
>
> os.stat("c:\\windows\\system32\\user32.dll")
Please refer to the subject. We are talking about raw strings.
>> Windows path names are one of the two primary applications of raw
>> strings (the other being regexes).
>
> IMHO the primary u
> BTW, there's an easy work-around for this special case:
>
> os.stat(os.path.join(r"c:\windows\system32", "user32.dll"))
No matter what the decision is, there are always work-arounds.
The question is what language suits the users most. Being
able to specify characters by ordinal IMO has much les
> "The Python Software Foundation officially supports the current
> stable major release of Python. By "supports" we mean that the PSF
> will produce bug fix releases of this version, currently Python 2.5.
> We may release patches for earlier versions if necessary, such as to
> fix securi
>> Why do you need such a statement?
>
> I think Fedora might want it, per recent discussions on fedora-devel-list.
In that case, I would rather have somebody official of the Fedora list
state the request explicitly, than basing it on hearsay.
> "The Python Software Foundation maintains the curr
> Python can dispose of a raft of bugs present only in the older
> versions with WONTFIX at release of a new stable version (after
> double-checking that they don't exist in the stable version).
I'm all in favor of formalizing a policy of when Python releases
are produced, and what Python releases
everything, so
it is essential that there are very very few new patches in each
security release.
Please let me know what you think.
Regards,
Martin
PEP: XX
Title: Maintenance of Python Releases
Version: $Revision$
Last-Modified: $Date$
Author: Martin v. Löwis <[EMAIL PROTECTED]>
Discussio
> > I'm all in favor of formalizing a policy of when Python releases
> > are produced, and what Python releases, and what kinds of changes
> > they may contain. However, such a policy should be addressed
> > primarily to contributors, as a guidance, not to users, as
> > a promise. So I have pr
> I clicked on the tracker link out of curiosity noticed that the
> tracker has been spammed -- issues 1028, 1029 and 1030 are all spam
> (1028 seems a test by the spammer).
>
> These issues should be deleted and their creator's accounts disabled.
(Notice that the spammer hasn't been as successfu
> * without the Unicode escapes, the only way to put non-ASCII
> code points into a raw Unicode string is via a source code encoding
> of say UTF-8 or UTF-16, pretty much defeating the original
> requirement of writing ASCII code only
That's no problem, though - just don't put the Unicode ch
> I don't understand the point of a "security release" made up to a year
> after commit, especially in view of the first quoted paragraph.
The objective is to reduce load for the release manager. Any kind of
release that is worth anything takes several hours to produce, in
my experience (if it c
> In the meantime (thinking out loud here), would it be possible to keep
> search engines from seeing a submission or an edit until a trusted person
> has had a chance to approve it?
It would be possible, but I would strongly oppose it. A bug tracker
where postings need to be approved is just unac
> My point is that if those steps are required for a release, the branch
> is not "immediately releasable" by my standards if they're not done.
> Especially if a release candidate is required.
But how does that help in practice? If you find after the release that
the branch was not in a releasable
> We should decide what's right for security releases and then assess
> whether we need to recruit in order to perform that activity the way we
> want to.
I disagree. If you would like to see a certain policy implemented, you
need to locate the volunteers *first*, and only then you can start
setti
> Still, I'm in agreement with you that the repository holds the security
> patches and that the tarballs are a convenience. They are an important
> convenience though, so I would say that they should be released in a
> timely manner after the commit of the security patches. I don't think
> we ne
> > In effect, this is what the PEP says. That's intentional (i.e. it
> > is my intention - others may have different intentions). It's the
> > repository that holds the security patches; the tarballs (and the
> > version number bumps) are just a convenience.
>
> It's not the intentions of th
> | I think we would need to restrict the total number of releases
> | made per year. The one-year limit may be debatable, and immediate
> | releases might be possible, as long as there is some provision
> | that releases are not made at a too-high rate.
>
> I would agree, but...
> has there been
> You can always can make a checkout of the security-manteined-only
> branch, if you're in a particular hurry (maybe the PEP should say
> something about this).
Indeed. I can add explicit wording to say that.
Regards,
Martin
___
Python-Dev mailing list
Aahz schrieb:
> On Mon, May 14, 2007, "Martin v. L?wis" wrote:
>> Skip(?):
>>> In the meantime (thinking out loud here), would it be possible to keep
>>> search engines from seeing a submission or an edit until a trusted person
>>> has had a chance to approve it?
>> It would be possible, but I woul
> I'm reluctant to mention the name of one particular tool I'm aware
> of, but as well as the above, it also has OCR to defeat CAPTCHA, and
> automatically creates throw-away e-mail accounts with a range of free
> web-mail providers for registration purposes.
Right. We considered CAPTCHA, but some
> I'm looking at Python/marshal.c and there are a lot of places that
> don't support sequences that are larger than would fit into size(int).
> I looked for marshal referenced in the PEP and didn't find anything.
> Was this an oversight or intentional?
These changes were only made after merging th
> If we anticipate users rather than programmers to register (as if so, it
> would be nice to collect that info to formulate sensible responses), then
> questions like
> The orb that shines in the sky during the day.
This question I could not answer, because I don't know what an orb is
(it'
Ah, forgot to mention that a browsable version of the
branch is at
http://svn.python.org/view/python/branches/ssize_t/?rev=42382
Unfortunately, you cannot check out that URL. OTOH,
you can checkout "peg revisions" (I have no clue what a
peg is)
http://svn.python.org/projects/python/branches/[EMA
> My underlying point: seeing porno spam on the practice site gave me a bad
> itch both because I detest spammers in general and because I would not want
> visitors turned off to Python by something that is completely out of place
> and potentially offensive to some. So I am willing to help us
> The point of this message is to see if anyone thinks 2000 is
> unreasonable. It could probably be raised, but I'm not going to try
> it since I don't have access to a Windows box. Testing this remotely
> sucks.
If this turns out ever to be a limitation, I would challenge the
reporter to rewrit
> * New method (proposed by Shane Holloway): s1.isdisjoint(s2).
> Logically equivalent to "not s1.intersection(s2)" but has an
> early-out if a common member is found. The speed-up is potentially
> large given two big sets that may largely overlap or may not
> intersect at all. There is also a m
> Do we know how these spam comments entered the system?
Through the web site. Submission through email is not an
issue: you need to use a registered email address, and
those are hard to guess.
> And has there been any spam submitted since that point?
One day after the tracker was renamed to bu
>> I'd rather see iterator versions of the set operations.
>
> Interesting idea. I'm not sure I see how to make it work.
> If s|t returned an iterator, then how would s|t|u work?
I don't think s.union(t) should return an iterator, if for
no other reason than compatibility. Instead, there might
Brett Cannon schrieb:
> For removing extension modules from the build process on Windows, do you
> just delete the File entry from PCbuild/pythoncore.vcproj?
No, you also need to remove the entry from PC/config.c.
Regards,
Martin
___
Python-Dev mailing
>> For example, I keep running into the issue that distutils doesn't
>> currently support parallel builds. I have been pondering supporting
>> "-j" for building extensions, using both unbounded "-j" and the GNU make
>> style -jN build server. However, I know that the patch will be rejected,
>> so I
Am 03.12.2010 23:48, schrieb Éric Araujo:
>> But I'm not interested at all in having it in distutils2. I want the
>> Python build itself to use it, and alas, I can't because of the freeze.
> You can’t in 3.2, true. Neither can you in 3.1, or any previous
> version. If you implement it in distutil
Am 03.12.2010 23:55, schrieb Dima Tisnek:
> How hard or reasonable would it be to free memory pages on OS level?
Very easy. Python already does that.
> [pcmiiw] Gabage collection within a generation involves moving live
> objects to compact the generation storage. This separates the memory
> regi
> q1 are generations placed in separate memory regions, or are all
> generations in one memory regions and there is a pointer that
> signifies the boundary between generations?
You should really start reading the source code. See Modules/gcmodule.c.
To answer your question: neither, nor. All obje
> Oh my bad, I must've confused python with some research paper.
> Unique id is not so hard to make without an address.
>
> While on this topic, what is the real need for unique ids?
They are absolutely needed for mutable objects. For immutable ones,
it would be ok to claim that they are identica
Am 04.12.2010 00:35, schrieb Terry Reedy:
> On 12/3/2010 5:52 PM, "Martin v. Löwis" wrote:
>> Am 03.12.2010 23:48, schrieb Éric Araujo:
>>>> But I'm not interested at all in having it in distutils2. I want the
>>>> Python build itself to use it,
Am 04.12.2010 01:00, schrieb Terry Reedy:
> On 12/3/2010 6:46 PM, "Martin v. Löwis" wrote:
>
>>> and stable as D1. I do not know what Martin means by 'integrate' (other
>>> than that he be able to use it to build Python)
>>
>> That th
> Am I still missing something?
Apparently. The hole C API would break if objects would move in memory.
Since they have to stay at fixed addresses, it's easy enough to use the
address as ID. There is no problem to be solved here.
Regards,
Martin
___
Pyt
2101 - 2200 of 5277 matches
Mail list logo
