[Python-Dev] python-dev sprint at PyCon
Every PyCon has featured a python-dev sprint. For the past few years, hacking on the AST branch has been a tradition, but we'll have to come up with something new for this year's conference (in Dallas Texas; sprints will be Monday Feb. 27 through Thursday March 2). According to Anthony's release plan, a first alpha of 2.5 would be released in March, hence after PyCon and the sprints. We should discuss possible tasks for a python-dev sprint. What could we do? When the discussion is over, someone should update the wiki page with whatever tasks are suggested: http://wiki.python.org/moin/PyCon2006/Sprints. --amk ___ 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] [C++-sig] GCC version compatibility
Christoph Ludwig [EMAIL PROTECTED] writes: Hi, this is to continue a discussion started back in July by a posting by Dave Abrahams url:http://thread.gmane.org/gmane.comp.python.devel/69651 regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. On Sat, Jul 16, 2005 at 12:13:58PM +0200, Christoph Ludwig wrote: On Sun, Jul 10, 2005 at 07:41:06PM +0200, Martin v. Löwis wrote: Maybe. For Python 2.4, feel free to contribute a more complex test. For Python 2.5, I would prefer if the entire code around ccpython.cc was removed. I submitted patch #1239112 that implements the test involving two TUs for Python 2.4. I plan to work on a more comprehensive patch for Python 2.5 but that will take some time. I finally had the spare time to look into this problem again and submitted patch #1324762. The proposed patch implements the following: I just wanted to write to encourage some Python developers to look at (and accept!) Christoph's patch. This is really crucial for smooth interoperability between C++ and Python. Thank you, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.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] python-dev sprint at PyCon
At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
Every PyCon has featured a python-dev sprint. For the past few years,
hacking on the AST branch has been a tradition, but we'll have to come
up with something new for this year's conference (in Dallas Texas;
sprints will be Monday Feb. 27 through Thursday March 2).
According to Anthony's release plan, a first alpha of 2.5 would be
released in March, hence after PyCon and the sprints. We should
discuss possible tasks for a python-dev sprint. What could we do?
* PEP 343 implementation ('with:')
* PEP 308 implementation ('x if y else z')
* A bytes type
Or perhaps some of the things that have been waiting for the AST branch to
be finished, i.e.:
* One of the global variable speedup PEPs
* Guido's instance variable speedup idea (LOAD_SELF_IVAR and
STORE_SELF_IVAR, see
http://mail.python.org/pipermail/python-dev/2002-February/019854.html)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
Every PyCon has featured a python-dev sprint. For the past few years,
hacking on the AST branch has been a tradition, but we'll have to come
up with something new for this year's conference (in Dallas Texas;
sprints will be Monday Feb. 27 through Thursday March 2).
According to Anthony's release plan, a first alpha of 2.5 would be
released in March, hence after PyCon and the sprints. We should
discuss possible tasks for a python-dev sprint. What could we do?
* PEP 343 implementation ('with:')
* PEP 308 implementation ('x if y else z')
* A bytes type
* PEP 328 - absolute/relative import
* PEP 341 - unifying try/except and try/finally (I believe this was
accepted; it's still marked Open in PEP 0)
Or perhaps some of the things that have been waiting for the AST branch to
be finished, i.e.:
* One of the global variable speedup PEPs
* Guido's instance variable speedup idea (LOAD_SELF_IVAR and
STORE_SELF_IVAR, see
http://mail.python.org/pipermail/python-dev/2002-February/019854.html)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
On 11/1/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote: Every PyCon has featured a python-dev sprint. For the past few years, hacking on the AST branch has been a tradition, but we'll have to come up with something new for this year's conference (in Dallas Texas; sprints will be Monday Feb. 27 through Thursday March 2). According to Anthony's release plan, a first alpha of 2.5 would be released in March, hence after PyCon and the sprints. We should discuss possible tasks for a python-dev sprint. What could we do? I added the 4 PEPs mentioned and a few more ideas here: http://wiki.python.org/moin/PyCon2006/Sprints/PythonCore n ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote: * PEP 328 - absolute/relative import I assume that references to 2.4 in that PEP should be changed to 2.5, and so on. It also appears to me that the PEP doesn't record the issue brought up by some people about the current absolute/relative ambiguity being useful for packaging purposes. i.e., being able to nest third-party packages such that they end up seeing their dependencies, even though they're not installed at the root package level. For example, I have a package that needs Python 2.4's version of pyexpat, and I need it to run in 2.3, but I can't really overwrite the 2.3 pyexpat, so I just build a backported pyexpat and drop it in the package, so that the code importing it just ends up with the right thing. Of course, that specific example is okay since 2.3 isn't going to somehow grow absolute importing. :) But I think people brought up other examples besides that, it's just the one that I personally know I've done. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote: * PEP 328 - absolute/relative import I assume that references to 2.4 in that PEP should be changed to 2.5, and so on. For the part that hasn't been implemented yet, yes. It also appears to me that the PEP doesn't record the issue brought up by some people about the current absolute/relative ambiguity being useful for packaging purposes. i.e., being able to nest third-party packages such that they end up seeing their dependencies, even though they're not installed at the root package level. For example, I have a package that needs Python 2.4's version of pyexpat, and I need it to run in 2.3, but I can't really overwrite the 2.3 pyexpat, so I just build a backported pyexpat and drop it in the package, so that the code importing it just ends up with the right thing. Of course, that specific example is okay since 2.3 isn't going to somehow grow absolute importing. :) But I think people brought up other examples besides that, it's just the one that I personally know I've done. I guess this ought to be recorded. :-( The issue has been beaten to death and my position remains firm: rather than playing namespace games, consistent renaming is the right thing to do here. This becomes a trivial source edit, which beats the problems of debugging things when it doesn't work out as expected (which is very common due to the endless subtleties of loading multiple versions of the same code). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote: I guess this ought to be recorded. :-( The issue has been beaten to death and my position remains firm: rather than playing namespace games, consistent renaming is the right thing to do here. This becomes a trivial source edit, Well, it's not trivial if you're (in my case) trying to support 2.3 and 2.4 with the same code base. It'd be nice to have some other advice to offer people besides, go edit your code. Of course, if the feature hadn't already existed, I suppose a PEP to add it would have been shot down, so it's a reasonable decision. which beats the problems of debugging things when it doesn't work out as expected (which is very common due to the endless subtleties of loading multiple versions of the same code). Yeah, Bob Ippolito and I batted around a few ideas about how to implement simultaneous multi-version imports for Python Eggs, some of which relied on the relative/absolute ambiguity, but I think the main subtleties have to do with dynamic imports (including pickling) and the use of __name__. Of course, since we never actually implemented it, I don't know what other subtleties could potentially exist. Python Eggs currently allow you to install multiple versions of a package, but at runtime you can only import one of them, and you get a runtime VersionConflict exception if two eggs' version criteria are incompatible. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote: I guess this ought to be recorded. :-( The issue has been beaten to death and my position remains firm: rather than playing namespace games, consistent renaming is the right thing to do here. This becomes a trivial source edit, Well, it's not trivial if you're (in my case) trying to support 2.3 and 2.4 with the same code base. It'd be nice to have some other advice to offer people besides, go edit your code. Of course, if the feature hadn't already existed, I suppose a PEP to add it would have been shot down, so it's a reasonable decision. Why can't you add your version's directory to sys.path before importing pyexpat? n ___ 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] apparent ruminations on mutable immutables (was: PEP 351, the freeze protocol)
Noam Raphael [EMAIL PROTECTED] wrote: On 10/31/05, Josiah Carlson [EMAIL PROTECTED] wrote: About the users-changing-my-internal-data issue: ... You can have a printout before it dies: I'm crashing your program because something attempted to modify a data structure (here's the traceback), and you were told not to. Then again, you can even raise an exception when people try to change the object, as imdict does, as tuples do, etc. Both solutions would solve the problem, but would require me to wrap the built-in set with something which doesn't allow changes. This is a lot of work - but it's quite similiar to what my solution would actually do, in a single built-in function. I am an advocate for PEP 351. However, I am against your proposed implementation/variant of PEP 351 because I don't believe it ads enough to warrant the additional complication and overhead necessary for every object (even tuples would need to get a .frozen_cache member). Give me a recursive freeze from PEP 351 (which handles objects that are duplicated, but errors out on circular references), and I'll be happy. You suggest two ways for solving the problem. The first is by copying my mutable objects to immutable copies: And by caching those results, then invalidating them when they are updated by your application. This is the same as what you would like to do, except that I do not rely on copy-on-write semantics, which aren't any faster than freeze+cache by your application. This isn't correct - freezing a set won't require a single copy to be performed, as long as the frozen copy isn't saved after the original is changed. Copy+cache always requires one copy. You are wrong, and you even say you are wrong...freezing a set doesn't require a COPY, IF the frozen COPY isn't saved after the original is CHANGED. Creating an immutable set IS CREATING A COPY, so it ALSO copies, and you admit as much, but then say the equivalent of copying isn't copying because I say so. In any case, whether you choose to use freeze, or use a different API, this particular problem is solvable without copy-on-write semantics. Right. But I think that a significant simplification of the API is a nice bonus for my solution. And about those copy-on-write semantics - it should be proven how complex they are. Remember that we are talking about frozen-copy-on-write, which I think would simplify matters considerably - for example, there are at most two instances sharing the same data, since the frozen copy can be returned again and again. I think that adding an additional attribute to literally every single object to handle the caching of 'frozen' objects, as well as a list to every object to handle callbacks which should be called on object mutation, along with a _call_stuff_when_mutated() method that handles these callback calls, IN ADDITION TO the __freeze__ method which is necessary to support this, is a little much, AND IS CERTAINLY NOT A SIMPLIFICATION! Let us pause for a second and consider: Original PEP proposed 1 new method: __freeze__, which could be implemented as a subclass of the original object (now), and integrated into the original classes as time goes on. One could /register/ __freeze__ functions/methods a'la Pickle, at which point objects wouldn't even need a native freeze method. Your suggestion offers 2 new methods along with 2 new instance variables. Let's see, a callback handler, __freeze__, the cache, and the callback list. Doesn't that seem a little excessive to you to support freezing? It does to me. If Guido were to offer your implementation of freeze, or no freeze at all, I would opt for no freeze, as implementing your freeze on user-defined classes would be a pain in the ass, not to mention implementing them in C code would be more than I would care to do, and more than I would ask any of the core developers to work on. Even without validation, there are examples that force a high number of calls, which are not O(1), ammortized or otherwise. [Snap - a very interesting example] Now, the actual time analysis on repeated freezings and such gets ugly. There are actually O(k) objects, which take up O(k**2) space. When you modify object b[i][j] (which has just been frozen), you get O(k) callbacks, and when you call freeze(b), it actually results in O(k**2) time to re-copy the O(k**2) pointers to the O(k) objects. It should be obvious that this IS NOT AMMORTIZABLE to original object creation time. That's absolutely right. My ammortized analysis is correct only if you limit yourself to cases in which the original object doesn't change after a frozen() call was made. In that case, it's ok to count the O(k**2) copy with the O(k**2) object creation, because it's made only once. But here's the crucial observation which you are missing. You yourself have stated that in both your table and graph examples you want your application to continue to modify
Re: [Python-Dev] python-dev sprint at PyCon
At 10:34 AM 11/1/2005 -0800, Neal Norwitz wrote: Why can't you add your version's directory to sys.path before importing pyexpat? With library code that can be imported in any order, there is no such thing as before. Anyway, Guido has pronounced on this already, so it's moot. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 11:14 AM 11/1/2005 -0700, Guido van Rossum wrote: I guess this ought to be recorded. :-( The issue has been beaten to death and my position remains firm: rather than playing namespace games, consistent renaming is the right thing to do here. This becomes a trivial source edit, Well, it's not trivial if you're (in my case) trying to support 2.3 and 2.4 with the same code base. You should just bite the bullet and make a privatized copy of the package(s) on which you depend part of your own distributions. It'd be nice to have some other advice to offer people besides, go edit your code. Of course, if the feature hadn't already existed, I suppose a PEP to add it would have been shot down, so it's a reasonable decision. I agree it would be nice if we could do something about deep version issues. But it's hard, and using the absolute/relative ambiguity isn't a solution but a nasty hack. I don't have a solution either except copying code (which IMO is a *fine* solution in most cases as long as copyright issues don't prevent you). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] a different kind of reduce...
[Martin Blais] I'm always--literally every time-- looking for a more functional form, something that would be like this: # apply dirname() 3 times on its results, initializing with p ... = repapply(dirname, 3, p) [Greg Ewing] Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) 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] svn checksum error
On Sun, 2005-10-30 at 19:08 -0600, [EMAIL PROTECTED] wrote: Martin The natural question then is: what operating system, what Martin subversion version are you using? Sorry, wasn't thinking in terms of svn bugs. I was anticipating some sort of obvious pilot error. I am on Mac OSX 10.3.9, running svn 1.1.3 I built from source back in the May timeframe. Should I upgrade to 1.2.3 as a matter of course? Fredrik welcome to the wonderful world of subversion error messages ... Fredrik deleting the offending directory and doing svn up is the Fredrik easiest way to fix this. Thanks. I zapped Objects. The next svn up complained about Misc. The next about Lib. After that, the next svn up ran to completion. Skip You didn't happen to try to update a checked out copy from a repo that had an older cvs2svn conversion to the one produced by the final conversion, did you? Cause that will cause these errors too. --Dan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:35 AM 11/1/2005 -0500, A.M. Kuchling wrote:
Every PyCon has featured a python-dev sprint. For the past few years,
hacking on the AST branch has been a tradition, but we'll have to come
up with something new for this year's conference (in Dallas Texas;
sprints will be Monday Feb. 27 through Thursday March 2).
According to Anthony's release plan, a first alpha of 2.5 would be
released in March, hence after PyCon and the sprints. We should
discuss possible tasks for a python-dev sprint. What could we do?
* PEP 343 implementation ('with:')
* PEP 308 implementation ('x if y else z')
* A bytes type
Or perhaps some of the things that have been waiting for the AST branch to
be finished, i.e.:
* One of the global variable speedup PEPs
* Guido's instance variable speedup idea (LOAD_SELF_IVAR and
STORE_SELF_IVAR, see
http://mail.python.org/pipermail/python-dev/2002-February/019854.html)
I hope to attend the sprints this year, so i'd be around to help
people get started and answer questions. With luck, I'll also be
giving a technical presentation on the work at the main conference.
Jeremy
___
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] a different kind of reduce...
Raymond Hettinger wrote: [Martin Blais] I'm always--literally every time-- looking for a more functional form, something that would be like this: # apply dirname() 3 times on its results, initializing with p ... = repapply(dirname, 3, p) [Greg Ewing] Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) And we have solved the map, filter and reduce are going away! Let's all weep together problem with one strike! Reinhold -- Mail address is perfectly valid! ___ 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] apparent ruminations on mutable immutables (was: PEP 351, the freeze protocol)
On 11/1/05, Josiah Carlson [EMAIL PROTECTED] wrote: ... I am an advocate for PEP 351. However, I am against your proposed implementation/variant of PEP 351 because I don't believe it ads enough to warrant the additional complication and overhead necessary for every object (even tuples would need to get a .frozen_cache member). Give me a recursive freeze from PEP 351 (which handles objects that are duplicated, but errors out on circular references), and I'll be happy. That's fine - but it doesn't mean that I must be happy with it. ... This isn't correct - freezing a set won't require a single copy to be performed, as long as the frozen copy isn't saved after the original is changed. Copy+cache always requires one copy. You are wrong, and you even say you are wrong...freezing a set doesn't require a COPY, IF the frozen COPY isn't saved after the original is CHANGED. Creating an immutable set IS CREATING A COPY, so it ALSO copies, and you admit as much, but then say the equivalent of copying isn't copying because I say so. No, I am not wrong. I am just using misleading terms. I will call a frozen copy a frozen image. Here it goes: freezing a set doesn't require a COPY, IF the frozen IMAGE isn't saved after the original is CHANGED. I suggest that there would be a way to create a frozenset without COPYING an O(n) amount of MEMORY. When a frozen set is created by a call frozen(x), it would not copy all the data, but would rather reference the existing data, which was created by the non-frozen set. Only if the original set changes, when there's a frozen set referencing the data, the MEMORY would be actually copied. I call it a frozen copy because it behaves as a frozen copy, even though not all the memory is being copied. When you call the COPY function in the COPY module with a string, it doesn't really copy memory - the same string is returned. When you copy a file inside subversion, it doesn't actually copy all the data associated with it, but does something smarter, which takes O(1). The point is, for the user, it's a copy. Whether or not memory is actually being copied, is an implementation detail. ... I think that adding an additional attribute to literally every single object to handle the caching of 'frozen' objects, as well as a list to every object to handle callbacks which should be called on object mutation, along with a _call_stuff_when_mutated() method that handles these callback calls, IN ADDITION TO the __freeze__ method which is necessary to support this, is a little much, AND IS CERTAINLY NOT A SIMPLIFICATION! I don't agree. You don't need to add a list to every object, since you can store all those relations in one place, with a standard function for registering them. Anyway, code written in Python (which is the language we are discussing) WON'T BE COMPLICATED! The frozen mechanism, along with two new protocols (__frozen__ and __changed__), would be added automatically! The internal state of a class written in Python can be automatically frozen, since it's basically a dict. Now let's see if it's a simplification: 1. No Python code would have to be made more complicated because of the change. 2. There would be no need to find workarounds, like cStringIO, for the fact that strings and tuples are immutable. 3. You would be able to put any kind of object into a set, or use it as a dict key. 4. Classes (like the graph example) would be able to give users things without having to make a choice between risking their users with strange bugs, making a complicated interface, making very inefficient methods, and writing complicated wrapper classes. I will ask you: Is this a complication? The answer is: it requires a significent change of the CPython implementation. But about the Python language: it's definitely a simplification. Let us pause for a second and consider: Original PEP proposed 1 new method: __freeze__, which could be implemented as a subclass of the original object (now), and integrated into the original classes as time goes on. One could /register/ __freeze__ functions/methods a'la Pickle, at which point objects wouldn't even need a native freeze method. Your suggestion offers 2 new methods along with 2 new instance variables. Let's see, a callback handler, __freeze__, the cache, and the callback list. Doesn't that seem a little excessive to you to support freezing? It does to me. If Guido were to offer your implementation of freeze, or no freeze at all, I would opt for no freeze, as implementing your freeze on user-defined classes would be a pain in the ass, not to mention implementing them in C code would be more than I would care to do, and more than I would ask any of the core developers to work on. As I said above: this suggestion would certainly require more change in the Python implementation than your suggestion. But the Python language would gain a lot more. Implementing my frozen on user-defined classes would not be a pain
Re: [Python-Dev] a different kind of reduce...
On 11/1/05, Reinhold Birkenfeld [EMAIL PROTECTED] wrote: Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) And we have solved the map, filter and reduce are going away! Let's all weep together problem with one strike! Reinhold I have no problems with map and filter goint away. About reduce - please remember that you need to add this method to any callable, including every type (I mean the constructor). I am not sure it is a good trade for throwing away one builting, which is a perfectly reasonable function. Noam ___ 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] a different kind of reduce...
Reinhold Birkenfeld wrote: Raymond Hettinger wrote: [Martin Blais] I'm always--literally every time-- looking for a more functional form, something that would be like this: # apply dirname() 3 times on its results, initializing with p ... = repapply(dirname, 3, p) [Greg Ewing] Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) And we have solved the map, filter and reduce are going away! Let's all weep together problem with one strike! not really, those right now work with any callable, class C: ... def __call__(self, x): ... return 2*x ... map(C(), [1,2,3]) [2, 4, 6] that's why attaching functionaliy as methods is not always the best solution. regards. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python-dev sprint at PyCon
amk Every PyCon has featured a python-dev sprint. For the past few amk years, hacking on the AST branch has been a tradition, but we'll amk have to come up with something new for this year's conference... This is just a comment from the peanut gallery, as it's highly unlikely I'll be in attendance, but why not continue with the AST theme? Instead of working on the AST branch, you could start to propagate the AST representation around. For example, you could use the new AST code to improve/extend/rewrite the optimization steps the compiler currently performs. Another alternative would be to rewrite Pychecker (or Pychecker 2) to operate from the AST representation. Skip ___ 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] apparent ruminations on mutable immutables (was:PEP 351, the freeze protocol)
Noam, There's a simple solution to all this - write a competing PEP. One of the two competing PEPs may be accepted. FWIW, I'm +1 on PEP 351 in general, and -1 on what you've proposed. PEP 351 is simple to explain, simple to implement and leaves things under the control of the developer. I think there are still some issues to be resolved, but the basic premise is exactly what I would want of a freeze protocol. Tim Delaney ___ 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] apparent ruminations on mutable immutables (was: PEP 351, the freeze protocol)
That's fine. I wish that you read my answer, think about it a little, and just tell me in a yes or a no if you still consider it dead. I think that I have answered all your questions, and I hope that at least others would be convinced by them, and that at the end my suggestion would be accepted. I still consider it dead. If the implementation is hard to explain, it's a bad idea. Also, not all user-defined classes have a __dict__, and not all user-defined classes can have arbitrary attributes added to them. c class foo(object): ... __slots__ = ['lst'] ... def __init__(self): ... self.lst = [] ... a = foo() a.bar = 1 Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'foo' object has no attribute 'bar' - Josiah ___ 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] a different kind of reduce...
Reinhold Birkenfeld wrote: And we have solved the map, filter and reduce are going away! Let's all weep together problem with one strike! I'm not sure if you're wildly enthusiastic, or very sarcastic. I'm not sure which I should be either ... The thought does appeal to me - especially func.partial(args). I don't see any advantage to func.map(args) over func(*args), and it loses functionality in comparison with map(func, args) (passing the function as a separate reference). Tim Delaney ___ 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 328 - absolute imports (python-dev sprint at PyCon)
Guido van Rossum wrote: On 11/1/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 10:22 AM 11/1/2005 -0700, Guido van Rossum wrote: * PEP 328 - absolute/relative import I assume that references to 2.4 in that PEP should be changed to 2.5, and so on. For the part that hasn't been implemented yet, yes. It also appears to me that the PEP doesn't record the issue brought up by some people about the current absolute/relative ambiguity being useful for packaging purposes. i.e., being able to nest third-party packages such that they end up seeing their dependencies, even though they're not installed at the root package level. For example, I have a package that needs Python 2.4's version of pyexpat, and I need it to run in 2.3, but I can't really overwrite the 2.3 pyexpat, so I just build a backported pyexpat and drop it in the package, so that the code importing it just ends up with the right thing. Of course, that specific example is okay since 2.3 isn't going to somehow grow absolute importing. :) But I think people brought up other examples besides that, it's just the one that I personally know I've done. I guess this ought to be recorded. :-( The issue has been beaten to death and my position remains firm: rather than playing namespace games, consistent renaming is the right thing to do here. This becomes a trivial source edit, which beats the problems of debugging things when it doesn't work out as expected (which is very common due to the endless subtleties of loading multiple versions of the same code). Just for reference, may I remind you of this thread last year: http://mail.python.org/pipermail/python-dev/2004-September/048695.html The PEP's timeline should be updated accordingly. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 01 2005) 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] a different kind of reduce...
Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote: Reinhold Birkenfeld wrote: And we have solved the map, filter and reduce are going away! Let's all weep together problem with one strike! I'm not sure if you're wildly enthusiastic, or very sarcastic. I'm not sure which I should be either ... The thought does appeal to me - especially func.partial(args). I don't see any advantage to func.map(args) over func(*args), and it loses functionality in comparison with map(func, args) (passing the function as a separate reference). I was under the impression that: fcn.old builtin name(...) would perform equivalently as old builtin name(fcn, ...) does now. So all the following would be equivalent... func.map(args) map(func, args) [func(i) for i in args] Me, I still use map, so seeing it as fcn.map(...) instead of map(fcn,...) sounds good to me...though it does have the ugly rub of suggesting that None.map/filter should exist, which I'm not really happy about. In regards to the instance __call__ method, it seems reasonable to require users to implement their own map/filter/reduce call. - Josiah ___ 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] apparent ruminations on mutable immutables (was: PEP 351, the freeze protocol)
On 11/1/05, Josiah Carlson [EMAIL PROTECTED] wrote: ... I still consider it dead. If the implementation is hard to explain, it's a bad idea. It is sometimes true, but not always. It may mean two other things: 1. The one trying to explain is not talented enough. 2. The implementation is really not very simple. A hash table, used so widely in Python, is really not a simple idea, and it's not that easy to explain. Also, not all user-defined classes have a __dict__, and not all user-defined classes can have arbitrary attributes added to them. c class foo(object): ... __slots__ = ['lst'] ... def __init__(self): ... self.lst = [] ... a = foo() a.bar = 1 Traceback (most recent call last): File stdin, line 1, in ? AttributeError: 'foo' object has no attribute 'bar' It doesn't matter. It only means that the implementation would have to make frozen copies also of __slots__ items, when freezing a user-defined class. I am afraid that this question proves that I didn't convey my idea to you. If you like, please forgive my inability to explain it clearly, and try again to understand my idea, by going over what I wrote again, and thinking on it. You can also wait for the PEP that I intend to write. And you can also forget about it, if you don't want to bother with it - you've already helped a lot. Noam ___ 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] a different kind of reduce...
[Greg Ewing] Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 [Raymond Hettinger] Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) Sorry to rain on everybody's parade, but I don't think so. There are many different types of callables. This stuff would only work if they all implemented the same API. That's unlikely to happen. A module with functions to implement the various functional operations has much more potential. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] a different kind of reduce...
On 1 nov 2005, at 22.40, Guido van Rossum wrote: [Greg Ewing] Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 [Raymond Hettinger] Hmm, using the function's own namespace is an interesting idea. It might also be a good place to put other functionals: results = f.map(data) newf = f.partial(somearg) Sorry to rain on everybody's parade, but I don't think so. There are many different types of callables. This stuff would only work if they all implemented the same API. That's unlikely to happen. A module with functions to implement the various functional operations has much more potential. Perhaps then a decorator that uses these functions? //Simon ___ 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
