Re: [Python-Dev] The "lazy strings" patch
On 23-Oct-2006, at 16:58 , Larry Hastings wrote:I genuinely don't know how many external Python extension modules are well-behaved in this regard. But in case it helps: I just checked PIL, NumPy, PyWin32, and SWIG, and all of them were well-behaved. Apart from stringobject.c, there was exactly one spot in the Python source tree which made assumptions about the structure of PyStringObjects (Mac/Modules/macos.c). It's in the block starting with the comment "This is a hack:". Note that this is unfixed in my patch, so just now all code using that self-avowed "hack" will break.As the author of that hack, that gives me an idea for where you should look for code that will break: code that tries to expose low-level C interfaces to Python. (That hack replaced an even earlier worse hack, that took the id() of a string in Python and added a fixed number to it to get at the address of the string, to fill it into a structure, blush).Look at packages such as win32, PyObjC, ctypes, bridges between Python and other languages, etc. That's where implementors are tempted to bend the rules of Official APIs for the benefit of serious optimizations. --Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jackIf I can't dance I don't want to be part of your revolution -- Emma Goldman ___ 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] The "lazy strings" patch
On Oct 24, 2006, at 11:09 AM, Jack Jansen wrote: Look at packages such as win32, PyObjC, ctypes, bridges between Python and other languages, etc. That's where implementors are tempted to bend the rules of Official APIs for the benefit of serious optimizations. PyObjC should be safe in this regard, I try to conform to the official rules :-) I do use PyString_AS_STRING outside of the GIL in other extensions though, the lazy strings patch would break that. My code is of course bending the rules here and can easily be fixed by introducing a temporary variable. Ronald -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com 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] The "lazy strings" patch
Jean-Paul Calderone wrote: > On Mon, 23 Oct 2006 07:58:25 -0700, Larry Hastings <[EMAIL PROTECTED]> wrote: >> [snip] >> If external Python extension modules are as well-behaved as the shipping >> Python source tree, there simply wouldn't be a problem. Python source is >> delightfully consistent about using the macro PyString_AS_STRING() to get at >> the creamy char *center of a PyStringObject *. When code religiously uses >> that macro (or calls PyString_AsString() directly), all it needs is a >> recompile with the current stringobject.h and it will Just Work. >> >> I genuinely don't know how many external Python extension modules are well- >> behaved in this regard. But in case it helps: I just checked PIL, NumPy, >> PyWin32, and SWIG, and all of them were well-behaved. > > FWIW, http://www.google.com/codesearch?q=+ob_sval Possible more enlightening (we *know* string objects play with this field!): http://www.google.com/codesearch?hl=en&lr=&q=ob_sval+-stringobject.%5Bhc%5D&btnG=Search Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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
[Python-Dev] Hunting down configure script error
Per my conversation with Martin v. Löwis on the python-list, I think I have found a problem with the configure script and Makefile.in. For Python 2.4.4 it seems that the arguement --libdir does not change the Makefile. Specifically I need this to change the libdir to /usr/lib64 for RH on a x86_64 machine. I'd like to contribute a fix for this, but I'm relatively new so I would appreciate some guidance. In the Makefile, I tried setting LIBDIR to $(exec_prefix)/lib64 and SCRIPTDIR to $(prefix)/lib64 manually. Unfortuantely that created an error when I ran python2.4: Could not find platform independent libraries Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] 'import site' failed; use -v for traceback so I edited my /etc/profile and included: export PYTHONHOME = "/usr" and reran python2.4 and now the only error is: 'import site' failed; use -v for traceback I poked around in /Modules/getpath.c and I'm starting to understand how things are comming together. My question is: how does $(prefix) from the congifure script make it into PREFIX in the c code? I see on line 106 of /Modules/getpath.c that it checks to see if PREFIX is defined and if not set's it to "/usr/local". So I did a grep on PREFIX from the Python2.4.4 dir level and it didn't return anything that looks like PREFIX is being set based on the input to the configure script. Where might this be happening? I'm assuming there's also a similar disconnect for LIBDIR (even though it never get's set properly in the Makefile, even when I edited it by hand, those changes don't make it into the code but I don't know where it should be changed in the code.) Respectfully, Christopher Taylor ___ 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] __str__ bug?
Mike Krell wrote:
> Is this a bug? If not, how do I override __str__ on a unicode derived class?
Based on the behaviour of str and the fact that overriding unicode.__repr__
works just fine, I'd say file a bug on SF.
I think this bit in PyUnicode_Format needs to use PyUnicode_CheckExact instead
of PyUnicode_Check:
case 's':
case 'r':
if (PyUnicode_Check(v) && c == 's') {
The corresponding code in PyString_Format makes a call to _PyObject_Str which
deals with subclasses correctly.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.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] __str__ bug?
> Based on the behaviour of str and the fact that overriding unicode.__repr__ > works just fine, I'd say file a bug on SF. Done. This is item 1583863. 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] Hunting down configure script error
Ok, here's what I found: In addition to the configure script not taking changing LIBDIR, Modules/getpath.c uses a hardcoded value for static chat lib_python[] = "lib/python" VERSION; which appears on line 134. So even if the configure script changes LIBDIR it won't do much good because the value is hardcoded in (as opposed to using LIBDIR). So I can tell that this would need to be changed ... anyone else know much about this? I'm wondering if my posts are going through?? Respectfully, Christopher Taylor ___ 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] Hunting down configure script error
Christopher> I'm wondering if my posts are going through?? Yup. Sorry, but I've no useful comments to make on your problems though. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hunting down configure script error
Christopher Taylor wrote: > Ok, here's what I found: In addition to the configure script not > taking changing LIBDIR, Modules/getpath.c uses a hardcoded value for > static chat lib_python[] = "lib/python" VERSION; > which appears on line 134. So even if the configure script changes > LIBDIR it won't do much good because the value is hardcoded in (as > opposed to using LIBDIR). > > So I can tell that this would need to be changed ... anyone else know > much about this? > > I'm wondering if my posts are going through?? > Your posts are making it. It's just that everyone's ignoring you :) regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Hunting down configure script error
> Your posts are making it. It's just that everyone's ignoring you :) I feel loved . Seriously, why would somoene ignore this? this is obviously not a pebkac problem. Respectfully, Christopher Taylor ___ 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] Hunting down configure script error
>> Your posts are making it. It's just that everyone's ignoring you :) Christopher> I feel loved . Christopher> Seriously, why would somoene ignore this? this is Christopher> obviously not a pebkac problem. I'm not sure what a "pebkac" problem is. I will attempt to channel the other members of the group (OMM...) and suggest that folks are either (like me) unfamiliar with the problem domain or too busy at the moment to look into the details. Your Best Bet (tm) would be to file a bug report on SourceForge so it doesn't get completely forgotten. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hunting down configure script error
[EMAIL PROTECTED] wrote: > I'm not sure what a "pebkac" problem is. http://en.wikipedia.org/wiki/PEBKAC You'll learn some new nonsense every day ;-) ___ 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] Hunting down configure script error
[EMAIL PROTECTED] wrote: > >> Your posts are making it. It's just that everyone's ignoring you :) > > Christopher> I feel loved . > > Christopher> Seriously, why would somoene ignore this? this is > Christopher> obviously not a pebkac problem. > > I'm not sure what a "pebkac" problem is. Problem Exists Between Chair And Keyboard regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] __str__ bug?
I believe you've overriden unicode.__str__ as you expect. class S(str): def __str__(self): return "S.__str__" class U(unicode): def __str__(self): return "U.__str__" print str(S()) print str(U()) This script prints: S.__str__ U.__str__ Regards, -- KAJIYAMA, Tamito <[EMAIL PROTECTED]> >Is this a bug? If not, how do I override __str__ on a unicode derived class? > >class S(str): >def __str__(self): return '__str__ overridden' > >class U(unicode): >def __str__(self): return '__str__ overridden' >def __unicode__(self): return u'__unicode__ overridden' > >s = S() >u = U() > >print 's:', s >print "str(s):", str(s) >print 's substitued is "%s"\n' % s >print 'u:', u >print "str(u):", str(u) >print 'u substitued is "%s"' % u > >- > >s: __str__ overridden >str(s): __str__ overridden >s substitued is "__str__ overridden" > >u: >str(u): __str__ overridden >u substitued is "" > >Results are identical for 2.4.2 and 2.5c2 (running under windows). > > 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] __str__ bug?
> class S(str): > def __str__(self): return "S.__str__" > > class U(unicode): > def __str__(self): return "U.__str__" > > print str(S()) > print str(U()) > > This script prints: > > S.__str__ > U.__str__ Yes, but "print U()" prints nothing, and the explicit str() should not be necessary. 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] PEP 355 status
On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > > It would be terrific if you gave us some clue about what is wrong in > > PEP355, so > > that the next guy does not waste his time. For instance, I find PEP355 > > incredibly good for my own path manipulation (much cleaner and concise than > > the > > awful os.path+os+shutil+stat mix), and I have trouble understanding what is > > *so* wrong with it. > > > > You said "it's an amalgam of unrelated functionality", but you didn't say > > what > > exactly is "unrelated" for you. > > Sorry, no time. But others in this thread clearly agreed with me, so > they can guide you. I'd like to write a post mortem for PEP 355. But one important question that haven't been answered is if there is a possibility for a path-like PEP to succeed in the future? If so, does the path-object implementation have to prove itself in the wild before it can be included in Python? From earlier posts it seems like you don't like the concept of path objects, which others have found very interesting. If that is the case, then it would be nice to hear it explicitly. :) -- mvh Björn ___ 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] Python 2.4.4 docs?
Does someone need to unpack the 2.4.4 docs in the right place so that http://www.python.org/doc/2.4.4/ works? --amk ___ 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 2.4.4 docs?
On Tuesday 24 October 2006 21:02, A.M. Kuchling wrote: > Does someone need to unpack the 2.4.4 docs in the right place so that > http://www.python.org/doc/2.4.4/ works? That would be me, and yes, and done. Sorry for the delay; life's just been busy lately. Time for me to go look at the release PEP again... -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] PEP 355 status
BJörn Lindqvist wrote: > On 10/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On 9/30/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote: >>> It would be terrific if you gave us some clue about what is wrong in >>> PEP355, so >>> that the next guy does not waste his time. For instance, I find PEP355 >>> incredibly good for my own path manipulation (much cleaner and concise than >>> the >>> awful os.path+os+shutil+stat mix), and I have trouble understanding what is >>> *so* wrong with it. >>> >>> You said "it's an amalgam of unrelated functionality", but you didn't say >>> what >>> exactly is "unrelated" for you. >> Sorry, no time. But others in this thread clearly agreed with me, so >> they can guide you. > > I'd like to write a post mortem for PEP 355. But one important > question that haven't been answered is if there is a possibility for a > path-like PEP to succeed in the future? If so, does the path-object > implementation have to prove itself in the wild before it can be > included in Python? From earlier posts it seems like you don't like > the concept of path objects, which others have found very interesting. > If that is the case, then it would be nice to hear it explicitly. :) Let me take a crack at it - I'm always good for spouting off an arrogant opinion :) Part 1: "Amalgam of Unrelated Functionality" To me, the Path module felt very much like the "swiss army knife" anti-pattern - a whole lot of functions that had little in common other than the fact that paths were involved. More specifically, I think its important to separate the notion of paths as abstract "reference" objects from filesystem manipulators. When I call a function that operates on a path, I want to clearly distinguish between a function that merely does a transformation on the path string, vs. one that actually hits the disk. This goes along with the "principle of least surprise" - it should never be the case that I cause an i/o operation to occur when I wasn't expecting it. For example, a function that computes the parent directory of a path should not IMHO be a sibling of a function which tests for the existence or readability of a file. I tend to think of paths and filesystems as broken down into 3 distinct domains, which are locators, inodes, and files. I realize that not all file systems on all platforms use the term 'inode', and have somewhat different semantics, but they all have some object which fulfills that role. -- A locator is an abstract description of how to "get to" a resource. A file path is a "locator" in exactly the sense that a URL is. Locators need not refer to 'real' resources in order to be valid. A locator to a non-existent resource still maintains a consistent structure, and can be manipulated and transformed without ever actually dereferencing it. A locator does not, however, have any properties or attributes - you cannot tell, for example, the creation date of a file by looking at its locator. -- An inode is a descriptor that points to some actual content. It actually lives on the filesystem, and has attributes (such as creation data, last modified date, permissions, etc.) -- 'Files' are raw content streams - they are the actual bytes that make up the data within the file. Files do not have 'names' or 'dates' directly in of themselves - only the inodes that describe them do. Now, I don't insist that everyone in the world should classify things the way I do - I'm just describing how I see it. Were I to come up with my own path-related APIs, they would most likely be divided into 3 sub-modules corresponding to the 3 subdivisions listed above. I would want to make it clear that when you are operating strictly at the locator level, you aren't touching inodes or files; When you are operating at the inode level, you aren't touching file content. Part 2: Should paths be objects? I should mention that while I appreciate the power of OOP, I am also very much against the kind of OOP-absolutism that has been taught in many schools of software engineering in the last two decades. There are a lot of really good, formal, well-thought-out systems of program organization, and OOP is only one of many. A classic example is relational algebra which forms the basis for relational databased - the basic notion that all operations on tabular data can be "composed" or "chained" in exactly the way that mathematical formula can be. In relational algebra, you can take a view of a view of a view, or a subquery of a query of a view of a table, and so on. Even single, scalar values - such as the count of the number of results of a query - are of the same data type as a 'relation', and can be operated on as such, or fed as input to a subsequent operation. I bring up the example of relational algebra because it applies to paths as well: There is a kind of "path algebra", where an operation on a path results in another path, which can be operated on further. Now,
Re: [Python-Dev] PEP 355 status
(one additional postscript - One thing I would be interested in is an approach that unifies file paths and URLs so that there is a consistent locator scheme for any resource, whether they be in a filesystem, on a web server, or stored in a zip file.) -- Talin ___ 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 355 status
Talin writes: > (one additional postscript - One thing I would be interested in is an > approach that unifies file paths and URLs so that there is a consistent > locator scheme for any resource, whether they be in a filesystem, on a > web server, or stored in a zip file.) +1 But doesn't file:/// do that for files, and couldn't we do something like zipfile:///nantoka.zip#foo/bar/baz.txt? Of course, we'd want to do ziphttp://your.server.net/kantoka.zip#foo/bar/baz.txt, too. That way leads to madness ___ 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 355 status
[EMAIL PROTECTED] wrote: > Talin writes: > > (one additional postscript - One thing I would be interested in is an > > approach that unifies file paths and URLs so that there is a consistent > > locator scheme for any resource, whether they be in a filesystem, on a > > web server, or stored in a zip file.) > > +1 > > But doesn't file:/// do that for files, and couldn't we do something > like zipfile:///nantoka.zip#foo/bar/baz.txt? Of course, we'd want to > do ziphttp://your.server.net/kantoka.zip#foo/bar/baz.txt, too. That > way leads to madness > It would make more sense to register protocol handlers to this magical unification of resource manipulation. But allow me to perform my first channeling of Guido.. YAGNI. -- Scott Dial [EMAIL PROTECTED] [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] PEP 355 status
[EMAIL PROTECTED] wrote: > Talin writes: > > (one additional postscript - One thing I would be interested in is an > > approach that unifies file paths and URLs so that there is a consistent > > locator scheme for any resource, whether they be in a filesystem, on a > > web server, or stored in a zip file.) > > +1 > > But doesn't file:/// do that for files, and couldn't we do something > like zipfile:///nantoka.zip#foo/bar/baz.txt? Of course, we'd want to > do ziphttp://your.server.net/kantoka.zip#foo/bar/baz.txt, too. That > way leads to madness file:/// does indeed to it, but only the network module understands strings in that format. Ideally, you should be able to pass "file:///..." to a regular "open" function. I wouldn't expect it to be able to understand "http://";. But the "file:" protocol should always be supported. In other words, I'm not proposing that the built-in file i/o package suddenly grow an understanding of network schema types. All I am proposing is a unified name space. - Talin ___ 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
