Re: [Python-Dev] buildbot is all green
Georg Brandl wrote: > Don't we have a Windows slave yet? No; nobody volunteered a machine yet (plus the hand-holding that is always necessary with Windows). 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] buildbot is all green
"Neal Norwitz" <[EMAIL PROTECTED]> writes: > http://www.python.org/dev/buildbot/ Wow, that's very cool! Cheers, mwh -- this "I hate c++" is so old it's as old as C++, yes -- from Twisted.Quotes ___ 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()
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > Martin v. Löwis wrote: >> M.-A. Lemburg wrote: > True. However, note that the .encode()/.decode() methods on > strings and Unicode narrow down the possible return types. > The corresponding .bytes methods should only allow bytes and > Unicode. I forgot that: what is the rationale for that restriction? >>> >>> To assure that only those types can be returned from those >>> methods, ie. instances of basestring, which in return permits >>> type inference for those methods. >> >> Hmm. So it for type inference >> Where is that documented? > > Somewhere in the python-dev mailing list archives ;-) > > Seriously, we should probably add this to the documentation. Err.. I don't think this is a good argument, for quite a few reasons. There certainly aren't many other features in Python designed to aid type inference and the knowledge that something returns "unicode or str" isn't especially useful... Cheers, mwh -- ROOSTA: Ever since you arrived on this planet last night you've been going round telling people that you're Zaphod Beeblebrox, but that they're not to tell anyone else. -- The Hitch-Hikers Guide to the Galaxy, Episode 7 ___ 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] r42490 - in python/branches/release24-maint: Lib/fileinput.py Lib/test/test_fileinput.py Misc/NEWS
Why are these new features being backported to 2.4 ?
georg.brandl wrote:
> Author: georg.brandl
> Date: Sun Feb 19 10:51:33 2006
> New Revision: 42490
>
> Modified:
>python/branches/release24-maint/Lib/fileinput.py
>python/branches/release24-maint/Lib/test/test_fileinput.py
>python/branches/release24-maint/Misc/NEWS
> Log:
> Patch #1337756: fileinput now accepts Unicode filenames.
>
>
> Modified: python/branches/release24-maint/Lib/fileinput.py
> ==
> --- python/branches/release24-maint/Lib/fileinput.py (original)
> +++ python/branches/release24-maint/Lib/fileinput.py Sun Feb 19 10:51:33 2006
> @@ -184,7 +184,7 @@
> """
>
> def __init__(self, files=None, inplace=0, backup="", bufsize=0):
> -if type(files) == type(''):
> +if isinstance(files, basestring):
> files = (files,)
> else:
> if files is None:
>
> Modified: python/branches/release24-maint/Lib/test/test_fileinput.py
> ==
> --- python/branches/release24-maint/Lib/test/test_fileinput.py
> (original)
> +++ python/branches/release24-maint/Lib/test/test_fileinput.pySun Feb
> 19 10:51:33 2006
> @@ -157,3 +157,13 @@
> verify(fi.lineno() == 6)
> finally:
> remove_tempfiles(t1, t2)
> +
> +if verbose:
> +print "15. Unicode filenames"
> +try:
> +t1 = writeTmp(1, ["A\nB"])
> +fi = FileInput(files=unicode(t1, sys.getfilesystemencoding()))
> +lines = list(fi)
> +verify(lines == ["A\n", "B"])
> +finally:
> +remove_tempfiles(t1)
>
> Modified: python/branches/release24-maint/Misc/NEWS
> ==
> --- python/branches/release24-maint/Misc/NEWS (original)
> +++ python/branches/release24-maint/Misc/NEWS Sun Feb 19 10:51:33 2006
> @@ -74,6 +74,8 @@
> Library
> ---
>
> +- Patch #1337756: fileinput now accepts Unicode filenames.
> +
> - Patch #1373643: The chunk module can now read chunks larger than
>two gigabytes.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 19 2006)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] Stateful codecs [Was: str object going in Py3K]
On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: > M.-A. Lemburg wrote: > > Walter Dörwald wrote: > >> Anyway, I've started implementing a patch that just adds > >> codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig, > >> UTF-16, UTF-16-LE and UTF-16-BE are already working. > > > > Nice :-) > > gencodec.py is updated now too. The rest should be manageble too. I'll leave > updating the CJKV codecs to Hye-Shik though. > Okay. I'll look whether how CJK codecs can be improved by the new protocol soon. I guess it'll be not so difficult because CJK codecs have a their own common stateful framework already. BTW, CJK codecs don't have V yet. :-) Hye-Shik ___ 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()
> "Ian" == Ian Bicking <[EMAIL PROTECTED]> writes: Ian> Encodings cover up eclectic interfaces, where those Ian> interfaces fit a basic pattern -- data in, data out. Isn't "filter" the word you're looking for? I think you've just made a very strong case that this is a slippery slope that we should avoid. -- 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
Re: [Python-Dev] [Python-checkins] r42490 - in python/branches/release24-maint: Lib/fileinput.py Lib/test/test_fileinput.py Misc/NEWS
Georg Brandl wrote: > M.-A. Lemburg wrote: >> Why are these new features being backported to 2.4 ? >> >> georg.brandl wrote: >>> Author: georg.brandl >>> Date: Sun Feb 19 10:51:33 2006 >>> New Revision: 42490 >>> >>> Modified: >>>python/branches/release24-maint/Lib/fileinput.py >>>python/branches/release24-maint/Lib/test/test_fileinput.py >>>python/branches/release24-maint/Misc/NEWS >>> Log: >>> Patch #1337756: fileinput now accepts Unicode filenames. > > Is that a new feature? I thought that wherever a filename is accepted, > it can be unicode too. > > The previous behavior was a bug in any case, since it treated the > unicode string as a sequence of filenames. Would you fix that by > raising a ValueError? No, but from the text in the NEWS file things sounded a lot like a feature rather than a bug fix. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 19 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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()
> "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
M> Martin v. Löwis wrote:
>> No. The reason to ban string.decode and bytes.encode is that it
>> confuses users.
M> Instead of starting to ban everything that can potentially
M> confuse a few users, we should educate those users and tell
M> them what these methods mean and how they should be used.
ISTM it's neither "potential" nor "a few".
As Aahz pointed out, for the common use of text I/O it requires only a
single clue ("Unicode is The One True Plain Text, everything else must
be decoded to Unicode before use.") and you don't need any "education"
about "how to use" codecs under Martin's restrictions; you just need
to know which ones to use.
This is not a benefit to be given up lightly.
Would it be reasonable to put those restrictions in the codecs? Ie,
so that bytes().encode('gzip') is allowed for the "generic" codec
'gzip', but bytes().encode('utf-8') is an error for the "charset"
codec 'utf-8'?
--
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
Re: [Python-Dev] 2.5 release schedule
Hi Neal & Jeremy, On Fri, Feb 17, 2006 at 10:53:19PM -0800, Neal Norwitz wrote: > I don't think it belongs in the PEP. I bumped the priority to 7 which > is the standard protocol, though I don't know that it's really > followed. Ok. > I will enumerate the existing problems for Jeremy in the > bug report. > > In the future, I would also prefer separate bug reports. Feel free > to assign new bugs to Jeremy too. :-) Thanks :-) A bientot, Armin ___ 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()
> "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
M> The main reason is symmetry and the fact that strings and
M> Unicode should be as similar as possible in order to simplify
M> the task of moving from one to the other.
Those are perfectly compatible with Martin's suggestion.
M> Still, I believe that this is an educational problem. There are
M> a couple of gotchas users will have to be aware of (and this is
M> unrelated to the methods in question):
But IMO that's wrong, both in attitude and in fact. As for attitude,
users should not have to be aware of these gotchas. Codec writers, on
the other hand, should be required to avoid presenting users with
those gotchas. Martin's draconian restriction is in the right
direction, but you can argue it goes way too far.
In fact, of course it's related to the methods in question.
"Original" vs "derived" data can only be defined in terms of some
notion of the "usual semantics" of the streams, and that is going to
be strongly reflected in the semantics of the methods.
M> * "encoding" always refers to transforming original data into a
M> derived form
M> * "decoding" always refers to transforming a derived form of
M> data back into its original form
Users *already* know that; it's a very strong connotation of the
English words. The problem is that users typically have their own
concept of what's original and what's derived. For example:
M> * for Unicode codecs the original form is Unicode, the derived
M> form is, in most cases, a string
First of all, that's Martin's point!
Second, almost all Americans, a large majority of Japanese, and I
would bet most Western Europeans would say you have that backwards.
That's the problem, and it's the Unicode advocates' problem (ie,
ours), not the users'. Even if we're right: education will require
lots of effort. Rather, we should just make it as easy as possible to
do it right, and hard to do it wrong.
BTW, what use cases do you have in mind for Unicode -> Unicode
decoding? Maximally decomposed forms and/or eliminating compatibility
characters etc? Very specialized.
M> Codecs also unify the various interfaces to common encodings
M> such as base64, uu or zip which are not Unicode related.
Now this is useful and has use cases I've run into, for example in
email, where you would like to use the same interface for base64 as
for shift_jis and you'd like to be able to write
def encode-mime-body (string, codec-list):
if codec-list[0] not in charset-codec-list:
raise NotCharsetCodecException
if len (codec-list) > 1 and codec-list[-1] not in transfer-codec-list:
raise NotTransferCodecException
for codec in codec-list:
string = string.encode (codec)
return string
mime-body = encode-mime-body ("This is a pen.",
[ 'shift_jis', 'zip', 'base64' ])
I guess I have to admit I'm backtracking from my earlier hardline
support for Martin's position, but I'm still sympathetic: (a) that's
the direct way to "make it easy to do it right", and (b) I still think
the use cases for non-Unicode codecs are YAGNI very often.
--
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] Enhancements to the fileinput module
I've just checked in some enhancements to the fileinput module. * fileno() to check the current file descriptor * mode argument to allow opening in universal newline mode * openhook argument to allow transparent opening of compressed or encoded files. Please feel free to comment. 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] Enhancements to the fileinput module
Georg Brandl wrote: > I've just checked in some enhancements to the fileinput module. > > * fileno() to check the current file descriptor > * mode argument to allow opening in universal newline mode > * openhook argument to allow transparent opening of compressed > or encoded files. > > Please feel free to comment. hey, where's the PEP, the endless thread where the same arguments are repeated over and over again, the -1 vetos from the peanut gallery, and the mandatory off-topic subthreads? (looks good to me. it might be idea to mention that hook_compressed uses the extension instead of the file signature to determine what de- compressor to use, though...) ___ 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] buildbot is all green
Benji York wrote: > Neal Norwitz wrote: >> http://www.python.org/dev/buildbot/ > > If there's interest in slightly nicer buildbot CSS (something like > http://buildbot.zope.org/) I'd be glad to contribute. +1. Looks nice! 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] bdist_* to stdlib?
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> On 2/16/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: >> /usr/share often is on a different mount; that's the whole >> rationale for /usr/share. Guido> I don't think I've worked at a place where something like Guido> that was done for at least 10 years. Isn't this argument Guido> outdated? I don't know. It may be obsolete in practice. I just know that I do it, and so do several of the people on Coda list. In my case, I don't do it because I'm short of disk space. I do it because my preferred distributed file system is Coda, which doesn't support exporting a local file system. You use a specialized server instead. Because Coda is designed for disconnected use, the files I actually am using are in the cache (200MB, so cache misses when disconnected are fairly rare). But if the host whose files I'm browsing gets an update and I'm connected, Coda automatically refreshes the cache. Coda is still not really production quality, and development on Coda and similar (eg Intermezzo) seem pretty slow, so this use case may never be of practical importance. -- 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
Re: [Python-Dev] bytes.from_hex()
> "Josiah" == Josiah Carlson <[EMAIL PROTECTED]> writes:
Josiah> The question remains: is str.decode() returning a string
Josiah> or unicode depending on the argument passed, when the
Josiah> argument quite literally names the codec involved,
Josiah> difficult to understand? I don't believe so; am I the
Josiah> only one?
Do you do any of the user education *about codec use* that you
recommend? The people I try to teach about coding invariably find it
difficult to understand. The problem is that the near-universal
intuition is that for "human-usable text" is pretty much anything *but
Unicode* will do. This is a really hard block to get them past.
There is very good reason why Unicode is plain text ("original" in
MAL's terms) and everything else is encoded ("derived"), but students
new to the concept often take a while to "get" it.
Maybe it's just me, but whether it's the teacher or the students, I am
*not* excited about the education route. Martin's simple rule *is*
simple, and the exceptions for using a "nonexistent" method mean I
don't have to reinforce---the students will be able to teach each
other. The exceptions also directly help reinforce the notion that
text == Unicode.
I grant the point that .decode('base64') is useful, but I also believe
that "education" is a lot more easily said than done in this case.
--
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
Re: [Python-Dev] Proposal: defaultdict
On 2/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > My post probably hasn't convinced you, but much of the confusion, I > believe, is based on Martin's original belief that 'k in dd' should > always return true if there is a default. One can argue that way, but > then you end up on the circular train of thought that gets you to "you > can't do anything useful if that is the case, .popitem() doesn't work, > len() is undefined, ...". Keep it simple, keep it sane. A default factory implementation fundamentally modifies the behavior of the mapping. There is no single answer to the question "what is the right behavior for contains, len, popitem" as that depends on what the code that consumes the mapping is written like, what it is attempting to do, and what you are attempting to override it to do. Or, simply, on why you are providing a default value. Resisting the temptation to guess the why and just leaving the methods as is seems the best choice; overriding __contains__ to return true is much easier than reversing that behavior would be. An example when it could theoretically be used, if not particularly useful. The gettext.install() function was just updated to take a names parameter which controls which gettext accessor functions it adds to the builtin namespace. Its implementation looks for "method in names" to decide. Passing a default-true dict would allow the future behavior to be bind all checked names, but only if __contains__ returns True. Even though it would make a poor base implementation, and these effects aren't a good candidate for it, the code style that could best leverage such a __contains__ exists. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ 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] buildbot is all green
Martin v. Löwis wrote: > I personally don't care much about the visual look of web pages. > However, people have commented that the buildbot page is ugly, > so yes, please do contribute something. See http://www.benjiyork.com/pybb. It doesn't look quite as good in IE because of the limited HTML the buildbot waterfall display generates and the limitations of IE's CSS support. > Bonus points for visually separating the "trunk" columns from > the "2.4" columns. The best I could do without hacking buildbot was to highlight the trunk "builder" links. This only works in Firefox, also because of IE's limited CSS2 support. More could be done if the HTML generation was modified, but that didn't seem prudent. -- Benji York ___ 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()
> "Bob" == Bob Ippolito <[EMAIL PROTECTED]> writes:
Bob> On Feb 17, 2006, at 8:33 PM, Josiah Carlson wrote:
>> But you aren't always getting *unicode* text from the decoding
>> of bytes, and you may be encoding bytes *to* bytes:
Please note that I presumed that you can indeed assume that decoding
of bytes always results in unicode, and encoding of unicode always
results in bytes. I believe Guido made the proposal relying on that
assumption too. The constructor notation makes no sense for making an
object of the same type as the original unless it's a copy constructor.
You could argue that the base64 language is indeed a different
language from the bytes language, and I'd agree. But since there's no
way in Python to determine whether a string that conforms to base64 is
supposed to be base64 or bytes, it would be a very bad idea to
interpret the distinction as one of type.
>> b2 = bytes(b, "base64")
>> b3 = bytes(b2, "base64")
>> Which direction are we going again?
Bob> This is *exactly* why the current set of codecs are INSANE.
Bob> unicode.encode and str.decode should be used *only* for
Bob> unicode codecs. Byte transforms are entirely different
Bob> semantically and should be some other method pair.
General filters are semantically different, I agree. But "encode" and
"decode" in English are certainly far more general than character
coding conversion. The use of those methods for any stream conversion
that is invertible (eg, compression or encryption) is not insane.
It's just pedagogically inconvenient given the existing confusion
(outside of python-dev, of course) about character coding
issues.
I'd like to rephrase your statement as "*only* unicode.encode and
str.decode should be used for unicode codecs". Ie, str.encode(codec)
and unicode.decode(codec) should raise errors if codec is a "unicode
codec". The question in my mind is whether we should allow other
kinds of codecs or not.
I could live with "not", but if we're going to have other kinds
of codecs, I think they should have concrete signatures. Ie,
basestring -> basestring shouldn't be allowed. Content transfer
encodings like BASE64 and quoted-printable, compression, encryption,
etc IMO should be bytes -> bytes. Overloading to unicode -> unicode
is sorta plausible for BASE64 or QP, but YAGNI. OTOH, the Unicode
standard does define a number of unicode -> unicode transformations,
and it might make sense to generalize to case conversions etc. (Note
that these conversions are pseudo-invertible, so you can think of them
as generalized .encode/.decode pairs. The inverse is usually the
identity, which seems weird, but from the pedagogical standpoint you
could handle that weirdness by raising an error if the .encode method
were invoked.)
To be concrete, I could imagine writing
s2 = s1.decode('upcase')
if s2 == s1:
print "Why are you shouting at me?"
else:
print "I like calm, well-spoken snakes."
s3 = s2.encode('upcase')
if s3 == s2:
print "Never fails!"
else:
print "See a vet; your Python is *very* sick."
I chose the decode method to do the non-trivial transformation because
.decode()'s value is supposed to be "original" text in MAL's terms.
And that's true of uppercase-only text; you're still supposed to be
able to read it, so I guess it's not "encoded". That's pretty
pedantic; I think it's better to raise on .encode('upcase').
--
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
Re: [Python-Dev] bytes.from_hex()
> "Bengt" == Bengt Richter <[EMAIL PROTECTED]> writes: Bengt> The characters in b could be encoded in plain ascii, or Bengt> utf16le, you have to know. Which base64 are you thinking about? Both RFC 3548 and RFC 2045 (MIME) specify subsets of US-ASCII explicitly. -- 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
Re: [Python-Dev] buildbot is all green
Benji York wrote: > Martin v. Löwis wrote: >> I personally don't care much about the visual look of web pages. >> However, people have commented that the buildbot page is ugly, >> so yes, please do contribute something. > > See http://www.benjiyork.com/pybb. > > It doesn't look quite as good in IE because of the limited HTML the > buildbot waterfall display generates and the limitations of IE's CSS > support. > >> Bonus points for visually separating the "trunk" columns from >> the "2.4" columns. > > The best I could do without hacking buildbot was to highlight the trunk > "builder" links. This only works in Firefox, also because of IE's > limited CSS2 support. > > More could be done if the HTML generation was modified, but that didn't > seem prudent. I'd like to see vertical lines between the column. Why is everything bold? Bye, Walter Dörwald ___ 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:
> BTW, what use cases do you have in mind for Unicode -> Unicode
> decoding?
I think "rot13" falls into that category: it is a transformation
on text, not on bytes.
For other "odd" cases: "base64" goes Unicode->bytes in the *decode*
direction, not in the encode direction. Some may argue that base64
is bytes, not text, but in many applications, you can combine base64
(or uuencode) with abitrary other text in a single stream. Of course,
it could be required that you go u.encode("ascii").decode("base64").
> def encode-mime-body (string, codec-list):
> if codec-list[0] not in charset-codec-list:
> raise NotCharsetCodecException
> if len (codec-list) > 1 and codec-list[-1] not in transfer-codec-list:
> raise NotTransferCodecException
> for codec in codec-list:
> string = string.encode (codec)
> return string
>
> mime-body = encode-mime-body ("This is a pen.",
> [ 'shift_jis', 'zip', 'base64' ])
I think this is an example where you *should* use the codec API,
as designed. As that apparently requires streams for stacking (ie.
no support for codec stacking), you would have to write
def encode_mime_body(string, codec_list):
stack = output = cStringIO.StringIO()
for codec in reversed(codec_list):
stack = codecs.getwriter(codec)(stack)
stack.write(string)
stack.reset()
return output.getValue()
Notice that you have to start the stacking with the last codec,
and you have to keep a reference to the StringIO object where
the actual bytes end up.
Regards,
Martin
P.S. there shows some LISP through in your Python code :-)
___
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: > Do you do any of the user education *about codec use* that you > recommend? The people I try to teach about coding invariably find it > difficult to understand. The problem is that the near-universal > intuition is that for "human-usable text" is pretty much anything *but > Unicode* will do. It really is a matter of education. For the first time in my career, I have been teaching the first-semester programming course, and I was happy to see that the text book already has a section on text and Unicode (actually, I selected the text book also based on whether there was good discussion of that aspect). So I spent quite some time with data representation (integrals, floats, characters), and I hope that the students now "got it". If they didn't learn it that way in the first semester (or already got mis-educated in highschool), it will be very hard for them to relearn. So I expect that it will take a decade or two until this all is common knowledge. 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()
Stephen J. Turnbull wrote:
> Bengt> The characters in b could be encoded in plain ascii, or
> Bengt> utf16le, you have to know.
>
> Which base64 are you thinking about? Both RFC 3548 and RFC 2045
> (MIME) specify subsets of US-ASCII explicitly.
Unfortunately, it is ambiguous as to whether they refer to US-ASCII,
the character set, or US-ASCII, the encoding. It appears that
RFC 3548 talks about the character set only:
- section 2.4 talks about "choosing an alphabet", and how it should
be possible for humans to handle such data.
- section 2.3 talks about non-alphabet characters
So it appears that RFC 3548 defines a conversion bytes->text.
To transmit this, you then also need encoding. MIME appears
to also use the US-ASCII *encoding* ("charset", in IETF speak),
for the "base64" Content-Transfer-Encoding.
For an example where base64 is *not* necessarily ASCII-encoded,
see the "binary" data type in XML Schema. There, base64 is embedded
into an XML document, and uses the encoding of the entire XML
document. As a result, you may get base64 data in utf16le.
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] buildbot is all green
Walter Dörwald wrote: > I'd like to see vertical lines between the column. Can you please elaborate? Between which columns? > Why is everything bold? Not sure. 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] buildbot is all green
Martin v. Löwis wrote: > Walter Dörwald wrote: >> I'd like to see vertical lines between the column. > > Can you please elaborate? Between which columns? Something like this: http://styx.livinglogic.de/~walter/python/buildbot.gif >> Why is everything bold? > > Not sure. Bye, Walter Dörwald ___ 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] r42396 - peps/trunk/pep-0011.txt
On 2/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > > > I don't have a strong opinion. Any one else have an opinion about > > removing --with-wctype-functions from configure? > > FWIW, I announced this plan in Dec 2004: > > http://mail.python.org/pipermail/python-dev/2004-December/050193.html > > I didn't get any replies back then, so assumed that no-one > would object, but forgot to add this to the PEP 11. > > The reason I'd like to get this removed early rather than > later is that some Linux distros happen to use the config > switch causing the Python Unicode implementation on those > distros to behave inconsistent with regular Python > builds. Like I said I don't have a strong opinion. At least update PEP 11 now. It would be good to ask on c.l.p. I suspect that no one cares enough about this flag to complain. So it's probably ok to remove it. But we should at least give people the opportunity to object. > Another candidate for removal is the --disable-unicode > switch. > > We should probably add a deprecation warning for that in > Py 2.5 and then remove the hundreds of > #idef Py_USING_UNICODE > from the source code in time for Py 2.6. I've heard of a bunch of people using --disable-unicode. I'm not sure if it's curiosity or if there are really production builds without unicode. Ask this on c.l.p too. We can update configure to add the warning and add a note to PEP 11. If we don't hear any complaints remove it for 2.6. If there are complaints, we can always back off. n ___ 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] Proposal: defaultdict
Michael Urman wrote: > On 2/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > >>My post probably hasn't convinced you, but much of the confusion, I >>believe, is based on Martin's original belief that 'k in dd' should >>always return true if there is a default. One can argue that way, but >>then you end up on the circular train of thought that gets you to "you >>can't do anything useful if that is the case, .popitem() doesn't work, >>len() is undefined, ...". Keep it simple, keep it sane. > > > A default factory implementation fundamentally modifies the behavior > of the mapping. There is no single answer to the question "what is the > right behavior for contains, len, popitem" as that depends on what the > code that consumes the mapping is written like, what it is attempting > to do, and what you are attempting to override it to do. Or, simply, > on why you are providing a default value. Resisting the temptation to > guess the why and just leaving the methods as is seems the best > choice; overriding __contains__ to return true is much easier than > reversing that behavior would be. I agree that there is simply no universally correct answer for the various uses of default_factory. I think ambiguity on points like this is a sign that something is overly general. In many of the concrete cases it is fairly clear how these methods should work. In the most obvious case (default_factory=list) what seems to be to be the correct implementation is one that no one is proposing, that is, "x in d" means "d.get(x)". But that uses the fact that the return value of default_factory() is a false value, which we cannot assume in general. And it effects .keys() -- which I would propose overriding for multidict (so it only returns keys with non-empty lists for values), but I don't see how it could be made correct for default_factory. I just don't see why we should cram all these potential features into dict by using a vague feature like default_factory. Why can't we just add a half-dozen new types of collections (to the module of the same name)? Each one will get its own page of documentation, a name, a proper __repr__, and well defined meaning for all of these methods that it shares with dict only insofar as it makes sense to share. Note that even if we use defaultdict or autodict or something besides changing dict itself, we still won't get a good __contains__, a good repr, or any of the other features that specific collection implementations will give us. Isn't there anyone else who sees the various dict-like objects being passed around as recipes, and thinks that maybe that's a sign they should go in the stdlib? The best of those recipes aren't all-encompassing, they just do one kind of container well. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.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] buildbot is all green
Walter Dörwald wrote: > I'd like to see vertical lines between the column. I've done a version like that (still at http://www.benjiyork.com/pybb). > Why is everything bold? I was trying to increase the legibility of the smaller type (a result of trying to fit more in the horizontal space). The current version is bold-free with slightly larger text. -- Benji York ___ 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] test_fileinput failing on Windows
This started failing since last night: C:\Code\python\PCbuild>python ..\lib\test\test_fileinput.py 1. Simple iteration (bs=0) 2. Status variables (bs=0) 3. Nextfile (bs=0) 4. Stdin (bs=0) 5. Boundary conditions (bs=0) 6. Inplace (bs=0) 7. Simple iteration (bs=30) 8. Status variables (bs=30) 9. Nextfile (bs=30) 10. Stdin (bs=30) 11. Boundary conditions (bs=30) 12. Inplace (bs=30) 13. 0-byte files 14. Files that don't end with newline 15. Unicode filenames 16. fileno() 17. Specify opening mode Traceback (most recent call last): File "..\lib\test\test_fileinput.py", line 201, in verify(lines == ["A\n", "B\n", "C\n", "D"]) File "C:\Code\python\lib\test\test_support.py", line 204, in verify raise TestFailed(reason) test.test_support.TestFailed: test failed `lines` at that point is ['A\n', 'B\n', '\n', 'C\n', 'D'] which indeed doesn't equal ["A\n", "B\n", "C\n", "D"] ___ 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] buildbot is all green
On 2/19/06, Benji York <[EMAIL PROTECTED]> wrote: > Walter Dörwald wrote: > > I'd like to see vertical lines between the column. > > I've done a version like that (still at http://www.benjiyork.com/pybb). I liked your current version better so I installed it. n ___ 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] buildbot is all green
Martin v. Löwis wrote: > Benji York wrote: > >>See http://www.benjiyork.com/pybb. > > > Great! you haven't explicitly stated that: may I copy this on > python.org? (I did, but I need confirmation) Sure! Feel free to use it as you wish. I replied to Walter Dörwald's suggestions and made a few changes, but don't know which I like better. If you prefer the new one at http://www.benjiyork.com/pybb you can use it as well. (copying python-dev as a permanent record of permission) -- Benji York ___ 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] test_fileinput failing on Windows
Never mind -- repaired it. ___ 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] New Module: CommandLoop
This is something I've been working on for a bit, and I think it is
more or less ready to bring up on this list. I'd like to add a module
(though probably not for 2.5).
Before you ask, this module is _not_ compatible with cmd.py, as it is
command oriented, whereas cmd.py is line oriented.
Anyway, I'm looking for feedback, feature requests before starting the
submission process.
Code available here:
http://littlelanguages.com/web/software/python/modules/cmdloop.py
Base class for writing simple interactive command loop environments.
CommandLoop provides a base class for writing simple interactive user
environments. It is designed around sub-classing, has a simple command
parser, and is trivial to initialize.
Here is a trivial little environment written using CommandLoop:
import cmdloop
class Hello(cmdloop.commandLoop):
PS1='hello>'
@cmdloop.aliases('hello', 'hi', 'hola')
@cmdloop.shorthelp('say hello')
@cmdloop.usage('hello TARGET')
def helloCmd(self, flags, args):
'''
Say hello to TARGET, which defaults to 'world'
'''
if flags or len(args) != 1:
raise cmdloop.InvalidArguments
print 'Hello %s!' % args[0]
@cmdloop.aliases('quit')
def quitCmd(self, flags, args):
'''
Quit the environment.
'''
raise cmdloop.HaltLoop
Hello().runLoop()
Here's a more complex example:
import cmdloop
class HelloGoodbye(cmdloop.CommandLoop):
PS1='hello>'
def __init__(self, default_target = 'world'):
self.default_target = default_target
self.target_list = []
@cmdloop.aliases('hello', 'hi', 'hola')
@cmdloop.shorthelp('say hello')
@cmdloop.usage('hello [TARGET]')
def helloCmd(self, flags, args):
'''
Say hello to TARGET, which defaults to 'world'
'''
if flags or len(args) > 1:
raise cmdloop.InvalidArguments
if args:
target = args[0]
else:
target = self.default_target
if target not in self.target_list:
self.target_list.append(target)
print 'Hello %s!' % target
@cmdloop.aliases('goodbye')
@cmdloop.shorthelp('say goodbye')
@cmdloop.usage('goodbye TARGET')
def goodbyeCmd(self, flags, args):
'''
Say goodbye to TARGET.
'''
if flags or len(args) != 1:
raise cmdloop.InvalidArguments
target = args[0]
if target in self.target_list:
print 'Goodbye %s!' % target
self.target_list.remove(target)
else:
print "I haven't said hello to %s." % target
@cmdloop.aliases('quit')
def quitCmd(self, flags, args):
'''
Quit the environment.
'''
raise cmdloop.HaltLoop
def _onLoopExit(self):
if len(self.target_list):
self.pushCommands(('quit',))
for target in self.target_list:
self.pushCommands(('goodbye', target))
else:
raise cmdloop.HaltLoop
HelloGoodbye().runLoop()
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
oops, error in the example: s/commandLoop/CommandLoop/g
On 2/19/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> This is something I've been working on for a bit, and I think it is
> more or less ready to bring up on this list. I'd like to add a module
> (though probably not for 2.5).
>
> Before you ask, this module is _not_ compatible with cmd.py, as it is
> command oriented, whereas cmd.py is line oriented.
>
> Anyway, I'm looking for feedback, feature requests before starting the
> submission process.
>
> Code available here:
> http://littlelanguages.com/web/software/python/modules/cmdloop.py
>
> Base class for writing simple interactive command loop environments.
>
> CommandLoop provides a base class for writing simple interactive user
> environments. It is designed around sub-classing, has a simple command
> parser, and is trivial to initialize.
>
> Here is a trivial little environment written using CommandLoop:
>
> import cmdloop
>
> class Hello(cmdloop.commandLoop):
> PS1='hello>'
>
> @cmdloop.aliases('hello', 'hi', 'hola')
> @cmdloop.shorthelp('say hello')
> @cmdloop.usage('hello TARGET')
> def helloCmd(self, flags, args):
> '''
> Say hello to TARGET, which defaults to 'world'
> '''
> if flags or len(args) != 1:
> raise cmdloop.InvalidArguments
> print 'Hello %s!' % args[0]
>
> @cmdloop.aliases('quit')
> def quitCmd(self, flags, args):
> '''
> Quit the environment.
> '''
> raise cmdloop.HaltLoop
>
> Hello().runLoop()
>
> Here's a more complex example:
>
> import cmdloop
>
> class HelloGoodbye(cmdloop.CommandLoop):
> PS1='hello>'
>
> def __init__(self, default_target = 'world'):
> self.default_target = default_target
> self.target_list = []
>
> @cmdloop.aliases('hello', 'hi', 'hola')
> @cmdloop.shorthelp('say hello')
> @cmdloop.usage('hello [TARGET]')
> def helloCmd(self, flags, args):
> '''
> Say hello to TARGET, which defaults to 'world'
> '''
> if flags or len(args) > 1:
> raise cmdloop.InvalidArguments
> if args:
> target = args[0]
> else:
> target = self.default_target
> if target not in self.target_list:
> self.target_list.append(target)
> print 'Hello %s!' % target
>
> @cmdloop.aliases('goodbye')
> @cmdloop.shorthelp('say goodbye')
> @cmdloop.usage('goodbye TARGET')
> def goodbyeCmd(self, flags, args):
> '''
> Say goodbye to TARGET.
> '''
> if flags or len(args) != 1:
> raise cmdloop.InvalidArguments
> target = args[0]
> if target in self.target_list:
> print 'Goodbye %s!' % target
> self.target_list.remove(target)
> else:
> print "I haven't said hello to %s." % target
>
> @cmdloop.aliases('quit')
> def quitCmd(self, flags, args):
> '''
> Quit the environment.
> '''
> raise cmdloop.HaltLoop
>
> def _onLoopExit(self):
> if len(self.target_list):
> self.pushCommands(('quit',))
> for target in self.target_list:
> self.pushCommands(('goodbye', target))
> else:
> raise cmdloop.HaltLoop
>
> HelloGoodbye().runLoop()
>
> --
> Crutcher Dunnavant <[EMAIL PROTECTED]>
> littlelanguages.com
> monket.samedi-studios.com
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
On 2/19/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > This is something I've been working on for a bit, and I think it is > more or less ready to bring up on this list. I'd like to add a module > (though probably not for 2.5). > > Before you ask, this module is _not_ compatible with cmd.py, as it is > command oriented, whereas cmd.py is line oriented. > > Anyway, I'm looking for feedback, feature requests before starting the > submission process. > > Code available here: > http://littlelanguages.com/web/software/python/modules/cmdloop.py Just so you know, there is a basic rule that all new modules need to have been used in the while and generally accepted and used by the Python community before being accepted. While this is not a hard rule, it is mostly followed so if there is no visible use of the module by the rest of the world it will be difficult to get it accepted. -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] New Module: CommandLoop
Yes, I know. Hence this not being a patch. This is really meant to be a compelling alternative to cmd.Cmd, and as such I'm trying to get some discussion about it. On 2/19/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 2/19/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote: > > This is something I've been working on for a bit, and I think it is > > more or less ready to bring up on this list. I'd like to add a module > > (though probably not for 2.5). > > > > Before you ask, this module is _not_ compatible with cmd.py, as it is > > command oriented, whereas cmd.py is line oriented. > > > > Anyway, I'm looking for feedback, feature requests before starting the > > submission process. > > > > Code available here: > > http://littlelanguages.com/web/software/python/modules/cmdloop.py > > Just so you know, there is a basic rule that all new modules need to > have been used in the while and generally accepted and used by the > Python community before being accepted. While this is not a hard > rule, it is mostly followed so if there is no visible use of the > module by the rest of the world it will be difficult to get it > accepted. > > -Brett > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] Proposal: defaultdict
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > [Terry Reedy] >> One is a 'universal dict' that maps every key to something -- the >> default if >> nothing else. That should not have the default ever explicitly entered. >> Udict.keys() should only give the keys *not* mapped to the universal >> value. > > Would you consider it a mapping invariant that "k in dd" implies "k in > dd.keys()"? > > Is the notion of __contains__ at odds with notion of universality? No and not sure. I'll leave it to Martin v. Löwis to explain/defend his particular notion of a udict. My main point is that there are multiple legitimate variations of the notion of a default dict, so that there is no 'one right way' to design one. I notice that Michael Urman and Ian Bicking said much the same today. Of course, having said that different variations are useful in different situations, I would nowise claim that all variations can serve as drop-in replacements for regular dicts everywhere they are now used. I think that a new default-dict feature should cater to such variations. Beyond that, I don't know whether it is better to modify dict (with blank hooks) or add a new subclassable default-dict base type. 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] bytes.from_hex()
On Feb 19, 2006, at 10:55 AM, Martin v. Löwis wrote:
> Stephen J. Turnbull wrote:
>> BTW, what use cases do you have in mind for Unicode -> Unicode
>> decoding?
>
> I think "rot13" falls into that category: it is a transformation
> on text, not on bytes.
The current implementation is a transformation on bytes, not text.
Conceptually though, it's a text->text transform.
> For other "odd" cases: "base64" goes Unicode->bytes in the *decode*
> direction, not in the encode direction. Some may argue that base64
> is bytes, not text, but in many applications, you can combine base64
> (or uuencode) with abitrary other text in a single stream. Of course,
> it could be required that you go u.encode("ascii").decode("base64").
I would say that base64 is bytes->bytes. Just because those bytes
happen to be in a subset of ASCII, it's still a serialization meant
for wire transmission. Sometimes it ends up in unicode (e.g. in
XML), but that's the exception not the rule.
-bob
___
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] buildbot is all green
> No; nobody volunteered a machine yet (plus the hand-holding that > is always necessary with Windows). What exactly is needed for this? Does it need to be a machine dedicated to this stuff, or could I just run the tests once every day or so when I feel like it and have them submitted to buildbot? Regards, Manuzhai ___ 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] buildbot is all green
Neal Norwitz wrote: > On 2/19/06, Benji York <[EMAIL PROTECTED]> wrote: >> Walter Dörwald wrote: >>> I'd like to see vertical lines between the column. >> I've done a version like that (still at http://www.benjiyork.com/pybb). > > I liked your current version better so I installed it. How about this one: http://styx.livinglogic.de/~walter/python/BuildBot_%20Python.html Bye, Walter Dörwald ___ 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] New Module: CommandLoop
[Crutcher Dunnavant]
> Anyway, I'm looking for feedback, feature requests before starting the
> submission process.
With respect to the API, the examples tend to be visually dominated dominated
by
the series of decorators. The three decorators do nothing more than add a
function attribute, so they are essentially doing the same type of action.
Consider combining those into a single decorator and using keywords for the
various arguments. For example, change:
@cmdloop.aliases('goodbye')
@cmdloop.shorthelp('say goodbye')
@cmdloop.usage('goodbye TARGET')
to just:
@cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
usage='goodbye TARGET')
leaving the possibility of multiple decorators when one line gets to long:
@cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
@cmdloop.addspec(usage='goodbye TARGET # where TARGET is a filename in
the current directory')
Another thought on the API is to consider adding another decorator option to
make commands case-insensitive so that 'help', 'HELP', and 'Help' will all work:
@cmdloop.addspec(case_sensitive=True)
Also, in the absence of readline(), consider adding support for "!" style
repeats of previous commands.
The exception hierarchy looks to be well-designed. I'm not clear on whether it
is internal or part of the API. If the latter, is there an example of how to
trap and handle specific exceptions in specific contexts?
If you're interested, here are a few code comments based on my first
read-through:
1) The "chars" variable can be eliminated and the "while chars" and
"c=chars.pop(0)" sequence simplified to just:
for c in reversed(str):
. . .
2) Can the reformatDocString() function be replaced by textwrap.dedent() or do
they do something different?
3) In _mapCommands(), the sort can be simplified from:
self._cmds.sort(lambda a, b: cmp(a.aliases[0], b.aliases[0]))
to:
self._cmds.sort(key=operator.itemgetter(0))
or if you want to avoid module dependencies:
self._cmds.sort(key=lambda a: a[0])
4) In _preCommand, the sort simplifies from:
names = self.aliasdict.keys()
names.sort()
for name in names:
to:
for name in sorted(self.aliasdict):
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] buildbot is all green
On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > On 2/19/06, Benji York <[EMAIL PROTECTED]> wrote: > >> Walter Dörwald wrote: > >>> I'd like to see vertical lines between the column. > >> I've done a version like that (still at http://www.benjiyork.com/pybb). > > > > I liked your current version better so I installed it. > > How about this one: > http://styx.livinglogic.de/~walter/python/BuildBot_%20Python.html > I like it. It's really nice to be able to fit it all on a single screen (at least for me). Seems slightly crisper to me as well. -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] buildbot is all green
On Sunday 19 February 2006 16:14, Benji York wrote: > I replied to Walter Dörwald's suggestions and made a few changes, but > don't know which I like better. If you prefer the new one at > http://www.benjiyork.com/pybb you can use it as well. I like the new one better; any chance we can switch to that on buildbot.zope.org as well? ;-) The improved use of horizontal space is good. -Fred -- Fred L. Drake, Jr. ___ 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] buildbot is all green
On Sunday 19 February 2006 18:07, Walter Dörwald wrote: > How about this one: > http://styx.livinglogic.de/~walter/python/BuildBot_%20Python.html Sigh. This is nice too. Now I'm not sure which I'd rather see on zope.org. ;-) -Fred -- Fred L. Drake, Jr. ___ 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] New Module: CommandLoop
[Raymond Hettinger] > 1) The "chars" variable can be eliminated and the "while chars" and > "c=chars.pop(0)" sequence simplified to just: >for c in reversed(str): Actually, that should have been just: for c in str: . . . 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] New Module: CommandLoop
Whoa, thanks. Incorporated the suggestions to the code.
On 2/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Crutcher Dunnavant]
> > Anyway, I'm looking for feedback, feature requests before starting the
> > submission process.
>
> With respect to the API, the examples tend to be visually dominated dominated
> by
> the series of decorators. The three decorators do nothing more than add a
> function attribute, so they are essentially doing the same type of action.
> Consider combining those into a single decorator and using keywords for the
> various arguments. For example, change:
>
> @cmdloop.aliases('goodbye')
> @cmdloop.shorthelp('say goodbye')
> @cmdloop.usage('goodbye TARGET')
>
> to just:
>
> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
> usage='goodbye TARGET')
>
> leaving the possibility of multiple decorators when one line gets to long:
>
> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
> @cmdloop.addspec(usage='goodbye TARGET # where TARGET is a filename
> in
> the current directory')
Well, why not support both, and leave it up to the user?
> Another thought on the API is to consider adding another decorator option to
> make commands case-insensitive so that 'help', 'HELP', and 'Help' will all
> work:
> @cmdloop.addspec(case_sensitive=True)
shouldn't this be a property of the shell, and not the individual commands?
Perhaps a CASE_SENSITIVE=False attribute on the shell?
> Also, in the absence of readline(), consider adding support for "!" style
> repeats of previous commands.
How would this work? Would it be a simple replay of the previous
command? Would it search a command history? How do we make it interact
with the _preCommand code? I'm not sure how to make this work.
> The exception hierarchy looks to be well-designed. I'm not clear on whether
> it
> is internal or part of the API. If the latter, is there an example of how to
> trap and handle specific exceptions in specific contexts?
The exceptions are part of the API, but are only meant to be thrown by
user code, and handled by the module code. There aren't any situations
when user code needs to catch modules that I know of.
> If you're interested, here are a few code comments based on my first
> read-through:
>
> 1) The "chars" variable can be eliminated and the "while chars" and
> "c=chars.pop(0)" sequence simplified to just:
> for c in reversed(str):
> . . .
chars is something of a navel. The parser went through some evolution,
and for a time, it _didn't_ consume a character every time arround.
However, the chars are not reversed, so given s/str/cmdline/g:
for c in cmdline:
...
> 2) Can the reformatDocString() function be replaced by textwrap.dedent() or do
> they do something different?
I guess so, they seem to do the same thing.
> 3) In _mapCommands(), the sort can be simplified from:
> self._cmds.sort(lambda a, b: cmp(a.aliases[0], b.aliases[0]))
> to:
> self._cmds.sort(key=operator.itemgetter(0))
> or if you want to avoid module dependencies:
> self._cmds.sort(key=lambda a: a[0])
well, almost. we are sorting on the aliases, so
self._cmds.sort(key=lambda a: a.aliases[0])
> 4) In _preCommand, the sort simplifies from:
> names = self.aliasdict.keys()
> names.sort()
> for name in names:
> to:
> for name in sorted(self.aliasdict):
>
cool.
> Raymond
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] New Module: CommandLoop
s/catch modules/catch exceptions/g
On 2/19/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> Whoa, thanks. Incorporated the suggestions to the code.
>
> On 2/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > [Crutcher Dunnavant]
> > > Anyway, I'm looking for feedback, feature requests before starting the
> > > submission process.
> >
> > With respect to the API, the examples tend to be visually dominated
> > dominated by
> > the series of decorators. The three decorators do nothing more than add a
> > function attribute, so they are essentially doing the same type of action.
> > Consider combining those into a single decorator and using keywords for the
> > various arguments. For example, change:
> >
> > @cmdloop.aliases('goodbye')
> > @cmdloop.shorthelp('say goodbye')
> > @cmdloop.usage('goodbye TARGET')
> >
> > to just:
> >
> > @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
> > usage='goodbye TARGET')
> >
> > leaving the possibility of multiple decorators when one line gets to long:
> >
> > @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
> > @cmdloop.addspec(usage='goodbye TARGET # where TARGET is a
> > filename in
> > the current directory')
>
> Well, why not support both, and leave it up to the user?
>
> > Another thought on the API is to consider adding another decorator option to
> > make commands case-insensitive so that 'help', 'HELP', and 'Help' will all
> > work:
> > @cmdloop.addspec(case_sensitive=True)
>
> shouldn't this be a property of the shell, and not the individual commands?
> Perhaps a CASE_SENSITIVE=False attribute on the shell?
>
> > Also, in the absence of readline(), consider adding support for "!" style
> > repeats of previous commands.
>
> How would this work? Would it be a simple replay of the previous
> command? Would it search a command history? How do we make it interact
> with the _preCommand code? I'm not sure how to make this work.
>
> > The exception hierarchy looks to be well-designed. I'm not clear on
> > whether it
> > is internal or part of the API. If the latter, is there an example of how
> > to
> > trap and handle specific exceptions in specific contexts?
>
> The exceptions are part of the API, but are only meant to be thrown by
> user code, and handled by the module code. There aren't any situations
> when user code needs to catch modules that I know of.
>
> > If you're interested, here are a few code comments based on my first
> > read-through:
> >
> > 1) The "chars" variable can be eliminated and the "while chars" and
> > "c=chars.pop(0)" sequence simplified to just:
> > for c in reversed(str):
> > . . .
>
> chars is something of a navel. The parser went through some evolution,
> and for a time, it _didn't_ consume a character every time arround.
> However, the chars are not reversed, so given s/str/cmdline/g:
>
> for c in cmdline:
> ...
>
> > 2) Can the reformatDocString() function be replaced by textwrap.dedent() or
> > do
> > they do something different?
>
> I guess so, they seem to do the same thing.
>
> > 3) In _mapCommands(), the sort can be simplified from:
> > self._cmds.sort(lambda a, b: cmp(a.aliases[0], b.aliases[0]))
> > to:
> > self._cmds.sort(key=operator.itemgetter(0))
> > or if you want to avoid module dependencies:
> > self._cmds.sort(key=lambda a: a[0])
>
> well, almost. we are sorting on the aliases, so
> self._cmds.sort(key=lambda a: a.aliases[0])
>
> > 4) In _preCommand, the sort simplifies from:
> > names = self.aliasdict.keys()
> > names.sort()
> > for name in names:
> > to:
> > for name in sorted(self.aliasdict):
> >
>
> cool.
>
> > Raymond
> >
>
>
> --
> Crutcher Dunnavant <[EMAIL PROTECTED]>
> littlelanguages.com
> monket.samedi-studios.com
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] Removing Non-Unicode Support?
Neal Norwitz wrote: > On 2/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > >>Neal Norwitz wrote: > > >>Another candidate for removal is the --disable-unicode >>switch. >> >>We should probably add a deprecation warning for that in >>Py 2.5 and then remove the hundreds of >>#idef Py_USING_UNICODE >>from the source code in time for Py 2.6. > > I've heard of a bunch of people using --disable-unicode. I'm not sure > if it's curiosity or if there are really production builds without > unicode. Ask this on c.l.p too. Such a switch quite likely is useful to those creating Python interpreters for small hand-held devices, where space is at a premium. I would hesitate to remove switches to drop features in general, for that reason. Although I have played with reducing the footprint of Python, I am not currently doing so. I could never get the footprint down sufficiently to make it usable, unfortunately. But I would like to see the Python developers maintain an awareness of memory consumption and not assume that Python is always run on modern fully-loaded desktops. We are seeing increasing use of Python in embedded systems these days. -Jeff ___ 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] New Module: CommandLoop
>> @cmdloop.aliases('goodbye')
>> @cmdloop.shorthelp('say goodbye')
>> @cmdloop.usage('goodbye TARGET')
>>
>> to just:
>>
>> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
>> usage='goodbye TARGET')
>>
>> leaving the possibility of multiple decorators when one line gets to long:
>>
>> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
>> @cmdloop.addspec(usage='goodbye TARGET # where TARGET is a filename
>> in
>> the current directory')
> Well, why not support both, and leave it up to the user?
Having only one method keeps the API simple. Also, the addspec() approach
allows the user to choose between single and multiple lines.
BTW, addspec() could be made completely general by supporting all possible
keywords at once:
def addspec(**kwds):
def decorator(func):
func.__dict__.update(kwds)
return func
return decorator
With an open definition like that, users can specify new attributes with less
effort.
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] buildbot is all green
Manuzhai wrote: >>No; nobody volunteered a machine yet (plus the hand-holding that >>is always necessary with Windows). > > > What exactly is needed for this? Does it need to be a machine dedicated > to this stuff, or could I just run the tests once every day or so when I > feel like it and have them submitted to buildbot? "The point" of buildbot (atleast the way we use it) is to see immediately what check-in broke the tests on some platform. So yes, permanent availability would be desirable. However, buildbot runs in the background (atleast on Unix), and gets triggered whenever a checkin occurs. So the machine doesn't have to be *dedicated*; any machine that is always on might do. 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] New Module: CommandLoop
On 2/19/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >> @cmdloop.aliases('goodbye')
> >> @cmdloop.shorthelp('say goodbye')
> >> @cmdloop.usage('goodbye TARGET')
> >>
> >> to just:
> >>
> >> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye',
> >> usage='goodbye TARGET')
> >>
> >> leaving the possibility of multiple decorators when one line gets to long:
> >>
> >> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say goodbye')
> >> @cmdloop.addspec(usage='goodbye TARGET # where TARGET is a
> >> filename
> >> in
> >> the current directory')
>
> > Well, why not support both, and leave it up to the user?
>
> Having only one method keeps the API simple. Also, the addspec() approach
> allows the user to choose between single and multiple lines.
>
> BTW, addspec() could be made completely general by supporting all possible
> keywords at once:
>
> def addspec(**kwds):
> def decorator(func):
> func.__dict__.update(kwds)
> return func
> return decorator
>
> With an open definition like that, users can specify new attributes with less
> effort.
Well, yes it could. But as it currently stands, there is no mechanism
for user code to manipulate commands, so that would be of limited
utility, versus throwing errors if the user specified something
unsupported.
>
>
> Raymond
>
>
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.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] buildbot is all green
Benji York wrote: > See http://www.benjiyork.com/pybb. > > It doesn't look quite as good in IE because of the limited HTML the > buildbot waterfall display generates and the limitations of IE's CSS > support. Thanks again for the contribution! > The best I could do without hacking buildbot was to highlight the trunk > "builder" links. This only works in Firefox, also because of IE's > limited CSS2 support. > > More could be done if the HTML generation was modified, but that didn't > seem prudent. I looked at it, and it would require quite a lot of changes to the buildbot, so I abstain from wanting such a thing (atleast for the moment). Your regex-matching (or whatever the mechanism is) works quite well for me. 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] New Module: CommandLoop
On Feb 19, 2006, at 5:03 PM, Raymond Hettinger wrote:
>>> @cmdloop.aliases('goodbye')
>>> @cmdloop.shorthelp('say goodbye')
>>> @cmdloop.usage('goodbye TARGET')
>>>
>>> to just:
>>>
>>> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say
>>> goodbye',
>>> usage='goodbye TARGET')
>>>
>>> leaving the possibility of multiple decorators when one line gets
>>> to long:
>>>
>>> @cmdloop.addspec(aliases=['goodbye'], shorthelp ='say
>>> goodbye')
>>> @cmdloop.addspec(usage='goodbye TARGET # where TARGET is
>>> a filename
>>> in
>>> the current directory')
>
>> Well, why not support both, and leave it up to the user?
>
> Having only one method keeps the API simple. Also, the addspec()
> approach
> allows the user to choose between single and multiple lines.
>
> BTW, addspec() could be made completely general by supporting all
> possible
> keywords at once:
>
> def addspec(**kwds):
> def decorator(func):
> func.__dict__.update(kwds)
> return func
> return decorator
>
> With an open definition like that, users can specify new attributes
> with less
> effort.
Doesn't this discussion belong on c.l.p / python-list?
-bob
___
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] New Module: CommandLoop
I know it is tempting and perhaps ok in your own privatecode, but casually masking builtins like 'str' in public library code sets a bad example ;-). tjr ___ 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] buildbot is all green
>>>is always necessary with Windows). With a couple of more machines added, should there be two separate pages for trunk and 2.4 builds? Or do most checkins affect both? ___ 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] javascript "standing on Python's shoulders" as it moves forward.
Sorry for the slightly off-topic post, but I thought it of interest that Brendan Eich (the "father" of javascript) has blogged about the future of js, and specifically how he will "borrow from Python for iteration, generators, and comprehensions" and more generally why he is "standing on Pythons shoulders" when appropriate. http://weblogs.mozillazine.org/roadmap/archives/2006/02/ The fact my name appears there is a happy coincidence related to the fact I am working with Mozilla on making their DOM "language agnostic" and supporting Python - but the general reasons why Python is seen as important is interesting... Mark ___ 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] New Module: CommandLoop
totally agree, removed them. On 2/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > I know it is tempting and perhaps ok in your own privatecode, but casually > masking builtins like 'str' in public library code sets a bad example ;-). > > tjr > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/crutcher%40gmail.com > -- Crutcher Dunnavant <[EMAIL PROTECTED]> littlelanguages.com monket.samedi-studios.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] New Module: CommandLoop
Bob Ippolito wrote: > Doesn't this discussion belong on c.l.p / python-list? yes, please. ___ 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] Proposal: defaultdict
"Michael Urman" <[EMAIL PROTECTED]> wrote: > > On 2/19/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > My post probably hasn't convinced you, but much of the confusion, I > > believe, is based on Martin's original belief that 'k in dd' should > > always return true if there is a default. One can argue that way, but > > then you end up on the circular train of thought that gets you to "you > > can't do anything useful if that is the case, .popitem() doesn't work, > > len() is undefined, ...". Keep it simple, keep it sane. > > A default factory implementation fundamentally modifies the behavior > of the mapping. There is no single answer to the question "what is the > right behavior for contains, len, popitem" as that depends on what the > code that consumes the mapping is written like, what it is attempting > to do, and what you are attempting to override it to do. Or, simply, > on why you are providing a default value. Resisting the temptation to > guess the why and just leaving the methods as is seems the best > choice; overriding __contains__ to return true is much easier than > reversing that behavior would be. I agree, there is nothing perfect. But at least in all of my use-cases, and the majority of the ones I've seen 'in the wild', my previous post provided an implementation that worked precisely like desired, and precisely like a regular dictionary, except when accessing a non-existant key via: value = dd[key] . __contains__, etc., all work exactly like they do with a non-defaulting dictionary. Iteration via popitem(), pop(key), items(), iteritems(), __iter__, etc., all work the way you would expect them. The only nit is that code which iterates like: for key in keys: try: value = dd[key] except KeyError: continue (where 'keys' has nothing to do with dd.keys(), it is merely a listing of keys which are desired at this particular point) However, the following works like it always did: for key in keys: if key not in dd: continue value = dd[key] > An example when it could theoretically be used, if not particularly > useful. The gettext.install() function was just updated to take a > names parameter which controls which gettext accessor functions it > adds to the builtin namespace. Its implementation looks for "method in > names" to decide. Passing a default-true dict would allow the future > behavior to be bind all checked names, but only if __contains__ > returns True. > > Even though it would make a poor base implementation, and these > effects aren't a good candidate for it, the code style that could > best leverage such a __contains__ exists. Indeed, there are cases where an always-true __contains__ exists, and the pure-Python implementation I previously posted can be easily modified to offer such a feature. However, because there are also use cases for the not-always-true __contains__, picking either as the "one true way" seems a bit unnecessary. Presumably, if one goes into the collections module, the other will too. Actually, they could share all of their code except for a simple flag which determines the always-true __contains__. With minor work, that 'flag', or really the single bit it would require, may even be embeddable into the type object. Arguably, there should be a handful of these defaulting dictionary-like objects, and for each variant, it should be documented what their use-cases are, and any gotcha's that will inevitably come up. - Josiah ___ 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" <[EMAIL PROTECTED]> wrote:
>
> > "Josiah" == Josiah Carlson <[EMAIL PROTECTED]> writes:
>
> Josiah> The question remains: is str.decode() returning a string
> Josiah> or unicode depending on the argument passed, when the
> Josiah> argument quite literally names the codec involved,
> Josiah> difficult to understand? I don't believe so; am I the
> Josiah> only one?
>
> Do you do any of the user education *about codec use* that you
> recommend? The people I try to teach about coding invariably find it
> difficult to understand. The problem is that the near-universal
> intuition is that for "human-usable text" is pretty much anything *but
> Unicode* will do. This is a really hard block to get them past.
> There is very good reason why Unicode is plain text ("original" in
> MAL's terms) and everything else is encoded ("derived"), but students
> new to the concept often take a while to "get" it.
I've not been teaching Python; when I was still a TA, it was strictly
algorithms and data structures. Of those people who I have had the
opportunity to entice into Python, I've not followed up on their
progress to know if they had any issues.
I try to internalize it by not thinking of strings as encoded data, but
as binary data, and unicode as text. I then remind myself that unicode
isn't native on-disk or cross-network (which stores and transports bytes,
not characters), so one needs to encode it as binary data. It's a
subtle difference, but it has worked so far for me.
In my experience, at least for only-English speaking users, most people
don't even get to unicode. I didn't even touch it until I had been well
versed with the encoding and decoding of all different kinds of binary
data, when a half-dozen international users (China, Japan, Russia, ...)
requested its support in my source editor; so I added it. Supporting it
properly hasn't been very difficult, and the only real nit I have
experienced is supporting the encoding line just after the #! line for
arbitrary codecs (sometimes saving a file in a particular encoding dies).
I notice that you seem to be in Japan, so teaching unicode is a must.
If you are using the "unicode is text" and "strings are data", and they
aren't getting it; then I don't know.
> Maybe it's just me, but whether it's the teacher or the students, I am
> *not* excited about the education route. Martin's simple rule *is*
> simple, and the exceptions for using a "nonexistent" method mean I
> don't have to reinforce---the students will be able to teach each
> other. The exceptions also directly help reinforce the notion that
> text == Unicode.
Are you sure that they would help? If .encode() and .decode() drop from
strings and unicode (respectively), they get an AttributeError. That's
almost useless. Raising a better exception (with more information)
would be better in that case, but losing the functionality that either
would offer seems unnecessary; which is why I had suggested some of the
other method names. Perhaps a "This method was removed because it
confused users. Use help(str.encode) (or unicode.decode) to find out
how you can do the equivalent, or do what you *really* wanted to do."
> I grant the point that .decode('base64') is useful, but I also believe
> that "education" is a lot more easily said than done in this case.
What I meant by "education" is 'better documentation' and 'better
exception messages'. I didn't learn Python by sitting in a class; I
learned it by going through the tutorial over a weekend as a 2nd year
undergrad and writing software which could do what I wanted/needed.
Compared to the compiler messages I'd been seeing from Codewarrior and
MSVC 6, Python exceptions were like an oracle. I can understand how
first-time programmers can have issues with *some* Python exception
messages, which is why I think that we could use better ones. There is
also the other issue that sometimes people fail to actually read the
messages.
Again, I don't believe that an AttributeError is any better than an
"ordinal not in range(128)", but "You are trying to encode/decode
to/from incompatible types. expected: a->b got: x->y" is better. Some
of those can be done *very soon*, given the capabilities of the
encodings module, and they could likely be easily migrated, regardless
of the decisions with .encode()/.decode() .
- Josiah
___
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] Removing Non-Unicode Support?
On 2/19/06, Jeff Rush <[EMAIL PROTECTED]> wrote: [Quoting Neal Norwitz] > > I've heard of a bunch of people using --disable-unicode. I'm not sure > > if it's curiosity or if there are really production builds without > > unicode. Ask this on c.l.p too. > > Such a switch quite likely is useful to those creating Python interpreters > for small hand-held devices, where space is at a premium. I would hesitate > to remove switches to drop features in general, for that reason. > > Although I have played with reducing the footprint of Python, I am not > currently doing so. I could never get the footprint down sufficiently to > make it usable, unfortunately. But I would like to see the Python > developers maintain an awareness of memory consumption and not assume that > Python is always run on modern fully-loaded desktops. We are seeing > increasing use of Python in embedded systems these days. Do you know of any embedded platform that doesn't have unicode support as a requirement? Python runs fine on Nokia phones running Symbian, where *everything* is a Unicode string. -- --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] buildbot is all green
On 2/19/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > With a couple of more machines added, should there be two separate pages > for trunk and 2.4 builds? Or do most checkins affect both? They don't; I think a separate page would be a fine idea. FWIW, it looks like all the sample templates are still wasting a lot of horizontal space in the first two columns the second is almost always empty. Perhaps the author of the change could be placed *below* the timestamp instead of next to it? Also for all practical purposes we can probably get rid of the seconds in the timestamp. -- --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] buildbot is all green
Walter Dörwald wrote: > Neal Norwitz wrote: > >>On 2/19/06, Benji York <[EMAIL PROTECTED]> wrote: >> >>>Walter Dörwald wrote: >>> I'd like to see vertical lines between the column. >>> >>>I've done a version like that (still at http://www.benjiyork.com/pybb). >> >>I liked your current version better so I installed it. > > > How about this one: > http://styx.livinglogic.de/~walter/python/BuildBot_%20Python.html > All formats would be improved of the headers could be made to float at the top of the page as scrolling took place. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] buildbot is all green
Terry Reedy wrote: is always necessary with Windows). > > > With a couple of more machines added, should there be two separate pages > for trunk and 2.4 builds? Or do most checkins affect both? I'd like to avoid this, assuming that people only look at the "main" page. An individual checkin affects either the trunk or 2.4, but never both; many check-ins come in pairs. 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
