[Python-Dev] That library reference, yet again
What is the status of http://effbot.org/lib/ ? I think it's a step in the right direction. Is it still in progress? Can I have access to toolchain source code and/or conversion output? I would like to set up something like gotapi.com for the Python library reference, or help the gotapi people to include it. But gotapi needs link targets for functions etc., but the original Python library reference doesn't have them. I really like the simple linking idea here: http://online.effbot.org/2006_01_01_archive.htm#link-doc Here's another working example with (ugly) link targets: http://www.zvon.org/other/python/PHP/search.php Cheers, Johann ___ Python-Dev mailing list Python-Dev@python.org 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 syntax for 'dynamic' attribute access
> On 2/13/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > [snip] > > I've tried this out on Brett's urllib & urllib2 examples below. (calling > > the new builtin attrview() to emphasise the fact that it retains a > > reference to the original instance). I don't consider it any uglier than > > the proposed syntax changes, and it provides a few other benefits: > > > >- the two-argument form is naturally available as the .get() method > > on the resulting dict-like object (e.g. "attrview(obj).get(some_attr, > > None)") > > > >- hasattr() is naturally replaced by containment testing (e.g. > > "some_attr in attrview(obj)") > > > >- keywords/builtins are easier to look up in the documentation than > > symbolic syntax > > > > With this approach, performance would be attained by arranging to create > > the view objects once, and then performing multiple dynamic attribute > > accesses using those view objects. On 2/13/07, Collin Winter <[EMAIL PROTECTED]> wrote: > This changes my vote: +1 on including attrview(), -1 on the syntax proposal. Me too! I imagine that the addition of the proposed "obj.[name]" syntax to Python 2.6 would lead to more software that will not run on 2.5 and earlier versions. I don't think the benefits outweigh this backward incompatibility of new code. Therefore I'm -1 on including "obj.[name]" in Python 2.6. For Python 3000, I think it would be alright. With "attrview(obj)[name]" it would be possible to provide a fallback implementation in the same module for pre-2.6 users, so +1 for that. Johann C. Rocholl ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On 3/6/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > #1115886 complains that in the file name '.cshrc', the > entire file name is treated as an extension, with no > root. > > #1462106 contains a patch for that, changing the behavior > so that there will always be a root file name (and no > extension if the file is just a dotfile). > > Should this be changed? Opinions? +1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On 3/6/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> It's *useful* to classify e.g. .svn directories or .*rc files by their
> "extension"
I respectfully disagree. When trying to find directories named .svn or
files named .bashrc, I do
>>> filename in ('.svn', '.bashrc')
because I don't expect filenames like foo.svn or bar.bashrc -- have
you ever seen one? These are not "extensions" for me.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
Brilliant!
On 4/1/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK
> CAPITAL C}$):
> return None${ZERO WIDTH NO-BREAK SPACE}$
>
> This is still easy to read and makes the full power of type-annotated Python
> available to ASCII believers.
+1
J
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Add pure python PNG writer module to stdlib?
I'm working on simple module to write PNG image files in pure python. Adding it to the standard library would be useful for people who want to create images on web server installations without gd and imlib, or on platforms where the netpbm tools are not easily available. Does anybody find this idea interesting? Does anybody think it could go into stdlib before the feature freeze for 2.5? The module consists of only one file. It imports only sys, zlib, struct (maybe re for testing). Some benchmarks for comparison with the pnmtopng program (from netpbm), encoding a plain RGB file with 24 bits per pixel, input file size 11520017 bytes (11M), measured with the 'time' command, including Python interpreter start-up: pnmtopngpng.py straight encoding 1.31 seconds0.72 seconds resulting file size 342953 bytes292885 bytes interlaced encoding 3.78 seconds4.88 seconds resulting file size 422441 bytes346872 bytes The source code of the module lives here: http://svn.browsershots.org/trunk/shotfactory/lib/image/png.py http://trac.browsershots.org/browser/trunk/shotfactory/lib/image/png.py I am willing to maintain the module for 5+ years, as it is a small but important part of my main project. I am also willing to write latex documentation and tests for the module, and I think I could do that within the next three days. The module is licensed under the Apache License 2.0, and I am ready to sign a contributor agreement for the PSF. I will probably add support for more different PNG formats, especially alpha channel transparency, and then maybe color palettes. I don't plan to add PNG decoding because it would make the module much larger and rather complex. Sorry if this contribution seems brash. Perhaps it is easy enough to download and deploy my module separately. But I thought that if there is a chance to get it in before beta1, I should not hesitate and just ask. Cheers, Johann ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add pure python PNG writer module to stdlib?
> > Does anybody find this idea interesting?
>
> Yes, although I wouldn't want an interface taking in strings but something
> more like an iterator that returns each row which itself contains int
> triples. In other words more array-based than string based.
I agree that arrays would be semantically closer to the concept of
scanlines of pixel values. OTOH, I have my reasons for choosing the
string interface:
1. String is what you get from any file-like object with file.read(),
be it a PPM file on disk, or a pipe like this: os.popen('djpeg
test.jpg')
2. String is unbeatable in terms of efficiency.
3. Everybody knows how to use strings.
4. String can easily be created from other representations, for example:
>>> from array import array
>>> B = array('B')
>>> B.extend((255, 255, 255))
>>> B.tostring()
'\xff\xff\xff'
> > Does anybody think it could go into stdlib before the feature freeze for
> 2.5?
>
> Nope. To get added to the stdlib there needs to be support from the
> community that the module is useful and best-of-breed. Try posting on
> c.l.py and see if people pick it up and like it. No way that is going to
> happen before b1. But there is always 2.6 .
That's what I thought. My remote hope was that there would be
immediate concensus on python-dev about both the 'useful' and
'best-of-breed' parts. Anybody else with a +1? ;-)
Seriously, it's totally fine with me if the module doesn't make it
into 2.5, or even if it never makes it into stdlib. I'm just offering
it with some enthusiasm.
Cheers,
Johann
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
