[Python-Dev] Dropping support for Win9x
I'd like to remove support for Windows 9x (95, 98(SE), ME) soon from the Python trunk. This would primarily affect all wide-string APIs (which would be considered present unconditionally), as well as certain "new" Win32 functions; in this cleanup, I would also drop support for NT+ before Windows 2000 (i.e. NT 3.1, 3.5(1), 4.0). I'm not sure whether w9xpopen should be left in place; Tim suggested it should, however, I don't see why (something with alternative command line interpreters IIRC). The 2.5 installer already gives a warning on W9x that this will be the last release. If you object to this plan, please speak up. 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] [Python-3000] Universal newlines support in Python 3.0
On 11/08/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/11/07, Tony Lownds <[EMAIL PROTECTED]> wrote:
> > Is this ok: when newline='\r\n' or newline='\r' is passed, only that
> > string is used to determine
> > the end of lines. No translation to '\n' is done.
>
> I *think* it would be more useful if it always returned lines ending
> in \n (not \r\n or \r). Wouldn't it? Although this is not how it
> currently behaves; when you set newline='\r\n', it returns the \r\n
> unchanged, so it would make sense to do this too when newline='\r'.
> Caveat user I guess.
Neither this wording, nor the PEP are clear to me, but I'm
assuming/hoping that there will be a way to spell the current
behaviour for universal newlines on input[1], namely that files can
have *either* bare \n, *or* the combination \r\n, to delimit lines.
Whichever is used (I have no need for mixed-style files) gets
translated to \n so that the program sees the same data regardless.
[1] ... at least the bit I care about :-)
This behaviour is immensely useful for uniform treatment of Windows
text files, which are an inconsistent mess of \n-only and \r\n
conventions.
Specifically, I'm looking to replicate this behaviour:
>xxd crlf
000: 610d 0a62 0d0a a..b..
>xxd lf
000: 610a 620aa.b.
>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> open('crlf').read()
'a\nb\n'
>>> open('lf').read()
'a\nb\n'
>>>
As demonstrated, this is the default in Python 2.5. I'd hope it was so
in 3.0 as well.
Sorry I can't test this for myself - I don't have the time/toolset to
build my own Py3k on Windows...
Paul.
___
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] [Python-3000] Universal newlines support in Python 3.0
Paul Moore schrieb:
> Specifically, I'm looking to replicate this behaviour:
>
>>xxd crlf
> 000: 610d 0a62 0d0a a..b..
>
>>xxd lf
> 000: 610a 620aa.b.
>
>>python
> Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
open('crlf').read()
> 'a\nb\n'
open('lf').read()
> 'a\nb\n'
>
> As demonstrated, this is the default in Python 2.5. I'd hope it was so
> in 3.0 as well.
Note that Python does nothing special in the above case. For non-Windows
platforms, you'd get two different results -- the conversion from \r\n to
\n is done by the Windows C runtime since the default open() mode is text mode.
Only with mode 'U' does Python use its own universal newline mode.
With Python 3.0, the C library is not used and Python uses universal newline
mode by default.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
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] [Python-3000] Universal newlines support in Python 3.0
On 12/08/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Note that Python does nothing special in the above case. For non-Windows > platforms, you'd get two different results -- the conversion from \r\n to > \n is done by the Windows C runtime since the default open() mode is text > mode. > > Only with mode 'U' does Python use its own universal newline mode. Pah. You're right - I almost used 'U' and then "discovered" that I didn't need it (and got bitten by a portability bug as a result :-() > With Python 3.0, the C library is not used and Python uses universal newline > mode by default. That's what I expected, but I was surprised to find that the PEP is pretty unclear on this. The phrase "universal newlines" is mentioned only once, and never defined. Knowing the meaning, I can see how the PEP is intended to say that universal newlines on input is the default (and you set the newline argument to specify a *specific*, non-universal, newline value) - but I missed it on first reading. Thanks for the clarification. Paul. ___ 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
