Re: [Python-Dev] Dropping support for Win9x in 2.6
Zitat von Trent Mick <[EMAIL PROTECTED]>: > Are there specific code areas in mind that would be ripped out for this > or is this mainly to avoid having to test on and ensure new code is > compatible with? Primarily the non-W versions of the file system API. I think the W9x popen support could also go away. I don't think any testing happens for W9x; I (atleast) can't test it myself (I installed a Windows 95 system to test the 2.4 installer, but had to give up the machine shortly after that). 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] bytes.from_hex()
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: Greg> Stephen J. Turnbull wrote: >> the kind of "text" for which Unicode was designed is normally >> produced and consumed by people, who wll pt up w/ ll knds f >> nnsns. Base64 decoders will not put up with the same kinds of >> nonsense that people will. Greg> The Python compiler won't put up with that sort of nonsense Greg> either. Would you consider that makes Python source code Greg> binary data rather than text, and that it's inappropriate to Greg> represent it using a unicode string? The reason that Python source code is text is that the primary producers/consumers of Python source code are human beings, not compilers. There are no such human producers/consumers of base64. Unless you prefer that I expressed that last sentence as "VGhlIHJlYXNvbiB0aG F0IFB5dGhvbiBzb3VyY2UgY29kZSBpcyB0ZXh0IGlzIGJlY2F1c2UgdGhlIHByaW1 hcnkKcHJvZHVjZXJzL2NvbnN1bWVycyBvZiBQeXRob24gc291cmNlIGNvZGUgYXJl IGh1bWFuIGJlaW5ncywgbm90CmNvbXBpbGVycy4="? >> You're basically assuming that the person who implements the >> code that processes a Unicode string is the same person who >> implemented the code that converts a binary object into base64 >> and inserts it into a string. Greg> No, I'm assuming the user of base64 knows the Greg> characteristics of the channel he's using. Yes, which implies that you assume he has control of the data all the way to the channel that actually requires base64. Use case: the Gnus MUA supports the RFC that allows non-ASCII names in MIME headers that take file names. The interface was written for message-at-a-time use, which makes sense for composition. Somebody else added "save and strip part" editing capability, but this only works one MIME part at a time. So if you have a message with four MIME parts and you save and strip all of them, the first one gets encoded four times. The reason for *this* bug, and scores like it over the years, is that somebody made it convenient to put wire protocols into a text document. Shouldn't Python do better than that? Shouldn't Python text be for humans, rather than be whatever had the tag "character" attached to it for convenience of definition of a protocol for communication of data humans can't process without mechanical assistance? >> I don't think it's a good idea to gratuitously introduce wire >> protocols as unicode codecs, Greg> I am *not* saying that base64 is a unicode codec! If that's Greg> what you thought I was saying, it's no wonder we're Greg> confusing each other. I know you don't think that it's a duck, but it waddles and quacks. Ie, the question is not what I think you're saying. It's "what is the Python compiler/interpreter going to think?" AFAICS, it's going to think that base64 is a unicode codec. Greg> The only time I need to use something like base64 is when I Greg> have something that will only accept text. In Py3k, "accepts Greg> text" is going to mean "takes a character string as input", Characters are inherently abstract, as a class they can't be instantiated as input or output---only derived (ie, encoded) characters can. I don't believe that "takes a character string as input" has any intrinsic meaning. Greg> Does that make it clearer what I'm getting at? No. I already understood what you're getting at. As I said, I'm sympathetic in principle. In practice, I think it's a loaded gun aimed at my foot. And yours. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] PEP 328
Since I implemented[*] PEP 328, Aahz suggested I take over editing the PEP, too, as there were some minor discussion points to add still. I haven't been around for the discussioons, though, and it's been a while for everone else, I think, so I'd like to rehash and ask for any other open points. The one open point that Aahz forwarded me, and is expressed somewhat in http://mail.python.org/pipermail/python-dev/2004-September/048695.html , is the case where you have a package that you want to transparently supply a particular version of a module for forward/backward compatibility, replacing a version elsewhere on sys.path (if any.) I see four distinct situations for this: 1) Replacing a stdlib module (or a set of them) with a newer version, if the stdlib module is too old, where you want the whole stdlib to use the newer version. 2) Same as 1), but private to your package; modules not in your package should get the stdlib version when they import the 'replaced' module. 3) Providing a module (or a set of them) that the stdlib might be missing (but which will be a new enough version if it's there) 1) and 3) are easy to solve: put the module in a separate directory, insert that into sys.path; at the front for 1), at the end for 3). Mailman, IIRC, does this, and I think it works fine. 2) is easy if it's a single module; include it in your package and import it relatively. If it's a package itself, it's again pretty easy; include the package and include it relatively. The package itself is hopefully already using relative imports to get sibling packages. If the package is using absolute imports to get sibling packages, well, crap. I don't think we can solve that issue whatever we do: that already breaks. The real problem with 2) is when you have tightly coupled modules that are not together in a package and not using relative imports, or perhaps when you want to *partially* override a package. I would argue that tightly coupled modules should always use relative imports, whether they are together in a package or not (even though they should probably be in a package anyway.) I'd also argue that having different modules import different versions of existing modules is a bad idea. It's workable if the modules are only used internally, but exposing anything is troublesome. for instance, an instance of a class defined in foo (1.0) imported by bar will not be an instance of the same class defined in foo (1.1) imported by feeble. Am I missing anything? ([*] incorrectly, to be sure, but I have a 'correct' version ready that I'll upload in a second; I was trying to confuse Guido into accepting my version, instead.) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] bytes.from_hex()
> "Ron" == Ron Adam <[EMAIL PROTECTED]> writes: Ron> So, lets consider a "codec" and a "coding" as being two Ron> different things where a codec is a character sub set of Ron> unicode characters expressed in a native format. And a Ron> coding is *not* a subset of the unicode character set, but an Ron> _opperation_ performed on text. Ron> codec -> text is always in *one_codec* at any time. No, a codec is an operation, not a state. And text qua text has no need of state; the whole point of defining text (as in the unicode type) is to abstract from such representational issues. Ron> Pure codecs such as latin-1 can be envoked over and over and Ron> you can always get back what you put in in a single step. Maybe you'd like to define them that way, but it doesn't work in general. Given that str and unicode currently don't carry state with them, it's not possible for "to ASCII" and "to EBCDIC" to be idempotent at the same time. And for the languages spoken by 75% of the world's population, "to latin-1" cannot be successfully invoked even once, let alone be idempotent. You really need to think about how your examples apply to codecs like KOI8-R for Russian and Shift JIS for Japanese. In practice, I just don't think you can distinguish "codecs" from "coding" using the kind of mathematical properties you have described here. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] cProfile prints to stdout?
I just noticed that cProfile (like profile) prints to stdout. Yuck. I guess that's to be expected because the pstats module does the actual printing and it's used by both modules. I'm willing to give up backward compatibility to achieve a little more sanity and flexibility here. I propose rewriting the necessary bits to att a stream= keyword argument where necessary and using stream.write(...) or print >> stream, ... instead of the current bare print. I'd prefer the default for the stream be sys.stderr as well. Thoughts? 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
Re: [Python-Dev] cProfile prints to stdout?
On 2/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I just noticed that cProfile (like profile) prints to stdout. Yuck. I > guess that's to be expected because the pstats module does the actual > printing and it's used by both modules. I'm willing to give up backward > compatibility to achieve a little more sanity and flexibility here. I > propose rewriting the necessary bits to att a stream= keyword argument where > necessary and using stream.write(...) or print >> stream, ... instead of the > current bare print. I'd prefer the default for the stream be sys.stderr as > well. > > Thoughts? +0 from me (would be +1 since it seems very reasonable, but I never use profile and this will break some code somewhere). -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] cProfile prints to stdout?
[Skip] >I just noticed that cProfile (like profile) prints to stdout. Yuck. I > guess that's to be expected because the pstats module does the actual > printing and it's used by both modules. I'm willing to give up backward > compatibility to achieve a little more sanity and flexibility here. I > propose rewriting the necessary bits to att a stream= keyword argument where > necessary and using stream.write(...) or print >> stream, ... instead of the > current bare print. I'd prefer the default for the stream be sys.stderr as > well. > > Thoughts? FWIW, this idea has come-up a couple of times before so it should probably get fixed once and for all. Raymond ___ 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] cProfile prints to stdout?
[EMAIL PROTECTED] wrote: > I just noticed that cProfile (like profile) prints to stdout. Yuck. I > guess that's to be expected because the pstats module does the actual > printing and it's used by both modules. I'm willing to give up backward > compatibility to achieve a little more sanity and flexibility here. I > propose rewriting the necessary bits to att a stream= keyword argument where > necessary and using stream.write(...) or print >> stream, ... instead of the > current bare print. I'd prefer the default for the stream be sys.stderr as > well. Probably related: http://python.org/sf/1235266 Cheers, Georg ___ 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] cProfile prints to stdout?
Georg> Probably related: Georg> http://python.org/sf/1235266 Don't think so. That was just a documentation nit (and is now fixed and closed at any rate). 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
Re: [Python-Dev] cProfile prints to stdout?
[EMAIL PROTECTED] wrote: > Georg> Probably related: > > Georg> http://python.org/sf/1235266 > > Don't think so. That was just a documentation nit (and is now fixed and > closed at any rate). Well, it is another module that prints to stdout instead of stderr. Okay, not so closely related ;) Georg ___ 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] PEP 328
On 2/25/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > Since I implemented[*] PEP 328, Aahz suggested I take over editing the PEP, > too, as there were some minor discussion points to add still. I haven't been > around for the discussioons, though, and it's been a while for everone else, > I think, so I'd like to rehash and ask for any other open points. > > The one open point that Aahz forwarded me, and is expressed somewhat in > http://mail.python.org/pipermail/python-dev/2004-September/048695.html , is > the case where you have a package that you want to transparently supply a > particular version of a module for forward/backward compatibility, replacing > a version elsewhere on sys.path (if any.) I see four distinct situations for > this: > > 1) Replacing a stdlib module (or a set of them) with a newer version, if the > stdlib module is too old, where you want the whole stdlib to use the > newer version. > > 2) Same as 1), but private to your package; modules not in your package > should get the stdlib version when they import the 'replaced' module. > > 3) Providing a module (or a set of them) that the stdlib might be missing > (but which will be a new enough version if it's there) > > 1) and 3) are easy to solve: put the module in a separate directory, insert > that into sys.path; at the front for 1), at the end for 3). Mailman, IIRC, > does this, and I think it works fine. > > 2) is easy if it's a single module; include it in your package and import it > relatively. If it's a package itself, it's again pretty easy; include the > package and include it relatively. The package itself is hopefully already > using relative imports to get sibling packages. If the package is using > absolute imports to get sibling packages, well, crap. I don't think we can > solve that issue whatever we do: that already breaks. > > The real problem with 2) is when you have tightly coupled modules that are > not together in a package and not using relative imports, or perhaps when > you want to *partially* override a package. I would argue that tightly > coupled modules should always use relative imports, whether they are > together in a package or not (even though they should probably be in a > package anyway.) I'd also argue that having different modules import > different versions of existing modules is a bad idea. It's workable if the > modules are only used internally, but exposing anything is troublesome. for > instance, an instance of a class defined in foo (1.0) imported by bar will > not be an instance of the same class defined in foo (1.1) imported by > feeble. > > Am I missing anything? > > ([*] incorrectly, to be sure, but I have a 'correct' version ready that I'll > upload in a second; I was trying to confuse Guido into accepting my version, > instead.) One thing you're missing here is that the original assertion about the impossibility of editing the source code of the third-party package that's being incorporated into your distribution, is simply wrong. Systematically modifying all modules in a package to change their imports to assume a slightly different hierarchy can easily be done mechanically. I'd also add that eggs promise to provide a different solution for most concerns. I believe we should go ahead and implement PEP 338 faithfully without revisiting the decisions. If we were wrong (which I doubt) we'll have the opportunity to take a different direction in 2.6. -- --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] cProfile prints to stdout?
On 2/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I just noticed that cProfile (like profile) prints to stdout. Yuck. Can you clarify? Why is it wrong to send the output of the profiler to stdout? It seems to make sense to me that you should be able to redirect the profiler's output to a file with a simple ">file". -- --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] Translating docs
After a small talk with Raymond, yesterday in the breakfast, I proposed in PyAr the idea of start to translate the Library Reference. You'll agree with me that this is a BIG effort. But not only big, it's dynamic! So, we decided that we need a system that provide us the management of the translations. And it'd be a good idea the system to be available for translations in other languages. One of the guys proposed to use Launchpad (https://launchpad.net/). The question is, it's ok to use a third party system for this initiative? Or you (we) prefer to host it in-house? Someone alredy thought of this? Thank you! .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] PEP 328
"Thomas Wouters" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > The one open point that Aahz forwarded me, and is expressed somewhat in > http://mail.python.org/pipermail/python-dev/2004-September/048695.html , > is > the case where you have a package that you want to transparently supply a > particular version of a module for forward/backward compatibility, > replacing > a version elsewhere on sys.path (if any.) I see four distinct situations > for > this: Did you mean three? > 1) Replacing a stdlib module (or a set of them) with a newer version, if > the >stdlib module is too old, where you want the whole stdlib to use the >newer version. > > 2) Same as 1), but private to your package; modules not in your package >should get the stdlib version when they import the 'replaced' module. > > 3) Providing a module (or a set of them) that the stdlib might be missing >(but which will be a new enough version if it's there) Or did you forget the fourth? In any case, the easy solution to breaking code is to not do it until 3.0. There might never be a 2.7 to worry about. Terry Jan Reedy ___ 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] cProfile prints to stdout?
>> I just noticed that cProfile (like profile) prints to stdout. Yuck. Guido> Can you clarify? Why is it wrong to send the output of the Guido> profiler to stdout? If the program emits a bunch of output of its own I want to keep it separate from what is arguably the debug output of the profiler (even though the profiler prints all its output at the end): foo.py > /dev/null 2> foo.prof Guido> It seems to make sense to me that you should be able to redirect Guido> the profiler's output to a file with a simple ">file". It is currently impossible to separate profile output from the program's output. 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
Re: [Python-Dev] cProfile prints to stdout?
On 2/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >> I just noticed that cProfile (like profile) prints to stdout. Yuck. > > Guido> Can you clarify? Why is it wrong to send the output of the > Guido> profiler to stdout? > > If the program emits a bunch of output of its own I want to keep it separate > from what is arguably the debug output of the profiler (even though the > profiler prints all its output at the end): > > foo.py > /dev/null 2> foo.prof > > Guido> It seems to make sense to me that you should be able to redirect > Guido> the profiler's output to a file with a simple ">file". > > It is currently impossible to separate profile output from the program's > output. It is if you use the "advanced" use of the profiler -- the profiling run just saves the profiling data to a file, and the pstats module invoked separately prints the output. -- --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] defaultdict and on_missing()
FWIW this has now been checked in. Enjoy! --Guido On 2/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 2/22/06, Michael Chermside <[EMAIL PROTECTED]> wrote: > > A minor related point about on_missing(): > > > > Haven't we learned from regrets over the .next() method of iterators > > that all "magically" invoked methods should be named using the __xxx__ > > pattern? Shouldn't it be named __on_missing__() instead? > > Good point. I'll call it __missing__. I've uploaded a new patch to > python.org/sf/1433928. -- --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] bytes.from_hex()
Stephen J. Turnbull wrote:
> The reason that Python source code is text is that the primary
> producers/consumers of Python source code are human beings, not
> compilers
I disagree with "primary" -- I think human and computer
use of source code have equal importance. Because of the
fact that Python source code must be acceptable to the
Python compiler, a great many transformations that would
be harmless to English text (upper casing, paragraph
wrapping, etc.) would cause disaster if applied to a
Python program. I don't see how base64 is any different.
> Yes, which implies that you assume he has control of the data all the
> way to the channel that actually requires base64.
Yes. If he doesn't, he can't safely use base64 at all.
That's true regardless of how the base64-encoded data
is represented. It's true of any data of any kind.
> Use case: the Gnus MUA supports the RFC that allows non-ASCII names in
> MIME headers that take file names...
I'm not familiar with all the details you're alluding
to here, but if there's a bug here, I'd say it's due
to somebody not thinking something through properly.
It shouldn't matter if something gets encoded four
times as long as it gets decoded four times at the
other end. If it's not possible to do that, someone
made an assumption about the channel that wasn't
true.
> It's "what is the Python compiler/interpreter going
> to think?" AFAICS, it's going to think that base64 is
> a unicode codec.
Only if it's designed that way, and I specifically
think it shouldn't -- i.e. it should be an error
to attempt the likes of a_unicode_string.encode("base64")
or unicode(something, "base64"). The interface for
doing base64 encoding should be something else.
> I don't believe that "takes a character string as
> input" has any intrinsic meaning.
I'm using that phrase in the context of Python, where
it means "a function that takes a Python character
string as input".
In the particular case of base64, it has the added
restriction that it must preserve the particular
65 characters used.
> In practice, I think it's a loaded gun
> aimed at my foot. And yours.
Whereas it seems quite the opposite to me, i.e.
*failing* to clearly distinguish between text and
binary data here is what will lead to confusion and
foot-shooting.
I think we need some concrete use cases to talk
about if we're to get any further with this. Do
you have any such use cases in mind?
Greg
___
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] cProfile prints to stdout?
>> It is currently impossible to separate profile output from the >> program's output. Guido> It is if you use the "advanced" use of the profiler -- the Guido> profiling run just saves the profiling data to a file, and the Guido> pstats module invoked separately prints the output. Sure, but then it's not "simple". Your original example was "... > file". I'd like it to be (nearly) as easy to do it right yet keep it simple. 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
Re: [Python-Dev] Translating docs
Zitat von Facundo Batista <[EMAIL PROTECTED]>: > The question is, it's ok to use a third party system for this > initiative? Or you (we) prefer to host it in-house? Someone alredy > thought of this? I thought about it at one time, and I think the doc strings can be translated very well using gettext-based procedures; I once submitted a POT file to the translation project: http://www.iro.umontreal.ca/translation/registry.cgi?domain=python Translating the library reference as such is more difficult, because it can't be translated in small chunks very well. Some group of French translators once translated everything for 1.5.2, and that translation never got updated. 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] Translating docs
On Feb 25, 2006, at 4:43 PM, [EMAIL PROTECTED] wrote: > Zitat von Facundo Batista <[EMAIL PROTECTED]>: > >> The question is, it's ok to use a third party system for this >> initiative? Or you (we) prefer to host it in-house? Someone alredy >> thought of this? > > I thought about it at one time, and I think the doc strings can be > translated very well using gettext-based procedures; I once submitted > a POT file to the translation project: > > http://www.iro.umontreal.ca/translation/registry.cgi?domain=python > > Translating the library reference as such is more difficult, because > it can't be translated in small chunks very well. > > Some group of French translators once translated everything for 1.5.2, > and that translation never got updated. A similar situation applies to Italy -- a lot of stuff is translated at http://www.python.it/doc/Python-Docs/html/ (the C-API and Extending and Embedding aren't translated, though), but it's 2.3.4- vintage docs. There's no real mechanism or process to ensure updates. Alex ___ 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] bytes.from_hex()
Greg Ewing wrote:
> Stephen J. Turnbull wrote:
>> It's "what is the Python compiler/interpreter going
> > to think?" AFAICS, it's going to think that base64 is
> > a unicode codec.
>
> Only if it's designed that way, and I specifically
> think it shouldn't -- i.e. it should be an error
> to attempt the likes of a_unicode_string.encode("base64")
> or unicode(something, "base64"). The interface for
> doing base64 encoding should be something else.
I agree
> I think we need some concrete use cases to talk
> about if we're to get any further with this. Do
> you have any such use cases in mind?
>
> Greg
Or at least some where more concrete than trying to debate abstract
meanings. ;-)
Running a short test over all the codecs and converting u"Python" to
string and back to unicode resulted in the following output. These are
the only ones of the 92 that couldn't do the round trip successfully.
It seems to me these will need to be moved and/or made to work with
unicode at some point.
Test 1: UNICODE -> STRING -> UNICODE
1: 'bz2_codec'
Traceback (most recent call last):
File "codectest.py", line 29, in test1
u2 = unicode(s, c) # to unicode
TypeError: decoder did not return an unicode object (type=str)
2: 'hex_codec'
Traceback (most recent call last):
File "codectest.py", line 29, in test1
u2 = unicode(s, c) # to unicode
TypeError: decoder did not return an unicode object (type=str)
3: 'uu_codec'
Traceback (most recent call last):
File "codectest.py", line 29, in test1
u2 = unicode(s, c) # to unicode
TypeError: decoder did not return an unicode object (type=str)
4: 'quopri_codec'
Traceback (most recent call last):
File "codectest.py", line 29, in test1
u2 = unicode(s, c) # to unicode
TypeError: decoder did not return an unicode object (type=str)
5: 'base64_codec'
Traceback (most recent call last):
File "codectest.py", line 29, in test1
u2 = unicode(s, c) # to unicode
TypeError: decoder did not return an unicode object (type=str)
6: 'zlib_codec'
Traceback (most recent call last):
File "codectest.py", line 29, in test1
u2 = unicode(s, c) # to unicode
TypeError: decoder did not return an unicode object (type=str)
7: 'tactis'
Traceback (most recent call last):
File "codectest.py", line 28, in test1
s = u1.encode(c) # to string
LookupError: unknown encoding: tactis
___
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] Translating docs
2006/2/25, Alex Martelli <[EMAIL PROTECTED]>: > A similar situation applies to Italy -- a lot of stuff is translated > at http://www.python.it/doc/Python-Docs/html/ (the C-API and > Extending and Embedding aren't translated, though), but it's 2.3.4- > vintage docs. There's no real mechanism or process to ensure updates. We don't want that to happen, no. BTW, Alex, so bad you're not here. We miss you, :) .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Fwd: Translating docs
2006/2/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > Translating the library reference as such is more difficult, because > it can't be translated in small chunks very well. The SVN directory "python/dist/src/Doc/lib/" has 276 .tex's, with an average of 250 lines each. Maybe manage each file independently could work. > Some group of French translators once translated everything for 1.5.2, > and that translation never got updated. We're afraid of this. And that's why we think that it'd be necessary to have some automated system that tell us if the original file got updated, if there're new files to translate, to show the state of the translation (in process, finished, not even started, etc...). I think that a system like this is not so difficult, but if the wheel is already invented... .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes)
Almann T. Goo wrote: > One of the biggest points of contention to this is of course the > backwards incompatibility with a new keyword ... Alternatively, 'global' could be redefined to mean what we're thinking of for 'outer'. Then there would be no change in keywordage. There would be potential for breaking code, but I suspect the actual amount of breakage would be small, since there would have to be 3 scopes involved, with something in the middle one shadowing a global that was referenced in the inner one with a global statement. Given the rarity of global statement usage to begin with, I'd say that narrows things down to something well within the range of acceptable breakage in 3.0. Greg ___ 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] PEP for Better Control of Nested Lexical Scopes
On 2/22/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > That's what rankles people about this, I think -- there > doesn't seem to be a good reason for treating the global > scope so specially, given that all scopes could be > treated uniformly if only there were an 'outer' statement. > All the arguments I've seen in favour of the status quo > seem like rationalisations after the fact. I agree, hence my initial pre-PEP feeler on the topic ;). > > Since there were no nested lexical scopes back > > then, there was no need to have a construct for arbitrary enclosing > > scopes. > > However, if nested scopes *had* existed back then, I > rather suspect we would have had an 'outer' statement > from the beginning, or else 'global' would have been > given the semantics we are now considering for 'outer'. Would it not be so horrible to make "global" be the "outer"-type keyword--basically meaning "lexically global" versus "the global scope"? It would make the semantics for Python's nested lexical scopes to be more in line with other languages with this feature and fix my orthogonality gripes. As far as backwards compatibility, I doubt there would be too much impact in this regard, as places that would break would be where "global" was used in a closure where the name was shadowed in an enclosing scope. A "from __future__ import lexical_global" (which we'd have for adding the "outer"-like keyword anyway) could help diminish the growing pains. -Almann -- Almann T. Goo [EMAIL PROTECTED] ___ 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] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes)
On 2/26/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Alternatively, 'global' could be redefined to mean > what we're thinking of for 'outer'. Then there would > be no change in keywordage. > > There would be potential for breaking code, but I > suspect the actual amount of breakage would be > small, since there would have to be 3 scopes > involved, with something in the middle one > shadowing a global that was referenced in the > inner one with a global statement. > > Given the rarity of global statement usage to begin > with, I'd say that narrows things down to something > well within the range of acceptable breakage in 3.0. You read my mind--I made a reply similar to this on another branch of this thread just minutes ago :). I am curious to see what the community thinks about this. -Almann -- Almann T. Goo [EMAIL PROTECTED] ___ 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] Fwd: Translating docs
Facundo Batista wrote: > 2006/2/25, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: > >> Translating the library reference as such is more difficult, because >> it can't be translated in small chunks very well. > > The SVN directory "python/dist/src/Doc/lib/" has 276 .tex's, with an > average of 250 lines each. > > Maybe manage each file independently could work. > > >> Some group of French translators once translated everything for 1.5.2, >> and that translation never got updated. > > We're afraid of this. And that's why we think that it'd be necessary > to have some automated system that tell us if the original file got > updated, if there're new files to translate, to show the state of the > translation (in process, finished, not even started, etc...). > > I think that a system like this is not so difficult, but if the wheel > is already invented... Wouldn't a post-commit hook in SVN be enough? Also, the docs could be managed in a Wiki (or, if the translators know how to use it, in SVN too) so that translators can correct and revise what others have translated... Martin: There aren't any German docs, are there? Georg ___ 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] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes)
On 2/23/06, Steven Bethard <[EMAIL PROTECTED]> wrote: > On 2/22/06, Almann T. Goo <[EMAIL PROTECTED]> wrote: > > def incrementer_getter(val): > >def incrementer(): > >val = 5 > >def inc(): > >..val += 1 > >return val > >return inc > >return incrementer > > Sorry, what way did the user think? I'm not sure what you think was > supposed to happen. My apologies ... I shouldn't use vague terms like what the "user thinks." My problem, as is demonstrated in the above example, is that the implicit nature of evaluating a name in Python conflicts with the explicit nature of the proposed "dot" notation. It makes it easier for a user to write obscure code (until Python 3K when we force users to use "dot" notation for all enclosing scope access ;-) ). This sort of thing can be done today with code using attribute access on its module object to evaluate and rebind global names. With the "global" keyword however, users don't have to resort to this sort of trick. Because of Python's name binding semantics and the semantic for the "global" keyword, I think the case for an "outer"-type keyword is stronger and we could deprecate "global" going forward in Python 3K. One of the biggest points of contention to this is of course the backwards incompatibility with a new keyword ... Python has already recently added "yield" and we're about to get "with" and "as" in 2.5. As far as the "user-interface" of the language getting bloated, I personally think trading "global" for an "outer" mitigates that some. -Almann -- Almann T. Goo [EMAIL PROTECTED] ___ 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
