Re: [Python-Dev] fixing tests on windows

[Tim Golden]

Terry Reedy wrote:
> If the testdir disallows the search indexer, then there should be no need 
> to disable Windows Search Service.  If privatizing the dir kept other 
> programs out, then likewise.
> 
> | Or were you suggesting that there is some programmatic way for the
> | test suite to create directories that disallow the Search Service,
> | etc.?
> 
> I suspect, but do not know, that the dialog box effects changes through 
> user-programmable interfaces.  So while I would start with manual changes 
> to see if that solves the problem, I presume there must be a system call 
> for changing dir attributes.

The problem is, I think, that it isn't just the Indexing Service
which generates this issue. TortoiseSVN is well known for doing
the same thing, and there could be now and potentially will be
in the future other programs. I don't think that hunting down
and turning off their interference case by case is a viable
solution in the long-term. Although it would obviously be a
way forward in the short term, _faute de mieux_.

[Tony Nelson]
> I'd think that files and directories created in the TEMP
> directory would normally not be indexed on any OS, including
> MSWindows. But this is just a guess.

I'm inclined to think you're right. And a first pass I had at
producing a solution simply used tempfile to do everything.
Unfortunately that's far more invasive than I was really
comfortable with at the time: at the very least, you have
to patch several tests which fail if there's an (escaped)
backslash in the path.

However, it's clear that my attempt to cause the minimum damage
isn't enough to clear the problem 100%. So I think the next move
is indeed to turn test_support.TESTFN into a function (in some
way) which generates a unique tempfile reference, possibly with
a context manager to clean up. Or something.

The complication is that, while most test simply want a handy
file to exist or be written to, and don't really care what
happens afterwards, some tests are testing the very mechanism
of creating/deleting a file etc. So a wholesale replacement
isn't necessarily straightforward.

On we go.

TJG

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] fixing tests on windows

[Tim Golden]

Trent Nelson wrote:
> 1.  For a given python[_d].exe, always use the same test directory, 
> but hash it against the entire python process path such that it's 
> unique only for a given python instance.

This is to guard against several build runs in parallel, presumably?

> 2.  Make sure every time a test wants a temp file, it gets a 
> unique one in this directory.  Sounds like your TESTFN 
> modification would take care of this for those tests using 
> TESTFN

Not quite; at present TESTFN is constant for one set of test runs. 
It would need to be a function call to change for every test
within the run.

; if TESTFN is the preferred approach then any other 
> tests using tempfile or hardcoding file names would then be 
> changed to use this instead.

Part of the problem (for me): I don't know if it is "the preferred
approach", merely that it's there and widely but not universally
used and is the likely cause of the locking problems we're seeing.
If anything's rolling its own tempfile solution, I'm inclined to
leave that alone. As someone's pointed out elsewhere, the temp
directories are almost certainly not monitored.

> 3.  In order to address tests that either call the 
> test_support methods for removing files/directories, 
> or those that call os.(unlink|remove), do what ever 
> needs to be done to make these no-ops on Windows if an 
> error occurs.

I'm reluctant to monkey patch os.(unlink|remove). I'd rather
provide and encourage the use of a test_support.remove_test_file
function, or even a context manager which did the same, failing
silently if needs be.

> 4.  At the end of the regrtest.py run, create a suspended arbitrary 
> process (i.e. explorer.exe), hijack the main thread context of the 
> process and inject a routine (i.e. overwrite the thread context's 
> instruction pointers) that takes care of removing the temporary 
> directory that was used for testing -- patiently re-trying if 
> any failures occur until all rogue processes also accessing the 
> file(s) stop doing so.  Resume the thread before exiting python.

OK. That was scary. (Interesting site, though).

[... snip ...]

> Guess it all depends on how much effort we want to put into cleaning 
> up our test directory really -- just ensuring tests get a clean area 
> and unique file names each run is the easy part.

Yes. I'm trying desperately hard to stick to a narrow remit of
getting tests to run consistently in the face of messy file-locking
semantics under Windows. I really don't want to wade into the minor
minefield of making all the tests run with consistent temp file
semantics. But I may have to.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] fixing tests on windows

[Trent Nelson]

I agree with Tim, you can jump through as many hoops as you want (setting 
directories private, using %TEMP% exclusively, etc), but I doubt anything is 
going to change the behaviour of things like virus scanners, for example.

Tim, let me know if you need help with anything, perhaps we could set up a 
temporary branch outside of trunk to play around with various approaches to see 
what works best.  This'll ensure we don't adversely affect the main buildbots, 
but also give us the option to get different Windows boxes to build our test 
branch on demand.

Trent.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tim Golden [EMAIL 
PROTECTED]
Sent: 04 April 2008 04:04
Cc: python-dev@python.org
Subject: Re: [Python-Dev] fixing tests on windows

Terry Reedy wrote:
> If the testdir disallows the search indexer, then there should be no need
> to disable Windows Search Service.  If privatizing the dir kept other
> programs out, then likewise.
>
> | Or were you suggesting that there is some programmatic way for the
> | test suite to create directories that disallow the Search Service,
> | etc.?
>
> I suspect, but do not know, that the dialog box effects changes through
> user-programmable interfaces.  So while I would start with manual changes
> to see if that solves the problem, I presume there must be a system call
> for changing dir attributes.

The problem is, I think, that it isn't just the Indexing Service
which generates this issue. TortoiseSVN is well known for doing
the same thing, and there could be now and potentially will be
in the future other programs. I don't think that hunting down
and turning off their interference case by case is a viable
solution in the long-term. Although it would obviously be a
way forward in the short term, _faute de mieux_.

[Tony Nelson]
> I'd think that files and directories created in the TEMP
> directory would normally not be indexed on any OS, including
> MSWindows. But this is just a guess.

I'm inclined to think you're right. And a first pass I had at
producing a solution simply used tempfile to do everything.
Unfortunately that's far more invasive than I was really
comfortable with at the time: at the very least, you have
to patch several tests which fail if there's an (escaped)
backslash in the path.

However, it's clear that my attempt to cause the minimum damage
isn't enough to clear the problem 100%. So I think the next move
is indeed to turn test_support.TESTFN into a function (in some
way) which generates a unique tempfile reference, possibly with
a context manager to clean up. Or something.

The complication is that, while most test simply want a handy
file to exist or be written to, and don't really care what
happens afterwards, some tests are testing the very mechanism
of creating/deleting a file etc. So a wholesale replacement
isn't necessarily straightforward.

On we go.

TJG

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/tnelson%40onresolve.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] __eq__ vs hash

[Ralf Schmitt]

Hi all,

the news file for python 2.6 does not mention that you need to define
__hash__ in case you define __eq__ for a class.
This breaks some code (for me: mercurial and pyparsing).
Shouldn't this be documented somewhere (I also cannot find it in the
whatsnew file).

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/M

[Trent Nelson]

> I don't like the part where the solution kills the Python process during
> a rebuild. It's too surprising for the user.

Hmmm.  When you say rebuild, I assume you mean the change I made to the 
pythoncore project's pre-link step to call kill_python.exe, and not to the 
post-build step of kill_python that runs itself?  Personally, when I'm doing 
development, if I've got the pcbuild\python_d.exe console open, it's usually to 
test one liners, I'm not using it to do anything important.  If I forget to 
close it before I kick off a build, it's annoying running into errors at the 
link stage, I'd certainly prefer the build system to kill off anything that'll 
inhibit a successful link before actually linking.

What do others that do Windows development think?  I don't have a problem 
changing the build behaviour if the approach I've taken is generally disliked.

   Trent.


From: Christian Heimes [EMAIL PROTECTED]
Sent: 04 April 2008 09:25
To: [EMAIL PROTECTED]; Trent Nelson
Subject: Re: r62129 - in python/trunk: PCbuild/debug.vsprops   
PCbuild/kill_python.c PCbuild/kill_python.vcproj   PCbuild/pcbuild.sln 
PCbuild/pythoncore.vcproj   PCbuild/release.vsprops Tools/buildbot/Makefile   
Tools/buildbot/build-amd64.bat Tools/buildbot/bui...

trent.nelson schrieb:
> Author: trent.nelson
> Date: Thu Apr  3 20:27:06 2008
> New Revision: 62129
>
> Added:
>python/trunk/PCbuild/kill_python.c   (contents, props changed)
>python/trunk/PCbuild/kill_python.vcproj
> Removed:
>python/trunk/Tools/buildbot/Makefile
>python/trunk/Tools/buildbot/kill_python.bat
>python/trunk/Tools/buildbot/kill_python.c
>python/trunk/Tools/buildbot/kill_python.mak
> Modified:
>python/trunk/PCbuild/debug.vsprops
>python/trunk/PCbuild/pcbuild.sln
>python/trunk/PCbuild/pythoncore.vcproj
>python/trunk/PCbuild/release.vsprops
>python/trunk/Tools/buildbot/build-amd64.bat
>python/trunk/Tools/buildbot/build.bat
>python/trunk/Tools/buildbot/buildmsi.bat
> Log:
> Reimplement kill_python.  The existing version had a number of flaws, namely, 
> it didn't work for x64 and it wasn't precise about which python_d.exe it was 
> killing -- it just killed the first one it came across that happened to have 
> 'pcbuild\python_d.exe' or 'build\python_d.exe' in it's path.  The new version 
> has been rewritten from the ground up and now lives in PCbuild, instead of 
> Tools\buildbot, and it has also been incorporated into the Visual Studio 
> solution (pcbuild.sln) as 'kill_python'.  The solution has also been altered 
> such that kill_python is called where necessary in the build process in order 
> to prevent any linking errors due to open file locks.  In lieu of this, all 
> of the existing bits and pieces in Tools\buildbot that called out to 
> kill_python at various points have also be
>  en removed as they are now obsolete.  Tested on both Win32 and x64.

I don't like the part where the solution kills the Python process during
a rebuild. It's too surprising for the user.

Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/M

[Amaury Forgeot d'Arc]

On Fri, Apr 4, 2008 at 12:57 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
>
>  > I don't like the part where the solution kills the Python process during
>  > a rebuild. It's too surprising for the user.
>
>  Hmmm.  When you say rebuild, I assume you mean the change I made to the 
> pythoncore project's pre-link step to call kill_python.exe, and not to the 
> post-build step of kill_python that runs itself?  Personally, when I'm doing 
> development, if I've got the pcbuild\python_d.exe console open, it's usually 
> to test one liners, I'm not using it to do anything important.  If I forget 
> to close it before I kick off a build, it's annoying running into errors at 
> the link stage, I'd certainly prefer the build system to kill off anything 
> that'll inhibit a successful link before actually linking.
>
>  What do others that do Windows development think?  I don't have a problem 
> changing the build behaviour if the approach I've taken is generally disliked.

I agree with Christian: in interactive sessions, the F7 key should not
kill my running testsuite... I prefer the linker errors.
Please do this only for buildbot builds!
Or maybe have it controlled by an enviroment variable.

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Annotations support in python

[Benjamin Peterson]

On Thu, Apr 3, 2008 at 11:49 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote:

> The release schedule for 2.6/3.0 is
> http://www.python.org/dev/peps/pep-0361/
> 3.0 will have the feature, 2.6 may or may not.

There is an issue for this: http://bugs.python.org/issue2331

>
>
> n
>
> On Thu, Apr 3, 2008 at 4:47 AM, Heshan Suriyaarachchi
> <[EMAIL PROTECTED]> wrote:
> >  Hi,
> >  I need to work with annotations as it is said in [1]. Currently I
> am
> > using python 2.5.1. I would like to know whether the
> > next release of python will support this feature. If the next version
> > support this feature I would like to know when are you
> >  planning to release it. I used the __future__ module but I could not
> get
> > the annotations with it.
> >
> > [1] -  http://www.python.org/dev/peps/pep-3107/
> >
> > Thanx
> > Heshan Suriyaarachchi
> >
> >
> >
> > ___
> >  Python-Dev mailing list
> >  Python-Dev@python.org
> >  http://mail.python.org/mailman/listinfo/python-dev
> >  Unsubscribe:
> > http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com
> >
> >
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6a2 and 3.0a4

[Gerhard Häring]

Hello Barry,

Great job with the releases!

Barry Warsaw wrote:
> On behalf of the Python development team and the Python community, I'm  
> happy to announce the second alpha release of Python 2.6, and the  
> fourth alpha release of Python 3.0. [...]

In case you don't know already, the website is not fully updated, yet:

http://www.python.org/download/releases/2.6/

Top of the page says "2.6a1" instead of "2.6a2".

This file is apparently not yet updated for 2.6alpha2.

http://www.python.org/download/releases/2.6/NEWS.txt


For the 3.0 version:

Top of the page still says "3.0a3".

Cheers,

-- Gerhard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Guido van Rossum]

On Fri, Apr 4, 2008 at 2:46 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> the news file for python 2.6 does not mention that you need to define
> __hash__ in case you define __eq__ for a class.
> This breaks some code (for me: mercurial and pyparsing).
> Shouldn't this be documented somewhere (I also cannot find it in the
> whatsnew file).

Well, technically this has always been the requirement.

What specific code breaks? Maybe we need to turn this into a warning
in order to be more backwards compatible?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Ralf Schmitt]

On Fri, Apr 4, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Fri, Apr 4, 2008 at 2:46 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> > the news file for python 2.6 does not mention that you need to define
> > __hash__ in case you define __eq__ for a class.
> > This breaks some code (for me: mercurial and pyparsing).
> > Shouldn't this be documented somewhere (I also cannot find it in the
> > whatsnew file).
>
> Well, technically this has always been the requirement.
>

> What specific code breaks? Maybe we need to turn this into a warning
> in order to be more backwards compatible?
>

I don't feel like digging into mercurial or pyparsing code currently. sorry.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Guido van Rossum]

Understood. Neither do I. :-) But maybe you could get the authors of
that code into this discussion?

On Fri, Apr 4, 2008 at 7:53 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
>
>
>
> On Fri, Apr 4, 2008 at 4:38 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > On Fri, Apr 4, 2008 at 2:46 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> > > the news file for python 2.6 does not mention that you need to define
> > > __hash__ in case you define __eq__ for a class.
> > > This breaks some code (for me: mercurial and pyparsing).
> > > Shouldn't this be documented somewhere (I also cannot find it in the
> > > whatsnew file).
> >
> > Well, technically this has always been the requirement.
> >
> >
> > What specific code breaks? Maybe we need to turn this into a warning
> > in order to be more backwards compatible?
> >
>
> I don't feel like digging into mercurial or pyparsing code currently. sorry.
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Jason Orendorff]

On Fri, Apr 4, 2008 at 9:38 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>  What specific code breaks? Maybe we need to turn this into a warning
>  in order to be more backwards compatible?

I looked at Mercurial.

It doesn't use __hash__ at all.  It uses __eq__ in two files, three total uses:
http://hg.intevation.org/mercurial/crew/file/6c4e12682fb9/mercurial/commands.py
http://hg.intevation.org/mercurial/crew/file/6c4e12682fb9/mercurial/context.py

-j
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Tracker Issues

[Tracker]

ACTIVITY SUMMARY (03/28/08 - 04/04/08)
Tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 1799 open (+34) / 12577 closed (+13) / 14376 total (+47)

Open issues with patches:   536

Average duration of open issues: 716 days.
Median duration of open issues: 1257 days.

Open Issues Breakdown
   open  1774 (+34)
pending25 ( +0)

Issues Created Or Reopened (47)
___

Add gettext.pgettext() and variants support  03/29/08
   http://bugs.python.org/issue2504created  genepi
   

Easier creation of _ast nodes03/29/08
CLOSED http://bugs.python.org/issue2505created  georg.brandl  
   patch   

Line tracing of continue after always-taken if is incorrect  03/29/08
CLOSED http://bugs.python.org/issue2506created  nedbat
   

Exception state lives too long in 3.003/29/08
   http://bugs.python.org/issue2507created  pitrou
   patch   

When you create a file using file(path, "w") if the filename is  03/29/08
CLOSED http://bugs.python.org/issue2508created  kobipe3   
   

Bazaar ignore file   03/29/08
CLOSED http://bugs.python.org/issue2509created  benjamin.peterson 
   patch, easy 

Bazaar ignore file   03/29/08
   http://bugs.python.org/issue2510created  benjamin.peterson 
   patch, easy 

Give AST's excepthandler proper attributes   03/29/08
CLOSED http://bugs.python.org/issue2511created  georg.brandl  
   patch   

decide what to do with gettext API   03/29/08
   http://bugs.python.org/issue2512created  benjamin.peterson 
   patch   

64bit cross compilation on windows   03/30/08
   http://bugs.python.org/issue2513created  mhammond  
   patch, 64bit

new AST init breaks on Store and other fieldless Nodes   03/30/08
CLOSED http://bugs.python.org/issue2514created  aronacher 
   patch   

Segfault while operating on closed sqlite3 cursor.   03/30/08
   http://bugs.python.org/issue2515created  pjdavis   
   

Instance methods are misreporting the number of arguments03/30/08
   http://bugs.python.org/issue2516created  belopolsky
   patch   

Error when printing an exception containing a Unicode string 03/31/08
   http://bugs.python.org/issue2517reopened benjamin.peterson 
   patch   

smtpd.py to handle huge email03/31/08
   http://bugs.python.org/issue2518created  kawai 
   patch   

Typing 'modules' in the interactive help system fails when impor 03/31/08
   http://bugs.python.org/issue2519created  dennis
   

macerrors.py cannot be imported due to non-ascii characters in c 03/31/08
   http://bugs.python.org/issue2520created  thecube   
   patch   

ABC caches should use weak refs  03/31/08
   http://bugs.python.org/issue2521created  amaury.forgeotdarc
   26backport  

locale.format() problems with decimal separator  03/31/08
   http://bugs.python.org/issue2522created  mishok13  
   patch   

binary buffered reading is quadratic 

Re: [Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows)

[Trent Nelson]

I've raised issue 2550 to track this problem.  I've also provided a patch on 
the tracker to test_socket.py that reproduces the issue.  Anyone mind if I 
commit this to trunk?  I'd like to observe if any other platforms exhibit 
different behaviour via buildbots.  It'll cause all the Windows slaves to fail 
on test_socket though.  (I can revert it once I've seen how the buildbots 
behave until I can come up with an actual patch for Windows that fixes the 
issue.)

http://bugs.python.org/issue2550
http://bugs.python.org/file9939/test_socket.py.patch

Trent.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Trent Nelson [EMAIL 
PROTECTED]
Sent: 03 April 2008 22:40
To: python-dev@python.org
Subject: [Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows 
vs Unix (or why test_asynchat is sometimes dying on Windows)

I started looking into this:

http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/289/step-test/0

Pertinent part:

test_asyncore

test_asynchat

command timed out: 1200 seconds without output
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
remoteFailed: [Failure instance: Traceback from remote host -- Traceback (most 
recent call last):
Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
]

I tried to replicate it on the buildbot in order to debug, which, surprisingly, 
I could do consistently by just running rt.bat -q -d -uall test_asynchat.  As 
the log above indicates, the python process becomes completely and utterly 
wedged, to the point that I can't even attach a remote debugger and step into 
it.

Digging further, I noticed that if I ran the following code in two different 
python consoles, EADDRINUSE was *NOT* being raised by socket.bind():

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 54322))

However, take out the setsockopt line, and wallah, the second s.bind() will 
raise EADDRINUSE, as expected.  This manifests into a really bizarre issue with 
test_asynchat in particualr, as subsequent sock.accept() calls on the socket 
put python into the uber wedged state (can't even ctrl-c out at the console, 
need to kill the process directly).

Have to leave the office and head home so I don't have any more time to look at 
it tonight -- just wanted to post here for others to mull over.

Trent.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/tnelson%40onresolve.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Guido van Rossum]

On Fri, Apr 4, 2008 at 8:08 AM, Jason Orendorff
<[EMAIL PROTECTED]> wrote:
> On Fri, Apr 4, 2008 at 9:38 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> >  What specific code breaks? Maybe we need to turn this into a warning
>  >  in order to be more backwards compatible?
>
>  I looked at Mercurial.
>
>  It doesn't use __hash__ at all.  It uses __eq__ in two files, three total 
> uses:
>  
> http://hg.intevation.org/mercurial/crew/file/6c4e12682fb9/mercurial/commands.py
>  
> http://hg.intevation.org/mercurial/crew/file/6c4e12682fb9/mercurial/context.py

If it breaks, perhaps the instances of one of those classes that
define __eq__ but not __hash__ are used in a set or as dict keys?
That's the difference between 2.5 and 2.6 in this area.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Paul Moore]

On 04/04/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>  >  It doesn't use __hash__ at all.  It uses __eq__ in two files, three total 
> uses:
>  >  
> http://hg.intevation.org/mercurial/crew/file/6c4e12682fb9/mercurial/commands.py
>  >  
> http://hg.intevation.org/mercurial/crew/file/6c4e12682fb9/mercurial/context.py
>
>
> If it breaks, perhaps the instances of one of those classes that
>  define __eq__ but not __hash__ are used in a set or as dict keys?
>  That's the difference between 2.5 and 2.6 in this area.

That looks like it. I'll work up a patch and submit it to the
Mercurial developers.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Dirkjan Ochtman]

Paul Moore wrote:
> That looks like it. I'll work up a patch and submit it to the
> Mercurial developers.

I've already got one going.

Cheers,

Dirkjan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] osx x86 buildbot offer

[Thomas Heller]

I can offer an OS X x86 machine to run a buildbot on.  This is a physical 
machine,
running OS X 10.5 Leopard.

Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] fixing tests on windows

[Terry Reedy]

"Tim Golden" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| > I suspect, but do not know, that the dialog box effects changes through
| > user-programmable interfaces.  So while I would start with manual 
changes
| > to see if that solves the problem, I presume there must be a system 
call
| > for changing dir attributes.
|
| The problem is, I think, that it isn't just the Indexing Service
| which generates this issue. TortoiseSVN is well known for doing
| the same thing, and there could be now and potentially will be
| in the future other programs. I don't think that hunting down
| and turning off their interference case by case is a viable
| solution in the long-term.

And that is exactly not what I was suggesting.  I do not know how much 
privitizing a directory actually blocks, but if Microsoft says 'only you 
can access the folder', perhaps it would block some things.

Don't most scanners read files rapidly, close, and move on?  Perhaps 
testall could either hang around at the end trying to make sure all is 
removed.  Perhaps display a message, wait five seconds, try again, up to a 
minute or so.

tjr



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/M

[Martin v. Löwis]

> What do others that do Windows development think?  I don't have a
> problem changing the build behaviour if the approach I've taken is
> generally disliked.

I think kill_python should only ever be invoked in the build slaves;
it should *not* be part of the regular build. If developers find they
can't build because some files are still open, they should kill
the processes themselves.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6a2 and 3.0a4

[Terry Reedy]

"Gerhard Häring" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| In case you don't know already, the website is not fully updated, yet:
|
| http://www.python.org/download/releases/2.6/
|
| Top of the page says "2.6a1" instead of "2.6a2".
|
| This file is apparently not yet updated for 2.6alpha2.
|
| http://www.python.org/download/releases/2.6/NEWS.txt
|
|
| For the 3.0 version:
|
| Top of the page still says "3.0a3".

The tops of the pages are fixed, but the left sidebar DOWNLOAD/Releases 
list still says 6a1 and 0a3. 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/M

[Trent Nelson]

Ok, I'll change the approach this weekend.

Trent.


From: "Martin v. Löwis" [EMAIL PROTECTED]
Sent: 04 April 2008 19:57
To: Trent Nelson
Cc: Christian Heimes; python-dev@python.org
Subject: Re: [Python-Dev] r62129 - in python/trunk: PCbuild/debug.vsprops 
PCbuild/kill_python.c PCbuild/kill_python.vcproj PCbuild/pcbuild.sln 
PCbuild/pythoncore.vcproj PCbuild/release.vsprops Tools/buildbot/Makefile 
Tools/buildbot/build-amd64.bat Tools/buildbo...

> What do others that do Windows development think?  I don't have a
> problem changing the build behaviour if the approach I've taken is
> generally disliked.

I think kill_python should only ever be invoked in the build slaves;
it should *not* be part of the regular build. If developers find they
can't build because some files are still open, they should kill
the processes themselves.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6a2 and 3.0a4

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Apr 4, 2008, at 3:03 PM, Terry Reedy wrote:
>
> "Gerhard Häring" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | In case you don't know already, the website is not fully updated,  
> yet:
> |
> | http://www.python.org/download/releases/2.6/
> |
> | Top of the page says "2.6a1" instead of "2.6a2".
> |
> | This file is apparently not yet updated for 2.6alpha2.
> |
> | http://www.python.org/download/releases/2.6/NEWS.txt
> |
> |
> | For the 3.0 version:
> |
> | Top of the page still says "3.0a3".
>
> The tops of the pages are fixed, but the left sidebar DOWNLOAD/ 
> Releases
> list still says 6a1 and 0a3.

I think I fixed these -- at least a grep of my local tree turns up no  
other references to 2.6a1 or 3.0a3.  It might take a little while for  
the site to get rebuilt though.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR/aHknEjvBPtnXfVAQJ3TQP+IrKnzpxWlJoEDovpg4hb2h4mcVhB5h6+
cpKczLE6DWlC4H4t76hZdRIOf/unAX6FeaTzlA7xLiXNkIlBT455k39jL98ZUmPy
OjOw6n96WyhWL6zmVBnF4YuBFKo2D1Sj9rzYF8i1qtwY3Xq0rvtSSTNmVSnqXDOu
x6H5Z5lm1AY=
=Qzkl
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6a2 and 3.0a4

[Gregor Lingl]

Hi, something doesn't work as usual, at least for me:

When I try to download the Python 2.6a2 release for Windows by clicking

* Windows x86 MSI Installer (2.6a2)
   (sig)
  

instead of the usual download dialog I get an

Error 404: File not found

for the url

http://www.python.org/ftp/python/2.6/python-2.6a2.msi .

The same is true when trying to download Python 3.0 a4.

Embarassed,
Gregor



Barry Warsaw schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team and the Python community, I'm  
> happy to announce the second alpha release of Python 2.6, and the  
> fourth alpha release of Python 3.0.
>
> Please note that these are alpha releases, and as such are not  
> suitable for production environments.  We continue to strive for a  
> high degree of quality, but there are still some known problems and  
> the feature sets have not been finalized.  These alphas are being  
> released to solicit feedback and hopefully discover bugs, as well as  
> allowing you to determine how changes in 2.6 and 3.0 might impact  
> you.  If you find things broken or incorrect, please submit a bug  
> report at
>
> http://bugs.python.org
>
> For more information and downloadable distributions, see the Python  
> 2.6 web
> site:
>
> http://www.python.org/download/releases/2.6/
>
> and the Python 3.0 web site:
>
> http://www.python.org/download/releases/3.0/
>
> We are planning one more alpha release of each version, followed by  
> two beta releases, with the final releases planned for August 2008.   
> See PEP 361 for release details:
>
>  http://www.python.org/dev/peps/pep-0361/
>
> Enjoy,
> - -Barry
>
> Barry Warsaw
> [EMAIL PROTECTED]
> Python 2.6/3.0 Release Manager
> (on behalf of the entire python-dev team)
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.8 (Darwin)
>
> iQCVAwUBR/WImHEjvBPtnXfVAQJmoQP+MzqNDI+Xt8zua/FE7Ca4TVXoIIy2uoOm
> I1i3+vmevZ9vtAb9hcGwfEgPY4LSwb9Js4KnJJWMPaMuFJK4NgGoiMdj+t42zDbQ
> bEzfBUOCoVkejLRxIQnWeJf1Hu8JocYyCHIRffv57/QdKpHuiSs8aE8GIT3STo3o
> I88H5NY1GgI=
> =WT2z
> -END PGP SIGNATURE-
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/gregor.lingl%40aon.at
>
>
>   
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a2 and 3.0a4

[Martin v. Löwis]

> Error 404: File not found

That has a simple explanation: the file is not there because it just
doesn't exist yet, which in turn is because I have problems creating
it (which is in turn due to switching to Visual Studio 2008).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows)

[Trent Nelson]

Interesting results!  I committed the patch to test_socket.py in r62152.  I was 
expecting all other platforms except for Windows to behave consistently (i.e. 
pass).  That is, given the following:

import socket
host = '127.0.0.1'
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind((host, 0))
port = sock.getsockname()[1]
sock.close()
del sock

sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock1.bind((host, port))
sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock2.bind((host, port))


the second bind should fail with EADDRINUSE, at least according to the 
'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 7.5 of 
Stevens' UNIX Network Programming Volume 1 (2nd Ed):

"With TCP, we are never able to start multiple servers that bind
 the same IP address and same port: a completely duplicate binding.
 That is, we cannot start one server that binds 198.69.10.2 port 80
 and start another that also binds 198.69.10.2 port 80, even if we
 set the SO_REUSEADDR socket option for the second server."

The results: both Windows *and* Linux fail the patched test; none of the 
buildbots for either platform encountered an EADDRINUSE socket.error after the 
second bind().  FreeBSD, OS X, Solaris and Tru64 pass the test -- EADDRINUSE is 
raised on the second bind.  (Interesting that all the ones that passed have a 
BSD lineage.)

I've just reverted the test in r62156 as planned.  The real issue now is that 
there are tests that are calling test_support.bind_socket() with the assumption 
that the port returned by this method is 'unbound', when in fact, the current 
implementation can't guarantee this:

def bind_port(sock, host='', preferred_port=54321):
for port in [preferred_port, 9907, 10243, 32999, 0]:
try:
sock.bind((host, port))
if port == 0:
port = sock.getsockname()[1]
return port
except socket.error, (err, msg):
if err != errno.EADDRINUSE:
raise
print >>sys.__stderr__, \
'  WARNING: failed to listen on port %d, trying another' % port

This logic is only correct for platforms other than Windows and Linux.  I 
haven't looked into all the networking test cases that rely on bind_port(), but 
I would think an implementation such as this would be much more reliable than 
what we've got for returning an unused port:

def bind_port(sock, host='127.0.0.1', *args):
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host, 0))
port = s.getsockname()[1]
s.close()
del s

sock.bind((host, port))
return port

Actually, FWIW, I just ran a full regrtest.py against trunk on Win32 with this 
change in place and all the tests still pass.

Thoughts?

Trent.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Trent Nelson [EMAIL 
PROTECTED]
Sent: 04 April 2008 17:07
To: python-dev@python.org
Subject: Re: [Python-Dev] socket.SOL_REUSEADDR: different semantics between 
Windows vs Unix (or why test_asynchat is sometimes dying on Windows)

I've raised issue 2550 to track this problem.  I've also provided a patch on 
the tracker to test_socket.py that reproduces the issue.  Anyone mind if I 
commit this to trunk?  I'd like to observe if any other platforms exhibit 
different behaviour via buildbots.  It'll cause all the Windows slaves to fail 
on test_socket though.  (I can revert it once I've seen how the buildbots 
behave until I can come up with an actual patch for Windows that fixes the 
issue.)

http://bugs.python.org/issue2550
http://bugs.python.org/file9939/test_socket.py.patch

Trent.


From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Trent Nelson [EMAIL 
PROTECTED]
Sent: 03 April 2008 22:40
To: python-dev@python.org
Subject: [Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows 
vs Unix (or why test_asynchat is sometimes dying on Windows)

I started looking into this:

http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/289/step-test/0

Pertinent part:

test_asyncore

test_asynchat

command timed out: 1200 seconds without output
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
remoteFailed: [Failure instance: Traceback from remote host -- Traceback (most 
recent call last):
Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
]

I tried to replicate it on the buildbot in order to debug, which, surprisingly, 
I could do consistently by just running rt.bat -q -d -uall test_asynchat.  As 
the log above indicates, the python process becomes completely and utterly 
wedged, to the point that I can't even 

Re: [Python-Dev] Python source code on Bazaar vcs

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 25, 2008, at 2:05 PM, [EMAIL PROTECTED] wrote:
>
>>> Did I misread the directions or do I really need the --create-prefix
>>> arg?
>
>Barry> You do, the first time you push a user branch because  
> users/skip
>Barry> doesn't exist yet.  It's mentioned in the docs, but it's  
> pretty
>Barry> easy to overlook ;).
>
> Well, I noticed the mention in .../dev/bazaar, where it reads, "the  
> first
> time you do this, you might need to add --create-prefix".  Perhaps  
> that
> should read "... you will need to ...".
>
> It pushed fine with --create-prefix.

Thanks Skip.  Fixed.
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBR/aR7XEjvBPtnXfVAQIoXgQAsN6Hfs1JjdFMOI1/Ef2kLeeBfTPxf+Ys
K9y81yEHUNonaQEIF9ptnyOIEyic5uX+Ig4cYO20i1LgvGEIIiCg191EJtYFc9jr
s1dTgmE3PQfiR7J2m2SWS06bYMsanBdAAW/ZnMpgmUMZixYEX43z7Q+kjFibwTn+
UbGz2uLeW+o=
=Fx0S
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] socket.SOL_REUSEADDR: different semantics between Windows vs Unix (or why test_asynchat is sometimes dying on Windows)

[Jean-Paul Calderone]

On Fri, 4 Apr 2008 13:24:49 -0700, Trent Nelson <[EMAIL PROTECTED]> wrote:
>Interesting results!  I committed the patch to test_socket.py in r62152.  I 
>was expecting all other platforms except for Windows to behave consistently 
>(i.e. pass).  That is, given the following:
>
>import socket
>host = '127.0.0.1'
>sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>sock.bind((host, 0))
>port = sock.getsockname()[1]
>sock.close()
>del sock
>
>sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>sock1.bind((host, port))
>sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>sock2.bind((host, port))
>
>
>the second bind should fail with EADDRINUSE, at least according to the 
>'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 7.5 of 
>Stevens' UNIX Network Programming Volume 1 (2nd Ed):
>
>"With TCP, we are never able to start multiple servers that bind
> the same IP address and same port: a completely duplicate binding.
> That is, we cannot start one server that binds 198.69.10.2 port 80
> and start another that also binds 198.69.10.2 port 80, even if we
> set the SO_REUSEADDR socket option for the second server."
>
>The results: both Windows *and* Linux fail the patched test; none of the 
>buildbots for either platform encountered an EADDRINUSE socket.error after the 
>second bind().  FreeBSD, OS X, Solaris and Tru64 pass the test -- EADDRINUSE 
>is raised on the second bind.  (Interesting that all the ones that passed have 
>a BSD lineage.)

Notice that the quoted text explains that you cannot start multiple servers
that etc.  Since you didn't call listen on either socket, it's arguable that
you didn't start any servers, so there should be no surprise regarding the
behavior.  Try adding listen calls at various places in the example and
you'll see something different happen.

FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote on
Linux/BSD/UNIX/etc.  On Windows, however, that option actually means
something quite different.  It means that the address should be stolen from
any process which happens to be using it at the moment.

There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think,
which, AIUI, makes it impossible for another process to steal the port
using SO_REUSEADDR.

Hope this helps,

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Dates wrong on front page of pydotorg

[Martin Thomas]

Did anyone else notice that the dates are incorrect in the news items  
on the front page? As an example:
Published: Mon, 4 Apr 2008
which should be
Published: Fri, 4 Apr 2008

I'll poke around and see if I can figure it out.

Cheers //M




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dates wrong on front page of pydotorg

[Guilherme Polo]

2008/4/4, Martin Thomas <[EMAIL PROTECTED]>:
> Did anyone else notice that the dates are incorrect in the news items
>  on the front page? As an example:
>  Published: Mon, 4 Apr 2008
>  which should be
>  Published: Fri, 4 Apr 2008
>
>  I'll poke around and see if I can figure it out.
>

There is a file (newsindex.yml) which contains the news items. The
publication date is hand written so it is just a typo from whoever
commited that news item with that publication date.

I just fixed it (as you pointed out). Thanks ;)

Anyway, did you send this to the wrong list or was it intentional ?

Regards,

>  Cheers //M
>
>
>
>  ___
>  Python-Dev mailing list
>  Python-Dev@python.org
>  http://mail.python.org/mailman/listinfo/python-dev
>  Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/ggpolo%40gmail.com
>


-- 
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] __eq__ vs hash

[Jean-Paul Calderone]

On Fri, 4 Apr 2008 07:38:04 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On Fri, Apr 4, 2008 at 2:46 AM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
>> the news file for python 2.6 does not mention that you need to define
>> __hash__ in case you define __eq__ for a class.
>> This breaks some code (for me: mercurial and pyparsing).
>> Shouldn't this be documented somewhere (I also cannot find it in the
>> whatsnew file).
>
>Well, technically this has always been the requirement.
>
>What specific code breaks? Maybe we need to turn this into a warning
>in order to be more backwards compatible?
>

There was some code in Twisted (one class, specifically) which was broken/
revealed to be broken by this Python 2.6 change.  The code assumed identity
hashing if no __hash__ method was implemented.  This ended up only working
if you only had a singleton instance of the class, but the class also went
out of its way to make sure that was the case.  We have since changed the
code to work on Python 2.6.

If you're curious about the details, here's the code after the fix:

http://twistedmatrix.com/trac/browser/trunk/twisted/web2/dav/element/base.py?rev=22305#L345

Here's the changeset that fixed it:

http://twistedmatrix.com/trac/changeset/22305

And here's the same class before the fix:

http://twistedmatrix.com/trac/browser/trunk/twisted/web2/dav/element/base.py?rev=22304#L344

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Dates wrong on front page of pydotorg

[Martin Thomas]

On Apr 4, 2008, at 6:37 PM, Guilherme Polo wrote:

> 2008/4/4, Martin Thomas <[EMAIL PROTECTED]>:
>> Did anyone else notice that the dates are incorrect in the news items
>> on the front page? As an example:
>> Published: Mon, 4 Apr 2008
>> which should be
>> Published: Fri, 4 Apr 2008
>>
>> I'll poke around and see if I can figure it out.
>>
>
> There is a file (newsindex.yml) which contains the news items. The
> publication date is hand written so it is just a typo from whoever
> commited that news item with that publication date.
>
> I just fixed it (as you pointed out). Thanks ;)
Welcome :-)
>
>
> Anyway, did you send this to the wrong list or was it intentional ?
I sent it to the wrong list.. should have pydotorg.  Sorry.
//M

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] RELEASED Python 2.6a2 and 3.0a4

[Terry Reedy]

"Barry Warsaw" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
I think I fixed these -- at least a grep of my local tree turns up no
other references to 2.6a1 or 3.0a3.  It might take a little while for
the site to get rebuilt though.
=

Fixed now.
Now  I am only waiting for the Windows binaries to be built and added 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] inittimezone - shouldn't it be static?

[skip]

Looks to me like the inittimezone function in timemodule.c should be static.
I don't see it called from any code other than within that module.  If it's
not supposed to be static it needs a more pythonic name.  (Can't dig into
this just now as I'm flying from Denver to Chicago a.t.m...)

Skip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] osx x86 buildbot offer

[Neal Norwitz]

On Fri, Apr 4, 2008 at 11:52 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
> I can offer an OS X x86 machine to run a buildbot on.  This is a physical 
> machine,
>  running OS X 10.5 Leopard.

Thanks Thomas!

Martin and I will coordinate with you off-list.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Antony Joseph wants to chat

[Antony Joseph]

---

Antony Joseph wants to stay in better touch using some of Google's coolest new
products.

If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-29833b0a8-b7e4c018a7-1e5ec176e7509c87
You'll need to click this link to be able to chat with Antony Joseph.

To get Gmail - a free email account from Google with over 2,800 megabytes of
storage - and chat with Antony Joseph, visit:
http://mail.google.com/mail/a-29833b0a8-b7e4c018a7-e7105acb3e

Gmail offers:
- Instant messaging right inside Gmail
- Powerful spam protection
- Built-in search for finding your messages and a helpful way of organizing
  emails into "conversations"
- No pop-up ads or untargeted banners - just text ads and related information
  that are relevant to the content of your messages

All this, and its yours for free. But wait, there's more! By opening a Gmail
account, you also get access to Google Talk, Google's instant messaging
service:

http://www.google.com/talk/

Google Talk offers:
- Web-based chat that you can use anywhere, without a download
- A contact list that's synchronized with your Gmail account
- Free, high quality PC-to-PC voice calls when you download the Google Talk
  client

Gmail and Google Talk are still in beta. We're working hard to add new features
and make improvements, so we might also ask for your comments and suggestions
periodically. We appreciate your help in making our products even better!

Thanks,
The Google Team

To learn more about Gmail and Google Talk, visit:
http://mail.google.com/mail/help/about.html
http://www.google.com/talk/about.html

(If clicking the URLs in this message does not work, copy and paste them into
the address bar of your browser).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com