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
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
Greg Ewing wrote:
> Martin Devera wrote:
>
>> Greg, what change do you have in mind regarding that "3 instruction
>> addition" to refcounting ?
>
> I don't have any change in mind. If even an atomic inc
> is too expensive, it seems there's no hope for us.
Just from curiosity, would be a big prob
Martin v. Löwis wrote:
> 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 MSI
>>documen
Greg Ewing wrote:
> Steve Holden wrote:
>
>
>>This does, of course, assume that you're importing modules from the
>>filestore, which assumption is no longer valid in the presence of PEP
>>302 importers.
>
>
> Well, you need to allow for a sufficiently abstract
> notion of "filesystem".
>
For
Steve Holden wrote:
> This does, of course, assume that you're importing modules from the
> filestore, which assumption is no longer valid in the presence of PEP
> 302 importers.
Well, you need to allow for a sufficiently abstract
notion of "filesystem".
I haven't really thought it through in
Martin Devera wrote:
> Greg, what change do you have in mind regarding that "3 instruction
> addition" to refcounting ?
I don't have any change in mind. If even an atomic inc
is too expensive, it seems there's no hope for us.
--
Greg
___
Python-Dev mai
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 MSI
> documentation is the same.
I reconsid
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
_
Hiho,
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!
Regards,
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyth
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
Anthony Baxter wrote:
> Could people please treat the release25-maint branch as frozen for a day or
> two, just in case we have to cut an ohmygodnononokillme release? Thanks,
Otherwise to be known as 2.5.005?
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC
Could people please treat the release25-maint branch as frozen for a day or
two, just in case we have to cut an ohmygodnononokillme release? Thanks,
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Pyt
It's been nearly 20 months since the last major release
of Python (2.4), and 5 months since the first alpha
release of this cycle, so I'm absolutely thrilled to be
able to say:
On behalf of the Python development team
and the Python community, I'm happy to
announce the FINAL release of
Greg Ewing wrote:
> Armin Rigo wrote:
>
>
>>My (limited) understanding of the motivation for relative imports is
>>that they are only here as a transitional feature. Fully-absolute
>>imports are the official future.
>
>
> Guido does seem to have a dislike for relative imports,
> but I don't re
Josiah Carlson wrote:
> As it stands, in order to "work around" this particular feature, one
> would need to write a 'loader' to handle importing and/or main() calling
> in subpackage1/module1.py .
Yup. At the moment, you can rely on PEP 328, or an PEP 338, but not both at
the same time. This was
On Tue, Sep 19, 2006 at 03:46:59PM +1200, Greg Ewing wrote:
> There really shouldn't be
> any such thing as sys.path -- the view that any
> given module has of the package namespace should
> depend only on where it is
I do not understand this. Can you show an example? Imagine I have two
servers
> Ah, I think I understand now. First the minor critique: I believe
> the locking algorithm isn't thread-safe:
>
> while (ob->owner_thread != self_thread()) {
>unlock_mutex(thread_mutex[self_thread()])
> // wait for owning thread to go to quiscent state
>lock_mutex(thread_m
Greg Ewing wrote:
> Martin Devera wrote:
>
>> As I've written in "Big reader lock" paragraph of the original
>> proposal, these
>> objects could be handled by not blocking in read path
>
> But as was just pointed out, because of refcounting,
> there's really no such thing as read-only access to
19 matches
Mail list logo
