[Python-Dev] Update to httplib.py

2008-09-25 Thread Eldon Ziegler 
I updated httplib.py, python 2.4, to be able to bind to a specific IP
address when connecting to a remote site. Would there be any interest in
making this available to others? If so, are there instructions on how to
post an update?

Eldon Ziegler


___
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] Update to httplib.py

2008-09-25 Thread Eric Smith 

Eldon Ziegler wrote:

I updated httplib.py, python 2.4, to be able to bind to a specific IP
address when connecting to a remote site. Would there be any interest in
making this available to others? If so, are there instructions on how to
post an update?


Create an issue at http://bugs.python.org/, mark it as a feature 
request, and attach the patch. That is, assuming this feature is still 
missing in 2.6 and 3.0. I don't know enough about it to say.


Eric.
___
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] Status of MS Windows CE port

2008-09-25 Thread Ulrich Eckhardt 
On Wednesday 24 September 2008, Neal Norwitz wrote:
> In general, we try to ensure that there is an active maintainer,
> preferably more than one.  As long as it doesn't make the code that
> much harder to maintain, it is desirable to support more platforms.

Actually, looking at the sources, there are several places where even existing 
win32 ports would benefit. There are four main differences between CE and the 
desktop variants:
1. TCHAR is always WCHAR
2. some APIs are missing
3. the vendor-supplied C or C++ stdlibs are rather minimal
4. you always cross-compile

The first point is interesting to the desktop win32 variants because 
everything since NT4 (or even 3.x) also used UCS2 or UTF-16 internally. Only 
win9x and ME(?) use 8-bit chars, and since support for them is being dropped, 
this would save a few conversions while allowing better Unicode support. I 
think getting Python to compile with _UNICODE #defined will be my first step.

The second point is mainly about features that don't exist like a current 
directory for a process or environment variables. Some other APIs don't 
support all parameters or similar differences. This should be rather easy to 
do.

The third means that functions like e.g. system() are simply not available in 
the supplied C API. If the functionality itself exists, it can be built on 
top of the win32 API. There might be a few cases where the desktop variants 
would benefit from one less adaption layer, too.

The last one only affects the build system and possibly the integration of 
unit testing. pythonce.sf.net already have one based on SCons, which is nice 
and easily extended. Being able to build 64 bit variants on 32 bit systems 
and vice versa might be another benefit.

> It's possible.  The best way to get the ball rolling is to produce
> some patches against the mainline.

Hmmm, which mainline? 2.5, 2.6 or 3.0? Up to now I have only looked at 2.5, 
because that one is stable. However, quite a few of above changes are not 
suitable for a stable version though, so I'll either have to restrict them to 
only CE or rather apply them to version 3. We can discuss that when I have 
actual patches.

> Perhaps the best way to start is using Bazaar or some distributed
> version control system for your patches.  Once you've demonstrated
> your ability and intent, we can make a branch.

I'll be digging into Bazaar, looks like an interesting topic by itself anyway. 
You'll hear from me!

cheers

Uli

-- 
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**
   Visit our website at 
**
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten 
bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen 
Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein 
sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, 
weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte 
Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht 
verantwortlich.

**

___
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] Update to httplib.py

2008-09-25 Thread Bill Janssen 
Eldon Ziegler <[EMAIL PROTECTED]> wrote:

> I updated httplib.py, python 2.4, to be able to bind to a specific IP
> address when connecting to a remote site.

Would that be something like

  conn = httplib.HTTPConnection('82.94.237.218', 80)

Doesn't it already do that?

Bill
___
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] Update to httplib.py

2008-09-25 Thread Oleg Broytmann 
On Thu, Sep 25, 2008 at 09:00:56AM -0700, Bill Janssen wrote:
> Eldon Ziegler <[EMAIL PROTECTED]> wrote:
> > I updated httplib.py, python 2.4, to be able to bind to a specific IP
> > address when connecting to a remote site.
> 
> Would that be something like
> 
>   conn = httplib.HTTPConnection('82.94.237.218', 80)
> 
> Doesn't it already do that?

   It's the destination address. AFAIU OP said about source address - in
case the program runs on a computer with many addresses - multihomed server
or such...

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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] Status of MS Windows CE port

2008-09-25 Thread Martin v. Löwis 
> - Is anyone already working on this? I know that Brad Clements made an 
> attempt 
> some years ago but didn't get it integrated, are there any others? Maybe even 
> any ongoing work?

My understanding is that Python works fairly well on CE as-is, so no
significant patches are needed.

If that understanding is incorrect, it may be because it broke over
time, or it may be that my understanding was incorrect to begin with.

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] Status of MS Windows CE port

2008-09-25 Thread Martin v. Löwis 
> 1. TCHAR is always WCHAR

Python shouldn't be using TCHAR at all; that getpathp uses it is
misguided (IMO).

> The first point is interesting to the desktop win32 variants because 
> everything since NT4 (or even 3.x) also used UCS2 or UTF-16 internally. Only 
> win9x and ME(?) use 8-bit chars, and since support for them is being dropped, 
> this would save a few conversions while allowing better Unicode support. I 
> think getting Python to compile with _UNICODE #defined will be my first step.

Please don't. Whether or not _UNICODE is defined should have no effect.

> The third means that functions like e.g. system() are simply not available in 
> the supplied C API.

In this case, not defining HAVE_SYSTEM would be already sufficient, no?

> If the functionality itself exists, it can be built on 
> top of the win32 API. There might be a few cases where the desktop variants 
> would benefit from one less adaption layer, too.

Again, in the specific case of system(), the replacement is already
there, in form of the subprocess module· There might be other places
also, but apart from stdio (which is mostly gone in 3.0) and memory
management, I can't think of any.

> The last one only affects the build system and possibly the integration of 
> unit testing. pythonce.sf.net already have one based on SCons, which is nice 
> and easily extended. Being able to build 64 bit variants on 32 bit systems 
> and vice versa might be another benefit.

Wouldn't it be easier to extend the VS projects? VS targets CE fairly
well, no?

>> It's possible.  The best way to get the ball rolling is to produce
>> some patches against the mainline.
> 
> Hmmm, which mainline? 2.5, 2.6 or 3.0?

The mainline is 2.6 (i.e. trunk). 2.5 and 3.0 are branches.

> Up to now I have only looked at 2.5, 
> because that one is stable. However, quite a few of above changes are not 
> suitable for a stable version though, so I'll either have to restrict them to 
> only CE or rather apply them to version 3. We can discuss that when I have 
> actual patches.

I guess none of your changes are suitable for 2.5 (as they probably
constitute new features). You should really target trunk (i.e. 2.7) when
you produce patches.

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] Status of MS Windows CE port

2008-09-25 Thread Michael Foord 

Martin v. Löwis wrote:
- Is anyone already working on this? I know that Brad Clements made an attempt 
some years ago but didn't get it integrated, are there any others? Maybe even 
any ongoing work?



My understanding is that Python works fairly well on CE as-is, so no
significant patches are needed.

If that understanding is incorrect, it may be because it broke over
time, or it may be that my understanding was incorrect to begin with.
  


I used to follow the Python-CE list. I believe that Luke Dunstan (who 
has done the most recent work on a port) discussed a previous attempt to 
get the patch-set accepted into trunk but it was rejected because it 
required too *many* changes.


Michael


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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/

___
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] Status of MS Windows CE port

2008-09-25 Thread Martin v. Löwis 
> I used to follow the Python-CE list. I believe that Luke Dunstan (who
> has done the most recent work on a port) discussed a previous attempt to
> get the patch-set accepted into trunk but it was rejected because it
> required too *many* changes.

Perhaps. But I also recall committing patches that
suggested a number of changes necessary for CE (e.g. r46819,
from #1495999 by Lukas Dunstan, and r46064, from #1492356,
by the same author). I don't recall rejecting a patch from
him, but I may have forgotten, or somebody else may have
rejected such a patch.

I do recall a certain unhappiness with the patches. If you
look at http://bugs.python.org/issue1492356, it starts with
"This patch contains part of the changes". What would be
the rationale for including part of the changes, but not all
of them? This appears to be a widespread view of port maintainers:
let's try to get some changes in. Apparently, some believe that
suggesting fewer changes might be more successful. I feel
uncomfortable with that, because I then don't know how many
more times they will approach me with another collection
of a few changes, and whether learning what the later changes
are might have impact on the earlier changes (which I had
already accepted).

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