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> I certainly didn't mean to rule that out.
Speaking for myself, that's all I really wanted to hear at this time.
As Bob Ippolito said, currently it's straightforward to
internationalize an application, and well worth the minimal overhead
if it's at all serious. It's just that it would be nice if quick and
dirty additions for i18n programs could be done as easily and with the
same facility as for mono-Euro-lingual programs. I also think that at
present Python is to the point where it's natural to write in a style
where i18n is nearly costless (I use unicode strings habitually, and
prefer %(var)s to positional %s anyway, because I find it easier to
read). It would be a shame to regress from that!
Why "mono-Euro-lingual"? Well, in teaching Python in Japan, one thing
that is really annoying about the current print statement is that
automatic spacing. Japanese doesn't use spaces to separate words, so
you basically have to start with the '%' operator when teaching
Japanese students output using variables. Several of them have said
"oh, another typical American software that breaks Japanese". Dunno
what to do about that, though, setting that based on the POSIX locale
would break my personal usage (when things are broken, I want to see
the debug output in English!)
Guido> But I doubt that the only text to be i18n'd will occur in
Guido> printf format strings. (In fact, I expect that few apps
Guido> requiring i18n will be so primitive as to use *any* printf
Guido> calls at all.)
Personally I don't write complex applications in native Python, I
write them for Zope or something like that. Then I don't have to
worry about generic Python facilities; I have to use whatever the
substrate is using. However, I do write simple CGIs that need to
produce English and Japanese pages (at least), and it's often enough
to write something like (this is from memory):
def addressWarningPage (formDict)
simplePageHeader (_("Address Warning"))
print _("""\
I'm sorry, %(user)s, but the address you submitted is %(address)s,
which appears to be a mobile phone address. Please use a real email
address, because the mailing list for %(course)s distributes large
attachments.""") % formDict
simplePageFooter ()
where the simplePageFunctions themselves have been inherited from old
code that simply 'print'ed to stdout, and formDict is constructed by
the underlying CGI handler, so it's always available. I write a fair
number of these pages, there are always new ways to go wrong
This is very similar to what Bob Ippolito describes, and it's easy
enough to do. However, my translators _do_ confuse the "s" for
"string argument" with English pluralization (they're not native
English speakers, usually). It would be nice (for me) if we could
use notation that doesn't use stray format characters. It would be
nice to be able to lose the "_()" calls to gettext(). The function
would look to see if a message catalog was available for the current
output stream, and if not, do no translation. (I'm not sure this can
work, because it might conflict with things done automatically based
on environment settings of POSIX locale.)
It would be nice if a single function could support format strings
with positional arguments and those with named variable substitution.
(Not at the same time, though, that should be an error, I think.) If
not, a separate function would be easy enough to support in a
conversion script.
All that's still pretty abstract, I guess. But so far, I don't see
any reason why your proposal for the $1 positional syntax in printf()
hinders any of the above. I just wanted to make sure that asking for
them is OK.
--
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] Replacement for print in Python 3.0
Hi, Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit : > It would be > nice to be able to lose the "_()" calls to gettext(). The function > would look to see if a message catalog was available for the current > output stream, and if not, do no translation. That doesn't sound right to me. 1. You still need to do automatic extraction of these strings (gettext has tools for that, which rely on the use of the "_()" function - or any other dedicated function (*)). 2. You can't assume that all strings must be i18n'ed. For example if I'm interfacing with the user via a text-based network protocol which has a field named "Length", I don't want that "Length" field to be replaced with the Japanese translation of the word "Length". For i18n, "explicit is better than implicit" ;) The beauty of "_()" is that it's at the same time explicit, easily recognizable, and very short to type and read (it doesn't clutter the source code). If I dare say, the "%" operator has the same qualities. (*) of course more automatization of what gettext does could be a nice improvement too! > But so far, I don't see > any reason why your proposal for the $1 positional syntax in printf() > hinders any of the above. As I said Python needs an operator or function that does string formatting using a simple template, *without* doing output at the same time. The current syntax is the '%' operator, it could change, but it shouldn't be removed in favor of an inflexible print-with-formatting approach. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Guido writes:
> Is it worth doing this and completely dropping the %-based formats in
> Py3k? (Just asking -- it might be if we can get people to get over the
> shock of $ becoming first class ;-).
In my opinion, YES -- it's worth seriously considering it. A single,
well-designed solution for string interpolation (with syntactic support
if needed to make it very easy to use) is FAR better than having one
good solution and another legacy solution. Just the awkwardness of the
trailing s in "%(foo)s" is enough to motivate a search for something
better.
But this presuposes that there IS a single well-designed solution. PEP 292
templates are an excellent start, but they are not that solution. The
largest problem is the lack of a means for formatting numbers. People
should think hard about good solutions.
He continues:
> I proposed ${varname%fmt} earlier but it prevents you to extend the
> varname syntax to arbitrary expressions, which I think is an extension
> that will get lots of requests.
I certainly agree that we should keep open the syntactic possibility
to allow arbitrary Python expressions between "${" and "}" in an
interpolation string even though it may not be supported today.
I favor idea (Barry's?) of using "${::}"
where is an identifier (but someday might allow expressions),
and and behave like the % interpolation modifiers
today. I would have suggested it myself, but somehow I failed to realize
that slice literals are allowed only within subscripts and thus do not
conflict with this use.
-- Michael Chermside
___
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 08:55, Nick Coghlan wrote: > The leading 'p' (for 'positional') is necessary to get around the fact that > $1 > is currently an illegal identifier in a Template That should be fixable. Ideally, $1 is better than $p1. -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] Replacement for print in Python 3.0
On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote: > 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. I don't think enough people know about Tools/i18n/pygettext. It does all the extractions for you, producing a GNU gettext compatible .pot file. You can even teach it to recognize extraction keywords other than the default _(). printf() should be easy to recognize, although we might have to make a slight modification since IIRC, pygettext will only extract strings from keyword functions with exactly one argument. That should be easy to fix. -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] Replacement for print in Python 3.0
On Thu, 2005-09-08 at 07:48, Antoine Pitrou wrote: > As I said Python needs an operator or function that does string > formatting using a simple template, *without* doing output at the same > time. The current syntax is the '%' operator, it could change, but it > shouldn't be removed in favor of an inflexible print-with-formatting > approach. I believe we already have that in the constituent parts of stream.write() and Template.substitute(). I don't have any problem with the built-in print() function (or printf()) combining the two for convenience. After all, print's entire purpose is convenience. -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] Replacement for print in Python 3.0
Barry Warsaw wrote:
> On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
>
>
>>The leading 'p' (for 'positional') is necessary to get around the fact that
>>$1
>>is currently an illegal identifier in a Template
>
>
> That should be fixable. Ideally, $1 is better than $p1.
Oh, I know. I just didn't feel like cranking my brain up to the point of
figuring out the necessary change to the string.Template regex. It turns out
the one required change to the pattern is truly trivial though (I guess the
grief we gave PEP 292 about easy customisation was actually worthwhile):
from string import Template
class fmtTemplate(Template):
idpattern = '[_a-z0-9]*'
def format(*args, **kwds):
if kwds and (len(args) > 1):
raise ValueError("Cannot use both keyword and positional arguments")
fmt = fmtTemplate(args[0])
kwds.update(((str(idx), arg) for idx, arg in enumerate(args)))
return fmt.substitute(**kwds)
Py> format("$1: $2", "Num bees", 0.5)
'Num bees: 0.5'
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
Barry Warsaw wrote:
> On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
>
>
>>The leading 'p' (for 'positional') is necessary to get around the fact that
>>$1
>>is currently an illegal identifier in a Template
>
>
> That should be fixable. Ideally, $1 is better than $p1.
I also looked into the idea of adding formatting support to the
string.Template syntax.
Given a reimplementation of string.Template with the following pattern:
pattern = r"""
%(delim)s(?:
(?P%(delim)s) | # An escape sequence of two delimiters, or
(
(\[(?P[^%%]*)\])? # an optional simple format string,
(
(?P%(id)s) | # and a Python identifier, or
{(?P%(id)s)} # a braced identifier
)
) |
(?P) # An ill-formed delimiter expr
)
"""
And "convert" functions modified to use "fmt" where "'%s'" is currently used,
with "fmt" defined via:
fmt = mo.group('format')
if fmt is None:
fmt = '%s' # Default to simple string format
else:
fmt = '%' + fmt
The following works:
Py> t = format.Template("$item: $[0.2f]quantity")
Py> t.format(quantity=0.5, item='Bees')
'Bees: 0.50'
Combining with a 'format' function similar to the one in my previous message,
and an id pattern modified to permit numbers as identifiers:
Py> format("$1: $[0.2f]2", 'Bees', 0.5)
'Bees: 0.50'
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
[Python-Dev] PEP 3000 and new style classes
PEP 3000 - Core language says (http://www.python.org/peps/pep-3000.html#core-language) : - Support only new-style classes; classic classes will be gone Any possibility to add something like from __future__ import new_style_classes to have newly defined classes implicitly derive from 'object' (I understand this will be the implicit behavior when classic classes go away in Py3.0). -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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
> "Antoine" == Antoine Pitrou <[EMAIL PROTECTED]> writes: Antoine> Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen Antoine> J. Turnbull a écrit : >> It would be nice to be able to lose the "_()" calls to >> gettext(). The function would look to see if a message catalog >> was available for the current output stream, and if not, do no >> translation. I should have been more explicit. I meant only in the context of printf. You're right, gettext (and aliases) are still needed. Antoine> That doesn't sound right to me. 1. You still need to do Antoine> automatic extraction of these strings (gettext has tools Antoine> for that, which rely on the use of the "_()" function - Antoine> or any other dedicated function (*)). I think printf is an excellent candidate for such a function. Antoine> 2. You can't assume that all strings must be i18n'ed. IMO strings that are being printf'd can probably be assumed to be human readable, and therefore candidates for translation. This assumption does impose runtime overhead on non-i18n users, but I suspect it's smaller than that of caching regexps which has been determined to be acceptable. It would also make printf more hazardous for use in implementing protocol messages, but I think that's already pretty hazardous with the print statement. Although Guido has been very firm about not imposing overhead on _all_ users for the sake of i18n, implementing protocols is a similar minority activity, and there might be an acceptable tradeoff there. Antoine> As I said Python needs an operator or function that does Antoine> string formatting using a simple template, *without* Antoine> doing output at the same time. The current syntax is the Antoine> '%' operator, it could change, but it shouldn't be Antoine> removed in favor of an inflexible print-with-formatting Antoine> approach. AFAICT, that is the consensus view. Is there something concrete you're worried about here? Cheers, -- 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] PEP 3000 and new style classes
On Thu, Sep 08, 2005, Lisandro Dalcin wrote: > > Any possibility to add something like > > from __future__ import new_style_classes > > to have newly defined classes implicitly derive from 'object' (I > understand this will be the implicit behavior when classic classes go > away in Py3.0). You can already do __metaclass__ = type within each module -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ 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/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/5/05, Calvin Spealman <[EMAIL PROTECTED]> wrote: > > There is a lot of debate over this issue, obviously. Now, I think > > getting rid of the print statement can lead to ugly code, because a > > write function would be called as an expression, so where we'd once > > have prints on their own lines, that wouldn't be the case anymore, and > > things could get ugly. > > Sounds like FUD to me. Lots of functions/methods exist that *could* be > embedded in expressions, and never are. Or if they are, there's > actually a good reason, and then being a mere function (instead of a > statement) would actually be helpful. Anyway, why would it be > important that prints are on their own line where so many other > important actions don't have that privilege? For the same reason any statement is not an expression. Python doesn't allow assignments as expression, even though it has been implemented. Nor imports or function and class definitions. Readability is key. On the other hand, I actually don't like there being a print statement at all. We don't live in the days were console software rules and any other form of interface is an after thought. First-class printing to standard out seems to make a statement (no pun intended) that the language is intended for Unix-emulating operating systems (even Windows does, to some extent) and that anything you don't pipe through stdout or pull from stdin is something extra tossed in for a special crowd. Interface equality and neutrality would be a good thing in the language. But, I guess what I'm getting at is that if you do give special case to anything, give it special case properly. If text console IO is going to be only through functions and not directly in the language syntax, should it even be a built-in? Bring it to the level of any other interface API or keep it at its own status, but any middle ground seems half-hearted. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3000 and new style classes
On 9/8/05, Aahz <[EMAIL PROTECTED]> wrote: > > You can already do > > __metaclass__ = type > > within each module > Yes, you are right. But this way, you are making explicit a behavior that will be implicit in the future. For example, we could also do: two = float(4)/float(2) instead of from __future__ import division two = 4/2 -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 ___ 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
Michael Chermside writes: | Guido writes: | > Is it worth doing this and completely dropping the %-based formats in | > Py3k? (Just asking -- it might be if we can get people to get over the | > shock of $ becoming first class ;-). | | In my opinion, YES -- it's worth seriously considering it. A single, | well-designed solution for string interpolation (with syntactic support | if needed to make it very easy to use) is FAR better than having one | good solution and another legacy solution. Just the awkwardness of the | trailing s in "%(foo)s" is enough to motivate a search for something | better. hey folks, I managed to lose a few days worth of python-dev mail so I'm late to this discussion, but I thought I'd toss in a few (possibly outlying) data points form the visual effects/3d animation world. here at ILM we use python as the expression langauge in a number of 3d applications, and we usually end up adding a front-end parser so users can reference variable values inline via $ sytanx. they're still essentially writing python code, but with the extra added suger of $ references. I have first-hand information that the engineers at Pixar chose tcl over python a few years back as the expression language in their commercial shader editor "slim" for exactly this reason as well (i.e tcl already had $ refs, and they didn't want to present their own python-but-not language like we do here). so if replacing '' % () formatting with $ refs is an option in py3k, allow me to offer a +1000 vote for that :) ___ 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 8, 2005, at 5:42 AM, Barry Warsaw wrote: > On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote: > > >> 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. >> > > I don't think enough people know about Tools/i18n/pygettext. It does > all the extractions for you, producing a GNU gettext compatible .pot > file. You can even teach it to recognize extraction keywords other > than > the default _(). printf() should be easy to recognize, although we > might have to make a slight modification since IIRC, pygettext will > only > extract strings from keyword functions with exactly one argument. > That > should be easy to fix. You're right, I think Tools is probably a bad place for anything. If it's not part of the stdlib, I'll likely never find it. -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] reference counting in Py3K
Josiah Carlson wrote: > 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). Would you care to elaborate on the reasons behind the 'ick'? I'm a big fan of weave.inline and have used it very successfully for my own needs, so I'm genuinely curious (as I tend to teach its use, I like to know of potential problems I may not have seen). I should also add that a while ago a number of extremely annoying spurious recompilation bugs were finally fixed, in case this was what bothered you. Those bugs (hard to find) made weave in certain cases useless, as it recompiled everything blindly, thus killing its whole purpose. Feel free to reply off-list if you feel this is not appropriate for python-dev, though I think that a survey of the c-python bridges may be of interest to others. Cheers, f ___ 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
Fernando Perez <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > 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). > > Would you care to elaborate on the reasons behind the 'ick'? I'm a big fan of > weave.inline and have used it very successfully for my own needs, so I'm > genuinely curious (as I tend to teach its use, I like to know of potential > problems I may not have seen). 1. Mixing multiple languages in a single source file is bad form, yet it seems to be encouraged in weave.inline and other such packages (it becomes a big deal when the handful of Python becomes 20+ lines of C). 2. I experienced some minor but annoying issues in regards to automatic type conversions (strings, mmaps, buffers, and arrays if I remember correctly, it has been since February or March). There were other things, but I'm not sure if I am remembering them correctly or not (I spent around 12 hours over two days wrestling with weave.inline, but in 10 minutes I was using Pyrex effectively). > I should also add that a while ago a number of extremely annoying spurious > recompilation bugs were finally fixed, in case this was what bothered you. > Those bugs (hard to find) made weave in certain cases useless, as it > recompiled everything blindly, thus killing its whole purpose. I was actually finding that weave wasn't recompiling /enough/. I'd change some source, and get old behavior. I'd delete the various cache files, then see the recompilation and new behavior. With Pyrex and a bit of magic, I get auto-recompilation (though will seriously consider switching to Pyximport as another suggested). It also seemed to have some issues with interactive sessions, but I may be misremembering. > Feel free to reply off-list if you feel this is not appropriate for > python-dev, > though I think that a survey of the c-python bridges may be of interest to > others. Agreed. I admit that some of my issues would likely be lesser if I were to start to use inline now, with additional experience with such things. But with a few thousand lines of Pyrex and C working right now, I'm hard pressed to convince anyone (including myself) that such a switch is worthwhile. - 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] bug in urlparse
[EMAIL PROTECTED] wrote: > According to RFC 2396[1] section 5.2: RFC 2396 is obsolete. It was superseded by RFC 3986 / STD 66 early this year. In particular, the procedure for removing dot-segments from the path component of a URI reference -- a procedure that is only supposed to be done when 'resolving' a reference to absolute form (i.e., merging it with a base URI, which, being a URI, not a URI reference, is not allowed to contain dot-segments) -- has received a significant overhaul. The implementation guidance you quoted from RFC 2396 is no longer relevant. Technically, it never was relevant, since urlparse only claims to implement RFC 1808 (2396's predecessor, now ten years old). The new procedure says "...dot-segments are intended for use in URI references to express an identifier relative to the hierarchy of names in the base URI. The remove_dot_segments algorithm respects that hierarchy by removing extra dot-segments rather than treat them as an error or leaving them to be misinterpreted by dereference implementations." -Mike ___ 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: > Fernando Perez <[EMAIL PROTECTED]> wrote: >> Would you care to elaborate on the reasons behind the 'ick'? I'm a big fan >> of weave.inline and have used it very successfully for my own needs, so I'm >> genuinely curious (as I tend to teach its use, I like to know of potential >> problems I may not have seen). > > 1. Mixing multiple languages in a single source file is bad form, yet it > seems to be encouraged in weave.inline and other such packages (it > becomes a big deal when the handful of Python becomes 20+ lines of C). Agreed. I only use inline with explicit C strings for very short stuff, and typically use a little load_C_snippet() utility I wrote. That lets me keep the C sources in real C files, with proper syntax highlighting in Xemacs and whatnot. [... summary of weave problems] > Agreed. I admit that some of my issues would likely be lesser if I were > to start to use inline now, with additional experience with such things. > But with a few thousand lines of Pyrex and C working right now, I'm hard > pressed to convince anyone (including myself) that such a switch is > worthwhile. Thanks for your input. I certainly wasn't trying to suggest you change, I was just curious about your experiences. If you ever see this again, specific feedback on the scipy list would be very welcome. While I'm not 'officially' a scipy developer, I care enough about weave that occasionally I dig in and go in bugfixing expeditions. With proper bug reports we could improve a system which I think has a place (especially for scientific computing, with the Blitz support for arrays, which gives Numpy-like arrays in C++). I don't see weave as a competitor to pyrex, but rather as an alternate tool which can be excellent in certain contexts, and which I'd like to see improve whre possible. Regards, f ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3000 and new style classes
* Lisandro Dalcin <[EMAIL PROTECTED]> [2005-09-08 13:56:07 -0300]: > Yes, you are right. But this way, you are making explicit a behavior > that will be implicit in the future. > > For example, we could also do: > > two = float(4)/float(2) > > instead of > > from __future__ import division > two = 4/2 Why does it matter if the single statement you insert is spelled "__metaclass__ = type" instead of "from __future__ import whatever"? Remember, unlike the division example, you would only have to insert one statement, as opposed to changing every use of integer division. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital 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] bug in urlparse
On Thu, Sep 08, 2005 at 12:41:39PM -0600, Mike Brown wrote: > [EMAIL PROTECTED] wrote: > > According to RFC 2396[1] section 5.2: > > RFC 2396 is obsolete. It was superseded by RFC 3986 / STD 66 early this year. Thanks for the correction. Jeff pgpFDXgf6EeqZ.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tools directory (Was RE: Replacement for print in Python 3.0)
[finding Tools/i18n/pygettext.py] > You're right, I think Tools is probably a bad place for > anything. If it's not part of the stdlib, I'll likely never > find it. Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ scripts could be put in __main__ sections of appropriate modules? So that "python -m gettext" would be equivilant to "python Tools/i18n/pygettext.py"? (However, pyggettext.py is 22KB, which is a big addition to the module; not everything in Tools/Scripts might be used enough for this, or have an appopriate module to be put in either). Are there other ideas about how Tools/ could be improved? Either moving things, or making it more likely that people will look there for scripts? =Tony.Meyer ___ 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] Tools directory (Was RE: Replacement for print in Python 3.0)
On 9/8/05, Tony Meyer <[EMAIL PROTECTED]> wrote: > [finding Tools/i18n/pygettext.py] > > You're right, I think Tools is probably a bad place for > > anything. If it's not part of the stdlib, I'll likely never > > find it. > > Agreed. Maybe with the introduction of -m in Python 2.4, some of the Tools/ > scripts could be put in __main__ sections of appropriate modules? So that > "python -m gettext" would be equivilant to "python Tools/i18n/pygettext.py"? > > (However, pyggettext.py is 22KB, which is a big addition to the module; not > everything in Tools/Scripts might be used enough for this, or have an > appopriate module to be put in either). > > Are there other ideas about how Tools/ could be improved? Either moving > things, or making it more likely that people will look there for scripts? > I assume that the Windows installer includes the Tools/ directory. If it doesn't that is one problem. =) Otherwise it is mostly a lack of advertisement and them not being installed by ``make install``. If you just download the soure and install you will never know the directory even exists. It needs to be made obvious to people that it is even there. Probably the only way is to document the directory. -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] Replacement for print in Python 3.0
Michael Chermside wrote: > In my opinion, YES -- it's worth seriously considering it. A single, > well-designed solution for string interpolation (with syntactic support > if needed to make it very easy to use) is FAR better than having one > good solution and another legacy solution. Maybe backquotes could be repurposed in Py3k for interpolated string literals? -- 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] Replacement for print in Python 3.0
Stephen J. Turnbull wrote: > IMO strings that are being printf'd can probably be assumed to be > human readable, and therefore candidates for translation. This That's a dangerous assumption to make, I think. I'd be uncomfortable with having some strings in my program translated automatically and others not. EIBTI here, I feel. -- 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] Replacement for print in Python 3.0
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: Greg> Stephen J. Turnbull wrote: >> IMO strings that are being printf'd can probably be assumed to >> be human readable, and therefore candidates for translation. >> This Greg> That's a dangerous assumption to make, I think. Could be. For me, the name "print" is associated with a long history of magical behavior that only a human could possibly feel comfortable with. One of the great sins of Pascal was tarring the name "write" with the same brush! Greg> I'd be uncomfortable with having some strings in my program Greg> translated automatically and others not. EIBTI here, I Greg> feel. If printf is going to be part of a magical family of print* functions that do things like insert interword spacing and EOLs, I have no problem with documenting that among the other magical things that printf does, it translates strings. This is no less explicit than any other function that bundles several more primitive functions. If instead, we come up with a sufficiently excellent set of formatting and interpolation notations that printf isn't magic at all, simply a function that interprets a precisely defined set of explicit notations, then i18n should have its own notation, too. On reviewing the thread, the latter seems to be the direction things are going. Although several people have defended print's magical behaviors, most of them (and several others) seem at least as excited about a printf with a more economical yet powerful set of operators. -- 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] Replacement for print in Python 3.0
Greg Ewing wrote: > Maybe backquotes could be repurposed in Py3k for interpolated > string literals? backquotes are a PITA to type on many non-US keyboards. ___ 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
