Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries
Is there any objection to this patch? Any support? It is assigned to me. When I have time, will go through it in detail (the given use cases, more detailed timings, and a close reading of the code). If accepted, it will be for Py2.5, as it is a new feature. There is nothing broken about the existing eval() version, it just doesn't apply as broadly as you would have liked. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)
Martin v. Löwis wrote: M.-A. Lemburg wrote: ... and then the type change of that variable propagates throughout the extension. That depends on the usage of the code. If the variable is passed by value, no further changes are necessary. If a pointer to the variable is passed, you could replace it with Py_ssize_t x64; int x; foo(x64); x = x64; Then use x as you did with the original code. What if x64 has a 64-bit value ? How do you catch and process the truncation error ? To do this down-casting correctly, you'd need to write code that does bounds checks and integrate into the functions error handling. You basically end up having to convert the whole extension to Py_ssize_t. That is not necessary. Can you give in example of a module where you think it is necessary? If you want to port the extension to Py_ssize_t, this is essentially the case. You might want to take the unicodeobject.c file as example. Don't get me wrong: I don't mind doing this for the eGenix extensions, but I'm worried about the gazillion other useful extensions out there which probably won't get upgraded in time to be used with Python 2.5. I agree that it is not acceptable to require immediate whole-sale updates of every modules. However, I do believe that the number of modules that need any change at all is small, and that those modules can be modified with minimal effort to get them working again, backwards-compatible (i.e. with the only exception that they would fail if indices run above 2**31). I think all it takes is a set of new APIs for functions that use Py_ssize_t as output parameter and which are mapped to the regular API names if and only if the extension #defines PY_SSIZE_T_CLEAN (or some other capability flag). That is not enough. You also need to deal with the function pointers that change. We could use the type flags for these. much like we do for the new style numbers. Also, others have rejected/expressed dislike of the PY_SIZE_T_CLEAN macro already, so they would probably dislike further hackishness in that direction. That's easy to say... by not providing an easy way to upgrade extensions, you basically just move the requirement for hacks into the extensions. I wouldn't consider that a good solution. If you don't like the macro approach, why not simply leave the two separate sets of APIs visible. Old extensions would then use and link against the existing APIs. All Py_ssize_t aware and compatible extensions would use the new APIs instead. The old-style APIs should then take care of the proper down-casting and error reporting. In Py3K we could then remove the old-style ones and rename the new ones to the old names. Porting an already Py_ssize_t compatible extension to the renamed new style APIs would then become a simple task of searchreplace. Anyway, I have installed the PEP onsite, and added an Open Issues section, recording your comments. Thanks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 12 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
Martin v. Löwis wrote: M.-A. Lemburg wrote: If it were this easy, I wouldn't have objections. But it's not. It is so easy. Can you should me an example where it isn't? The variables you use with these APIs tend to propagate through the extension, you use them in other calls, make assignments, etc. They only propage if you make them. You don't have to, if you don't want to. If you implement extension types, you end up having to convert all the length related struct variables to Py_ssize_t. Only if you want to. If not, the module will work (nearly) unmodified. Of course, it will be limited to 32-bit indices. See my other reply on this topic. All this is fine, but it's also a lot of work which can be made easier. Recompiling an extension is well within range of many Python users, manually checking, fixing and porting it to the new API is certainly not. Sure. However, most users will compile it on 32-bit systems. If they find they cannot get it to work on a 64-bit system, they should ask the author for help, or just use it in 32-bit mode (as 64-bit mode won't gain them anything, anyway). I wonder how you are going to import a 32-bit extension into a 64-bit binary of Python. It simply doesn't work. The set of functions that will require Py_ssize_t is getting larger in your branch which is why I started this discussion. How so? I did not add a single function that has int* output values, AFAICT. No, but there are quite a few APIs with Py_ssize_t* output values. I am talking about the entirety of these functions, and claim that they are rarely used (including the Unicode and buffer APIs). I wouldn't say that PyString_AsStringAndSize() is rarely used and neither is PyArg_ParseTuple(). I agree that other APIs are certainly more domain specific and can be dealt with in the extension, but those two APIs need special care and so do the type slot functions. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 12 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
David Goodger wrote: Author: david.goodger Date: Thu Jan 12 04:33:16 2006 New Revision: 42015 Modified: peps/trunk/ (props changed) Log: add external link to Docutils public repo -- always up-to-date I just deleted the static copy of the docutils directory from the peps repository, and added in an external link (svn:externals 'docutils svn://svn.berlios.de/docutils/trunk/docutils/docutils'). This way, the external code should always be up-to-date. You may need to manually delete your peps/trunk/docutils directory to get this to work though -- SVN leaves subdirectories behind which hinder the externals update. Please let me know if this causes any problems. Thanks. Question: why do we need docutils in the peps/trunk/ directory in the first place ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 12 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
[M.-A. Lemburg] Question: why do we need docutils in the peps/trunk/ directory in the first place ? It's a convenience, so that a separate Docutils download install ( maintain) isn't necessary for those who process reST-format PEPs. -- David Goodger http://python.net/~goodger signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
David Goodger wrote: [M.-A. Lemburg] Question: why do we need docutils in the peps/trunk/ directory in the first place ? It's a convenience, so that a separate Docutils download install ( maintain) isn't necessary for those who process reST-format PEPs. Hmm, shouldn't these things be tracked under external/ ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 12 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
On 1/12/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: Hmm, shouldn't these things be tracked under external/ ?! What do you mean exactly? A new external directory? SVN provides a built-in mechanism for tracking external repositories, via the svn:externals property, and that's what I used. -- David Goodger http://python.net/~goodger ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
David Goodger wrote: On 1/12/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: Hmm, shouldn't these things be tracked under external/ ?! What do you mean exactly? A new external directory? Yes. SVN provides a built-in mechanism for tracking external repositories, via the svn:externals property, and that's what I used. I know, but I wouldn't expect SVN to query other servers than svn.python.org inside the standard repository directories. AFAIK, this is a first in the Python repository. Not sure if it's such a good idea. Branching and tagging doesn't work with external resources in Subversion, so things can become inconsistent. Also, what if you break the code in the berlios repo or the server is not reachable ? A release copy in the external/ dir would solve all these issues. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 12 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
M.-A. Lemburg wrote: AFAIK, this is a first in the Python repository. Not sure if it's such a good idea. Branching and tagging doesn't work with external resources in Subversion, so things can become inconsistent. Also, what if you break the code in the berlios repo or the server is not reachable ? A release copy in the external/ dir would solve all these issues. using svn:external is usually a lousy idea. using it in a public repository is a really, really, really lousy idea. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes: Martin v. Löwis wrote: So as for dealing with it somehow: I would make ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could reject to install it. I like this solution. Of course, Thomas (author of both py2exe and ctypes) may like the ability to have ctypes built into python.dll ... It is getting offtopic, but I don't care too much about that. I requested that zlib be changed to a builtin module too allow easier bootstrapping of py2exe'd apps which have a compressed library archive. The nearly only reason for me to implement the single-file option for py2exe was that the implementation simulates a static linked Python-dll, which allows for several totally-isolated interpreters in the same process. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
On 1/12/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: I know, but I wouldn't expect SVN to query other servers than svn.python.org inside the standard repository directories. AFAIK, this is a first in the Python repository. True, and worth discussing. Luckily the PEPs repository is a low-traffic, non-core area, so it's not urgent. Not sure if it's such a good idea. From my point of view, it's a time-saver. No more manual updates! They were a pain, and rarely got done. Branching and tagging doesn't work with external resources in Subversion, so things can become inconsistent. How so? The svn:externals property is treated the same as any other, and is copied along with everything else by svn copy. Also, what if you break the code in the berlios repo or the server is not reachable ? If the code in the repo ever breaks, it will be fixed within minutes. The server being unreachable is only a problem for initial checkouts; updates will just keep the code that was already there. In my experience, the berlios.de SVN server has rarely been unreachable. If there's a problem, we can always back out the svn:externals property and install the package. That having been said, I do see the value of installing a packaged release. We just released Docutils 0.4 a few days ago; I could install that statically. An alternative is to use svn:externals to link to a specific revision (via the -r option); I could link to the 0.4 release revision. This would solve the repo-breakage issue, but not the server-unreachability issue. I don't think these issues are major, but I wouldn't mind terribly if we decide to go with a static install. A release copy in the external/ dir would solve all these issues. That's basically what we had before (except no explicity external directory), but it was always out of date. The docutils package was directly in the trunk, for ease of import by the pep2html.py front end (easy to work around, but why bother?). Another minor nit with the old way: updates polluted the python-checkins list. -- David Goodger http://python.net/~goodger ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Martin v. Löwis [EMAIL PROTECTED] writes: Guido van Rossum wrote: On the other hand it breaks one of the most fundamental Python guidelines: if you get a core dump (segfault etc.) it's a bug in Python or in a 3rd party extension, not in *your* Python code. An exception would have to be made for any code that uses ctypes, as it is usually trivial to cause core dumps with ctypes (I'd venture it's hard to avoid them ;-). I don't expect this to count against including ctypes; but I do want it to be dealt with somehow! I think the strongest point *for* ctypes is the inclusion of dl in the source distribution, which has the very same flaws as ctypes in terms of crashability. So as for dealing with it somehow: I would make ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could reject to install it. Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building a module catalogue with buildbot
Martin v. Löwis wrote: My initial thought was that we could ask alpha testers to run this script on their alpha builds, and report back, but it just struck me that the buildbot already builds stuff on a couple of interesting platforms. Can buildbot deal with custom test/validation scripts, and collect the output somewhere ? Collecting the output is the real challenge. Basically, you are restricted to putting stdout of a process into a file. So a result that is a set of linked HTML files is not supported. The listmodule utility only outputs a plain list of available modules. Just being to able to scrape the lists off http://www.python.org/dev/buildbot/ would be good enough. /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP and stdlib
Hello, I've often read new PEP that are published, and they are often about new additions to the core language. Why not using them with the standard library. Guido often say that he don't want to include new module that aren't widely used in the community. It's a good thing, but it lead to the creation of a lot of API incompatible modules. Why not using PEP in order to create standard API like the Java world do with JSRs (Java Specification Requests) ? What do you think about that ? -- Fabien ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
Tim Peters wrote: Yes. please. svn:externals should always pin to a specific revision (or at least to a frozen tag). Updating to a new revision then is just a propedit away (to change the revision number); ditto for backing off to an older revision if the newer one has problems. wasn't the whole point for this exercise to make sure that the included version was always up to date. if you pin it to a given version, all we got from this was a dependence on another SVN server. (and a can of SVN worms, including issues with locking/cleanup, etc) /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
[David Goodger] ... An alternative is to use svn:externals to link to a specific revision (via the -r option); Yes. please. svn:externals should always pin to a specific revision (or at least to a frozen tag). Updating to a new revision then is just a propedit away (to change the revision number); ditto for backing off to an older revision if the newer one has problems. As to the rest, you're using externals in a vanilla way for their intended purpose, and I have no problems with that. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Thomas Heller wrote: Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module. Ok. The installer should then combine them all into a feature. Still, the admin could disable all of this just by removing _ctypes.dll, right? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ph.D. dissertation ideas?
At 02:36 PM 1/12/2006 -0800, Brett Cannon wrote: (I have a third, AOP for anything, but I don't think AOP is a good match for Python and thus not considering it for Python work) For what it's worth, I've been doing what I'll loosely refer to as research on implementing a non-traditional form of AOP in Python via the combination of extensible generic functions and contextual variables -- two concepts that already exist in Python but which can be extended far beyond what is in current use. The combination can be used to implement an explicit is better than implicit form of AOP, that is usually handled by a weaving language in classic AOP implementations. I don't know of any published AOP work that focuses on the use of these kinds of tools; the communities that talk about the respective technologies appear to be disjoint. Anyway, extensible generic operations in Python like 'len()', 'copy()' and so on are fairly common, but it's rare that people define their own such functions, as opposed to using ones in the stdlib. A typical workaround in larger frameworks is to use interfaces and adaptation, but extensible generic operations make it easier to separate concerns orthogonally. So, although you might think that AOP isn't a good match for Python, the truth is that there's actually a fair amount of AOP-like things being done with Python. It's just that classic structuring of AOP into things like aspects and weavers and all that crud is overcomplication. If you view it simply in terms of extensible operations, which can also make decisions based on context, then you can achieve all the same goals of classic AOP without using any of its concepts or terminology. One definition of AOP claims that it allows asserting qualified statements over oblivious code. Python has this basic ability natively -- monkeypatching suffices to meet that definition. The interesting question is, how can you do it *without* monkeypatching? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...)
M.-A. Lemburg wrote: What if x64 has a 64-bit value ? How do you catch and process the truncation error ? We were *both* discussing a scenario where no sizes exceed 2**31, right? Under such a scenario, this just won't happen. OTOH, if you were discussing a scenario where sizes might exceed 2**31, then I don't see why you are worried about Py_ssize_t* parameters alone: Even PyString_Size() might (of course!) return a value 2**31 - so it is not just output parameters, but also return values. For more information, please read Conversion guidelines in http://www.python.org/peps/pep-0353.html That is not necessary. Can you give in example of a module where you think it is necessary? If you want to port the extension to Py_ssize_t, this is essentially the case. You might want to take the unicodeobject.c file as example. unicodeobject.c is not an extension. We were discussing existing extension modules. We could use the type flags for these. much like we do for the new style numbers. Would you like to write a specification for that? If you don't like the macro approach, why not simply leave the two separate sets of APIs visible. To simplify the porting. All Py_ssize_t aware and compatible extensions would use the new APIs instead. The old-style APIs should then take care of the proper down-casting and error reporting. That is not possible. Some API does not support error reporting (like PyString_Size()). So callers don't expect it to fail. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r42015 - peps/trunk
[Tim Peters] Yes. please. svn:externals should always pin to a specific revision (or at least to a frozen tag). Updating to a new revision then is just a propedit away (to change the revision number); ditto for backing off to an older revision if the newer one has problems. [Fredrik Lundh] wasn't the whole point for this exercise Sorry, I don't know what the whole point was. to make sure that the included version was always up to date. if you pin it to a given version, all we got from this was a dependence on another SVN server. And very easy updating to a new version (a propedit away ...), and transparency about exactly what it is we're depending on (revision 12345 of project XYZ). (and a can of SVN worms, including issues with locking/cleanup, etc) I haven't experienced any of that. I've experienced plenty of locking/cleanup problems when a project switches _between_ making its own copies and using svn:externals, but none so long as it sticks to one way of doing that. Even on Windows ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ConfigParser to save with order
I see two paths here: - Rewrite ConfigParser entirely. - Apply my patch. Allowing 'surgical' editing of configuration files, as has been proposed many times both here and c.l.p would not require ConfigParser to be entirely rewritten (just more extensive modification of the write() method). Someone needs to make a PEP. Michael Chermside, in the first mail of the first link that you sent, was working in a solution, but don't know what is done. I believe that this always trails off without anything being achieved. IMO what would be best would be a pronouncement (or something of similar weight) about the direction that should be taken wrt to configuration file parsing support in the stdlib. * The status quo. * The status quo, but output files in a fixed order (but unrelated to the read order); i.e. http://python.org/sf/1399309 * 'Surgical' editing of files; i.e. preserve comments, whitespace, and ordering, appending new options/sections as needed. * A more complex configuration system (perhaps like others that exist in the wild). I'm happy to either submit or help with a patch for the third option (and maybe the fourth) if need be. I haven't personally found the lack of a more complex system in the stdlib a problem (although I suppose that the various more complex systems I have worked with could have been simplified if there was one). I do believe that failing to preserve comments and ordering is a problem. =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ph.D. dissertation ideas?
Brett, How about building a system that compiles a Python program (possibly annotated) to an AJAX program? That is, it analyzes the program to determine what's appropriate and possible for client-side and server-side, figures out the optimal network API (reduce latency, reduce calls, reduce data transfer, increase responsiveness), generates server-side Jython to run in Tomcat (or Python for mod_python), and client-side XHTML, CSS, and Javascript to implement the browser-based portion of the application. Oddities of browser implementations and Javascript VMs would be contained in the compiler and automatically pushed into the generated code. This would be a tremendously useful advance in building distributed systems that work with the Web. The current approach to AJAX is a bit like carpentry with old hand tools. You'd probably also push Python to higher levels of language-ness. Tough question. Language design is the over-reaching area that I love. Basically how can powerful language ideas be presented in a easy-to-use fashion. Could even generalize even farther to just making programming easier through the language. And for some reason networking protocols and concurrent programming have always caught my eye Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries
I sorta disagree about it not being broken. Adding a feature which
works for eval but not for exec seems pretty broken. It's difficult to
reason about what will happen in the exec context, so I can't see what
fixing it would endanger; but I'd deffinately like to see it for 2.5.
I've run rough timings on the code, ('test make time'), detailed in
the patch discussion, and it seems completely lost in the noise.
On 1/12/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
Is there any objection to this patch? Any support?
It is assigned to me. When I have time, will go through it in detail
(the given use cases, more detailed timings, and a close reading of the
code).
If accepted, it will be for Py2.5, as it is a new feature. There is
nothing broken about the existing eval() version, it just doesn't apply
as broadly as you would have liked.
Raymond
--
Crutcher Dunnavant [EMAIL PROTECTED]
monket.samedi-studios.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ph.D. dissertation ideas?
On 1/12/06, Bill Janssen [EMAIL PROTECTED] wrote: Brett, How about building a system that compiles a Python program (possibly annotated) to an AJAX program? That is, it analyzes the program to determine what's appropriate and possible for client-side and server-side, figures out the optimal network API (reduce latency, reduce calls, reduce data transfer, increase responsiveness), generates server-side Jython to run in Tomcat (or Python for mod_python), and client-side XHTML, CSS, and Javascript to implement the browser-based portion of the application. Oddities of browser implementations and Javascript VMs would be contained in the compiler and automatically pushed into the generated code. This would be a tremendously useful advance in building distributed systems that work with the Web. The current approach to AJAX is a bit like carpentry with old hand tools. You'd probably also push Python to higher levels of language-ness. Hmm. It's an idea. I also thought of Python - JavaScript compiler since JavaScript is not fun and getting to test using Python might be cool. But not sure how useful that would be. Plus I bet someone has does this with Java or something. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP and stdlib
Fabien Schwob wrote: What do you think about that ? See PEP 2. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unicode print/stdoutput exceptions are not nice
[EMAIL PROTECTED]
Martin v. Löwis schrieb:
Robert wrote:
is in a PythonWin Interactive session - ok results for cyrillic chars
(tolerant mbcs/utf-8 encoding!).
But if I do this on Win console (as you probably mean), I get also
encoding Errors - no matter if chcp1251, because cyrillic chars raise
the encoding errors also.
If you do chcp 1251 (not chcp1251) in the console, and then
run python.exe in the same console, what is the value of
sys.stdout.encoding?
correctly: 'cp1252' in my case; cyrillic-chars break print (on PC
linux 2.2 tty py24 sys.stdout.encoding is None (?); only
locale.getdef... useful? )
I live with this in site(customize):
import codecs
_stdout=sys.stdout
if sys.platform=='win32' and not
sys.modules.has_key('pywin.framework.startup'):
_stdoutenc=getattr(_stdout,'encoding',None) or sys.getdefaultencoding()
try: codecs.lookup(_stdoutenc)
except LookupError: _stdoutenc=sys.getdefaultencoding()
class StdOut:
def write(self,s):
_stdout.write(s.encode(_stdoutenc,'backslashreplace'))
sys.stdout=StdOut()
elif sys.platform.startswith('linux'):
import locale
_stdoutenc=locale.getdefaultlocale()[1]
try: codecs.lookup(_stdoutenc)
except LookupError: _stdoutenc=sys.getdefaultencoding()
class StdOut:
def write(self,s):
_stdout.write(s.encode(_stdoutenc,'backslashreplace'))
sys.stdout=StdOut()
I think this is not a good behaviour of python to be so picky.
I think it it is good.
Errors should never pass silently.
Unless explicitly silenced.
A political question. Arguments:
* Webbrowsers for example have to display defective HTML as good as
possible, unknown unicode chars as ? and so on... Users got very angry
in the beginning of browsers when 'strict' programmers displayed their
exception error boxes ...
* at least the print statement has to go through - the costs (for
angry users and developers; e.g.
http://blog.ianbicking.org/do-i-hate-unicode-or-do-i-hate-ascii.html)
are much higher when apps suddenly break in simple print/display-output
when the system picks up alien unicode chars somewhere (e.g.
occasionally in filenames,...). No one is really angry when occasionally
chinese chars are displayed cryptically on non-chinese computers. One
can investigate, add fonts, ... to improve, or do nothing in most cases,
but apps do not break on every print statement! This is not only true
for tty-output, but also for log-file redirect and almost any common
situation for print/normal stdout/file-(write)-output.
* anything is nice-printable in python by default, why not
unicode-strings!? If the decision for default 'strict' encoding on
stdout stands, we have at least to discuss about print-repr for unicode.
* the need for having technical strings 'strict' is much more rare. And
programmers are anyway very aware in such situations . e.g. by
asciifile.write( us.encode(xy,'strict') ) .
* on Windows for example the (good) mbcs_encode is anyway tolerant as
it: unkown chars are mapped to '?' . I never had any objection to this.
Some recommendations - soft to hard:
* make print-repr for unicode strings tolerant (and in PythonWin alwasy
tolerant 'mbcs' encoding)
* make stdout/files to have 'replace'-mode encoding by default. (similar
as done with my code above)
* set site.py/encoding=('ascii', 'replace') # if not utf-8/mbcs/locale
;enable a tuple
* save sys._setdefaultencoding by default
* I would also live perfectly with .encode(enc) to run 'replace' by
default, and 'strict' on demand. None of my apps and scripts would break
because of this, but win. A programmer is naturally very aware when he
wants 'strict'. Can you name realistic cases where 'replace' behavior
would be so critical that a program damages something?
In
[EMAIL PROTECTED] I showed, how I
solved this so far. Any better/portable idea?
Not sure why you aren't using sys.stdout.encoding on Linux. I would do
try:
c = codecs.getwriter(sys.stdout.encoding)
except:
c = codecs.getwriter('ascii')
sys.stdout = c(sys.stdout, 'replace')
Also, I wouldn't edit site.py, but instead add sitecustomize.py.
I have more problems with the shape of sys.path in different situations,
multiple sitecustomize.py on other apps, environments, OS / users,
cxfreeze,py2exe ... sitecustomize not stackable easily: a horror
solution. The need is for a callable _function_ or for general change in
python behaviour.
modifiying site.py is better and stable for me (I have my
patch/module-todo-list handy each time i install a new python), as I
always want tolerant behaviour. in code i check for
site.encoding/_setdefaultencoding (I save this). Thus i get one central
error if setup is not correct, but not evil unicode-errors somewhere
deep in the app once on a russian computer in the future...
Yes. But the original problem is, that occasionally unicode strings
(filenames in my
[Python-Dev] DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31
Here's the second December summary. As always, if anyone can spare some time to take a look over it and send any comments/suggestions/corrections/additions to me or Steve that would be great. I'm not all that confident about the default comparisons thread, so particular attention to that would be great. Thanks! = Announcements = QOTF: Quote of the Fortnight Python-dev is in love with Python, though sometimes too much, Fredrik Lundh contends: ...in reality, some things are carefully thought out and craftily implemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. Contributing thread: - `a quit that actually quits http://mail.python.org/pipermail/python-dev/2005-December/059283.html`__ [SJB] --- Reminder: plain text documentation patches are accepted --- Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or ReST fixes are also welcome. You won't be able to produce a diff file like with a normal patch, but comments that explain how to fix the docs are just as good. A form like in section XXX right before the paragraph starting with YYY, the documentation should say ZZZ will make it easy for the doc maintainers to apply your fix. Contributing thread: - `LaTeX and Python doc contributions http://mail.python.org/pipermail/python-dev/2005-December/059001.html`__ [SJB] --- PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January 2006 --- The next PyPy_ sprint is scheduled to take place from the 23rd to the 29th of January 2006 in Palma De Mallorca, Balearic Isles, Spain. There will be newcomer-friendly introductions and the focus will mainly be on current JIT work, garbage collection, alternative threading models, logic programming and on improving the interface with external functions. .. _PyPy: http://codespeak.net/pypy Contributing thread: - `Next PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January 2006 http://mail.python.org/pipermail/python-dev/2005-December/058975.html`__ [TAM] -- SHA-224, -256, -384 and -512 support in Python 2.5 -- Ronald L. Rivest asked about the cryptographic hash function support in Python, now that md5 and sha1 are broken in terms of collision-resistance. The new-in-Python-2.5 hashlib module was pointed out (and somewhat belatedly added to the NEWS file), which includes new implementations for SHA-224, -256, -384 and -512 (these, including tests, are already in SVN). Gregory P. Smith noted that although the code isn't currently available for earlier versions of Python, he does plan to release a standalone package for Python 2.3 and Python 2.4, when time permits. Contributing thread: - `hashlib - faster md5/sha, adds sha256/512 support http://mail.python.org/pipermail/python-dev/2005-December/058850.html`__ [TAM] = Summaries = --- Improving the documentation process --- Fredrik Lundh asked about automatically updating the development docs, so that users wouldn't be required to have a latex toolchain installed to get an HTML version of the current docs. This spawned a long discussion about using something other than LaTeX (e.g. microformats_ or ReST_) for markup. Though HTML has the advantage that many Python users are already familiar with it, a number of people voiced concerns about the ease of reading and writing it. ReST is generally easy to read and write, but some people suggested that for complicated structured text (like Python function and class definitions) it was no better than LaTeX. Fredrik Lundh presented some example code side-by-side_ and argued that using HTML with something like PythonDoc_ could better represent the documentation's intent. He also produced an initial conversion_ of the Python docs to this format. Fredrik also pointed out that currently the doc patch submission procedure is rather tedious, and listed_ the rather large number of steps required for end-users and developers to get their documentation fixes added to the current Python docs. He claimed that a simple wiki, discussion board, or user edit mechanism like that of roundup_, combined with automated updates of the documentation from the Python SVN trunk, could reduce this procedure to two or three simple steps. As a partial effort towards this goal, Trent Mick started posting `daily builds`_ of the Python HTML. This prompted Neal Norwitz to set up the docs server in a similar manner so
Re: [Python-Dev] Ph.D. dissertation ideas?
Brett Cannon wrote: On 1/12/06, Bill Janssen [EMAIL PROTECTED] wrote: Brett, How about building a system that compiles a Python program (possibly annotated) to an AJAX program? That is, it analyzes the program to determine what's appropriate and possible for client-side and server-side, figures out the optimal network API (reduce latency, reduce calls, reduce data transfer, increase responsiveness), generates server-side Jython to run in Tomcat (or Python for mod_python), and client-side XHTML, CSS, and Javascript to implement the browser-based portion of the application. Oddities of browser implementations and Javascript VMs would be contained in the compiler and automatically pushed into the generated code. This would be a tremendously useful advance in building distributed systems that work with the Web. The current approach to AJAX is a bit like carpentry with old hand tools. You'd probably also push Python to higher levels of language-ness. Hmm. It's an idea. I also thought of Python - JavaScript compiler since JavaScript is not fun and getting to test using Python might be cool. But not sure how useful that would be. Plus I bet someone has does this with Java or something. If you can persuade your supervisor to be interested in educational games, a Python learning system might be an interesting project with lots of scope for user modelling and goal-directed behaviour. There's been some work done on bomb-proofing the interpreter to offer a try-python type site, but nobody seems to have thought about how to engage a neophyte with an specific teaching strategy (possibly based on personality analysis) and then present problems to verify comprehension and offer appropriate feedback. That would be a terrific game! regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pystate.c changes for Python 2.4.2
Hi, At the company I work for, we've embedded Python in C++ application we develop. Since our upgrade to Python 2.4.2 from 2.4.1 we started hitting Py_FatalError(Invalid thread state for this thread) when using debug builds. We use both multiple interpreters and thread states. I think the problem is that PyThreadState_Delete (which is used when I destroy thread states and interpreters) is not making the same clean up that PyThreadState_DeleteCurrent is doing (which is used when we create threads from python code). If a thread id is reused (obviously not between two running threads), and the previous thread used PyThreadState_Delete instead of PyThreadState_DeleteCurrent, then an old and invalid value for autoTLSkey is still stored, and that is triggering the Py_FatalError when a call to PyThreadState_Swap is made. If I add this code at the end of PyThreadState_Delete: if (autoTLSkey PyThread_get_key_value(autoTLSkey) == tstate) PyThread_delete_key_value(autoTLSkey); then everything works fine. Could you please confirm if this is a bug ? Thanks a lot and have a nice day. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Martin v. Löwis [EMAIL PROTECTED] writes: Thomas Heller wrote: Sounds good, although it should be noted that ctypes is a package now, with a ctypes.wrap subpackage (contains the code generator), a ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X), and ctypes.test subpackage whcih contains several test modules. Plus the _ctypes.(dll|so) extension module. Ok. The installer should then combine them all into a feature. Still, the admin could disable all of this just by removing _ctypes.dll, right? Right. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pystate.c changes for Python 2.4.2
On Thu, Jan 12, 2006, Gabriel Becedillas wrote: If I add this code at the end of PyThreadState_Delete: if (autoTLSkey PyThread_get_key_value(autoTLSkey) == tstate) PyThread_delete_key_value(autoTLSkey); then everything works fine. Could you please confirm if this is a bug ? Regardless of whether you get any other responses, please go ahead and file a SourceForge bug report so that we don't lose track of this. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15
= Announcements = - Reminder: plain text documentation fixes are accepted - Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or ReST fixes are also welcome. You won't be able to produce a diff file like with a normal patch, but comments that explain how to fix the docs are just as good. A form like in section XXX right before the paragraph starting with YYY, the documentation should say ZZZ will make it easy for the doc maintainers to apply your fix. Contributing thread: - `c.l.p post on docs http://mail.python.org/pipermail/python-dev/2005-December/058479.html`__ [SJB] New-style exceptions patch requesting review With `PEP 352`_ ready_ for Guido's pronouncement, Michael Hudson has asked for a few more developers to review his patch_ to make all exceptions new-style. It should be basically ready, but it would be nice to have a few eyes for sanity checks, documentation, and compilations on the various platforms. .. _PEP 352: http://www.python.org/peps/pep-0352.html .. _ready: http://www.python.org/dev/summary/2005-10-16_2005-10-31.html#required-superclass-for-exceptions .. _patch: http://bugs.python.org/1104669 Contributing threads: - `New-style exceptions patch (was Re: PEP 8 updates/clarifications) http://mail.python.org/pipermail/python-dev/2005-December/058542.html`__ - `New-style exceptions patch http://mail.python.org/pipermail/python-dev/2005-December/058543.html`__ [SJB] Debugging lib available from ActiveState Trent Mick confirmed that ActiveState do distribute a separate distribution of debug DLLs for each Python release. These can be found by filling in the version number in the URL ftp://ftp.activestate.com/ActivePython/etc/ActivePython-version-win32-ix86-debug.zip Contributing thread: - `Plea to distribute debugging lib http://mail.python.org/pipermail/python-dev/2005-December/058446.html`__ [TAM] = Summaries = --- Updating the Python style guide --- Ian Bicking kicked off a lengthy discussion about updating various aspects of `PEP 8`_ (the Python code style guide), which resulted in a substantial revision of the PEP. PEP 8 stated that if a module defines a single exception raised for all sorts of conditions, it is generally called error or Error. Ian noted that other than some outlying cases (e.g. os.error, socket.error), CapWords are always used. He also wondered if exceptions should have names that are relatively unique, or simply unique within their namespace. Finally, he requested a position be taken on acronyms (e.g. HHTPRedirect or HttpRedirect). Barry Warsaw pointed out that since exceptions are now classes, the rules for naming classes should really apply; his preference is CapWordsEndingInError rather than Error or error. He also suggested that acronym letters should be capitalised. There was mostly consensus on this, although some prefer shorter exception class names. Guido wondered whether the function/method naming convention (lower_case, mixedCase, or CapWords) was so controversial that the PEP should not make a recommendation other than of consistency. In the end, however, the status quo (lower_case except for consistency reasons) won out. He was definite about module, package, and class names, however, which should be all-lowercase without underscores (modules/packages), or CapWords (class names). (He noted that standard library modules such as StringIO.py and UserDict.py that break this rule should be changed). PEP 8 recommended appending an underscore rather than corrupted spelling when a name conflicts with a reserved word e.g. class_ rather than klass). Ian suggested that a specific recommendation for the class argument to classmethods be made; out of cls, klass and class_ he preferred cls. He further suggested that, as self is not used outside of the first argument of instance methods, whatever spelling of the class argument is used should not be used elsewhere (e.g. cls for the class argument, and class_ elsewhere). This was generally accepted. A further suggestion from Barry's `Mailman style guide`_ was also made, that from-imports should follow non-from imports, and dotted imports should follow non-dotted imports. Non-dotted imports should be grouped by increasing length, while dotted imports should be grouped roughly alphabetically. However, this was felt to be too prescriptive; users should follow their own aesthetic taste. Various other small modifications and improvements were suggested and made, such as:: * PEP 8 stated that modules designed for use via from M import * should prefix their globals, internal
Re: [Python-Dev] r42015 - peps/trunk
[David Goodger] An alternative is to use svn:externals to link to a specific revision (via the -r option); [Tim Peters] Yes. please. Done. -- David Goodger http://python.net/~goodger signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ph.D. dissertation ideas?
Brett, Where are you doing your Phd and who will be your likely supervisor? It does make a difference. Your dissertation idea list seems to me to focus on implementation projects and not on research. Usually a dissertation proceeds from a hypothesis leading to an experiment, some measurements, and conclusions. Many universities tacitly expect a theorem and associated proof. The goal of dissertation research is a completed approved dissertation, not some intergalactic all encompassing contribution to human knowledge. Dissertation research should, IMHO, focus on a small, manageable problem. Frequently, universities have a large cooperative project involving many graduate students, each of whom research a small, well defined topic areas related to the larger project. Is this the case for your dissertation? What are your interests? Are you interested in language structure, language implementation, the formal interface between languages and applications, or what. Like most folks who lurk on this list, I have my list of things I'd like to see someone research. Tell us a bit more and I am sure you'll get lots of us to share. -d On Thu, 12 Jan 2006, Brett Cannon wrote: It is time once again in my educational career to come to python-dev for help for major project ideas. This time, though, it is for my Ph.D. dissertation (and thus can have larger scope than my masters thesis) but there are funding restrictions (and thus only certain areas I have possible funding for). First off, there are two areas where I have possible funding: XML integration into programming languages and game scripting support (I have a third, AOP for anything, but I don't think AOP is a good match for Python and thus not considering it for Python work). The XML integration I have no direct ideas since I don't use XML. There is the possibility of doing something like the LINQ project (http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp) or something, but I don't know how useful that could be. It would have to be just as generic, though, as the LINQ project in terms of working with intefaces to be Pythonic so it might turn out to be more about language support for querying data. For the game scripting, trying out the active objects for Python is a possibility (or something else that would help with concurrency). Since that could allow for agent objects to be more concurrent it can be argued that it would help with game scripting. I don't have any other ideas for the area of game scripting support. Now I am not locked down to these areas, but they are what I have possible grant money for. If through some miracle someone out there wants to fund my Ph.D. and wants something else worked on for Python, don't be shy. =) Unfortunately I don't think the PSF is up for funding my Ph.D., else I would say I would work on whatever python-dev decided they wanted to worked on that could be done as a dissertation. Anyway, any ideas are appreciated. There is no rush on this, either. Just getting this out there now while I am tentatively exploring possible topics. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/allison%40sumeru.stanford.edu -- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
