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

2008-04-05 Thread Guido van Rossum 
Sounds like an oversight. Please fix!

On Fri, Apr 4, 2008 at 5:37 PM,  <[EMAIL PROTECTED]> wrote:
>
>  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...)


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
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

2008-04-05 Thread Daniel Krech 

On Apr 4, 2008, at 10:38 AM, Guido van Rossum 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 think a warning would be nice. I've run into a number of places that  
are breaking due to the change. Including parts of the standard lib,  
in particular, unittest.TestSuite as used by nose [1].

There is already an open issue with patches for this in the issue  
tracker [2]. I've been running trunk with the patch installed and am  
able to get past the breakage due to the change. I don't believe the  
current patch is kicking out a warning however.

[1] http://code.google.com/p/python-nose/issues/detail?id=161
[2] http://bugs.python.org/issue2235

___
Python-Dev mailing list
[email protected]
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)

2008-04-05 Thread Trent Nelson 
> >"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."

> 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.

I agree in principle, Stevens says nothing about what happens if you *do* try 
and bind two sockets on two identical host/port addresses.  Even so, 
test_support.bind_port() makes an assumption that bind() will raise EADDRINUSE 
if the port is not available, which, as has been demonstrated, won't be the 
case on Windows or Linux.

> 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.

Probably explains why the python process wedges when this happens on Windows...

> 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.

Nod, if SO_EXCLUSIVEADDRUSE is used instead in the code I posted, Windows 
raises EADDRINUSE on the second bind().  I don't have access to any Linux boxes 
at the moment, so I can't test what sort of error is raised with the example I 
posted if listen() and accept() are called on the two sockets bound to 
identical addresses.  Can anyone else shed some light on this?  I'd be 
interested in knowing if the process wedges on Linux as badly as it does on 
Windows (to the point where it's not respecting ctrl-c or sigkill).


Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] configure error: "rm: conftest.dSYM: is a directory"

2008-04-05 Thread skip 
I just noticed this error message during configure:

checking whether gcc accepts -Olimit 1500... no
checking whether gcc supports ParseTuple __format__... no
checking whether pthreads are available without options... yes
checking whether g++ also accepts flags for thread support... no
checking for ANSI C header files... rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes

Note the "rm: conftest.dSYM: is a directory".  This occurred a few times
during the configure process.  Didn't cause it to conk out, but is annoying.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

2008-04-05 Thread skip 
>> Looks to me like the inittimezone function in timemodule.c should be
>> static.

Guido> Sounds like an oversight. Please fix!

Done.  inittimezone is now declared static.

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?

2008-04-05 Thread Mark Hammond 
As I was preparing to check-in my cross-compilation patch, which includes a
new x64 executable in the Lib/distutils/command directory, it occurs to me
that we don't actually need it in subversion - and nor do we need
wininst-9.0.exe.

I believe these executables are in svn for historical reasons.  The build
process for these executables are now integrated into the core Python build
process (although they are disabled by default).  There is a good use-case
for keeping executables built with older MSVC versions, but I don't see one
for executables built with the current version.

I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and
enable the building of that project by default in the standard build process
(and I'll setup the x64 build of the executable similarly).  They will then
need to be re-added when a future version moves away from Visual Studio
2008, but that seems like a reasonable way to approach things.  Are there
any objections to this, or should we stick with the status-quo and I'll add
the new x64 executable?  Or do things that way *just* for x64?
 
Thanks,

Mark. 

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

Re: [Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?

2008-04-05 Thread Martin v. Löwis 
> I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and
> enable the building of that project by default in the standard build process
> (and I'll setup the x64 build of the executable similarly).

There are two issues here:
a) how does the binary get into the release tarball? You might argue
   that it doesn't have to, as it is sufficient when it is included in
   the Windows installer, however, as currently implemented,
   bdist_wininst also runs on Unix, and people use it that way.
b) IIRC, upx was used to compress these executables. I don't think the
   the current build process covers this, yet (but then, the current
   binaries might not be compressed with upx anymore, either - not
   sure whether that would be a bug). Of course, upx would probably
   not currently apply to Win64-amd64.

As another alternative to providing a separate AMD64 binary, you could
also try to make the existing binary work properly on Win64, and tell
it with a config flag whether to look for Win32 or Win64 (or either)
on the target system.

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

Re: [Python-Dev] Thread-safe file objects, the return

2008-04-05 Thread Gregory P. Smith 
I've reviewed the patch on http://bugs.python.org/issue815646 and have
uploaded my modified version (mostly test improvements and some formatting
to keep C code under 80 columns with proper 8 space tabs).  I would have
committed it already but I have a sneaking suspicion that its unit test will
barf on windows since it could depend on some posix-like file system
semantics.

Could someone with a windows build environment please test it as asked in
the issue and report back in the tracker?

thanks!
-gps

On Wed, Apr 2, 2008 at 11:47 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Wed, Apr 2, 2008 at 3:17 AM, Antoine Pitrou <[EMAIL PROTECTED]>
> wrote:
> >  Guido van Rossum  python.org> writes:
> >  > Your solution (a counter) seems fine except I think perhaps the
> >  > close() call should not raise IOError -- instead, it should set a
> flag
> >  > so that the thread that makes the counter go to zero can close the
> >  > thread (after all the file got closed while it was being used).
> >
> >  I agree with Gregory: we should be explicit about what happens. I
> wonder
> >  what we would gain from that approach - apart from encouraging
> dangerous
> >  coding practices :)
> >  It also depends how far we want to go: I am merely proposing to fix the
> >  crashes, do we want to provide a "smarter" close() variation that does
> what
> >  you suggest for people that want (or need) to take the risk?
>
> I also agree with Gregory now -- at least on the issue of fclose().
>
> I think that for other (non-closing) operations we should be fine,
> given the Posix requirement that streams have an internal lock. While
> multiple threads reading from a file sounds insane, multiple files
> writing to a file is pretty common (think of stdout or stderr) and
> should be supported.
>
> >  > There are of course other concurrency issues besides close -- what if
> >  > two threads both try to do I/O on the file? What will the C stdio
> >  > library do in that case? Are stdio files thread-safe at the C level?
> >
> >  According to the glibc documentation, at
> >
> http://www.gnu.org/software/libc/manual/html_node/Streams-and-Threads.html:
> >
> >  « The POSIX standard requires that by default the stream operations are
> >  atomic. I.e., issuing two stream operations for the same stream in two
> >  threads at the same time will cause the operations to be executed as if
> >  they were issued sequentially. The buffer operations performed while
> >  reading or writing are protected from other uses of the same stream. To
> do
> >  this each stream has an internal lock object which has to be
> (implicitly)
> >  acquired before any work can be done. »
> >
> >  So according to POSIX rules it should be perfectly safe.
>
> Cool.
>
> >  In any case, someone would have to try my patch under Windows and OS X
> and
> >  see if test_file.py passes without crashing.
>
> I know Windows has internal locks on stdio. I trust that OSX, being a
> BSD descendant, is posix compliant. So I'm not worried about these.
>
> +1 on your patch, assuming some other developer reviews it and submits it.
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com