Re: [Python-Dev] More on server-side SSL support
+1 for mutual authentication, I would use this. Can the TLS handshake be made to respect timeouts on sockets, or would this require changes deep inside OpenSSL? Graham ___ 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] urllib exception compatibility
On 27 Sep 2007, 21:23:58, Brett Cannon wrote: > Should OSError and IOError become aliases to EnvironmentError? I > assume WindowsError and VMSError will just directly subclass which > ever exception sticks around. > > And should we bother with a PendingDeprecationWarning for IOError or > OSError? Or just have a Py3K warning for them and not worry about > their removal in the 2.x series and just let 2to3 handle the > transition? Am I missing something, as I thought Py2K was supposed to throw backwards compatability to the wind in favor of doing the "Right Thing"? If so, can't we lose the proposed OSError and IOError aliases altogether, and just keep EnvironmentError? Perhaps "EnvironmentError" is a bit long to type in all the places OSError and IOError are used, I personally like the look of OSError and IOError better in my code. I vote for a shorter name for EnvironmentError, e.g. EMError. just my 2c, Graham > > -Brett > ___ > 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/graham.horler%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/archive%40mail-archive.com
Re: [Python-Dev] MacOSX -framework options and distutils weirdness
I would be inclined to move gcc to gcc-real (for example), and create a script called gcc which dumps all environment variables, and command-line arguments and a time-stamp to /tmp/gcc., e.g.: #!/bin/sh FN=/tmp/gcc.$$ echo -n "date=" > $FN date '+%Y/%m/%d %H:%M:%S.%N' >> $FN echo -n "cmdline=" >> $FN echo $0 $@ >> $FN set >> $FN gcc-real "$@" echo "exitcode=$?" >> $FN (I don't know if any of this will be different on OSX, I'm using Linux.) Then run the command manually, and compare the dump files. Here's hoping this helps, Graham On 10 Oct 2007, 12:36:13, Greg Ewing wrote: > Ronald Oussoren wrote: > > > The deployment target does have an influence on how the compiler > > functions, which can explain when setting the target to a different > > value causes problems. > > I did some more experimenting, and it doesn't seem to be > related to MACOSX_DEPLOYMENT TARGET. I tried setting it > to 10.1, 10.2, 10.3, 10.4 and leaving it unset, and in > all these cases the command works when run directly from > the shell. > > So I'm not sure what to try next. > > -- > Greg > ___ > 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/graham.horler%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/archive%40mail-archive.com
[Python-Dev] Proposal for new 2to23 tool
I have been developing in Python since 1.5, and now have to support 2.1
as a minimum version. I do like to keep my code runnable on newer
versions however, and am considering the feasability of forward
compatibility with Python 3.0.
I also notice the Leo[1] project could use some assistance with forward
compatibility.
So I was wondering if anyone else had a need for a 2to23.py tool to help
make code compatible with 3.0 but not break it for 2.x.
Such a tool could also include implementations of new builtins added in
python 3.0, or work in tandem with a "py3to2" library. One such
function would be "print" (which would have to be renamed to
e.g. "prints" as "def print()" is a syntax error in 2.x). This would
have the added benefit of staunching the flow of wasted effort into many
differing implementations of such things, and maybe direct some of it
into development of this tool.
Hope this is on topic, and has not already been considered and dismissed.
Thanks,
Graham
[1] http://webpages.charter.net/edreamleo/front.html
P.S. a suggested prints() implementation for py3to2.py, including raising
a TypeError exception for extra keyword args, and returning None.
It works in python 2.1 through to python 3.0a1.
def prints(*args, **kw):
kw.setdefault('sep', ' ')
kw.setdefault('end', '\n')
kw.setdefault('file', sys.stdout)
if len(kw) > 3:
for k in ('sep', 'end', 'file'):
del kw[k]
if len(kw) > 1:
raise TypeError(', '.join(map(repr, kw.keys())) +
' are invalid keyword arguments for this function')
else:
raise TypeError('%r is an invalid keyword argument for this
function'
% list(kw.keys())[0])
kw['file'].write(kw['sep'].join(['%s' % a for a in args]) + kw['end'])
___
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] Proposal for new 2to23 tool
On 12 Nov 2007, 03:24:34, Jan Claeys wrote: > > Op zondag 11-11-2007 om 17:19 uur [tijdzone -0800], schreef Brett > Cannon: > > On Nov 11, 2007 4:00 PM, Graham Horler <[EMAIL PROTECTED]> wrote: > > > I have been developing in Python since 1.5, and now have to support 2.1 > > > as a minimum version. I do like to keep my code runnable on newer > > > versions however, and am considering the feasability of forward > > > compatibility with Python 3.0. > > > > > > I also notice the Leo[1] project could use some assistance with forward > > > compatibility. > > > > > > So I was wondering if anyone else had a need for a 2to23.py tool to help > > > make code compatible with 3.0 but not break it for 2.x. > > > > What exactly are you proposing? We already have 2to3 > > (http://svn.python.org/view/sandbox/trunk/2to3/) for source-to-source > > translation from 2.x to 3.0. > > Graham wants to convert his code such that it works on both Python 2.x > (probably even early versions of it?) & Python 3.x. Not 2 instances of > code, but one source that works on both 2.x and 3.x... Absolutely ___ 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] [poll] New name for __builtins__
This is an interesting thread, here is my 1c :-) Unless one is feeling chronologically challenged, it is always the __last__ layer looked in as Christian Heimes described, so maybe __lastns__ or __latter__, or even __zns__. Perhaps __final__ or __finalns__ sounds too similar to "finally:". How about __inbuilt__ :-? I don't like __finish__, __close__, __terminal__, __integral__ too ambiguous. Poll summary so far (but without vote tally, and sorry if I missed any), including the ones above. Rejected: __builtin__ GvR "I want to keep both concepts" __session__ GvR "too many unrelated meanings" __python__ GvR "But ... *everything* becomes a Python thingie." Humorous: __guts__ __pythongastric__ __the_dictionary_where_all_the_builtins_are_now__ __telescope__ __uberglobal__ With and without umlaut __zns__ Cryptic / confusing: __close__ __final__ __finalns__ __finish__ __global__ __inbuilt__ __integral__ __rootns__ __terminal__ The others: __basic__ __builtin_namespace__ __core__ __default_root__ __fixtures__ __implicit__ __inject_builtins__ __lang__ __last__ __lastns__ __latter__ __outer__ __py__ __pythoncore__ __pythonroot__ __root__ This one is popular but has beed described as "too short" __root_dict__ __rootdict__ __root_globals__ __rootnames__ __root_namespace__ __syswide__ __top__ __universal__ +0.2 from me I hope this helps to have them all in one list. ___ 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] [poll] New name for __builtins__
Are we scraping the __bottom__ of the English language __barrel__? Perhaps someone here can draw some inspiration from __monty__ python's flying __circus__. It would be nice to have a name with a pythonic __ground__. Unfortunately that show is not my __staple__ entertainment, and although I have a __general__ idea what the show's about, it needs a __canonic__ understanding of its __founding__ __elements__ in order to be used for __primary__ ideas. Sorry, went mad for a few seconds there. ___ 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] Rationale for NamedTemporaryFile revisited [SEC=UNCLASSIFIED]
On 18 Jan 2008, 06:42:26, Steve Holden wrote:
> [EMAIL PROTECTED] wrote:
> > Thank you very much for the quick reply.
> >
> > I believe we have to close the file in order be able to read it in - in this
> > case to feed a unittest. I actually tried to read it in before closing it,
> > but (as I suspected) the data wasn't available.
> The mistake you made was to change the mode from the default "w+b". The
> following code works on both Windows and Linux:
>
> from tempfile import NamedTemporaryFile
> fid = NamedTemporaryFile(mode='w+b',
> suffix='.tmp',
> dir='.')
>
> fid.write('My temp file')
> fid.seek(0)
> data = fid.read()
> print data
> fid.close()
If you need to read the data by opening the file again (from unittest
code for example), then you need to call fid.flush() (no need for seeking).
Again, comp.lang.python, but I could not resist.
regards.
___
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] Unaccompanied Patch
Hi all, I created a patch on 2007-08-15: http://bugs.python.org/issue1775025 I wonder, will it just stay in patches unnoticed until it has its very own associated bug report to keep it company? Thanks, Graham ___ 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
