Re: [Python-Dev] StreamHandler eating exceptions
Gustavo Niemeyer niemeyer.net> writes: > > The StreamHandler available under the logging package is currently > catching all exceptions under the emit() method call. In the > Handler.handleError() documentation it's mentioned that it's > implemented like that because users do not care about errors > in the logging system. > > I'd like to apply the following patch: [patch snipped] > Anyone against the change? > Good idea. I've checked into svn a patch for both logging/__init__.py and logging/handlers.py which raises both KeyboardInterrupt and SystemExit raised during emit(). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] StreamHandler eating exceptions
I wonder if, once PEP 352 is accepted, this shouldn't be changed so that there is only one except clause instead of two, and it says "except Exception:". This has roughly the same effect as the proposed (and already applied) patch, but does it in a Python-3000-compatible way. ATM it is less robust because it doesn't catch exceptions that don't derive from Exception -- but in all cases where this particular try/except has saved my butt (yes it has! multiple times! :-), the exception thrown was a standard exception. (Did anybody else notice the synchronicity of this request with the PEP 352 discussion?) On 10/31/05, Vinay Sajip <[EMAIL PROTECTED]> wrote: > Gustavo Niemeyer niemeyer.net> writes: > > > > > The StreamHandler available under the logging package is currently > > catching all exceptions under the emit() method call. In the > > Handler.handleError() documentation it's mentioned that it's > > implemented like that because users do not care about errors > > in the logging system. > > > > I'd like to apply the following patch: > [patch snipped] > > Anyone against the change? > > > > Good idea. I've checked into svn a patch for both logging/__init__.py and > logging/handlers.py which raises both KeyboardInterrupt and SystemExit raised > during emit(). > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
Adam Olsen wrote: > On 10/30/05, François Pinard <[EMAIL PROTECTED]> wrote: > >>All development is done in house by French people. All documentation, >>external or internal, comments, identifier and function names, >>everything is in French. Some of the developers here have had a long >>programming life, while they only barely read English. It is surely >>a constant frustration, for some of us, having to mangle identifiers by >>ravelling out their necessary diacritics. It does not look good, it >>does not smell good, and in many cases, mangling identifiers >>significantly decreases program legibility. > > > Hear, hear! Not all the world uses english, and restricting them to > latin characters simply means it's not readable in any language. It > doesn't make it any more readable for those of us who only understand > english. > > +1 on internationalized identifiers. > While I agree with the sentiments expressed, I think we should not underestimate the practical problems that moving away fr Therefore, if such steps are really going to be considered, I would really like to see them introduced in such a way that no breakage occurs for existing users, even the parochial ones who feel they (and their programs) don't need to understand anything but ASCII. If this means starting out with the features conditionally compiled, despite the added cost of the #ifdefs that would thereby be engendered I think that would be a good idea. We can fix their programs by making Unicode the default string type, but it will take much longer to fix their thinking. 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
Josiah Carlson wrote: [...] >>Perhaps I didn't make it clear. The difference between wxPython's Grid >>and my table is that in the table, most values are *computed*. This >>means that there's no point in changing the values themselves. They >>are also used frequently as set members (I can describe why, but it's >>a bit complicated.) > > > Again, user semantics. Tell your users not to modify entries, and/or > you can make copies of objects you return. If your users are too daft > to read and/or follow directions, then they deserve to have their > software not work. > That sounds like a "get out of jail free" card for Microsoft and many other software vendors ... 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
On 10/31/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > > It allows everything in Python to be both mutable and hashable, > > I don't understand, since it's already the case. Any user-defined object > is at the same time mutable and hashable. By default, user-defined objects are equal iff they are the same object, regardless of their content. This makes mutability a non-issue. If you want to allow different objects be equal you need to implement a consistent equality operator (commutative, etc), a consistent hash function and ensure that any attributes affecting equality or hash value are immutable. If you fail to meet any of these requirements and put such objects in dictionaries or sets it will result in undefined behavior that may change between Python versions and implementations. Oren ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] i18n identifiers (was: Divorcing str and unicode (no more implicit conversions).
Steve Holden wrote: > Therefore, if such steps are really going to be considered, I would > really like to see them introduced in such a way that no breakage occurs > for existing users, even the parochial ones who feel they (and their > programs) don't need to understand anything but ASCII. It is straight-forward to make this feature completely backwards compatible. Syntactically, it is a pure extension: existing code will continue to work unmodified, and will continue to have the same meaning. With the feature, you will be able to write code that previously produced SyntaxErrors. Semantically, the only potential incompatibility is that you might find Unicode strings in __dict__. If purely-ASCII identifiers are going to be represented by byte strings (as they are now), no change in meaning for existing code is anticipated. So it is not necessary to make the feature conditional to preserve compatibility. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] i18n identifiers
Martin v. Löwis wrote: > Steve Holden wrote: > >>Therefore, if such steps are really going to be considered, I would >>really like to see them introduced in such a way that no breakage occurs >>for existing users, even the parochial ones who feel they (and their >>programs) don't need to understand anything but ASCII. > > > It is straight-forward to make this feature completely backwards > compatible. Syntactically, it is a pure extension: existing code > will continue to work unmodified, and will continue to have the > same meaning. With the feature, you will be able to write code > that previously produced SyntaxErrors. > > Semantically, the only potential incompatibility is that you > might find Unicode strings in __dict__. If purely-ASCII identifiers > are going to be represented by byte strings (as they are now), > no change in meaning for existing code is anticipated. > > So it is not necessary to make the feature conditional to preserve > compatibility. If people are really all enthusiastic about such a feature, then it should happen in Python3k when the parser is rewritten to work on Unicode natively. Note that if you start with this now, a single module in your application using Unicode identifiers could potentially break the application: simply by the fact that stack frames, tracebacks and module globals would now contain Unicode. Any processing done on the identifiers, like e.g. error formatting would then have to deal with Unicode objects (due to the automatic conversion). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 31 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] a different kind of reduce...
Hi I find myself occasionally doing this: ... = dirname(dirname(dirname(p))) 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) There is a way to hack something like that with reduce, but it's not pretty--it involves creating a temporary list and a lambda function: ... = reduce(lambda x, y: dirname(x), [p] + [None] * 3) Just wondering, does anybody know how to do this nicely? Is there an easy form that allows me to do this? cheers, ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 352 Transition Plan
I've made a final pass over PEP 352, mostly fixing the __str__, __unicode__ and __repr__ methods to behave more reasonably. I'm all for accepting it now. Does anybody see any last-minute show-stopping problems with it? As always, http://python.org/peps/pep-0352.html -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
Hello, I have slept quite well, and talked about it with a few people, and I still think I'm right. About the users-changing-my-internal-data issue: > Again, user semantics. Tell your users not to modify entries, and/or > you can make copies of objects you return. If your users are too daft > to read and/or follow directions, then they deserve to have their > software not work. ... > When someone complains that something doesn't work, I tell them to read > the documentation. If your users haven't been told to RTFM often enough > to actually make it happen, then you need a RTFM-bat. Want to know how > you make one? You start wrapping the objects you return which segfaults > the process if they change things. When they start asking, tell them it > is documented quite clearly "do not to modify objects returned, or else". > Then there's the other option, which I provide below. I disagree. I read the manual when I don't know what something does. If I can guess what it does (and this is where conventions are good), I don't read the manual. And let's say I ought to read the complete manual for every method that I use, and that I deserve a death punishment (or a segmentation fault) if I don't. But let's say that I wrote a software, without reading the manual, and it worked. I have gone to work on other things, and suddenly a bug arises. When the poor guy who needs to fix it goes over the code, everything looks absolutely correct. Should he also read the complete manuals of every library that I used, in order to fix that bug? And remember that in this case, the object could have traveled between several places (including functions in other libraries), before it was changed, and the original data structure starts behaving weird. You suggest two ways for solving the problem. The first is by copying my mutable objects to immutable copies: > Also from the sounds of it, you are storing both source and destination > values in the same table...hrm, that sounds quite a bit like a > spreadsheet. How does every spreadsheet handle that again? Oh yeah, > they only ever store immutables (generally strings which are interpreted). > But I suppose since you are (of course) storing mutable objects, you > need to work a bit harder...so store mutables, and return immutable > copies (which you can cache if you want, and invalidate when your > application updates the results...like a wx.Grid update on changed). This is basically ok. It's just that in my solution, for many objects it's not necessary to make a complete copy just to prevent changing the value: Making frozen copies of objects which can't reference nonfrozen objects (sets, for example), costs O(1), thanks to the copy-on-write. Now, about the graph: > So let me get this straight: You've got a graph. You want to be able to > change the graph, but you don't want your users to accidentally change > the graph. Sounds to me like an API problem, not a freeze()/mutable problem. > Want an API? > > class graph: >... >def IterOutgoing(self, node): >... >def IterIncoming(self, node): >... >def IsAdjacent(self, node1, node2): >... >def IterNodes(self): >... >def AddEdge(self, f_node, t_node): >... >def RemEdge(self, node1, node2): >... >def AddNode(self): >... > > If you are reasonable in your implementation, all of the above > operations can be fast, and you will never have to worry about your > users accidentally mucking about with your internal data structures: > because you aren't exposing them. If you are really paranoid, you can > take the next step and implement it in Pyrex or C, so that only a > malicous user can muck about with internal structures, at which point > you stop supporting them. This will work. It's simply... well, not very beautiful. I have to invent a lot of names, and my users need to remember them all. If I give them a frozen set, with all the vertices than a vertex points to (which is an absolutely reasonable API), they will know how to deal with it without learning a lot of method names, thanks to the fact that they are already familiar with sets, and that a lot of thought has gone into the set interface. > > Now, about copy-on-write: ... > > What you have written here is fairly unintelligible, but thankfully you > clarify yourself...pity it still doesn't work, I explain below. I'm sorry if I am sometimes hard to understand. English is not my mother tongue, and it degrades as the hour gets later - and sometimes, things are hard to explain. If I don't explain myself, please say so and I'll try again. This is an excellent example - I wrote about callbacks, and went to sleep. Let me try to explain again how it *does* work. The frozen() function, and the __frozen__ protocol, would get another optional argument - an object to be notified when the *nonfrozen* object has changed. It may be called at most once - only on the first change to the object, and only
Re: [Python-Dev] a different kind of reduce...
On Mon, Oct 31, 2005, Martin Blais wrote: > > There is a way to hack something like that with reduce, but it's not > pretty--it involves creating a temporary list and a lambda function: > > ... = reduce(lambda x, y: dirname(x), [p] + [None] * 3) > > Just wondering, does anybody know how to do this nicely? Is there an > easy form that allows me to do this? This should go on comp.lang.python. Thanks. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
Steve Holden <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > [...] > >>Perhaps I didn't make it clear. The difference between wxPython's Grid > >>and my table is that in the table, most values are *computed*. This > >>means that there's no point in changing the values themselves. They > >>are also used frequently as set members (I can describe why, but it's > >>a bit complicated.) > > > > Again, user semantics. Tell your users not to modify entries, and/or > > you can make copies of objects you return. If your users are too daft > > to read and/or follow directions, then they deserve to have their > > software not work. > > > That sounds like a "get out of jail free" card for Microsoft and many > other software vendors ... If/when vendors are COMPLETE in their specifications and documentation, they can have that card, but being that even when they specify such behaviors they are woefully incomplete, there is not a card to be found, and I stand by my opinion. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
Noam Raphael <[EMAIL PROTECTED]> wrote: > Hello, > > I have slept quite well, and talked about it with a few people, and I > still think I'm right. And I'm going to point out why you are wrong. > About the users-changing-my-internal-data issue: > > > Again, user semantics. Tell your users not to modify entries, and/or > > you can make copies of objects you return. If your users are too daft > > to read and/or follow directions, then they deserve to have their > > software not work. > ... > > When someone complains that something doesn't work, I tell them to read > > the documentation. If your users haven't been told to RTFM often enough > > to actually make it happen, then you need a RTFM-bat. Want to know how > > you make one? You start wrapping the objects you return which segfaults > > the process if they change things. When they start asking, tell them it > > is documented quite clearly "do not to modify objects returned, or else". > > Then there's the other option, which I provide below. > > I disagree. I read the manual when I don't know what something does. > If I can guess what it does (and this is where conventions are good), > I don't read the manual. And let's say I ought to read the complete > manual for every method that I use, and that I deserve a death > punishment (or a segmentation fault) if I don't. But let's say that I > wrote a software, without reading the manual, and it worked. I have > gone to work on other things, and suddenly a bug arises. When the poor > guy who needs to fix it goes over the code, everything looks > absolutely correct. Should he also read the complete manuals of every > library that I used, in order to fix that bug? And remember that in > this case, the object could have traveled between several places > (including functions in other libraries), before it was changed, and > the original data structure starts behaving weird. 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. > 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. [snip graph API example] > This will work. It's simply... well, not very beautiful. I have to > invent a lot of names, and my users need to remember them all. If I > give them a frozen set, with all the vertices than a vertex points to > (which is an absolutely reasonable API), they will know how to deal > with it without learning a lot of method names, thanks to the fact > that they are already familiar with sets, and that a lot of thought > has gone into the set interface. I never claimed it was beautiful, I claimed it would work. And it does. There are 7 methods, which you can reduce if you play the special method game: RemEdge -> __delitem__((node, node)) RemNode -> __delitem__(node) #forgot this method before IterNodes -> __iter__() IterOutgoing,IterIncoming -> IterAdjacent(node) In any case, whether you choose to use freeze, or use a different API, this particular problem is solvable without copy-on-write semantics. > > > > Now, about copy-on-write: > ... > > > > What you have written here is fairly unintelligible, but thankfully you > > clarify yourself...pity it still doesn't work, I explain below. > > I'm sorry if I am sometimes hard to understand. English is not my > mother tongue, and it degrades as the hour gets later - and sometimes, > things are hard to explain. If I don't explain myself, please say so > and I'll try again. This is an excellent example - I wrote about > callbacks, and went to sleep. Let me try to explain again how it > *does* work. Thank you for the clarification (btw, your english is far better than any of the foreign languages I've been "taught" over the years). > This is not so. When a list creates its frozen copy, it gives itself > to all those frozen() calls. This means that it will be notified if > one of its members is changed. In that case, it has to do two simple > actions: 1. release the reference to its frozen copy, so that > subsequent freezes of the list would create a new frozen copy, and: 2. > notify about the change any object which froze the list and requested > notification. > > This frees us of any validation code. If we haven't been notified > about a change, there was no change, and the frozen copy is valid. > > In case you ask, the cost of notification is O(1), amortized. The > reason is that every frozen() call can cause at most one callback in > the future. Even without validation, there are examples that for
Re: [Python-Dev] PEP 351, the freeze protocol
On 10/31/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: ... > And I'm going to point out why you are wrong. I still don't think so. I think that I need to reclarify what I mean. > > 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. > > > 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. ... > I never claimed it was beautiful, I claimed it would work. And it does. > There are 7 methods, which you can reduce if you play the special method > game: > > RemEdge -> __delitem__((node, node)) > RemNode -> __delitem__(node) #forgot this method before > IterNodes -> __iter__() > IterOutgoing,IterIncoming -> IterAdjacent(node) > I just wanted to say that this game is of course a lot of fun, but it doesn't simplify the interface. > 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. > > > > Now, about copy-on-write: > > ... > Thank you for the clarification (btw, your english is far better than > any of the foreign languages I've been "taught" over the years). Thanks! It seems that if you are forced to use a language from time to time it improves a little... ... > 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. Why it's ok to analyze only that limited case? I am suggesting a change in Python: that every object you would like be mutable, and would support the frozen() protocol. When you evaluate my suggestion, you need to take a program, and measure its performance in the current Python and in a Python which implements my suggestion. This means that the program should work also on the current Python. In that case, my assumption is true - you won't change objects after you have frozen them, simply because these objects (strings which are used as dict keys, for example) can't be changed at all in the current Python implementation! I will write it in another way: I am proposing a change that will make Python objects, including strings, mutable, and gives you other advantages as well. I claim that it won't make existing Python programs run slower in O() terms. It would allow you to do many things that you can't do today; some of them would be fast, like editing a string, and some of them would be less fast - for example, repeatedly changing an object and freezing it. I think that the performance penalty may be rather small - remember that in programs which do not change strings, there would never be a need to copy the string data at all. And since I think that usually most of the dict lookups are for method or function names, there would almost never be a need to constuct a new object on dict lookup, because you search for the same names ag
Re: [Python-Dev] a different kind of reduce...
On 10/31/05, Martin Blais <[EMAIL PROTECTED]> wrote:
> 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)
[...]
> Just wondering, does anybody know how to do this nicely? Is there an
> easy form that allows me to do this?
FWIW, something like this works:
>>> def fpow(f, n):
... def res(*args, **kw):
... nn = n
... while nn > 0:
... args = [f(*args, **kw)]
... kw = {}
... nn -= 1
... return args[0]
... return res
...
>>> fn = r'a\b\c\d\e\f\g'
>>> d3 = fpow(os.path.dirname, 3)
>>> d3(fn)
'a\\b\\c\\d'
You can vary this a bit - the handling of keyword arguments is an
obvious place where I've picked a very arbitrary approach - but you
get the idea. This *may* be a candidate for addition to the new
"functional" module, but I'd be surprised if it got added without
proving itself "in the wild" first. More likely, it should go in a
local "utilities" module.
Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 351, the freeze protocol
I thought about something - > > I think that the performance penalty may be rather small - remember > that in programs which do not change strings, there would never be a > need to copy the string data at all. And since I think that usually > most of the dict lookups are for method or function names, there would > almost never be a need to constuct a new object on dict lookup, > because you search for the same names again and again, and a new > object is created only on the first frozen() call. You might even gain > performance, because s += x would be faster. > Name lookups can take virtually the same time they take now - method names can be saved from the beginning as frozen strings, so finding them in a dict will take just another bit test - is the object frozen - before doing exactly what is done now. Remember, the strings we are familiar with are simply frozen strings... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
Help! What's the magic to get $Revision$ and $Date$ to be expanded upon checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the latter has the svn revision and date in the headers, while the former still has Brett's original revision 1.5 and a date somewhere in June. I tried to fix this by rewriting the fields as $Revision$ and $Date$ but that doesn't seem to make a difference. Googling for this is a bit tricky because Google collapses $Revision and Revision, which makes any query for svn and $Revision rather non-specific. :-( It's also not yet in our Wiki. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
[Guido] > Help! > > What's the magic to get $Revision$ and $Date$ to be expanded upon > checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the > latter has the svn revision and date in the headers, while the former > still has Brett's original revision 1.5 and a date somewhere in June. > I tried to fix this by rewriting the fields as $Revision$ and $Date$ > but that doesn't seem to make a difference. > > Googling for this is a bit tricky because Google collapses $Revision > and Revision, which makes any query for svn and $Revision rather > non-specific. :-( It's also not yet in our Wiki. You have to set the `svn:keywords` property on each file for which you want these kinds of expansions: http://svnbook.red-bean.com/en/1.0/ch07s02.html#svn-ch-7-sect-2.3.4 Use svn propedit svn:keywords path/to/file to set that property to what you want. Looking at your examples, C:\Code>svn proplist -v http://svn.python.org/projects/peps/trunk/pep-0343.txt Properties on 'http://svn.python.org/projects/peps/trunk/pep-0343.txt': svn:keywords : Author Date Id Revision svn:eol-style : native So that has svn:keywords set, and expansion occurs. OTOH, C:\Code>svn proplist -v http://svn.python.org/projects/peps/trunk/pep-0352.txt Nada -- that one doesn't even have svn:eol-style set. See http://wiki.python.org/moin/CvsToSvn section "File Modes" for how to convince SVN to automatically set the properties you want on new files you commit (unfortunately, each developer has to do this in their own SVN config file). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
[Guido van Rossum] >What's the magic to get $Revision$ and $Date$ to be expanded upon >checkin? Expansion does not occur on checkin, but on checkout, and even then, only in your copy -- that one you see (the internal Subversion copy is untouched). You have to edit a property for the file where you want substitutions. That property is named "svn:keywords" and its value decides which kind of substitution you want to allow. This is all theory for me, I never used them. -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Freezing the CVS on Oct 26 for SVN switchover
Guido van Rossum wrote: >Help! > >What's the magic to get $Revision$ and $Date$ to be expanded upon >checkin? Comparing pep-0352.txt and pep-0343.txt, I noticed that the >latter has the svn revision and date in the headers, while the former >still has Brett's original revision 1.5 and a date somewhere in June. >I tried to fix this by rewriting the fields as $Revision$ and $Date$ >but that doesn't seem to make a difference. > >Googling for this is a bit tricky because Google collapses $Revision >and Revision, which makes any query for svn and $Revision rather >non-specific. :-( It's also not yet in our Wiki. > > It's an svn property associated with the file. The property name is svn:keywords, and the value is a space separated list of keywords you'd like to have substituted. Like this: svn propset svn:keywords "Date Revision" ...file list... The list of keywords it will handle is LastChangedDate (or Date) LastChangedRevision (or Revision or Rev) LastChangedBy (or Author) HeadURL (or URL) Id Gary Herron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
François Pinard wrote: > All development is done in house by French people. All documentation, > external or internal, comments, identifier and function names, > everything is in French. There's nothing stopping you from creating your own Frenchified version of Python that lets you use all the characters you want, for your own in-house use. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a different kind of reduce...
Martin Blais wrote: > 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) Maybe ** should be defined for functions so that you could do things like up3levels = dirname ** 3 -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Divorcing str and unicode (no more implicit conversions).
[Greg Ewing] >> All development is done in house by French people. All documentation, >> external or internal, comments, identifier and function names, >> everything is in French. > There's nothing stopping you from creating your own Frenchified > version of Python that lets you use all the characters you want, for > your own in-house use. No doubt that we, you and me and everybody, could all have our own little version of Python. :-) To tell all the truth, the very topic of your suggestion has already been discussed in-house already, and the decision has been to stick to Python mainstream. We could not justify to our administration that we start modifying our sources, in such a way that we ought to invest maintainance each time a new Python version appears, forever. On the other hand, we may reasonably guess that many people in this world would love being as comfortable as possible using Python, while naming identifiers naturally. It is not so unreasonable that we keep some _hope_ that Guido will soon choose to help us all, not only me. -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
