Re: [Python-Dev] [Python-3000] Universal newlines support in Python 3.0
Paul> ... that files can have *either* bare \n, *or* the combination Paul> \r\n, to delimit lines. As someone else pointed out, \r needs to be supported as well. Many Mac applications (Excel comes to mind) still emit text files with \r as the line terminator. 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] Python 3000 Sprint @ Google
It's official! The second annual Python Sprint @ Google is happening again: August 22-25 (Wed-Sat). We're sprinting at two locations, this time Google headquarters in Mountain View and the Google office in Chicago (thanks to Brian Fitzpatrick). We'll connect the two sprints with full-screen videoconferencing. The event is *free* and includes Google's *free gourmet food*. Anyone with a reasonable Python experience is invited to attend. The primary goal is to work on Python 3000, to polish off the first alpha release; other ideas are welcome too. Experienced Python core developers will be available for mentoring. (The goal is not to learn Python; it is to learn *contributing* to Python.) For more information and to sign up, please see the wiki page on python.org: http://wiki.python.org/moin/GoogleSprint Sign-up via the wiki page is strongly recommended to avoid lines getting badges. Please read the whole wiki page to make sure you're prepared. -- --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] Dropping support for Win9x
Martin v. Löwis wrote: > 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). I'm not entirely sure, but I think that w9xpopen gets used when it looks like the shell (as per %ComSpec%) is command.com rather than cmd.exe. My understanding is that a Win9x machine *upgraded* (rather than a clean re-install) to Win2k or XP will retain command.com as the %ComSpec% setting. If so, that *might* be sufficient reason to keep w9xpopen around. I don't have a strong opinion though: I'm all for dropping win9x support and would be happy with either a doc note that users need to ensure they aren't using command.com, or a warning in the installer if this is detected. Trent -- Trent Mick trentm at activestate.com ___ 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
In article <[EMAIL PROTECTED]>, "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote: > Guido van Rossum writes: > > > However, the old universal newlines feature also set an attibute named > > 'newlines' on the file object to a tuple of up to three elements > > giving the actual line endings that were observed on the file so far > > (\r, \n, or \r\n). This feature is not in PEP 3116, and it is not > > implemented. I'm tempted to kill it. Does anyone have a use case for > > this? > > I have run into files that intentionally have more than one newline > convention used (mbox and Babyl mail folders, with messages received > from various platforms). However, most of the time multiple newline > conventions is a sign that the file is either corrupt or isn't text. > If so, then saving the file may corrupt it. The newlines attribute > could be used to check for this condition. There is at least one Mac source code editor (SubEthaEdit) that is all too happy to add one kind of newline to a file that started out with a different line ending character. As a result I have seen a fair number of text files with mixed line endings. I don't see as many these days, though; perhaps because the current version of SubEthaEdit handles things a bit better. So perhaps it won't matter much for Python 3000. -- Russell ___ 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 8/13/07, Russell E Owen <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> "Stephen J. Turnbull" <[EMAIL PROTECTED]> wrote:
>
> > Guido van Rossum writes:
> >
> > > However, the old universal newlines feature also set an attibute named
> > > 'newlines' on the file object to a tuple of up to three elements
> > > giving the actual line endings that were observed on the file so far
> > > (\r, \n, or \r\n). This feature is not in PEP 3116, and it is not
> > > implemented. I'm tempted to kill it. Does anyone have a use case for
> > > this?
> >
> > I have run into files that intentionally have more than one newline
> > convention used (mbox and Babyl mail folders, with messages received
> > from various platforms). However, most of the time multiple newline
> > conventions is a sign that the file is either corrupt or isn't text.
> > If so, then saving the file may corrupt it. The newlines attribute
> > could be used to check for this condition.
>
> There is at least one Mac source code editor (SubEthaEdit) that is all
> too happy to add one kind of newline to a file that started out with a
> different line ending character. As a result I have seen a fair number
> of text files with mixed line endings. I don't see as many these days,
> though; perhaps because the current version of SubEthaEdit handles
> things a bit better. So perhaps it won't matter much for Python 3000.
I've seen similar behavior in MS VC++ (long ago, dunno what it does
these days). It would read files with \r\n and \n line endings, and
whenever you edited a line, that line also got a \r\n ending. But
unchanged lines that started out with \n-only endings would keep the
\n only. And there was no way for the end user to see or control this.
To emulate this behavior in Python you'd have to read the file in
binary mode *or* we'd have to have an additional flag specifying to
return line endings as encountered in the file. The newlines attribute
(as defined in 2.x) doesn't help, because it doesn't tell which lines
used which line ending. I think the newline feature in PEP 3116 falls
short too; it seems mostly there to override the line ending *written*
(from the default os.sep).
I think we may need different flags for input and for output.
For input, we'd need two things: (a) which are acceptable line
endings; (b) whether to translate acceptable line endings to \n or
not. For output, we need two things again: (c) whether to translate
line endings at all; (d) which line endings to translate. I guess we
could map (c) to (b) and (d) to (a) for a signature that's the same
for input and output (and makes sense for read+write files as well).
The default would be (a)=={'\n', '\r\n', '\r'} and (b)==True.
--
--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
[Python-Dev] Python 3000: confused about str8, str, bytes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I maintain the sqlite module in the standard library, which makes heavy use of PyString_* C API. Now I've made it work under Python 3000 insofar as tests pass, but the new Python string semantics mean I have more work to do here and make some API choices. I've read in another thread that the future of str8 is not decided yet. To be honest I was confused when I saw it first, it's documented nowhere as far as I can see. Is that decided yet? Is str8 going away? What will happen with the Python C API? Will PyString_* become what PyUnicode_* is in Python 2.x? - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwMw6dIO4ozGCH14RAoyEAJ0eoqZ8gSqKh5/HIXxhbG5xpMedLgCgquQV Qv+CGyoD8eSXaoAKzn2WBSM= =w4HB -END PGP SIGNATURE- ___ 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] Python 3000 Sprint @ Google
On 8/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > It's official! The second annual Python Sprint @ Google is happening > again: August 22-25 (Wed-Sat). I can't attend this year (damn doctor's appt.), but I will try to be on Google Talk (username of bcannon) in case I can help out somehow remotely. -Brett ___ 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: confused about str8, str, bytes
When I said it wasn't decided I was totally serious. No decision has been reached. However, I strongly recommend that you try to write all your code using PyUnicode and PyBytes, avoiding PyString completely. Even if str8/PyString will remain in existence, it will be a last resort type for backwards compatibility. We *may* at some point rename PyUnicode to PyString (or PyText, to avoid confusion), but don't count on this. If we do, we'll provide a tool or service to do the conversion for you. --Guido On 8/13/07, Gerhard Häring <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I maintain the sqlite module in the standard library, which makes heavy use > of PyString_* C API. Now I've made it work under Python 3000 insofar as > tests pass, but the new Python string semantics mean I have more work to do > here and make some API choices. > > I've read in another thread that the future of str8 is not decided yet. To > be honest I was confused when I saw it first, it's documented nowhere as > far as I can see. > > Is that decided yet? Is str8 going away? > > What will happen with the Python C API? Will PyString_* become what > PyUnicode_* is in Python 2.x? > > - -- Gerhard > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGwMw6dIO4ozGCH14RAoyEAJ0eoqZ8gSqKh5/HIXxhbG5xpMedLgCgquQV > Qv+CGyoD8eSXaoAKzn2WBSM= > =w4HB > -END PGP SIGNATURE- > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --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
