Re: [Python-Dev] Import and unicode: part two
On Fri, Jan 21, 2011 at 1:46 AM, Guido van Rossum wrote: > On Thu, Jan 20, 2011 at 5:16 AM, Nick Coghlan wrote: >> On Thu, Jan 20, 2011 at 10:08 PM, Simon Cross >> wrote: >>> I'm changing my vote on this to a +1 for two reasons: >>> >>> * Initially I thought this wasn't supported by Python at all but I see >>> that currently it is supported but that support is broken (or at least >>> limited to UTF-8 filesystem encodings). Since support is there, might >>> as well make it better (especially if it tidies up the code base at >>> the same time). >>> >>> * I still don't think it's a good idea to give modules non-ASCII names >>> but the "consenting adults" approach suggests we should let people >>> shoot themselves in the foot if they believe they have good reason to >>> do so. >> >> I'm also +1 on this for the reasons Simon gives. > > Same here. *Most* code will never be shared, or will only be shared > between users in the same community. When it goes wrong it's also a > learning opportunity. :-) > I don't want Python to encourage people to use non-ascii module names. Today, seeing UnicodeEncodingError is one of popular reasons for newbies to abandon learning Python in Japan. Non-ascii module name is an another source of confusion for newbies. Experienced Japanese programmers may not use non-ascii module names to avoid encoding issues. But novice programmers or non-programmers willing to learn programming with Python will wish to use Japanese module names. Their programs will stop working if they copy them to another environment. Sooner or later, they will see storange ImportError and will start complaining "Python sucks! Python doesn't support Japanese!" on Twitter. Copying files with non-ascii file name over platform is not easy as it sounds. What happen if I copy such files from OSX to my web hosting server ? Results might differ depending on tools I use to copy and platforms. Is it a good opportunity to start learnig abound encodings? I don't think so. They should learn concepts of charater set and encodings, Unicode and JIS character sets, some kind of Japanse encodings, number of platform specifix issues, non-standard extention of Microsoft and Apple, and so on. I think they should defer learning these messes until they get ready. -- Atsuo Ishimoto Mail: [email protected] Blog: http://d.hatena.ne.jp/atsuoishimoto/ Twitter: atsuoishimoto ___ 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] Import and unicode: part two
On Fri, Jan 21, 2011 at 2:59 PM, Nick Coghlan wrote: > > These all sound like good reasons to continue to *advise* against > using non-ASCII module names. But aside from that, they sound exactly > like a lot of the arguments we heard when Py3k started enforcing the > bytes/text distinction more rigorously: "you're going to break > stuff!". No, non-ASCII module names are new breakage you are going to introduce now :) If the advice against using non-ASCII module names is reasonable, why bother supporting them? > > Yes, we know. But if core software development components like Python > don't try to improve their Unicode support, how is the situation ever > going to get better? > Java, a leading language of IT industry, have already support non-ASCII class files for years. But I've never seen such files in production in Japan, and didn't improve situation until now. -- Atsuo Ishimoto Mail: [email protected] Blog: http://d.hatena.ne.jp/atsuoishimoto/ Twitter: atsuoishimoto ___ 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] Import and unicode: part two
Nick Coghlan writes: > On Fri, Jan 21, 2011 at 3:44 PM, Atsuo Ishimoto wrote: > > I don't want Python to encourage people to use non-ascii module names. I don't think anybody is *encouraging* it. The argument is for *permitting* it, partly for consistency with other identifiers, and partly because of Python's usual "consenting adults" standard for permitting "dangerous" practices. I realize this is a somewhat problematic distinction in Japan, for several reasons, but it's really not one that can be avoided in computing in any case. The sooner novice programmers learn it, the better. > > Today, seeing UnicodeEncodingError is one of popular reasons for > > newbies to abandon learning Python in Japan. Non-ascii module name is > > an another source of confusion for newbies. > > > > Experienced Japanese programmers may not use non-ascii module names to > > avoid encoding issues. > > > > But novice programmers or non-programmers willing to learn programming > > with Python will wish to use Japanese module names. Their programs > > will stop working if they copy them to another environment. Sooner or > > later, they will see storange ImportError and will start complaining > > "Python sucks! Python doesn't support Japanese!" on Twitter. So ask them, "What language *does* 'support Japanese'?" ;-) Seriously, "support Japanese" is an impossibly hard standard in the current environment. Not only does Japan have 5 more or less standard encodings still in daily use (EUC-JP, ISO-2022-JP, Shift JIS, UTF-8, and UTF-16LE), but many major IT companies have their own variants of the JIS standard character repertoire (all of the variant ideographs I've seen in the wild are in Unicode, but many corporate repertoires add extra symbols that are not), and of course some Microsoft utilities insist on using the deprecated UTF-8 signature with UTF-8. That said, I really don't see module names as a particular problem. By the time your novice is using her own modules (as opposed to importing stdlib and PyPI add-on modules, all with ASCII-only names), she'll be doing file I/O which has all the same problems, AFAICS. True, file names will be strings rather than identifiers, but I don't see why that matters. > > Copying files with non-ascii file name over platform is not easy as it > > sounds. Agreed, it's not trivial. But it's not that hard, either[1], and web hosts and others *could* help by providing checkers for languages that they support. > > What happen if I copy such files from OSX to my web hosting > > server ? Results might differ depending on tools I use to copy and > > platforms. I don't see why this problem is specific to Python modules, as opposed to any file name. > These all sound like good reasons to continue to *advise* against > using non-ASCII module names. +1 > But aside from that, they sound exactly like a lot of the arguments > we heard when Py3k started enforcing the bytes/text distinction > more rigorously: "you're going to break stuff!". Well, not exactly. Enforcing the bytes/text distinction was a change in the definition of Python; breakage was our fault. The change was made because in the (not so) long run it would reduce new breakage. Here, Python is fine (or at least we have some pretty good ideas how to fix it), it's the world that's broken. *Especially* Japan, with its five standard encodings in daily use and scads of private variant repertoires masquerading as standard encodings on top of that. But the whole world is broken because of the NFD/NFC thing. AFAIK, the only file system that tries to enforce an NF is Mac OS X HFS+, and (unfortunately for portability *from* Mac OS X *to* other systems) they chose NFD. Proper NFD support is arguably better for a number of reasons (for one, people regularly invent new composition sequences that will not have precomposed glyphs in any font), but NFC has the advantage that existing fonts support precomposed standard characters while many display engines do not support composition properly yet. And it's likely to stay broken for a while: the move to conformant display engines is going to take more time. I still don't see this as a reason to give up on non-ASCII module names. Just have the documentation warn that many non-ASCII names will be non-portable, so use on multiple systems will require care (maybe gloss that with "probably more care than you want to take"). Footnotes: [1] I actually find copying file names with spaces to be a bigger problem, because it's so hard to get shell quoting right. ___ 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] Import and unicode: part two
> I don't want Python to encourage people to use non-ascii module names. I don't think the feature is open for debate anymore. PEP 3131 has been accepted (after *long* debates), and I'll pronounce that supporting non-ASCII module names is a direct consequence of having it accepted. Of course, there may be limitations with respect to operating systems, and in the way Python modules integrate with the file system - but that non-ASCII module names must be supported is really out of question. If you would like this to be reverted, you need to write another PEP. 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] Import and unicode: part two
Atsuo Ishimoto writes: > Java, a leading language of IT industry, have already support > non-ASCII class files for years. But I've never seen such files in > production in Japan, and didn't improve situation until now. So why wouldn't Python work the same way? The rest of the world can use non-ASCII modules names sparingly, and Japanese programmers can avoid them diligently. Or learn to use them properly and teach each other; if anybody has the experience of multiple encodings needed to figure out a good way to use the native language in program identifiers despite the encoding problem, my bet is it would be Japan. ___ 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] Import and unicode: part two
On Thu, 20 Jan 2011 22:25:17 -0500 James Y Knight wrote: > > On Jan 20, 2011, at 3:55 PM, Antoine Pitrou wrote: > > > On Thu, 20 Jan 2011 15:27:08 -0500 > > Glyph Lefkowitz wrote: > >> > >> To support the latter, could we just make sure that zipimport has a > >> consistent, > >> non-locale-or-operating-system-dependent interpretation of encoding? > > > > It already has, but it's dependent on a flag in the zip file itself > > (actually, one flag per archived file in the zip it seems). > > > > (by the way, it would be nice if your text/mail editor wrapped lines at > > 80 characters or something) > > You could complain to Apple, but it seems unlikely that they'd change it. > They broke it intentionally in OSX 10.6.2 for better compatibility with MS > Outlook. > > (for the technically inclined: It still wraps lines at 80 characters in the > raw message, but it uses quoted-printable encoding to escape the line-breaks, > so mail readers which decode quoted-printable but can't flow text are now > S.O.L. Apple used to use the nice format=flowed standard instead.) I think most mail readers are able to word-wrap raw text correctly (even though it still makes your messages look bad amongst a thread of nicely-formatted 80-column messages). The real annoyance is when reading Web archives of mailing-lists, e.g. http://twistedmatrix.com/pipermail/twisted-python/2011-January/023346.html Regards Antoine. ___ 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-checkins] r87815 - peps/trunk/pep-3333.txt
On Thu, 20 Jan 2011 22:16:36 -0500
James Y Knight wrote:
>
> On Jan 20, 2011, at 9:31 PM, Ezio Melotti wrote:
> >> Modified: peps/trunk/pep-.txt
> >> ==
> >> --- peps/trunk/pep-.txt (original)
> >> +++ peps/trunk/pep-.txt Fri Jan 7 16:39:27 2011
> >> @@ -310,9 +310,9 @@
> >> elif not headers_sent:
> >> # Before the first output, send the stored headers
> >> status, response_headers = headers_sent[:] = headers_set
> >> - sys.stdout.write('Status: %s\r\n' % status)
> >> + sys.stdout.buffer.write('Status: %s\r\n' % status)
> >> for header in response_headers:
> >> - sys.stdout.write('%s: %s\r\n' % header)
> >> + sys.stdout.buffer.write('%s: %s\r\n' % header)
> >
> > Also note that .buffer might not be available in some cases (i.e. when
> > sys.stdout has been replaced with other objects).
>
> Do you have a recommendation for a better way to do bytes I/O on
> stdin/sydout, then?...just saying that .buffer might not be available isn't a
> very useful comment unless there's a replacement idiom...
Well, this is the recommmendation. There's no reason for
sys.stdXXX.buffer not to exist if you have full control over the
application (which you normally have if you do CGI).
Regards
Antoine.
___
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] Mail archive line wrapping (Was: Import and unicode: part two)
On Jan 21, 2011, at 6:31 AM, Antoine Pitrou wrote:
> On Thu, 20 Jan 2011 22:25:17 -0500
> James Y Knight wrote:
>>
>> On Jan 20, 2011, at 3:55 PM, Antoine Pitrou wrote:
>>> (by the way, it would be nice if your text/mail editor wrapped lines at
>>> 80 characters or something)
>>
>> You could complain to Apple, but it seems unlikely that they'd change it.
>> They broke it intentionally in OSX 10.6.2 for better compatibility with MS
>> Outlook.
>>
>> (for the technically inclined: It still wraps lines at 80 characters in the
>> raw message, but it uses quoted-printable encoding to escape the
>> line-breaks, so mail readers which decode quoted-printable but can't flow
>> text are now S.O.L. Apple used to use the nice format=flowed standard
>> instead.)
>
> I think most mail readers are able to word-wrap raw text correctly
> (even though it still makes your messages look bad amongst a thread of
> nicely-formatted 80-column messages).
> The real annoyance is when reading Web archives of mailing-lists, e.g.
> http://twistedmatrix.com/pipermail/twisted-python/2011-January/023346.html
Well, yes, that's a pretty annoying bug in mailman, isn't it? If only anyone
around here was involved in mailman and could fix it! :) [I've attempted to cc
this to mailman-users with this message, but since I'm not subscribed I dunno
if it'll make it or not.]
I have this in my user CSS override file to fix the issue for myself globally
on all such archives out in the world:
/* Mailing list archives */
html>body>pre { white-space: pre-wrap !important; }
But really, pipermail should just output a suitable style itself, e.g.: or a pre { white-space: pre-wrap;
} in the header.
That's supported on all browsers since FF3.0, IE8, Safari 3, Opera 8. There are
various nonstandard CSS selectors for reaching older browsers (IE5.5+, Firefox
pre-1.0+, Opera 4+)...But by the time this change gets made in mailman, and
released, and gets into the distros that the various list hosts around the web
use, and those hosts get upgraded, I doubt anyone will actually even be able to
run those old browsers anymore.
James
___
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] Mail archive line wrapping (Was: Import and unicode: part two)
On Fri, 21 Jan 2011 08:23:31 -0500
James Y Knight wrote:
> >
> > I think most mail readers are able to word-wrap raw text correctly
> > (even though it still makes your messages look bad amongst a thread of
> > nicely-formatted 80-column messages).
> > The real annoyance is when reading Web archives of mailing-lists, e.g.
> > http://twistedmatrix.com/pipermail/twisted-python/2011-January/023346.html
>
> Well, yes, that's a pretty annoying bug in mailman, isn't it? If only anyone
> around here was involved in mailman and could fix it! :) [I've attempted to
> cc this to mailman-users with this message, but since I'm not subscribed I
> dunno if it'll make it or not.]
Why is this a bug in mailman? Mailman archives messages as they are
sent (well, perhaps it mangles e-mail addresses, perhaps). If someone
draws a nice ASCII-art diagram which requires 90 columns instead of 80,
you wouldn't want the archive to break its rendering.
So, it's really the mail client (or its user :-)) which should handle
word-wrapping, not some downstream tool which has no idea of the
original intent.
> I have this in my user CSS override file to fix the issue for myself globally
> on all such archives out in the world:
> /* Mailing list archives */
> html>body>pre { white-space: pre-wrap !important; }
That doesn't wrap to 80 characters, does it? Only whatever the
current window/container width is, which isn't necessarily the right
thing (if that makes lines 160 characters long, it's still quite
uncomfortable to read).
Regards
Antoine.
___
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] Mail archive line wrapping (Was: Import and unicode: part two)
On Jan 21, 2011, at 08:23 AM, James Y Knight wrote: >Well, yes, that's a pretty annoying bug in mailman, isn't it? If only anyone >around here was involved in mailman and could fix it! :) [I've attempted to >cc this to mailman-users with this message, but since I'm not subscribed I >dunno if it'll make it or not.] Technically, Pipermail, but jeebus how I hate hacking on that code. :) Although it's been futile for the last decade, maybe this time will work: volunteers wanted! -Barry signature.asc Description: 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] Import and unicode: part two
On Fri, Jan 21, 2011 at 5:45 PM, Stephen J. Turnbull wrote: > Nick Coghlan writes: > > On Fri, Jan 21, 2011 at 3:44 PM, Atsuo Ishimoto > wrote: > > > > I don't want Python to encourage people to use non-ascii module names. > > I don't think anybody is *encouraging* it. The argument is for > *permitting* it, partly for consistency with other identifiers, and > partly because of Python's usual "consenting adults" standard for > permitting "dangerous" practices. I'm sorry, I was not clear. I was afraid that saying "learning opportunity" tempt people to try non-ASCII module names. In these days, even non technical people have access to Windows, Mac and Linux boxes at a time. So chances to be annoyed with broken non-ASCII named files are pretty common. > > I still don't see this as a reason to give up on non-ASCII module > names. Just have the documentation warn that many non-ASCII names > will be non-portable, so use on multiple systems will require care > (maybe gloss that with "probably more care than you want to take"). > Nice gloss. -- Atsuo Ishimoto Mail: [email protected] Blog: http://d.hatena.ne.jp/atsuoishimoto/ Twitter: atsuoishimoto ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-01-14 - 2011-01-21)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2527 (+29)
closed 20228 (+36)
total 22755 (+65)
Open issues with patches: 1062
Issues opened (44)
==
#10896: trace module compares directories as strings (--ignore-dir)
http://bugs.python.org/issue10896 reopened by SilentGhost
#10909: thread hang, possibly related to print
http://bugs.python.org/issue10909 opened by PythonInTheGrass
#10910: pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilati
http://bugs.python.org/issue10910 opened by X-Istence
#10911: cgi: add more tests
http://bugs.python.org/issue10911 opened by haypo
#10914: Python sub-interpreter test
http://bugs.python.org/issue10914 opened by pitrou
#10915: Make the PyGILState API compatible with multiple interpreters
http://bugs.python.org/issue10915 opened by pitrou
#10919: Environment variables are not expanded in _winreg when using R
http://bugs.python.org/issue10919 opened by rjnienaber
#10922: Unexpected exception when calling function_proxy.__class__.__c
http://bugs.python.org/issue10922 opened by DasIch
#10924: Adding salt and Modular Crypt Format to crypt library.
http://bugs.python.org/issue10924 opened by jafo
#10925: Document pure Python version of integer-to-float correctly-rou
http://bugs.python.org/issue10925 opened by mark.dickinson
#10932: distutils.core.setup - data_files misbehaviour ?
http://bugs.python.org/issue10932 opened by Thorsten.Simons
#10933: Tracing disabled when a recursion error is triggered (even if
http://bugs.python.org/issue10933 opened by fabioz
#10936: Simple CSS fix for left margin at docs.python.org
http://bugs.python.org/issue10936 opened by cdunn2001
#10937: WinPE 64 bit execution results with errors
http://bugs.python.org/issue10937 opened by gettingback2basics
#10938: Provide links to system specific strftime/ptime docs
http://bugs.python.org/issue10938 opened by hdiogenes
#10939: imaplib: Internaldate2tuple raises KeyError parsing month and
http://bugs.python.org/issue10939 opened by lavajoe
#10940: IDLE 3.2 hangs with Cmd-M hotkey on OS X 10.6 with 64-bit inst
http://bugs.python.org/issue10940 opened by rhettinger
#10941: imaplib: Internaldate2tuple produces wrong result if date is n
http://bugs.python.org/issue10941 opened by lavajoe
#10942: xml.etree.ElementTree.tostring returns type bytes, expected ty
http://bugs.python.org/issue10942 opened by JTMoon79
#10945: bdist_wininst depends on MBCS codec, unavailable on non-Window
http://bugs.python.org/issue10945 opened by eric.araujo
#10948: Trouble with dir_util created dir cache
http://bugs.python.org/issue10948 opened by diegoqueiroz
#10949: logging.RotatingFileHandler not robust enough
http://bugs.python.org/issue10949 opened by kalt
#10951: gcc 4.6 warnings
http://bugs.python.org/issue10951 opened by haypo
#10952: Don't normalize module names to NFKC?
http://bugs.python.org/issue10952 opened by haypo
#10954: No warning for csv.writer API change
http://bugs.python.org/issue10954 opened by lregebro
#10955: Possible regression with stdlib in zipfile
http://bugs.python.org/issue10955 opened by ronaldoussoren
#10956: file.write and file.read don't handle EINTR
http://bugs.python.org/issue10956 opened by eggy
#10957: Python FAQ grammar error
http://bugs.python.org/issue10957 opened by jerry.seutter
#10960: os.stat() does not mention that it follow symlinks by default
http://bugs.python.org/issue10960 opened by mmarkk
#10961: Pydoc touchups in new browser for 3.2
http://bugs.python.org/issue10961 opened by ron_adam
#10963: "subprocess" can raise OSError (EPIPE) when communicating with
http://bugs.python.org/issue10963 opened by dmalcolm
#10964: Mac installer need not add things to /usr/local
http://bugs.python.org/issue10964 opened by reowen
#10965: dev task of documenting undocumented APIs
http://bugs.python.org/issue10965 opened by brett.cannon
#10966: eliminate use of ImportError implicitly representing TestSkipp
http://bugs.python.org/issue10966 opened by brett.cannon
#10967: move regrtest over to using more unittest infrastructure
http://bugs.python.org/issue10967 opened by brett.cannon
#10968: threading.Timer should be a class so that it can be derived
http://bugs.python.org/issue10968 opened by Kain94
#10969: Make Tcl recommendation more prominent
http://bugs.python.org/issue10969 opened by rhettinger
#10970: "string".encode('base64') is not the same as base64.b64encode(
http://bugs.python.org/issue10970 opened by mahmoudimus
#10971: python Lib/test/regrtest.py -R 3:3: test_zipimport_support fai
http://bugs.python.org/issue10971 opened by haypo
#10972: zipfile: add "unicode" option to the force the filename encodi
http://bugs.python.org/issue10972 opened by haypo
#10973: 'ñ' not working with IDLE 3.2rc1 - OSX
[Python-Dev] Import and unicode: patch is ready for a review and tests
Hi, It looks like some people fear that non-ASCII module names will cause troubles for the interoperability: you can try my patch attached to issue #3080 to prevent these issues and fix all bugs :-) http://bugs.python.org/issue3080 I should maybe create a dummy Python project using non-ASCII module names to test it. I posted my patch on Rietveld: http://codereview.appspot.com/3972045 Victor ___ 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-checkins] devguide: Copy over the dev FAQ and *only* strip out stuff covered elsewhere in the
On Thu, Jan 20, 2011 at 16:58, Nick Coghlan wrote: > On Fri, Jan 21, 2011 at 6:42 AM, brett.cannon > wrote: >> brett.cannon pushed 82d3a1b694b3 to devguide: >> >> http://hg.python.org/devguide/rev/82d3a1b694b3 >> changeset: 167:82d3a1b694b3 >> user: Brett Cannon >> date: Thu Jan 20 12:40:47 2011 -0800 >> summary: >> Copy over the dev FAQ and *only* strip out stuff covered elsewhere in the >> devguide. Nick Coghlan should be a happy boy after this. > > Yay, thanks :) Watch what you wish for since you are now maintaining it. =) -Brett > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-checkins mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-checkins > ___ 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-checkins] devguide: Move Misc/README.Emacs to here.
It's the Emacs lovers who put that stuff in all of their files, so I ain't touching it. On Thu, Jan 20, 2011 at 13:06, Sandro Tosi wrote: > Hi, > > On Thu, Jan 20, 2011 at 20:33, brett.cannon > wrote: >> +.. >> + Local Variables: >> + mode: indented-text >> + indent-tabs-mode: nil >> + sentence-end-double-space: t >> + fill-column: 78 >> + coding: utf-8 >> + End: > > maybe this can be removed now > > Cheers, > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.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
Re: [Python-Dev] Import and unicode: part two
>> I don't think anybody is *encouraging* it. The argument is for >> *permitting* it, partly for consistency with other identifiers, and >> partly because of Python's usual "consenting adults" standard for >> permitting "dangerous" practices. > > I'm sorry, I was not clear. I was afraid that saying "learning > opportunity" tempt people to try non-ASCII module names. > In these days, even non technical people have access to Windows, Mac > and Linux boxes at a time. So chances to be annoyed with broken > non-ASCII named files are pretty common. Actually, as long people only involve Windows, or only involve Mac, it will all work just fine. It's only when they use non-Mac Unix (such as Linux), or try to move files across systems using sub-prime technology (such as your typical Windows zip utility) they will run into problems. But then it will be clear whom to blame - and people run in the same problems regardless of whether they move Python modules, or regular files (say, Word documents). So the more people get confronted with the poor support of non-ASCII file names in tools, the faster the tools will improve. It took PKWARE many years to come up with a reasonable Unicode story - but now it's really the tools that need to catch up, not the spec. 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
[Python-Dev] Triagers and checkin access to the devguide repository
Given that some of the dev guide docs cover triaging and other aspects of managing issues on the tracker, does it make sense to offer devguide checkin access to triagers that want it? Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
