On 5/16/2013 1:18 AM, Ben Hoyt wrote:
Thanks, Benjamin -- that's great!
This may not be a python-dev question exactly. But on Windows, is it
safe to update to 2.7.5 on top of 2.7.4 (at C:\Python27) using the .msi
installer? In other words, will it update/add/remove all the files
correctly? What
This may not be a python-dev question exactly. But on Windows, is it
safe to update to 2.7.5 on top of 2.7.4 (at C:\Python27) using the .msi
installer? In other words, will it update/add/remove all the files
correctly? What if python.exe is running?
Yes, I update all the time, but without
Yes, I update all the time, but without python running.
FYI, I tried this just now with Python 2.7.4 running, and the
installer nicely tells you that some files that need to be updated
are currently in use ... the following applications are using files,
please close them and click Retry ...
16.05.13 08:20, Georg Brandl написав(ла):
On behalf of the Python development team, I am pleased to announce the
releases of Python 3.2.5 and 3.3.2.
The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip
and xml.sax modules. Details can be found in the changelogs:
It
Am 16.05.13 10:42, schrieb Ben Hoyt:
FYI, I tried this just now with Python 2.7.4 running, and the
installer nicely tells you that some files that need to be updated
are currently in use ... the following applications are using files,
please close them and click Retry ... python.exe (Process
2013/5/16 Serhiy Storchaka storch...@gmail.com:
16.05.13 08:20, Georg Brandl написав(ла):
On behalf of the Python development team, I am pleased to announce the
releases of Python 3.2.5 and 3.3.2.
The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip
and xml.sax
2013/5/16 Serhiy Storchaka storch...@gmail.com:
16.05.13 08:20, Georg Brandl написав(ла):
On behalf of the Python development team, I am pleased to announce the
releases of Python 3.2.5 and 3.3.2.
The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip
and xml.sax
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 15, 2013, at 06:06 PM, Tres Seaver wrote:
On 05/15/2013 04:58 PM, Barry Warsaw wrote:
This leads me to hypothesize that the bug is due to an as yet
unidentified race condition during installation of Python source code
on Ubuntu, which is
On May 16, 2013, at 08:33 AM, Nick Coghlan wrote:
Personally, I would be suspicious of developmental web services doing
auto-reloading while an installer is recompiling the world. I don't have
enough context to be sure how plausible that is as a possible explanation,
though.
It's possible that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 16.05.2013 17:40, schrieb Barry Warsaw:
We've since found a few cases where Python 3.3 pyc files are
probably corrupted, so that shoots down my theory about a race
condition on reading/writing pyc files, since 3.3 implements
atomic-rename and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 16, 2013, at 06:22 PM, Christian Heimes wrote:
Are you able to reproduce the issue? Perhaps you could use inotify to
track down file activity. It shouldn't affect timing much and you can
track if more than one process it writing to the same
On 05/16/2013 09:38 AM, Barry Warsaw wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On May 16, 2013, at 06:22 PM, Christian Heimes wrote:
Are you able to reproduce the issue? Perhaps you could use inotify to
track down file activity. It shouldn't affect timing much and you can
track
On May 16, 2013, at 09:44 AM, Ethan Furman wrote:
Is it happening on the same machines? If so, perhaps a daemon to monitor
those files and then scream and shout when one changes. Might help track
down what's going on at the time. (Yeah, that does sound like saying
'inotify' but with more
On Thu, May 16, 2013 at 11:04 AM, Barry Warsaw ba...@python.org wrote:
On May 16, 2013, at 09:44 AM, Ethan Furman wrote:
Is it happening on the same machines? If so, perhaps a daemon to monitor
those files and then scream and shout when one changes. Might help track
down what's going on at
On 5/16/2013 2:04 PM, Barry Warsaw wrote:
No, it's all different kinds of machines, at different times, on different
files. So far, there's no rhyme or reason to the corruptions that I can
tell.
If the corruption only happens on Ubuntu, that would constitute 'rhyme'
;-). I realize that
This reminds me of the following bug, which can happen when two
processes are both writing the .pyc file and a third is reading it.
First some background.
When writing a .pyc file, we use the following strategy:
- open the file for writing
- write a dummy header (four null bytes)
- write the .py
On Thu, May 16, 2013 at 5:19 PM, Guido van Rossum gu...@python.org wrote:
This reminds me of the following bug, which can happen when two
processes are both writing the .pyc file and a third is reading it.
First some background.
When writing a .pyc file, we use the following strategy:
-
I still suspect this might explain most of what Barry saw, if not all.
—
Sent from Mailbox
On Thu, May 16, 2013 at 2:36 PM, Brett Cannon br...@python.org wrote:
On Thu, May 16, 2013 at 5:19 PM, Guido van Rossum gu...@python.org wrote:
This reminds me of the following bug, which can happen
On Thu, May 16, 2013 at 5:40 PM, Guido van Rossum gvanros...@gmail.com wrote:
I still suspect this might explain most of what Barry saw, if not all.
Quite possible, especially since he is seeing more issues on 3.2 than
3.3. Just wanted to fill people in on how 3.3 onwards does things is
all.
On 5/16/2013 5:30 PM, Brett Cannon wrote:
On Thu, May 16, 2013 at 5:19 PM, Guido van Rossum gu...@python.org wrote:
This reminds me of the following bug, which can happen when two
processes are both writing the .pyc file and a third is reading it.
First some background.
When writing a .pyc
On Thu, May 16, 2013 at 11:19 PM, Guido van Rossum gu...@python.org wrote:
This reminds me of the following bug, which can happen when two
processes are both writing the .pyc file and a third is reading it.
First some background.
When writing a .pyc file, we use the following strategy:
-
Guido van Rossum wrote:
This reminds me of the following bug, which can happen when two
processes are both writing the .pyc file and a third is reading it.
... I think all the errors are
actually explainable from this scenario.
The second writer will still carry on to write a valid
.pyc file,
On Thu, May 16, 2013 at 3:27 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
This reminds me of the following bug, which can happen when two
processes are both writing the .pyc file and a third is reading it.
... I think all the errors are
actually explainable
On 17 May 2013 08:37, Guido van Rossum gu...@python.org wrote:
On Thu, May 16, 2013 at 3:27 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Guido van Rossum wrote:
This reminds me of the following bug, which can happen when two
processes are both writing the .pyc file and a third is
I have encountered what I believe to be a bug but I'm sure there is some
reason things are done as they are and I am hoping someone can shed some light
or confirm it is indeed a bug.
As a bit of background I have a c++ class that I use sip to generate python
bindings. The potential python
On 5/16/2013 4:17 PM, victor.stinner wrote:
summary: fix compilation on Windows
That fixed my problem with compiling 3.4, 32 bit, Win 7. Thanks.
But I cannot compile 3.3 python_d since May 6. In fact, there are more
errors now than 8 hours ago.
7 things failed to build instead of 5 (3 is
On Fri, May 17, 2013 at 9:17 AM, Matt Newell newe...@blur.com wrote:
I don't really understand what the fixup_slot_dispatchers function is doing,
but it does seem like there must be a bug either in what it's doing, or in
PyNumber_InPlaceAdd's handling of a NotImplemented return value from
On Fri, May 17, 2013 at 1:38 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, May 17, 2013 at 9:17 AM, Matt Newell newe...@blur.com wrote:
I don't really understand what the fixup_slot_dispatchers function is doing,
but it does seem like there must be a bug either in what it's doing, or in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/16/2013 06:59 PM, Nick Coghlan wrote:
3.2 uses __pycache__, so it should only potentially conflict within
the same version.
I haven't heard any rumblings about anything like this in Fedora or
RHEL, so my suspicions still lean towards a
On Thursday, May 16, 2013 08:41:32 PM you wrote:
On Fri, May 17, 2013 at 1:38 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, May 17, 2013 at 9:17 AM, Matt Newell newe...@blur.com wrote:
I don't really understand what the fixup_slot_dispatchers function is
doing, but it does seem like
30 matches
Mail list logo
