Re: [Python-Dev] reference counting in Py3K
Greg Ewing <[EMAIL PROTECTED]> writes: > Guido van Rossum wrote: > >>>While we're on the subject of Python 3000, what's the >>>chance that reference counting when calling C >>>functions from Python will go away? >> >> We'd have to completely change the implementation. We're not >> planning on that. > > Also, the refcounting would have to be replaced by > something else that would also be fairly intrusive > on the C interface, such as having to remember to > make all your local variables known to the garbage > collector. > > A better plan would be to build something akin to > Pyrex into the scheme of things, so that all the > refcount/GC issues are taken care of automatically. Certainly, one of the goals of the PyPy project is to do experiments on GC strategy... Cheers, mwh -- If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. -- Jack Handey ___ 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] reference counting in Py3K
Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > A better plan would be to build something akin to > > Pyrex into the scheme of things, so that all the > > refcount/GC issues are taken care of automatically. > > That sounds exciting. I have to admit that despite hearing many > enthusiastic reviews, I've never used it myself -- in fact I've > written very little C code in the last few years, and zero new > extension modules. (Lots of Java, but that's another story. :-) Here's a perspective "from the trenches" as it were. I've been writing quite a bit of code, initially all in Python (27k lines in the last year or so). It worked reasonably well and fast. It wasn't fast enough. I needed a 25x increase in performance, which would have been easily attainable if I were to rewrite everything in C, but writing a module in pure C is a bit of a pain (as others can attest), so I gave Pyrex a shot (after scipy.weave.inline, ick). Initial versions ran around 2-3x as fast as pure Python. With various tricks, we are now running 75-100x faster in the pure Pyrex portions, with another 2-3x improvement possible (even using the VC6 compiler in Windows and old versions of gcc in linux, talk about multi-platform development!). With experience comes wisdom. I write new functionality that needs to be fast in pure C, wrapping it with Pyrex as necessary (which is quite simple), and make it all work with Python. > I expect that many standard extensions could benefit from a rewrite in > Pyrex, although this might take a lot of work and in some cases not > necessarily result in better code (_tkinter comes to mind -- though I > don't really know why this would be). So this shouldn't be the goal > (yet). Instead, we should encourage folks to write *new* extensions > using Pyrex. I'm not sure this is necessarily desireable. In my limited experience, one starts doing a line-by-line translation, getting Python objects as variables, etc. Then one starts predefining C variables and working with them, increasing speed by some measureable amount. Then one starts thinking about the data structures that are being passed (lists of lists, dictionary of lists, lists of dictionaries, ...), at which point one starts digging into PyList_GetItem, etc., manual in/decrefing, ..., and one's code starts getting the ugly of C modules, without the braces and semicolons. Offering it up as a standard library module: cool, +1. Give people one of the the best tools for wrapping C code and writing high-performance Python-accessable software. Encouraging its use for the writing of new extension modules: ick, -1. Writing pretty yet high performing Pyrex is an art that I'm not sure anyone can master. Perhaps a bit into the future, extending import semantics to notice .pyx files, compare their checksum against a stored md5 in the compiled .pyd/.so, and automatically recompiling them if they (or their includes) have changed: +10 (I end up doing this kind of thing by hand with phantom auto-build modules). - 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] reference counting in Py3K
Josiah Carlson wrote: > Perhaps a bit into the future, extending import semantics to notice .pyx > files, compare their checksum against a stored md5 in the compiled > .pyd/.so, and automatically recompiling them if they (or their includes) > have changed: +10 (I end up doing this kind of thing by hand with > phantom auto-build modules). which reminds me... does anyone know what happened to the various "inline C" versions that were quite popular a few years ago. e.g. http://mail.python.org/pipermail/python-dev/2002-January/019178.html (I've been using an extremely simple home-brewn version in a couple of projects, and it's extremely addictive, at least if you're a C/C++ veteran...) ___ 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] reference counting in Py3K
Fredrik Lundh wrote: > Josiah Carlson wrote: > >>Perhaps a bit into the future, extending import semantics to notice .pyx >>files, compare their checksum against a stored md5 in the compiled >>.pyd/.so, and automatically recompiling them if they (or their includes) >>have changed: +10 (I end up doing this kind of thing by hand with >>phantom auto-build modules). http://www.prescod.net/pyximport/ > which reminds me... does anyone know what happened to the various > "inline C" versions that were quite popular a few years ago. e.g. > > http://mail.python.org/pipermail/python-dev/2002-January/019178.html > > (I've been using an extremely simple home-brewn version in a couple of > projects, and it's extremely addictive, at least if you're a C/C++ veteran...) weave is alive and kicking and actively used although it could use some TLC. http://svn.scipy.org/svn/scipy_core -- Robert Kern [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter ___ 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 3 design principles
Collin Winter wrote: > Am 31-Aug 05, Charles Cazabon <[EMAIL PROTECTED]> schrieb: > > >>Perhaps py3k could have a py2compat module. Importing it could have the >>effect of (for instance) putting compile, id, and intern into the global >>namespace, making print an alias for writeln, alias the standard library >>namespace, ... ? > > > from __past__ import python2 If we ever get the ast-branch finished, then keeping a copy of the final 2.x parser around that targets the Python AST should actually be feasible, too. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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] Replacement for print in Python 3.0
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> Sure, we must provide good i18n support. But the burden on Guido> users who don't need i18n should be negligeable; they Guido> shouldn't have to type or know extra stuff that only exists Guido> for the needs of i18n. Agreed. That's best for i18n, too, if we can arrange a batteries- included approach to i18n at the same time. >> You're talking about Python 3.0; I don't know if it can be done >> within a reasonable amount of effort (and if not, too bad), but >> in that planning horizon it is surely worth some effort to find >> a solution. Guido> There seem to be many people interested in finding this Guido> solution; I see it as my task (among others) to make sure Guido> that their solution doesn't negatively affect the life of Guido> the majority of users who don't need it. Convenient as a Python optimized for i18n would be for me personally, I agree with that, too. But you wrote, "I'm not at all convinced that we should attempt to find a solution that handles both use cases; most Python code never needs i18n." And now, "That's too bad, [those who need i18n] will have to apply some global transformation to their code." It sounds to me like you have already decided that i18n applications will have to use a different way. But print-ng looks like becoming the OOWTDI for a lot of applications. IMO it's just too early to give up on print-ng becoming the one obvious way to do it for a lot of i18n apps, too. I realize that maybe it won't be solved for Python 3.0. Just, please don't close the door on it yet! Guido> Remember YAGNI! For-values-of-Y=I-A=am-ly y'rs, -- 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] reference counting in Py3K
On Wed, Sep 07, 2005 at 02:01:01AM -0400, Phillip J. Eby wrote: [...] > Just an FYI; Pyrex certainly makes it relatively painless to write code > that interfaces with C, but it doesn't do much for performance, and > naively-written Pyrex code can actually be slower than carefully-optimized > Python code. So, for existing modules that were written in C for > performance reasons, Pyrex isn't currently a substitute. I just want to second this; my experiments with pyrex on pysync produced no speedups. I got a much more noticable speed benefit from psyco. This was admittedly a long time ago... -- Donovan Baardahttp://minkirri.apana.org.au/~abo/ ___ 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] reference counting in Py3K
On 9/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > > A better plan would be to build something akin to > > > Pyrex into the scheme of things, so that all the > > > refcount/GC issues are taken care of automatically. > > > > That sounds exciting. I have to admit that despite hearing many > > enthusiastic reviews, I've never used it myself -- in fact I've > > written very little C code in the last few years, and zero new > > extension modules. (Lots of Java, but that's another story. :-) > > Here's a perspective "from the trenches" as it were. > > Encouraging its use for the writing of new extension modules: ick, -1. > Writing pretty yet high performing Pyrex is an art that I'm not sure > anyone can master. I'd just like to put in that it seems like the suggestions to use Pyrex were aimed at C-library wrapping extensions, not necessarily ones that were written in C for performance (I gather that there are very few of those, comparatively). So the encouragement to use Pyrex for new extension modules still seems perfect, to me; its use should definitely be encouraged when one needs to wrap some third-party library, and I'd bet that that's the common case. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ 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] Replacement for print in Python 3.0
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote: > But print-ng looks > like becoming the OOWTDI for a lot of applications. IMO it's just too > early to give up on print-ng becoming the one obvious way to do it for > a lot of i18n apps, too. +1. I have a gut feeling that we can make it easy for monolinguists to use printng without caring or even knowing about i18n, but also make it relatively painless to integrate i18n into an application or library. However I haven't had time to really explore that idea. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Simplify the file-like-object interface (Replacement for print in Python 3.0)
On 9/6/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > I'd also prefer something along the lines of Fredrik's suggestion, but > I don't write enough C code to understand Paul's last point. Could > someone briefly explain why mixins wouldn't work in C code? I had in mind "it would be complicated and messy, and probably no easier than just implementing all of the extra methods by hand" rather than "it's impossible". Sorry for being unclear. I haven't written many C extensions, either, so I may be misremembering. Also, the biggest extension I wrote, which does implement a file-like object, was written when Python 1.4/1.5 was current, and (still) uses the C API from then. (BTW, that's a great tribute to the backward-compatibility that Python provides!) Paul. ___ 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] Replacement for print in Python 3.0
Barry Warsaw wrote:
> On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
>
>
>>But print-ng looks
>>like becoming the OOWTDI for a lot of applications. IMO it's just too
>>early to give up on print-ng becoming the one obvious way to do it for
>>a lot of i18n apps, too.
>
>
> +1. I have a gut feeling that we can make it easy for monolinguists to
> use printng without caring or even knowing about i18n, but also make it
> relatively painless to integrate i18n into an application or library.
> However I haven't had time to really explore that idea.
I found the following to be an interesting experiment:
-
from string import Template
def format(*args, **kwds):
fmt = args[0]
kwds.update(("p%s" % idx, arg) for idx, arg in enumerate(args))
return Template(fmt).substitute(**kwds)
Py> format("$p1: $p2", "Bee count", 0.5)
'Bee count: 0.5'
-
The leading 'p' (for 'positional') is necessary to get around the fact that $1
is currently an illegal identifier in a Template. If we actually did something
like this, I would advocate adding the support for positional arguments
directly to string.Template.
For il8n output, you would be pulling the format string from somewhere else,
so you would stick with the current idiom of using keyword arguments:
-
Py> fmt = "$item: $count"
Py> format(fmt, item="Bee count", count=0.5)
'Bee count: 0.5'
-
There's also the
cute-and-kinda-useless-but-it-also-justifies-the-1-based-indexing:
-
Py> format("Kinda cute: $p0")
'Kinda cute: Kinda cute: $p0'
-
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.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] Replacement for print in Python 3.0
Nick Coghlan wrote:
> I found the following to be an interesting experiment:
>
> -
> from string import Template
>
> def format(*args, **kwds):
> fmt = args[0]
> kwds.update(("p%s" % idx, arg) for idx, arg in enumerate(args))
> return Template(fmt).substitute(**kwds)
I forgot to add the following concept:
-
def printf(*args, **kwds):
to = kwds.pop("to", sys.stdout)
to.write(format(*args, **kwds))
Py> printf("$p1: $p2\n", 1, 2)
1: 2
Py> printf("$p1: $p2\n", 1, 2, to=sys.stderr)
1: 2
Py> printf("$p1: $p2$to\n", 1, 2, to=sys.stderr)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 3, in printf
File "", line 4, in format
File "C:\Python24\lib\string.py", line 172, in substitute
return self.pattern.sub(convert, self.template)
File "C:\Python24\lib\string.py", line 162, in convert
val = mapping[named]
KeyError: 'to'
-
If you're dealing with an existing template that uses the 'to' keyword, then
it is possible to fall back to using:
-
def printraw(*args, **kwds):
to = kwds.pop("to", sys.stdout)
for arg in args:
to.write(arg)
Py> printraw(format("$p1: $p2$to\n", 1, 2, to="There"), to=sys.stderr)
1: 2There
-
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.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] Replacement for print in Python 3.0
On 9/7/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote: > > > But print-ng looks > > like becoming the OOWTDI for a lot of applications. IMO it's just too > > early to give up on print-ng becoming the one obvious way to do it for > > a lot of i18n apps, too. > > +1. I have a gut feeling that we can make it easy for monolinguists to > use printng without caring or even knowing about i18n, but also make it > relatively painless to integrate i18n into an application or library. > However I haven't had time to really explore that idea. I certainly didn't mean to rule that out. But I doubt that the only text to be i18n'd will occur in printf format strings. (In fact, I expect that few apps requiring i18n will be so primitive as to use *any* printf calls at all.) Anyway, let us hear what you had in mind rather than arguing over some abstract principle. -- --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] Python core documentation
Fred L. Drake, Jr. wrote: > It would be good to have more specific guidelines for documentation. Would it be possible to have each item in the documentation start out by auto quoting that items __doc__ string? Then omissions, errors, and contradictions would be easy to find and the full documentation would compliment the __doc__ strings rather than repeat them. Cheers, Ron ___ 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] reference counting in Py3K
Christopher Armstrong <[EMAIL PROTECTED]> wrote: > On 9/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > On 9/6/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > > > > A better plan would be to build something akin to > > > > Pyrex into the scheme of things, so that all the > > > > refcount/GC issues are taken care of automatically. > > > > > > That sounds exciting. I have to admit that despite hearing many > > > enthusiastic reviews, I've never used it myself -- in fact I've > > > written very little C code in the last few years, and zero new > > > extension modules. (Lots of Java, but that's another story. :-) > > > > Here's a perspective "from the trenches" as it were. > > > > Encouraging its use for the writing of new extension modules: ick, -1. > > Writing pretty yet high performing Pyrex is an art that I'm not sure > > anyone can master. > > I'd just like to put in that it seems like the suggestions to use > Pyrex were aimed at C-library wrapping extensions, not necessarily > ones that were written in C for performance (I gather that there are > very few of those, comparatively). So the encouragement to use Pyrex > for new extension modules still seems perfect, to me; its use should > definitely be encouraged when one needs to wrap some third-party > library, and I'd bet that that's the common case. To me, "new extension modules" != "wrapping C libraries for use with Python standard library inclusion". The latter is perfectly fine, the former may lead to fast but ugly Pyrex modules... But what if you don't want speed from pure Pyrex modules? Then why write them in Pyrex, why not stick with Python, or go to C for the speed, and Pyrex for the wrapping? - 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] Replacement for print in Python 3.0
On Sep 7, 2005, at 7:11 AM, Guido van Rossum wrote:
> On 9/7/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>> On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote:
>>
>>
>>> But print-ng looks
>>> like becoming the OOWTDI for a lot of applications. IMO it's
>>> just too
>>> early to give up on print-ng becoming the one obvious way to do
>>> it for
>>> a lot of i18n apps, too.
>>>
>>
>> +1. I have a gut feeling that we can make it easy for
>> monolinguists to
>> use printng without caring or even knowing about i18n, but also
>> make it
>> relatively painless to integrate i18n into an application or library.
>> However I haven't had time to really explore that idea.
>>
>
> I certainly didn't mean to rule that out. But I doubt that the only
> text to be i18n'd will occur in printf format strings. (In fact, I
> expect that few apps requiring i18n will be so primitive as to use
> *any* printf calls at all.)
In my experience, implementing i18n with *existing* Python (2.3 at
the time) features was not a big deal.
We used a translation company to translate all of the strings, and
they had no problem with normal Python %(format)s strings. We gave
it to them in an excel spreadsheet, and converted it to Apple
".strings" style files (which we parse directly in the Windows
version). Granted, we highlighted all of the "%(format)s" in the
spreadsheet so it was clear what should be preserved.
It worked like this:
def _(stringToBeLocalized):
return anAppropriateString
and all formatted strings in the code looked like this:
_('default english string %(variable)s') % someDict
from real world production code:
_(u'Installing this software requires %(requiredSpace)s of space.\n
\nYou have selected to install this software on the iPod "%(podName)
s" (%(totalFree)s available)') % {
u'requiredSpace': self.installer.getRequiredFreeDiskSpace(),
u'podName': self.podName,
u'totalFree': space,
}
I was also able to easily automate the process of extracting strings
to create that spreadsheet. I wrote a simple script that parsed the
Python modules and looked for function calls of "_" whose only
argument was a constant string. Worked great, and it was easy to write.
-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] Exception Reorg PEP checked in
(sorry for the delayed reply; vacation) On Aug 14, 2005, at 12:27 PM, Guido van Rossum wrote: On 8/14/05, Michael Hudson <[EMAIL PROTECTED]> wrote: Wilfredo S ánchez Vega <[EMAIL PROTECTED]> writes: I'm curious about why Python lacks FileNotFoundError, PermissionError and the like as subclasses of IOError. Good question. Lack of effort/inertia? Well, I wonder how often it's needed. My typical use is this: try: f = open(filename) except IOError, err: print "Can't open %s: %s" % (filename, err) return and the error printed contains all the necessary details (in fact it even repeats the filename, so I could probably just say "print err"). That's fine for log output, but weak for handling the error. Why do you need to know the exact reason for the failure? If you simply want to know whether the file exists, I'd use os.path.exists() or isfile(). (Never mind that this is the sometimes-frowned-upon look-before-you-leap; I think it's often fine.) If you're going to wave off the look-before-you-leap argument, I guess you're right in that case, but I think it's a pretty valid argument for a lot of applications. os.path.exists() also has a race condition in the case where the file is deleted between your test for is and the subsequent attempt to access it, so you'd still need to handle that error in the exception handling if you care about correctness. I agree that in many (most?) cases, this can be fudged, but if it's easier to do the correct thing, more people would do the correct thing. In any case, os.path.exists() also doesn't catch permissions errors, and I often find myself wanting to handle those errors specially as well. An example where both are useful is in an HTTP server, where a different status code should be returned to the client depending on success, file not found, permission denied, and other cases. Presently, I (and twisted.web) have to check errno in the IOError exception handler, which is really clunky, and I have to do it fairly often. Also note that providing the right detail can be very OS specific. Python doesn't just run on Unix and Windows. File not found is a detectable error case on all platforms, I think. On an OS that doesn't have permissions errors, I wouldn't expect the existence of an exception that isn't used to be a huge portability problem. I can't imagine that checking errno is a more portable solution. These two exist and are quite useful in Java, for whatever that's worth. -wsv smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> Guido> In a different thread I mentioned a design principle for Guido> which I have no catchy name, but which has often helped me Guido> design better APIs. One way to state it is to say that Guido> instead of a single "swiss-army-knife" function with Guido> various options that choose different behavior variants, Guido> it's better to have different dedicated functions for each Guido> of the major functionality types. So let's call it the Guido> "Swiss Army Knife (...Not)" API design pattern. I call the idea the 80/20 Split, or 'Convenience Functions'. You have a powerful, highly generalized function that can do most anything, and has an interface to prove it. Then, a collection of 'Convenience Functions' to constrain that "Swiss Army Knife" to handle 80% of the use-cases, while still letting Ye Power User dig a little deeper. The challenge is to keep the Convenience Function population low, so that you don't arrive at 8,020 different functions in the interface. Go, Python! Chris ___ 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] reference counting in Py3K
Guido van Rossum wrote: > How stable is Pyrex? Would you be willing to integrate it thoroughly > with the Python source tree, to the point of contributing the code to > the PSF? (Without giving up ownership or responsibility for its > maintenance.) It's reasonably stable now, I think, although some details might yet change. I'd want another couple of releases before calling it finished. When I do reach that point, I'd be perfectly willing to contribute it to the PSF. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] reference counting in Py3K
Phillip J. Eby wrote: > Just an FYI; Pyrex certainly makes it relatively painless to write code > that interfaces with C, but it doesn't do much for performance, and > naively-written Pyrex code can actually be slower than > carefully-optimized Python code. So, for existing modules that were > written in C for performance reasons, Pyrex isn't currently a substitute. If the performance-critical parts of the C code were translated into Pyrex-C (i.e. Pyrex code that only performs C operations) it shouldn't be significantly different. Alternatively, Pyrex could be used to create a wrapper around the existing C code, freeing it from having to deal with the Python/C API, thus making it easier to maintain. > One of the reasons for this is that Pyrex code uses the generic Python/C > APIs, like PySequence_GetItem, even in cases where PyList_GetItem or its > macro form would be more appropriate. Pyrex has no way currently to > say, "this is type X's C API, so use it when you have a variable that's > of type X, instead of using the generic object protocols." I'm thinking of teaching it about some of the builtin types (e.g. list, dict) so it can use more efficient APIs when appropriate. In the meantime, you can declare and call most of the APIs explicitly if you want. The exception is some of the macro forms which have nonstandard refcount behaviour. I'm also thinking of adding some declarations to help with that. > There are other issues that contribute to the inefficiency as well, like > redundant refcounting, assigning None to temporary variables, etc. Yes, it could probably do with a bit of flow analysis and peephole optimisation to deal with things like that. > I haven't used the absolute latest version of Pyrex, but older versions > also used C strings for attribute lookups, which was horribly slow. I > think the latest version now creates string objects at module > initialization to avoid this issue, though. Yes, it now precreates and interns all identifier strings, which should help considerably. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 342 open ( +3) / 2923 closed ( +1) / 3265 total ( +4) Bugs: 908 open ( +5) / 5232 closed (+10) / 6140 total (+15) RFE : 188 open ( +1) / 185 closed ( +1) / 373 total ( +2) New / Reopened Patches __ String formatting character for str.join (2005-09-04) CLOSED http://python.org/sf/1281573 opened by Nick Coghlan Speed up gzip.readline (~40%) (2005-09-04) http://python.org/sf/1281707 opened by April King Enable SSL for smtplib (2005-09-05) http://python.org/sf/1282340 opened by Phil Underwood AIX port from Elemental Security (2005-09-07) http://python.org/sf/1284289 opened by Guido van Rossum Patches Closed __ String formatting character for str.join (2005-09-04) http://python.org/sf/1281573 closed by ncoghlan New / Reopened Bugs ___ time.strptime() fails with unicode date string, de_DE locale (2005-09-01) CLOSED http://python.org/sf/1280061 opened by Adam Monsen tokenize module does not detect inconsistent dedents (2005-06-21) http://python.org/sf/1224621 reopened by arigo PyDateTime_Check references static object (2005-09-02) CLOSED http://python.org/sf/1280924 opened by Skip Montanaro xml.sax.expatreader doesn't pass encoding to ParserCreate (2005-09-02) http://python.org/sf/1281032 opened by Samuel Bayer Erroneous \url command in python.sty (2005-09-03) http://python.org/sf/1281291 opened by Rory Yorke array.arrays are not unpickleable (2005-09-03) CLOSED http://python.org/sf/1281383 opened by Reinhold Birkenfeld Py_BuildValue k format units don't work with big values (2005-09-04) http://python.org/sf/1281408 opened by Adal Chiriliuc exception when unpickling array.array objects (2005-09-04) http://python.org/sf/1281556 opened by John Machin urllib violates rfc 959 (2005-09-04) http://python.org/sf/1281692 opened by Matthias Klose logging.shutdown() not correct for chained handlers (2005-09-05) http://python.org/sf/1282539 opened by Fons Dijkstra socket.getaddrinfo() bug for IPv6 enabled platforms (2005-09-06) http://python.org/sf/1282647 opened by Ganesan Rajagopal PyArg_ParseTupleAndKeywords gives misleading error message (2005-09-06) http://python.org/sf/1283289 opened by japierro nit for builtin sum doc (2005-09-07) http://python.org/sf/1283491 opened by daishi harada os.path.abspath() / os.chdir() buggy with unicode paths (2005-09-07) http://python.org/sf/1283895 opened by Antoine Pitrou re nested conditional matching (?()) doesn't work (2005-09-07) http://python.org/sf/1284341 opened by Erik Demaine Bugs Closed ___ codecs.StreamRecoder.next doesn't encode (2005-07-10) http://python.org/sf/1235646 closed by doerwalter time.strptime() fails with unicode date string, de_DE locale (2005-09-01) http://python.org/sf/1280061 closed by bcannon crash recursive __getattr__ (2005-08-24) http://python.org/sf/1267884 closed by tjreedy Lambda and deepcopy (2005-08-31) http://python.org/sf/1277718 closed by tjreedy logging module broken for multiple threads? (2005-09-01) http://python.org/sf/1277903 closed by vsajip PyDateTime_Check references static object (2005-09-02) http://python.org/sf/1280924 closed by montanaro bz2module.c compiler warning (2005-08-26) http://python.org/sf/1274069 closed by birkenfeld discrepancy between str.__cmp__ and unicode.__cmp__ (2005-08-29) http://python.org/sf/1275719 closed by rhettinger array.arrays are not unpickleable (2005-09-03) http://python.org/sf/1281383 closed by rhettinger SyntaxError raised on win32 for correct files (2005-05-12) http://python.org/sf/1200686 closed by tim_one New / Reopened RFE __ non-sequence map() arguments for optimization (2005-09-02) CLOSED http://python.org/sf/1281053 opened by Ecnassianer of the Green Storm Give __len__() advice for "don't know" (2005-09-06) http://python.org/sf/1283110 opened by Tim Peters RFE Closed __ non-sequence map() arguments for optimization (2005-09-03) http://python.org/sf/1281053 closed by birkenfeld ___ 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
